Migration from Sync API v1 to Core API v2

[Bhupesh K.]

Hi

I am migrating my existing code from Sync API v1 to Core API v2. There is one issue I am facing. There was a call in Sync API v2 to check if the cached file is latest or not:

DbxFile mFile = dbxFs.open(testPath);
boolean latest;
latest = mFile.getSyncStatus().isLatest;

Then on the basis of this ‘latest’ variable, I performed certain tasks.

In API v2, I couldn’t find any DbxFile class. The only closest thing I could find is getRev() of FileMetadata.

How can I use getRev() to find if I have the latest file? Is there any other way to do so?

Please help.

[Greg-DB]

The API v2 SDKs don't provide caching layers for you like the Sync SDKs did, but if you are caching file content locally like that, the rev value you mentioned can be used to keep track of changes. That is, when you store a copy of a file locally, store the rev value for that copy as well. When you see the remote rev value as different from the local one, you know that the file changed and you should download the new version.

For example, when using listFolderContinue, you'll get a list of Metadata entries, where you can see if there's a new version of a file you cached.

[Bhupesh K.]

Ok, I have been able to implement this. I store the revision number of the cached file and compare it with the String returned by getRev(). Now, I have another question. 

Suppose I want to login with another Dropbox account. Sync API had unlink() function to logout from current Dropbox account. How can I implement this in Core API v2? I didn't find a similar function.

[Greg-DB]

The API v2 Java SDK doesn't handle storing the access token for you (like the Sync SDK did), so this is under your control. If you want to "unlink" the user, you can just throw away the access token you have stored for the user. You can additionally revoke the token using the tokenRevoke method.

[Bhupesh K.]

Hi

Thanks for this. I have another doubt. Is there any 'timeout' variable which can be set for API v2 functions like 

mDbxClient.files().download() or

mDbxClient.files().uploadBuilder etc.

If user Internet is slow and he is downloading/uploading a file, I don't want him to keep waiting. There should be some message displayed to him after 'timeout' occurs. Please help.

Regards

Varun

[Greg-DB]

There are standard timeouts, but you can also set custom ones using StandardHttpRequestor.Config.Builder.

[Bhupesh K.]

Hi

I am facing another issue while uploading a file on Dropbox. I have written code below for uploading a file.

InputStream inputStream = null;
FileMetadata obj = null;
try {
    inputStream = new FileInputStream(srcFile);
    obj = mDbxClient.files().uploadBuilder(remoteFolderPath + "/" + remoteFileName)
            .withMode(WriteMode.OVERWRITE)
            .uploadAndFinish(inputStream);
} catch (DbxException | IOException e) {
    obj = null;
    mException = e;
} finally {
    if (inputStream != null)
        try {
            inputStream.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
}

This code returns a NetworkIOException when Internet is off. While uploading a file with Internet off, Sync API v1 never threw any exception. When Internet was turned on, it automatically uploaded the file. Can I have such behaviour with Core API v2 also? How can I implement this?

[Greg-DB]

The Sync SDK did offer offline caching and queuing, but the API v2 SDKs do not. That being the case, if you need this functionality, you'll have to implement it in your application's code. E.g., if you get such an exception when attempting the upload, save the file to upload in a queue, and have your app try again when it detects that Internet access has returned.

[Robert S.138]

As an indication of how complex all that Sync API caching was, my new Android app used to use Sync and is now using Core API v2.  I dropped the caching functionality and my app now only offers user-directed upload and download of its local document files.  My code is about the same in length.  But the Android APK file is half the size of what it was when I was linking with the Dropbox Sync libraries.   So that caching function was huge, and very non-trivial.  To really do background syncing and caching well is way beyond what most application developers want to get into.  Fortunately for my app, that functionality was not essential, and I think the new functionality will actually be more deterministic and easier for my users to understand.  But there may be others who are not so lucky.