This is awesome stuff. It really adds a lot of end-user benefits when your app is able to sync via Dropbox.

While the APIs are only for iOS and Android, on BlackBerry 10, it's technically baked into the OS. If the user has linked their device to Dropbox, the OS automatically syncs the filelist and presents it as a part of the filesystem. This means that the user can open, edit, and save files directly to their Dropbox, without having to worry about connectivity. This also means that every BlackBerry 10 app can access your Dropbox folder, for free.

Even still, I have a feeling the Sync API likely offers something more than what I've described, but I haven't had a chance to delve into it. But I'm glad to see Dropbox branching out like this.

It'll be great to see this built into iOS as well. But they probably wont, cause that would just kill their iCloud storage sales.

I've run out of my iCloud free plan and will need to buy some memory soon even though I've got gigs of Dropbox that I'd much better prefer to use !

Not to beat a dead horse, but this is what really concerns me about iOS. It isn't that these hooks are missing, it's that Apple has a vested interest in never providing them.

Google has a similar interest, but has provided them in Android anywyay. The lack of an Intents system in iOS is annoying, and I'm concerned we'll never see one added.

I never understood this, the tutorial shows how to authenticate.

mDbxAcctMgr = DbxAccountManager.getInstance(getApplicationContext(), APP_KEY, APP_SECRET);

So anyone with some basic Android knowledge will be able to extract my applications key and secret?

Essentially no client side app can be considered able to keep secrets.

I would be interested in the implications of this from the authorising servers perspective. Here is the main mention of it in the OAuth spec: http://tools.ietf.org/html/rfc6749#page-52 and google's interpretation: https://developers.google.com/accounts/docs/OAuth2InstalledA.... Even though google say "t is assumed that these applications cannot keep secrets" I can't quite infer the actual implications of this?

Incidentally, this exact topic is now under discussion: http://news.ycombinator.com/item?id=5337099

> So anyone with some basic Android knowledge will be able to extract my applications key and secret?

Yes:

http://news.ycombinator.com/item?id=4410398

http://stackoverflow.com/questions/4419915/how-to-keep-the-o...

Yes. This is also how Twitter's authentication works. Twitter say that client developers should protect the secret in the binary by reasonable means, but the key from Twitter's own iOS and Android apps have already been extracted. (on a side note, why haven't any client devs who ran into token limited tries using the official keys yet? will they be taken out of an app store?)

> why haven't any client devs who ran into token limited tries using the official keys yet? will they be taken out of an app store?

Probably, just like AirFoil Speakers Touch has been kicked out for using some Apple private key extracted from the Airport firmware to act as an AirpLay receiver.

The APP credentials are for each app that integrates this Dropbox sync. The app keeps those to itself (probably hard-coded in the binary) and using them, it requests access to a Dropbox account.

Yep. And the same goes for iOS, too. I've taken a peek at the official Dropbox iOS app's API key and secret in the past just for fun, though I didn't go so far as to post them on Github.

Is there a way round that thou?

Surely you need to grant your app to be able to indentify itself, that means it has to have its secret baked in?

There isn't really a way around it other than implementing authentication in a remote server. In that scenario, the app doesn't authenticate directly with the service, but with a private server. This way you can, for example, authenticate your users and create sessions before they can access the Dropbox API.

It can still be abused, but at least you can know who did it.

How about storing the key and secret in an encrypted form?

And where would you keep the decryption key?

Keychain.

If a user doesn't have an account (or hasn't linked their account yet) Dropbox should let developers store data in an anonymous account tied to that device until the uses does. I think developers would pay for that.

I think Dropbox should pay developers to do this. You already have n apps storing x MB of data on Dropbox, sign up now for a free account!

I kind of hope this ends up replacing iCloud in a lot of apps. iAwriter could really do with using Dropbox by default.

Agreed. I'm finding the iOS version of iA Writer doesn't like it when I modify the file elsewhere - I have to manually switch files for it to detect the change.

Great stuff. Now it just needs to find it's way into the KeePass apps.

I've been using KeePass with Dropbox to send the file across devices, unfortunately it not a true sync, so if I add a Password into my iPhone (rare as that is), I can't update the master password file on Dropbox.

Does this require that my apps users each have a dropbox account?

Yes! From their "Getting Started" section - " you'll need to add snippets of code in the right places to successfully link a user's Dropbox account to your app"

Looks like it: https://www.dropbox.com/developers/sync/docs/android#com.dro...

yep, so you shouldnt rely on it but make it a feature of your app to sync the data to dropbox.

Android has had a Backup API for a long time: http://developer.android.com/training/cloudsync/backupapi.ht...

It's one of the most useful, yet under-used feature of Android. It allows apps to save their settings for when users change devices. Sadly, it doesn't allow sync-ing.

I could use this for a Qt app. Why not a c or c++ api instead of IOs and android ?

A c or c++ api for which platform?

Dropbox have to implement this api on a per-platform basis, so the question is first which platforms to support, then on those platforms what language APIs to provide.

I like the iOS API's simplicity. Also the ability to attach observers to file objects. Much easier to use than iCloud (IMHO) and cross platform are huge advantages for me personally.

One thing that I really have to complement Dropbox for is their abstraction layer. It is so much simpler and easier to use than other providers versions of the same API (e.g. Google Drive).

Anybody know what API they're using under the hood for this? I have wanted to use the delta REST API (https://www.dropbox.com/developers/core/api#delta) but since I can't limit it to the subdirs my app cares about, I get overwhelmed with a lot of noise and it generally ends up being more data than polling and walking the sub-tree each time.

The delta API is a real pain to work with unless you're interested in keep the entire Dropbox state in sync.

I ran into the same thing and it was only on my (fairly inactive) Dropbox account.

The other problem is that the API doesn't differentiate between a simple rename and a delete+create. I understand that's just file system semantics but I wish their API was a little smarter than that.

I digress. The delta API has left me with scars.

It'd be nice to have the API also for platforms like Windows Phone/Windows 8 and a pure javascript implementation.

Still, this is quite good.

Wasn't this announced a month or so ago?

29 days ago:

https://www.dropbox.com/developers/blog/26

Is there anyway one can use it for a web app? I only see Android and iOS support.

Take a look at the Core API for use from a web app: https://www.dropbox.com/developers/core/gs

this only makes sense if you save locally and want to have the files synced to the cloud like Dropbox does. Since a webapp will most likely not store stuff locally (and when it does, i doubt dropbox could access it) it doesnt really make sense.

But you can still use their Core API for this though.

I'd like to see this baked into Mac/Win applications since I'm not using Dropbox but would still like to use sync capabilities without having to install the whole desktop client.

For a just-released API/SDK, the documentation and tutorial on this is pretty nice.

Especially nice that for the Android SDK documentation, they didn't just publish javadoc-generated html files.

How did apps that used Dropbox handle it before this? Did they have to write a mechanism to sync data themselves?

From what I know most apps directly wrote to your Dropbox via their API, so not to the local file system first.

That meant you either had to be always online, or you had to write your own caching & syncing mechanism.