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

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