App Folder files not visible after un-install / re-install

Question

I noticed this in the debug environment where I have to do many re-installs in order to test persistent data storage, initial settings, etc... It may not be relevant in production, but I mention this anyway just to inform other developers.

Any files created by an app in its App Folder are not 'visible' to queries after manual un-install / re-install (from IDE, for instance). The same applies to the 'Encoded DriveID' - it is no longer valid.

It is probably 'by design' but it effectively creates 'orphans' in the app folder until manually cleaned by 'drive.google.com > Manage Apps > [yourapp] > Options > Delete hidden app data'. It also creates problem if an app relies on finding of files by metadata, title, ... since these seem to be gone. As I said, not a production problem, but it can create some frustration during development.

Can any of friendly Googlers confirm this? Is there any other way to get to these files after re-install?

score 4 · Answer 1 · answered Apr 27 '16 at 10:18

Try this approach:

Use requestSync() in onConnected() as:

@Override
public void onConnected(Bundle connectionHint) {
    super.onConnected(connectionHint);
    Drive.DriveApi.requestSync(getGoogleApiClient()).setResultCallback(syncCallback);
}

Then, in its callback, query the contents of the drive using:

final private ResultCallback<Status> syncCallback = new ResultCallback<Status>() {
    @Override
    public void onResult(@NonNull Status status) {
        if (!status.isSuccess()) {
            showMessage("Problem while retrieving results");
            return;
        }
        query = new Query.Builder()
                .addFilter(Filters.and(Filters.eq(SearchableField.TITLE, "title"),
                        Filters.eq(SearchableField.TRASHED, false)))
                .build();
        Drive.DriveApi.query(getGoogleApiClient(), query)
                .setResultCallback(metadataCallback);
    }
};

Then, in its callback, if found, retrieve the file using:

final private ResultCallback<DriveApi.MetadataBufferResult> metadataCallback =
        new ResultCallback<DriveApi.MetadataBufferResult>() {
    @SuppressLint("SetTextI18n")
    @Override
    public void onResult(@NonNull DriveApi.MetadataBufferResult result) {
        if (!result.getStatus().isSuccess()) {
            showMessage("Problem while retrieving results");
            return;
        }

        MetadataBuffer mdb = result.getMetadataBuffer();
        for (Metadata md : mdb) {
            Date createdDate = md.getCreatedDate();
            DriveId driveId = md.getDriveId();
        }

        readFromDrive(driveId);
    }
};

Job done!

Hope that helps!

The important part was `Drive.DriveApi.requestSync(getGoogleApiClient())` — Ryde, Feb 21 '17 at 00:01

score 3 · Accepted Answer · edited May 23 '17 at 12:34

3

It looks like Google Play services has a problem. (https://stackoverflow.com/a/26541831/2228408) For testing, you can do it by clearing Google Play services data (Settings > Apps > Google Play services > Manage Space > Clear all data).

Or, at this time, you need to implement it by using Drive SDK v2.

edited May 23 '17 at 12:34

Community

1
1

answered Oct 25 '14 at 03:07

y2ducky

206
1
4

1

@seanpj Are you sure it is only a problem when debugging? Did you test them? Thank you – user2847219 Jan 22 '16 at 17:11

score 0 · Answer 3 · answered Jun 19 '17 at 11:41

I think you are correct that it is by design.

By inspection I have concluded that until an app places data in the AppFolder folder, Drive does not sync down to the device however much to try and hassle it. Therefore it is impossible to check for the existence of AppFolder placed by another device, or a prior implementation. I'd assume that this was to try and create a consistent clean install.

I can see that there are a couple of strategies to work around this:

1) Place dummy data on AppFolder and then sync and recheck.

2) Accept that in the first instance there is the possibility of duplicates, as you cannot access the existing file by definition you will create a new copy, and use custom metadata to come up with a scheme to differentiate like-named files and choose which one you want to keep (essentially implement your conflict merge strategy across the two different files).

I've done the second, I have an update number to compare data from different devices and decide which version I want so decide whether to upload, download or leave alone. As my data is an SQLite DB I also have some code to only sync once updates have settled down and I deliberately consider people updating two devices at once foolish and the results are consistent but undefined as to which will win.

App Folder files not visible after un-install / re-install

3 Answers3

Linked