cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

DbxCredential Android vs Java

DbxCredential Android vs Java

vewert
Explorer | Level 4
Go to solution

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/c...) 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/drop... 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.

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution

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.)

View solution in original post

2 Replies 2

Greg-DB
Dropbox Staff
Go to solution

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
Explorer | Level 4
Go to solution

Thanks Greg, that makes sense.

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    vewert Explorer | Level 4
  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?