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

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

Hey Greg,

  I'm trying to compare the behavior of this new API with the old one. But I can't find the documentation for the old Rest API for iOS.  I want to know if the old loadFile:intoPath call (which downloads a file) automatically overwrote any existing file on the device, or if it generated an error?  It looks like it is automatically overwriting, but I wanted to make sure or find out if there was a setting for whether to overwrite or not.  I know that the new call has an argument for that.

Thanks

Bob

The old iOS Core SDK didn't have good documentation unfortunately. Here are the relevant methods/documentation in the comments though:

/* Loads the file contents at the given root/path and stores the result into destinationPath */
- (void)loadFile:(NSString *)path intoPath:(NSString *)destinationPath;

/* This will load a file as it existed at a given rev */
- (void)loadFile:(NSString *)path atRev:(NSString *)rev intoPath:(NSString *)destPath;

There wasn't a parameter for controlling overwriting at the destination.

The actual code is:

// Everything's OK, move temp file over to desired file
[fileManager removeItemAtPath:resultFilename error:nil];

BOOL success = [fileManager moveItemAtPath:tempFilename toPath:resultFilename error:&moveError];

So, yes, it seems it overwrote existing files by removing anything at the destination first, and then moving in the downloaded data (which it saved at a temporary location beforehand).

OK, great.

Also, what should I use as a replacement for this check? 

if ([DBSession sharedSession])

This is just at the beginning of the program to make sure Dropbox is there, but not necessarily logged in.  The [DropboxClientsManager setupWithAppKey:DROPBOX_APP_KEY] doesn't return any value, so I can't use that.

Thanks

Bob

It's probably fine then.  In the old version I guess there was a chance that the DBSession would fail for some reason?  

Hey Greg,

  I have everything working now.  However, when I try to upload a build to iTunes, it rejects it.  I get a bunch of errors like these:

ERROR ITMS-90087: "Unsupported Architectures. The executable for XXXXX.app/Frameworks/ObjectiveDropboxOfficial.framework contains unsupported architectures '[x86_64, i386]'."

ERROR ITMS-90209: "Invalid Segment Alignment. The app binary at 'XXXXX.app/Frameworks/ObjectiveDropboxOfficial.framework/ObjectiveDropboxOfficial' does not have proper segment alignment. Try rebuilding the app with the latest Xcode version."

ERROR ITMS-90125: "The binary is invalid. The encryption info in the LC_ENCRYPTION_INFO load command is either missing or invalid, or the binary is already encrypted. This binary does not seem to have been built with Apple's linker."

WARNING ITMS-90080: "The executable 'Payload/XXXXX.app/Frameworks/ObjectiveDropboxOfficial.framework' is not a Position Independent Executable. Please ensure that your build settings are configured to create PIE executables. For more information refer to Technical Q&A QA1788 - Building a Position Independent Executable in the iOS Developer Library."

Any idea what the problem is?  I used the Carthage method of installing the framework. 

Thanks

Bob

Yes, I followed the instructions exactly.  I tried it a couple of times.    What's weird is that earlier today it worked, but now it doesn't.  I think something about changing project targets might screw with the behavior.

I also, like that guy in the link, had some success by using Embedded Binaries earlier and then found it switching behaviors on me. I don't know, something seems flaky with that Carthage setup.    I am trying the CocoaPods method now.

The CocoaPods method does not work for me either.  I get this, for one thing:

Target 'ObjectiveDropboxOfficial' of project 'Pods' was rejected as an implicit dependency for 'ObjectiveDropboxOfficial.framework' because its architectures 'arm64' didn't contain all required architectures 'armv7 arm64'

Target 'Pods-XXXXXX' of project 'Pods' was rejected as an implicit dependency for 'Pods_XXXXXX'.framework' because its architectures 'arm64' didn't contain all required architectures 'armv7 arm64'

I don't like having to use the workspace file and having this CocoaPods thing screw with my XCode project, so I am going to restore from my TimeMachine backup and go back to trying to get the Carthage method to work.

Well, I got both of my builds to upload without iTunes complaining -- but there is definitely something weird going on.  This morning I ripped out the Dropbox framework and settings, and installed it again via Carthage.  My first target worked perfectly, uploaded fine.  But the second target wouldn't run -- 'image not found'.  I compared every setting for the two targets and they were exactly the same.  I 'fixed' the second target by embeddeding the Dropbox framework as a binary -- it ran -- but it still wouldn't upload to iTunes due to those architecture errors.

Then without doing anything but updating the version number, I rebuilt both targets and they both ran, both uploaded too.   I'm worried that my XCode project has something corrupted in it, because it is unpredictable, building a working version one minute and then a broken one the next, without me changing anything.  Also my XCode hung when I tried to quit.

Anyway Greg thanks for all the help, sorry I bothered you with so many questions about this new API.  

Bob