Comments
-
Perfect, thank you!
-
Great, thank you!
-
Great, thank you! With regard to a 503, though, a DBRequestErrorInternalServer is just a generic "anything over 500" error, isn't it? So if I want to check specifically for a file lock error, is it safe still to check for the 503 error? (That is, will DBError report a status code of 503 in this case?) All the best, Keith
-
That helps lots, thank you! I think I'm nearly there... One question on (4): What about for errors that aren't covered in the framework. For instance, if you recall, I found that I was encountering random 503 "failed to grab file lock" errors, in which case I would use the "retry-after" header. In API 2, the status code…
-
Hi Greg, Great, many thanks for the thorough reply! For (2) and (6) I'll probably write a couple of category methods to simplify those checks, then. And d'oh, I see that the -isKindOfClass: question is in fact already answered in the "Responding to edge cases" section. I'd missed that. So, in the same vein, I understand…
-
Thanks Gregory.
-
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…
-
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:)…
-
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…
