Develop Reference

Java, Codename One: Exporting and -most importantly- importing files between users

Here the problem: my app will generate some files, and I want to give to the users the opportunity to exchange these files between them.
This requires 3 steps:
Saving the data: easily done in Storage implementing the
functions required by the Externalizable class;
Sharing the data: done (probably, right now it's impossible to check if the
result is correct because the missing step 3) with the sharing
methods offered by the framework, as soon as I understood I needed
to use as mimetype "application/octect-stream";
importing the downloaded data (shared by another user): this one I can't manage to
find a way to make it work. Loading the files from the app's Storage
is easy, but accessing to the folders out of the app's Storage is
something I can't manage to do.
I used FileSystemStorage in the hope of gaining access at least to the Download folder that (mostly) every phone has, but apparently I can't manage to accomplish the task
Using the FileSystemStorage on Android, for example, I have access to
/storage/emulated/0
/storage/emulated/legacy
file:///system
The first two being related to the Storage of the app.
Acceding to file:/// I obtain a long list of folders, a partial list including
media
logs
sdcard
Removable
...
root
...
But when I try to access some of these, they all appear to be empty. Either I make some mistake or the app can't see their content.
So I wonder if there is a way to accomplish the task, namely to have access to the files (probably in the Download folder) the user has downloaded, to import them.

Phone apps live in isolation within the phone. Android literally creates a separate Linux user for every app so they don't step on each other and damage the phone. iOS does similar tricks.
As a result apps can't just write a file to downloads and can't just list all the files there. This would violate the users privacy. So the native API to share a file is usually separate from the files API. We do have a share API in the CN class which lets you share images etc. to an arbitrary OS app. See isNativeShareSupported and share.

Ok, maybe I found a solution for reading the files from the Download folder in an extension of CodenameOne called FileChooser.
According to this blog post it should give access to, between the others, the Download folder (at least in Android).
I'm going to try it and, when everything is ready and tested, edit this reply to say how it worked out for me.

Android Google Drive SDK: Saving to App Folder

For my current project, I would like to allow a user to create a sqlite database file and have them enter some content. Then the user has the option to sign into their google drive account and upload this file. Afterwards, after the user makes further edits, the new database file is uploaded to replace the old file. Finally, if the user has multiple devices, the database should be downloaded from the google drive and replace the existing file stored on the device.
Currently, I have successfully setup Google Drive SDK authentication and I can sign in to the app with my account.
My main question is, how do I upload a sqlite database file to the APP FOLDER when I choose to press a sync button? (This method should be called when the user needs to sync)
Additionally, how do I upload a sqlite database file to the APP FOLDER?

Your question is a bit broad, but I'll try to send you in the right direction.
First you have to decide if to use the REST Api or GDAA. Both will accomplish the same (actually the GDAA's functionality is a bit narrower now, but for your situation will do).
The big difference is that GDAA will handle on-line / off-line states for you, where with the REST Api, you have to implement some kind of non-UI thread (sync service) synchronization. Also, there are latency issues you must be aware when using GDAA.
Next, the process of uploading SQLite database is the same as any other binary data stream.
Grab the 'xxx.db' file, make output stream (or byte[] buffer) and create a GooDrive file with title + mimetype metadata, push the stream into it's content and send it on it's merry way. The only difference between a standard folder and an app folder is the parent of the file.
You get an ID you can subsequently use to download the file to the device. Or you can use search by metadata (title in your case) to get this ID. Again it comes as input stream and you dump it to an 'xxx.db' file on your device.
The second portion of your question deals with multiple devices. None of the apis will notify you about a change in GooDrive, so you must implement one of the 2 strategies:
1/ Polling (ouch), preferably in sync service with sync intervals the system gives you.
2/ GCM message broadcasted to the devices / users who are interested (not trivial, but efficient ... and sexy).
Another pitfall you must be aware when using multiple devices with GDAA is described in SO 29030110 and SO 22874657.
In case you decide to play with the 2 apis, I maintain basic CRUD implementation demos for both the REST and GDAA. The GDAADemo has also an option to work with the app folder.
Good Luck

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.

Android: Downloading flickr images

I have a project that I'm having trouble with (for an internship). My assignment is to create an Android app that downloads a random image from Flickr after running a search for a specified tag.
I know Flickr has an API, and I have an api key, but I'm struggling with understanding how to integrate this into an app, as it seems examples in Java are a bit sparse. Does anyone know the process of using the API to download an image after running a search? (Or if there's an easier way to do it without the API/being authenticated, that works too).
I should also mention that I can't use any external libraries.

For searching public photos you don't need to authenticate yourself with Flickr service API. First you have to register an API key for your apps, call the correct API function from the list
http://www.flickr.com/services/api/
and parse the result in format of JSON. But you can't use 3rd library in your project, you can follow this post
http://hintdesk.com/android-show-images-from-flickr-with-imagegridview/
it uses only Android libraries.

Well I can feel the difficulty of doing this w/o the so sweet and easy Flickrj-Android or Flickr4Java :)
The method you need is flickr.photos.getSizes.
Returns the available sizes for a photo. The calling user must have permission to view the photo.
You do not need to authenticate your API key if you do not want to download non-public photos.
Just get the wanted photo-id with a simple search (flickr.photos.search) and download the wanted photo with a simple URL file stream.
The returned data has the wanted download URL. So just run a parser and download away.

Verify Files in Local Machine is Up to Date with Dropbox server

I am developing a java app. i want to add feature to my app for verify files in my local dropbox folder is match with the files in dropbox server. how could i check my local dropbox folder is up to date ?
i found this on dropbox api. https://www.dropbox.com/developers/reference/api#delta
but haven't idea about how to use it.

The /delta call is the best way to keep your app's state up to date with Dropbox (as long as you're interested in more than just one file or folder.) You've already found the docs:
https://www.dropbox.com/developers/reference/api#delta
There are also two posts with some notes from the beta period:
https://www.dropbox.com/developers/announcements/15
https://www.dropbox.com/developers/announcements/16
You can find the Java SDK here:
https://www.dropbox.com/developers/reference/sdk
Inside the Java SDK, you'll find a working example app that uses /delta, named "SearchCache".
While the above resources will do a much better job explaining /delta, the basic idea is that when you first call it, you get the state of the Dropbox account, and on all subsequent calls, you get the "delta" of what you need to know to get up to date.