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.

what is "serviceAccountKey.json" referring to in the Firebase device-to-device notifications tutorial

I managed to go through the complete Firebase Android Codelab without too much problem, the app works perfectly. Now I would like to add device-to-device notifications. I found this tutorial:
And some things are not clear to me.
In the node script there is a line like this:
var serviceAccount = require("path/to/serviceAccountKey.json");
What is the "ServiceAccountKey.json" file? Is it just another name for google-services.json? If not, what is this?
Is there a simple "click through" tutorial how to deploy the node server code to the google environment?

In the blog post you're following, we're running the node.js script on Google Cloud's App Engine Flexible Environment using the Firebase Admin SDK. A service account is a way to give trusted processes access to Google Cloud Platform and Firebase resources.
You create a service account through the Google Cloud Console and then download the corresponding JSON file. The code in the blog post looks for that file and use it to initialize the Firebase Admin SDK.

Thanks to , and continuing on Frank's answer .. here's a few additional observations
1. serviceAccountKey.json is not the actual file name
Coming from work on the Android client side, I thought that was a fixed name the way that google-services.json is in the Android project. However, it's just a place-holder name. The file is generated with a unique name from the Google Web UI, and that is the file to apply where the place-holder is referenced.
2. You can only get the file one time
Going through the docs there, I thought maybe you can use an existing service account to get that file. However, after some looking around .. I tried creating a new one and from the dialog it gives there, the checkbox tells us you can only get that .json file one time - at time Service Account item is created.
The docs discuss creating a Service Account, but I didn't see much mention otherwise of getting that .json file.. so that's why it seemed ambigious until I saw this dialog.
3. The screen where you add a new service account
That Admin UI has a lot going on, including from the docs a variety of references to go to IAM Setup, Roles, etc.
At the risk of stating the obvious (but may help someone else arrive here faster than I did), - this was the view where I add the Service Acct and get the dialog to download the .json file.

Have a look at this comment
https://stackoverflow.com/a/49039675/2472466
in a nutshell, you generate serviceAccountKey.json file by requesting a new private key from the service accounts tab of your settings page in your Firebase dashboard.
The returned private key will be a .json file which will be your serviceAccountKey.json file ... once you rename it to be serviceAccountKey.json
the path/to/ is the directory where you store the returned json file, this directory must be within your firebase project

It's pretty confusing but firstly you'll have to generate a service account from Google IAM. Once you create the service account, right click on the three dots and select "create key". It should prompt you with JSON option. Download and store it within your project directory.

Android - Dropbox: Check for differences

Is it possible to check for differences between local and Dropbox?
Hello. I am currently working on a simple gallery App which displays all Dropbox images.
The workflow so far:
I log into Dropbox. The App scans recursively through all Dropbox folders and checks for images, then takes the metadata and displays the images.
Now I want to know if it is possible to check for differences so the App does not need to run through all folders every time but only if something has changed (for example if new images have been added to a Dropbox folder).
Thank you in advance.

The best way to keep track of changes in a Dropbox account when using the Dropbox API is by using /2/files/list_folder and /2/files/list_folder/continue:
https://www.dropbox.com/developers/documentation/http/documentation#files-list_folder
https://www.dropbox.com/developers/documentation/http/documentation#files-list_folder-continue
You should store the latest returned cursor, and then call back to /2/files/list_folder/continue using that cursor. It will returned only the changes since you last called.
For client-side apps, you can use /2/files/list_folder/longpoll to efficiently know when there are changes to retrieve:
https://www.dropbox.com/developers/documentation/http/documentation#files-list_folder-longpoll
There are also corresponding methods if you're using an SDK. For example, in the Dropbox Java SDK for API v2, these are listFolder, listFolderContinue, and listFolderLongpoll, respectively.

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.

Unable to get list of all files using google drive API

I am currently integrating goggle drive with my Java web application and I have an issue while getting the list of files associated with a account. I am using
https://content.googleapis.com/drive/v2/files?key={API-key} to get the list of files, but I am only getting the folders and files which are created from with in my application I am not able to get all the folders for that particular account.
For the same account when I tested it through 'try it' on 'developers.google.com' I am able to get all the folders and files
I am not able to understand why I am not getting all folders when I make the call from my application, should I be request for any extra permissions from google? Please help me what should I do

This behavior occurs when you only select the drive.files scope, which will only list the items created and/or modified by the application. You will need all of the listed scopes in this document (https://developers.google.com/drive/v2/reference/files/list) in order to access all the files from your drive account. Be sure to add all the scopes under your project, at https://console.developers.google.com