cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Back again with another edition of 'How we use Dropbox', so find out how Emma uses to-do lists to get it all done 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

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

Re: DbxCredential Android vs Java

Greg-DB
Dropboxer

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

Re: DbxCredential Android vs Java

Greg-DB
Dropboxer

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

Re: DbxCredential Android vs Java

vewert
Explorer | Level 4

Thanks Greg, that makes sense.

Who's talking

Top contributors to this post

  • User avatar
    vewert Explorer | Level 4
  • User avatar
    Greg-DB Dropboxer
What do Dropbox user levels mean?
Need more support?