Child Item

Where is documentation for Obj-C API?

Where is the documentation for the API functions provided by the new Objective-C SDK? I mean for functions in the classes like

DropboxClientsManager

DBFILESListFolderResult

DBFILESListFolderError

DBFILESFileMetadata

DropboxClient

Is the only documentation the header files in the source code for ObjectiveDropboxOfficial?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Hi Robert, you can find the full documentation here:

https://dropbox.github.io/dropbox-sdk-obj-c/api-docs/latest/

Keith B.7

Hi Gregory,

Is a transition guide planned? I have several, highly-complex Dropbox-based classes that handle a full folder sync, similar to what the desktop client does, and converting them to API 2 is not going to be easy no matter what, but it will be a lot harder without a transition guide that roughly maps API 1 Obj-C calls to API 2 calls.

I've only just started looking through, but for instance, I'm guessing that -listFolderContinue: is the equivalent of -getDelta: in API 1 - is that right? If so, how do I call the equivalent of -loadDelta: but with a path prefix? In API 1, I wrote a category of DBRestClient that reimplemented -loadDelta: but with a path prefix. (Hmm, presumably the cursor is returned after the first -listFolder: call somehow after which the path isn't needed, being part of the cursor?)

There seems to be a *lot* more methods in API 2 (listFolderLongPoll?), so it would be good to have a transition guide that covers how we can translate API 1 Objc-C code over to API 2 without having to read through the hundreds of method descriptions in the documentation to try to find equivalents.

Thanks!

Robert S.138

Keith, I don't think there ever will be a mapping to API v2 for the Sync functions. That level of functionality just won't be provided anymore. In our app which also used the Sync SDK, we are changing the functionality at the user level. Our app will no longer have a mode whereby a cache of synced files in maintained. Instead our users will have to deal will all local files. Then there will be an explicit user-directed mass upload or download of files. No more sync for us.

Keith B.7

Hi Robert, actually my API 1 app is using the Core API, not the Sync API. This involved writing a lot of code using the basic API 1 calls to work out what needs uploading and downloading, keeping a cache of the file states at the end of the previous sync and comparing that against changes on the server (using -loadDelta:) and locally whenever a sync is invoked.

From what I can see in the endpoints migration guide (<https://www.dropbox.com/developers/reference/migration-guide>), API 2 has everything I used in API 1, so it should "just" be a matter of rewriting the code to use the updated SDK methods, but the Objective-C SDK seems to have a lot more methods than v1 and it's going to be a lot of work going through the documentation trying to work out which v2 method corresponds with which v1 method. So what would be really useful is a simple mapping document, similar to the endpoints migration guide (but it doesn't need as much info), showing which methods in the v2 Obj-C API correspond to the methods in DBRestClient of API 1 (and which classes correspond). That's all that's really necessary, as DBRestClient contained all the main methods of the Core API.

Greg-DB

Hi Keith, the migration guide you linked to is the only transition document we have, but I'll send this along as a request for more SDK-specific ones. (The method names are derived from the endpoint names though, so it may still be of some use mapping the methods to each other.

To answer your specific questions, yes, listFolderContinue is the equivalent of getDelta (when supplying a cursor), and listFolder (setting recursive=true) is the equivalent of getDelta (when not supplying a cursor).

The equivalent of a path prefix would be supplying a specific path parameter to listFolder. The path is then encoded in the cursor for use with listFolderContinue.

If you have any other questions about mapping v1 to v2, just let me know!

Keith B.7

Great, thanks, Gregory. I'll go through the header files some more and try to work out how to map everything, then. A couple of other quick questions (sorry, I should probably start a new topic for this):

1) What's the equivalent of the parentRev for uploading files? In API 1, I cache the rev for a file and include it in the upload method -uploadFile:toPath:withParentRev:fromPath:. API 2 upload methods seem to have no such rev parameter, instead having a DBFILESWriteMode parameter for determining what to do if the file already exits.

2) I assume DBFilesRoutes is the core class, the equivalent of API 1's DBRestClient? Or rather, it seems that things have been broken down, so that I create a DropboxClient but that has a .filesRoutes property associated with it that does all the things DBRestClient used to do...

Actually, I should stop asking questions and dive in a bit more, I think.

Robert S - sorry for sidetracking your thread.

Greg-DB

1) On API v2, it's effectively the same, but you supply the rev value to DBFILESWriteMode -initWithUpdate: and pass that write mode to the upload call.

2) The structure is a bit different, but yes, DBFilesRoutes contains all of the file API call routes, i.e., all of the API calls you can make for the "files" namespace. There are other namespaces too, such as sharing, etc.

If you have any other questions, please do feel free to open a new thread.

Keith B.7

Thanks Gregory.