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

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?