Develop Reference

Sonarqube - How to exchange data with Compute Engine MeasureComputer implementation from Sensor

I am working on implementing SonarQube plugin for a custom platform specific language. The documentation is very limited and any code examples I see are outdated - usage of Decorators instead of MeasureComputer etc. I went through the sample plugin but it does not have the context I am looking for. My question is - how do I exchange the data between the Sensor and MeasureComputer implementation. The plugin invokes a command-line (vendor specific and I cannot change) that writes the data to a file. I would like the data from this file displayed in the General Metrics screen. In Sensor execute method, I am able to parse the file but I cannot save the Measure as the API has changed now and requires me to save the Measure with .on method that requires an InputFile, but this data is on the entire project and not on a file. I am not able to do a simple save of Metric on the project. I tried using MeasureComputer implementation, but I understand that this runs in Background task on server side, so I thought of setting the property under context.settings.setString("propName", "value") and tried retriving it using (MeasureComputerContext) context.getSettings().getString("propName"). This is not working either.
Can I save a Metric on the context that can be displayed in General inside a Sensor on the project and not the resource in 5.6.6 version. If so how?
If above is not possible, how can I store the file content to exchange with MeasureComputer, either add to list of files or set the property or object to be retrieved in MeasureComputer.
Thanks in Advance for your help. I have spent considerable time on this and the documentation leaves a lot to figure out.

For anyone else ending up here, looking for an answer, see the answer posted by Julien Henry on Google Groups here - https://groups.google.com/d/msg/sonarqube/yWsp7vuIsSo/ZugXMkp8CwAJ. Essentially, you can set the property at module level using .on(context.module()) and use it in Compute Engine.

Delete / trash file from android using android.gms.drive

I need to delete files from Google Drive using com.google.android.gms.drive. From what I've read here and across the web there is no support for file deletion in the "new API". Is that (still) correct? I mean the API isn't that new anymore ...
I also read about the "clear contents and forget"-strategy, but I'd like not to follow that approach.
Part 2 of the question: Given it's still impossible to delete files via the API mentioned above; is there any easy way to combine the REST API w/ the code I've already written? Something like
get token from GoogleApiClient
fire DELETE request w/ token and file id
???
profit
edit: The new Google Play Services (version 7.0.0 / March 2015) finally features a trash() method. See https://developer.android.com/reference/com/google/android/gms/drive/DriveResource.html for further details.
.
edit2: Apparently you cannot use trash() on files from the app folder: Cannot trash App Folder or files inside the App Folder. :((
edit3: As of May 28th, it's now possible to actually delete files.

UPDATE (May 2015)
Addition of trash / delete functionality to GDAA 7.5 renders the answer below irrelevant.
ORIGINAL ANSWER:
The sequence is:
Get DriveId from GDAA (file or folder)
Get ResourceId from DriveId.getResourceId() (may be null if file/folder is not committed yet)
use ResourceId (rsid) in this REST call:
com.google.api.services.drive.Drive.files().trash(rsid).execute()
com.google.api.services.drive.Drive.files().delete(rsid).execute()
finally realize that you can't do it since you'll see the file in GDAA long after it has been deleted / trashed. You can even write in it, create files in that folder you've just trashed, ... That's why people introduced the "clear contents and forget" strategy nobody likes.
Needless to say, this applies to any delete / trash action you may perform outside of GDAA universe (manually trash/delete using web interface etc...)
So, to wrap it up. 'pinoyyid' is right, each of the APIs is different and the GDAA can not replace the REST (yet). You'll quickly realize it when you try to work a little deeper, like getting thumbnail url, fighting latency issues etc... On the other hand GDAA has advantages, since it can work off-line without your app handling it. When using REST, your app should do all the Drive calls in some kind of sync service to separate your UI actions from network issues (delays, off-line, ...). GDAA handles this for you, but on it's own timing terms. And with no delete functionality.
I put a piece of code on github, that has both these API's used side-by-side and you may use it to play with different scenarios before committing yourself to one of them.
It would be nice to hear clearly from Google what the final strategy is, i.e.
Is GDAA going to replace REST one day, after all the REST functionality is in?
Will they retire the REST afterwards?
Good Luck

Delete is supported by the Google Drive Android API as of Google Play services 7.5 using the DriveResource.delete() method.
Delete is permanent, and recommended only for App Folder content, where trash is not available.

Passing java query result to fields / UCanAccess Compatibility

I have really low knowledge on Java and JasperReports, barely used those to play around, nothing too serious. A friend of mine has been trying to get someone to develop him an application that will generate PDFs with information from an access database for each of his clients, however, after 6 months and 7 developers who ditched him, he has found none, so he asked me if I could help him to which I said I'd give it a try.
What I have been able to do so far:
So far I've managed to successfully (Everything has been done separately, I have like 8 projects in total so far):
Use Jaspersoft Studio/iReport to create a single PDF with the required client information on each sheet.
Create a separate JasperReports project with a input field to get a pdf with a single client information.
Create a Java App with a JFrame to launch the report generation.
Create a Java App to connect to the access database through ucanaccess and validate the search criteria
Questions:
Now, after a few days on Google up and down I havnt managed to successfully achieve everything that I'd like to achieve, and I'd love if someone could either point me into good noob-proof guides or (if willing) provide a noob-proof answer so I can continue to move on.
Create a Java App where you can choose to generate all client's report or a single report for a specified client (I am assuming this isn't too complicated since it'd just be a matter to embed both Jasper reports into the java app), however I'd need to pass the input value into jasper report field to generate a single report (Not sure if this one was clear enough), and run the query for the data-set based on that field's value.
Ideally though not highly needed, pass yet another variable as a field to set a date range.
Since this is being done on a MS Access Database -*.accdb- (Don't blame me, I've been telling him to move to MySQL/SQL for quite a while now), I'd love to know if its possible to make JasperReports do a query based on a UCanAccess JDBC connection (Tried a few options, none worked).
Finally, I need to generate in the report a date range (Something like: "Between 1/Jan/2014 and 1/Feb/2014")
I feel like I've made a decent amount of progress so far, but since I am no pro on either JasperReports nor Java, I am getting stuck in a point where more knowledge is required to create a more decent and practical piece of software and I'd love if someone could point me into a better direction (Either if something is impossible or just a few links to help me get thru)

-Remeber to add ucanaccess jar and all dependencies jars in the Driver Classpath, while creating the Data Adapter
-You have to set Showschema=true:
e.g.
jdbc:ucanaccess://c:/db/database.accdb;Showschema=true
In this way Jasper Studio will be able to navigate the metadata of your database, and you'll find your tables under the PUBLIC schema.
Then you'll be able to create your reports as usual.

Implementing a Trial

I have made an application in which I want that the application should expire after say 180 Days but the problem is that if I take the system date, anyone could just change it and get going and I cannot also take the internet date because many times the user will be working offline. So how do I make it trial after which it self destructs itself? I cannot put any other DRM as I have read that checking MAC address is a very bad DRM and after going through Making commercial Java software (DRM) I realised I have to make it somewhat simple. So the idea I have in mind is that I put a count that how many times has the application being started, but where do I store the value in registry? (I have already read: read/write to Windows Registry using Java)
I have also read Create a trial version of a Java application, with limited functionality and How to create a trial version of a Java program but the answers given there were not satisfactory. Because:
1. In one answer it is given that use "Rampart" but that is a paid application and I do not want to use it.
2. In another answer they checked with system date but as I told earlier I do not want to use that either.
3. One Question and Answer was related to functionality which is not what I want to reduce
4. and further many of them require internet but my customers may not be using it all the time
I know that there is no perfect DRM and everyone of them can be cracked. What I am asking here is what is my best shot? (Note: I have limited number of users, I will not sell this application online)
Update: This question I believe is not off topic because what I really am asking is just how do I make my software go trial... I am just asking how? I know it can be cracked easily but just tell me what is the best way to set up a trial in java

Ship a data file with the package containing:
The name of the customer in full.
The date it was shipped.
The date it should expire.
A checksum of the whole file so it cannot be edited.
Every time you run:
Check that the checksum is still valid.
Check that the file mod date does not suggest that the file has been tampered with.
Display the customer name in a splash screen.
Make sure the mod date on the file is not later than the expiry date.
"Touch" the file to make sure it's mod-date changes to current date.
Make sure the "Touch" worked.
This way:
It is difficult to make a copy as the mod date will change.
It is difficult to distribute copies to others as the source is easily available.
It should be possible to detect most inexpert tampering.
Obviously - without adding hardware - it is impossible to cover all bases but I have found this scheme works well.

If internet connection is not available, there is one method left behind if end-users are in a company network and using windows with active directory (most companies have active directory if clients are windows), use active directory server as a time server. Most users may change clock time on their client windows, but they don't want to change time on their servers due to other affecting software (mail server etc). License4J can find and check date/time on a local active directory server.
(Disclosure: I work for License4J)

Share a piece of data between several Android apps

I am writing an SDK for Android that will be used by many different apps. Each app needs to know if there is a previous installation of another app that uses the SDK; the first one will create a random id (a cookie) and store it, all later apps have to read it and reuse it. Note that the cookie will be created anew for every device.
I have searched for a long time for the answer; please read thoroughly before answering because I have read lots of different StackOverflow answers and have scoured the internet reading random blogs; I have tried a lot of things but none worked (I will save you the links).
A ContentProvider is definitely overkill. Also it needs to intrude an app's AndroidManifest.xml, something I am trying to avoid.
Likewise for a service: needs to be defined in the AndroidManifest.xml, which I do not control and do not want to require changes to.
Using external storage would perhaps be an option, but I don't want to require additional permissions.
Using SharedPreferences directly with getSharedPreferences() does not work because apps can only access their own preferences.
I can get a common preferences object using createPackageContext(package, MODE).getSharedPreferences(). This would work beautifully if I had a main package and many clients of the data, but in fact I don't know the package of the app that will be installed first -- it can be any of them. I don't even have a list of package names to search. Passing a package name which has not been installed fails.
Following the approach above, I have tried to piggyback on some standard Android app which I can count on, and store my preferences there -- say:
createPackageContext(
"com.android.browser",
Context.CONTEXT_RESTRICTED)
.getSharedPreferences(
"GLOBAL_PREFS",
Context.MODE_WORLD_READABLE);
but it does not work: the error reads
Couldn't create directory for SharedPreferences file
/data/data/com.android.browser/shared_prefs/GLOBAL_PREFS.xml
So, to recap: I need to store a piece of data (a short string) in some standard location, so that any other app can go there and read it if present, and it should work if at all possible without doing any magic in the AndroidManifest.xml or requesting any permissions.
There probably isn't any perfect answer, so perhaps the best solution is to write to external storage; then so be it. To put things into context, apparently it is trivial to do this on iOS using a keychain, designed to store secure data.

Unfortunately there really isn't a great answer for this that I know of. You've come up with a pretty good outline of your options and the best way may well be with external storage.
Just to throw something out there, I suppose it's possible you could use a flat file with a fixed name and world readable (and possibly writable) permissions. You'd have to then iterate through all applications' directories and check for this known-named file in each folder and attempt to open it.
While this might work theoretically, consider the case where the app that contains the "cookie" is uninstalled. Then you're left cookie-less. You might want to create the cookie in every app, copying over the value of the previous cookies to new cookies.
I haven't actually tried this, but I imagine it should work.