You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.

Forum Discussion

vewert's avatar
vewert
Explorer | Level 4
4 years ago

DbxCredential Android vs Java

I recently updated my Android app to use OAuth code flow with PKCE, with refresh tokens. I am now working to update my Java Desktop application to also use PKCE with refresh tokens, and while looking at the examples I noticed a difference, in the way the DbxCredential is handled.

 

For android (https://github.com/dropbox/dropbox-sdk-java/blob/master/examples/android/src/main/java/com/dropbox/core/examples/android/DropboxClientFactory.java) it seem that a new DbxCredential object is created, using information from another DbxCredential object that was de-serialized (from stored preferences), which is then used to create the Client:

 

 

 

public static void init(DbxCredential credential) {
        credential = new DbxCredential(credential.getAccessToken(), -1L, credential.getRefreshToken(), credential.getAppKey());
        if (sDbxClient == null) {
            sDbxClient = new DbxClientV2(DbxRequestConfigFactory.getRequestConfig(), credential);
        }
    }

 

 

 

which is what I do in my Android App.

 

In the Java example (https://github.com/dropbox/dropbox-sdk-java/blob/master/examples/account-info/src/main/java/com/dropbox/core/examples/account_info/Main.java) it seems like it just uses one DbxCredential object created by de-serializing, without using the info to create a new DbxCredential object:

 

 

 

// Use DbxCredential instead of DbxAuthInfo.
        DbxCredential credential;
        try {
            credential = DbxCredential.Reader.readFromFile(argAuthFile);
        }
        catch (JsonReader.FileLoadException ex) {
            System.err.println("Error loading <auth-file>: " + ex.getMessage());
            System.exit(1); return;
        }

 

 

 

 

I'm just wondering why there is a difference? In the second example, is the Refresh token actually being refreshed?

 

Thanks for your help.

  • There isn't a big difference here. By setting the "-1L" expiration that makes the SDK immediately perform a refresh regardless of the actual expiration. The SDK will still handle the refresh process as/when needed though in either case, as long as the necessary pieces are given. (For PKCE, it only really needs the refresh token and app key.)

  • Greg-DB's avatar
    Greg-DB
    Icon for Dropbox Staff rankDropbox Staff

    There isn't a big difference here. By setting the "-1L" expiration that makes the SDK immediately perform a refresh regardless of the actual expiration. The SDK will still handle the refresh process as/when needed though in either case, as long as the necessary pieces are given. (For PKCE, it only really needs the refresh token and app key.)

    • vewert's avatar
      vewert
      Explorer | Level 4

      Thanks Greg, that makes sense.

About Dropbox API Support & Feedback

Node avatar for Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.5,917 PostsLatest Activity: 11 days ago
334 Following

If you need more help you can view your support options (expected response time for an email or ticket is 24 hours), or contact us on X or Facebook.

For more info on available support options for your Dropbox plan, see this article.

If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!