migrating from API 1 to 2 - how do I know if I have OAuth 1 tokens?

That code is written for getting tokens from the Sync SDK, but you're using the Core SDK, so the values would be a little different.

I put this together for you as a basic concept of how this would work for going from the Core SDK to the API v2 Objective-C SDK:

- (NSArray * )getTokensFromCoreSDK
{
    NSString *keychainPrefix = [[NSBundle mainBundle] bundleIdentifier];
    NSString *keychainId = [NSString stringWithFormat:@"%@.dropbox.auth", keychainPrefix];
    NSDictionary *keychainDict = @{(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
                                   (__bridge id)kSecAttrService: keychainId,
                                   (__bridge id)kSecMatchLimit: (__bridge id)kSecMatchLimitOne,
                                   (__bridge id)kSecReturnAttributes: (__bridge id)kCFBooleanTrue,
                                   (__bridge id)kSecReturnData: (__bridge id)kCFBooleanTrue};

    CFDictionaryRef result = NULL;
    OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)keychainDict,
                                          (CFTypeRef * )&result);
    NSDictionary *attrDict = (__bridge_transfer NSDictionary * )result;
    NSData *foundValue = [attrDict objectForKey:(__bridge id)kSecValueData];
    NSMutableArray *credentials = [[NSMutableArray alloc] init];

    if (status == noErr && foundValue) {
        NSDictionary *savedCreds = [NSKeyedUnarchiver unarchiveObjectWithData:foundValue];
        NSArray *credsForApp = [savedCreds objectForKey:@"kDBDropboxUserCredentials"];
        for (NSDictionary *credsForUser in credsForApp) {
            NSDictionary *token = @{
                                    @"userId": [credsForUser objectForKey:@"kDBDropboxUserId"],
                                    @"token": [credsForUser objectForKey:@"kMPOAuthCredentialAccessToken"],
                                    @"tokenSecret": [credsForUser objectForKey:@"kMPOAuthCredentialAccessTokenSecret"]
                                    };
            [credentials addObject:token];
        }
    }
    return credentials;
}

- (void)getAndSaveOAuth2TokensFromRetrievedOAuth1Tokens:(NSArray * )oauth1Tokens
{

    DBTransportClient *transportClient = [[DBTransportClient alloc] initWithAccessToken:nil selectUser:nil userAgent:nil delegateQueue:nil forceForegroundSession:nil appKey:APP_KEY appSecret:APP_SECRET];
    DropboxClient *client = [[DropboxClient alloc] initWithTransportClient:transportClient];

    for (NSDictionary *oauth1Token in oauth1Tokens) {
        [[client.authRoutes tokenFromOauth1:[oauth1Token objectForKey:@"token"] oauth1TokenSecret:[oauth1Token objectForKey:@"tokenSecret"]] response:^(DBAUTHTokenFromOAuth1Result *result, DBAUTHTokenFromOAuth1Error *routeError, DBRequestError *error) {
            if (result) {
                NSLog(@"OAuth 2 access token: %@\n", result.oauth2Token);
                DBAccessToken *accessToken = [[DBAccessToken alloc] initWithAccessToken:result.oauth2Token uid:[oauth1Token objectForKey:@"userId"]];
                [[DBOAuthManager sharedOAuthManager] storeAccessToken:accessToken];
            } else {
                NSLog(@"%@\n%@\n", routeError, error);
            }
        }];
    }

}

...

NSArray *oauth1Tokens = [self getTokensFromCoreSDK];
[self getAndSaveOAuth2TokensFromRetrievedOAuth1Tokens: oauth1Tokens];

I haven't tested that extensively, so be sure to test it well in your app. I hope it helps though!

Hey Greg,

  That's great, thanks!  That code works, but I think I am missing one step.  After I go through and store the new tokens, how do I get it to recognize that it is authorized?  I am finding that [DropboxClientsManager authorizedClient] is returning nil after storing the tokens.  If I quit the app and then run it again, THEN it recognizes the app as being authorized.  But how do I get it to know it's authorized without having to restart the app?

Another question if you do not mind.  I am making progress with the SDK and have been able to upload files.  But I don't understand why some DBFILESRoutes functions list two arguments for the return response, but they seem to require three in practice.  For example -createFolder:autorename says it returns a DBFILESFolderMetadata object and a DBFILESCreateFolderError object, but XCode gives me an error unless there is also a third DBRequestError object.  Is this a documentation mistake or is the third argument assumed but not shown for some reason?

Thanks!

Bob

I believe you can get that active within the same session using DropboxClientsManager.reauthorizeClient. Let me know if that doesn't work for you though.

Yes, the third one, a DBRequestError, applies to all calls and covers higher level failures (network issues, invalid access tokens, etc.) so it's not documented on each call individually.

Hey Greg,

  Yes that worked, thanks!  

In the process of debugging this I went through all of my various simulators and devices, because I don't know how to remove the OAuth2 tokens once they are on there.  I ran the old app to get the old tokens installed, then ran the new one to test the retrieval.  Is there any way to remove the new tokens in order to re-test the transfer?

Bob

Yea, you can use DBOAuthManager.clearStoredAccessToken for specific tokens, or DBOAuthManager.clearStoredAccessTokens for all tokens.

Ok, thanks Greg.

Also, when I use DBFILESgetMetadata, is there any way to tell if the path is a file or a folder?  In the old SDK there was an 'isDirectory' field of the metadata structure, but I don't see one for DBFILESMetadata. ?

Also, if it IS a folder, then how do you access the contents of the folder?  With the old SDK I uses a loop like this:

for (DBMetadata *file in metadata.contents)

Thanks

Bob

OK thanks, and how would you access the contents of the folder, is that included in the metadata or do you have to issue another call to get that?  Would I have to use listFolder?

Hey Greg,

  If getMetaData returns an error, how do you retrieve the error information from DBFILESGetMetadataError?    It looks like it only contains a path and a tag, and I can't tell what the tag is.  The docs say it represents the "union's current tag state", but it doesn't show any values.  Is there some other way to get information about why it failed or what the error is ?

Thanks,

Bob

Thanks for the reply.  I get that I can use the 'is' commands to check the error, but in the case of the metadata, there is a path and a tag.  The path is pretty self evident.  But what is the tag?  The docs don't seem to provide any details about what that is.  I'm just wondering in the case of an error, how I would go about determining the cause or reason.  The path I already know.  And it doesn't look like the tag tells me anything.  Does that make sense?

Thanks!

The "tag" is the way the API describes which member of the union the object is. The SDK uses it to determine what the "is" methods return. So, you don't need to access tag directly, as long as you use the "is" methods.

To get the actual error information, use the respective field. For example, DBFILESGetMetadataError.path gives you a DBFILESLookupError, which itself has various "is" methods to tell you which error it was (and so on, for any further nested errors).

Oh, I see, the path contains the error information. I had assumed the path was just the file pathname.

Thanks!

Hey Greg,

  With the old API, when I got a file's metadata, the returned DBMetadata structure included the filename, the path, the revision, the total bytes, and the last modified date.   Isn't that stuff commonly considered the metadata?  With the new API, getMetadata seems like it only returns the filename and path, is that correct?  How do I access that other information?

Thanks

Bob

OK, thanks, I got it now.

Also - is it okay to use the pathDisplay variable as a replacement for the old API's 'path' variable?  The docs say pathDisplay is only for display purposes, as if it might be incorrect sometimes.  But the other option is 'pathLower' , which is a lower-case version.  So what do you use if you just want the exact pathname, like what you had in the old API?

If the API is case insensitive, what happens when you upload a file with capitalization, and then try to download it again later?  Wouldn't it lose the capitalization?  Like, if I upload from once device and download to another, then if I used pathLower to create the new file, I would lose the original capitalization...

One reason why these docs are so confusing to me, and why I asked that previous question, is that for example, getMetadata says it returns a DBFILESMetadata object.  But if you go to the docs for that object, there is no indication that there are subclasses of that object for the various types -- file, folder, etc.  How would I know that if you hadn't told me?  Is there documentation I'm missing?

So that leads me to another question, sorry!  If I use -getMetadata:includeMediaInfo:includeDeleted:includeHasExplicitSharedMembers:

then I assume you can tell whether the file/folder is deleted by the type of DBFILESMetadata object that is returned -- a DBFILESDeletedMetadata object, right?  But then how do to tell if it was a file or a folder -- because normally you would check for a 

DBFILESFolderMetadata or  DBFILESFileMetadata object for that.  ??

Finally, the getMetadata docs say this about the 'includeDeleted' argument:

"If true, DeletedMetadata will be returned for deleted file or folder, otherwise notFound in DBFILESLookupError will be returned."  What does this mean?  Say I have a path to a file that does exist, and I call getMetadata with 'includeDeleted' = true.  Will I get both a DBFILESFileMetadata object in the return, as well as a 'notFound' in the DBFilesLookupError?  And where would that DBFilesLookupError be?  Would it be part of the returned  DBFILESGetMetadataError or the DBRequestError?

Thanks

Bob

The API is case-insensitive, but case-preserving. So when you upload a file with a certain casing, that will be preserved in pathDisplay, though you can reference that file with a lower-cased version of the path. 

In the re-creation scenario you describe, you can certainly re-use pathDisplay to create it with the casing you want.

And thanks, that's good feedback regarding the sub-classes in the documentation. I'll send it along to the team.

If you use includeDeleted with getMetadata, the resulting DBFILESMetadata will be one of DBFILESFileMetadata, DBFILESFolderMetadata, DBFILESDeletedMetadata. Deleted entries are neither files nor folders though. They just indicate that there was previously something at that path. (That something could have, at different points in time, been a file and a folder.)

For getMetadata, if you set includeDeleted to true, for a deleted entry, the "result" will be a DBFILESDeletedMetadata. If you set includeDeleted to false, the "route error" will contain a DBFilesLookupError (nested in a DBFILESGetMetadataError.path, to be strictly accurate.) You won't get both though.

You can see an example of the separation of the result, route error, and error for an RPC call like this here:

https://github.com/dropbox/dropbox-sdk-obj-c#rpc-style-request

Okay -- thanks for all of this help!  

I was wondering, is there any way to cause Dropbox errors intentionally for testing?  For example I would like to test the various upload errors that might happen.

Bob

Okay.  Another question -- can I use

([DropboxClientsManager authorizedClient] != nil)

as a replacement for 

[[DBSession sharedSession] isLinked]

?  Or are those two not equivalent?  Is there something better I should use?

Hey Greg,

  I am getting this kind of stuff printed to the console when I use the Dropbox API.  I'm not getting errors with the API calls, though.  Is this normal?

Thanks

Bob

2017-02-15 13:38:52.256303 Headspace[18414:3298160] [] nw_host_stats_add_src recv too small, received 24, expected 28
2017-02-15 13:38:52.259067 Headspace[18414:3298160] [] __nwlog_err_simulate_crash simulate crash already simulated "nw_socket_set_common_sockopts setsockopt SO_NOAPNFALLBK failed: [42] Protocol not available"
2017-02-15 13:38:52.259526 Headspace[18414:3298160] [] nw_socket_set_common_sockopts setsockopt SO_NOAPNFALLBK failed: [42] Protocol not available, dumping backtrace:
        [x86_64] libnetcore-856.30.16
    0   libsystem_network.dylib             0x0000000112e2e666 __nw_create_backtrace_string + 123
    1   libnetwork.dylib                    0x0000000116b1d006 nw_socket_add_input_handler + 3164
    2   libnetwork.dylib                    0x0000000116afa555 nw_endpoint_flow_attach_protocols + 3768
    3   libnetwork.dylib                    0x0000000116af9572 nw_endpoint_flow_setup_socket + 563
    4   libnetwork.dylib                    0x0000000116af8298 -[NWConcrete_nw_endpoint_flow startWithHandler:] + 2612
    5   libnetwork.dylib                    0x0000000116b13ae1 nw_endpoint_handler_path_change + 1261
    6   libnetwork.dylib                    0x0000000116b13510 nw_endpoint_handler_start + 570
    7   libnetwork.dylib                    0x0000000116b2b1f9 nw_endpoint_resolver_start_next_child + 2240
    8   libdispatch.dylib                   0x0000000112bab978 _dispatch_call_block_and_release + 12
    9   libdispatch.dylib                   0x0000000112bd50cd _dispatch_client_callout + 8
    10  libdispatch.dylib                   0x0000000112bb2e17 _dispatch_queue_serial_drain + 236
    11  libdispatch.dylib                   0x0000000112bb3b4b _dispatch_queue_invoke + 1073
    12  libdispatch.dylib                   0x0000000112bb6385 _dispatch_root_queue_drain + 720
    13  libdispatch.dylib                   0x0000000112bb6059 _dispatch_worker_thread3 + 123
    14  libsystem_pthread.dylib             0x0000000112f7e4de _pthread_wqthread + 1129
    15  libsystem_pthread.dylib             0x0000000112f7c341 start_wqthread + 13