In looking at the various examples of implementing short-lived tokens in Andriod, I wanted my implementation to use more primitive methods, instead of DropboxClientFactory, PicassoClient, and DbxRequestConfigFactory. So here is what I have done, trying to pattern my code after the code in DropboxActivity, and adapting it to my existing code for the long-lived access tokens.
The first thing I noticed is that I cannot follow the pattern of having one block of code for USE_SLT true and another block of code for USE_SLT false, as shown in DropboxActivity. I need to be able to create a DBClientV2 from the old long-lived token, if it exists, and from a new short-lived token, if not. So the onResume method in my activity that uses Dropbox contains:
requestConfig = DbxRequestConfig.newBuilder("TuneLab Tuning Files 2.6").build();
DbxCredential credential = null;
if(sDbxClient == null) {
String accessToken = prefs.getString(DBaccesstokenKEY, null); //..old-style long-lived
String serializedCredential = prefs.getString(DBcredentialKEY, null); //..new-style
//..At most one of the two Strings above will ever be non-null
if(accessToken != null) { //..first try the long-lived token
sDbxClient = new DbxClientV2(requestConfig, accessToken);
} else { //..no long-lived token. Try for a short-lived token.
if(serializedCredential != null) { //..check if short-lived already credential exists
try { //..expand the String to a DbxCredential object
credential = DbxCredential.Reader.readFully(serializedCredential);
} catch (Throwable t) {
nullOutDBaccessToken(); //..nulls both SharedPreferences above
}
} else if (authWasJustAttempted) { //..set by a button listener for "Link to Dropbox"
authWasJustAttempted = false; //..so we don't come here again
credential = Auth.getDbxCredential(); //..will be null if user said NO
}
if(credential != null) { //..either from serialized version, or from Auth attempt
credential = new DbxCredential(credential.getAccessToken(), -1L, credential.getRefreshToken(), credential.getAppKey());
if(credential != null) {
sDbxClient = new DbxClientV2(requestConfig, credential);
prefs.edit().putString(DBcredentialKEY, credential.toString()).apply(); //..necessary????
}
}
}
}
If sDbxClient is null after onResume, the activity presents the user with only one option, which is to link to Dropbox. If sDbxClient is not null, that means either an existing long-lived or short-lived access token was in effect, or this activity has just resumed after a successful Auth flow where the user said “yes”. The reference to requestConfig is to a private member of this activity that is referenced in onResume and in a button listener when the user chooses to establish a new link to Dropbox. If the user taps that button, authWasJustAttempted is set to true upon launching the Auth attempt:
List<String> scope = new ArrayList<>(Arrays.asList("files.content.write", "files.content.read"));
Auth.startOAuth2PKCE(getApplicationContext(), getString(R.string.APP_KEY), requestConfig, scope);
authWasJustAttempted = true;
It seems that the call shown in onResume to
credential = new DbxCredential(credential.getAccessToken(), -1L, credential.getRefreshToken(), credential.getAppKey());
accomplises the refreshing of the short-lived access token in credential, and so credential is changed from what it was after the readFully of the serialized version. If it is changed, then shouldn't the serialized version be updated in SharedPreferences too? I didn't see that in any of the examples, so I am confused as to whether or not it is necessary. What would happen if the token got refreshed, but the next time we come to this Activity, we try to refresh it again, but starting with a very stale version of the DbxCredential? Would it work anyway?
Other than these changes to my old code, the rest of my app would operate as before, using sDbxClient just as it was used before in uploading and downloading files. Finally, the scope that I think I need is just "files.content.write", "files.content.read" because all my app does is upload files to the App Folder or download files from the App Folder. I also examine the metadata for files to determine their last modified date. Does that require an additional scope, or are the two listed sufficient?
