Ok, maybe not every single app, but if your app has any sort of data, then yes, you should add Dropbox support to the app. Certainly if the app is a tool of some sort, you understand that the user values the data that has been generated; but even if the app is a game, the user still values that data! If they've spent 5 hours to complete a tonne of levels, it's nice to have that accomplishment backed up, or available on a second device. This is where Dropbox comes in.

If you've been living under a rock and don't know what Dropbox is, it's a service that allows users to create a special folder on their computer that automatically syncs itself to the Dropbox servers and then any other computers also using the same account. This provides the user with a cloud based backup service (with a basic version control too). Using the official Dropbox iOS, Android and Blackberry apps, the user can access any of the files in their Dropbox account on the go. Sounds simple, and it is. So simple that everyone should be using it (especially since the basic service is free).

So how can you use this magical service in your apps? Dropbox provides an SDK for developers that lets you access a user's Dropbox account (with their permission of course). Now it's up to you to implement a solution to use it.

Before I go into detail on using the SDK (a future post), I'm going to suggest a directory hierarchy that we all follow. Remember that the root folder of the Dropbox is actually a directory on the user's computer that they're using. We don't want to clutter that folder with all kinds of stuff the user doesn't understand, they're likely to delete it.

One of the first apps I used that was Dropbox enabled was 1Password (An awesome app by the way). Their solution was to create a file called

.ws.agile.1Password.settings

in the root folder that only contained the location of their actual data. This lets users store their data wherever they want (provided it's still under the main Dropbox folder), and 1Password can still find it. There's a problem with this though, when you have lots of apps installed, all using a similar plan, you're going to have a tonne of junk in the root folder. Not user friendly at all. Not to mention, that while Mac OS X will hide a file starting with a dot by default, some of your users might not have switched from Windows yet and Windows will show the 'hidden' file in the folder, just waiting to be deleted.

My proposal, is that we create a folder in the Dropbox root called

.apps

as a central repository for third party app data. From there you use a reverse domain name system similar to your bundle id, but instead of dots, use new directories, and only use lowercase. So keeping with the 1Password example, they would store their data in

.apps/ws/agile/1password/

This will be consistent for their iPhone, iPad, Android, Mac OS X and Windows clients. All of their 1Password apps will be able to find the data regardless of system being used. Any data that is system specific can be stored further down the hierarchy.

This system should keep everything clean, organized and out of view of the user. Windows users will still see the .apps folder but at least it's just one folder and it's name should make it's meaning clear to most users.

Be aware that because you're now backing up your user's data to their Dropbox, they can now easily browse (and even modify) that data if they're so inclined. So make sure you protect this data if it shouldn't be seen or modified. For example, if you're game has 10 levels and you have to complete them in order to advance to the next one, don't record level completion in a simple format that lets the user effectively just check off that they've completed a level. If reading the data is ok (high score list etc), you can still use a simple format to store the info, just add some sort of validation to ensure the file hasn't been modified. A hash file will probably be fine for most simple cases (use some salt that you're keeping secret).¹

Due to the rules change for iDevBlogADay, I am being rotated out for some fresh blood so this is my last official #idevblogaday post until I rotate in again. However, I will continue to blog on a regular basis at my main site: www.cerebralgardens.com. Some upcoming posts will involve how to actually do the syncing above. I have created a few components that I plan to release as Open Source and will go into detail on how to use them. If you're interested in reading more, you'll want to follow me on Twitter @CerebralGardens.

Thanks to everyone for reading my words so far, and especially to Miguel @mysterycoconut for running the whole iDevBlogADay thing.

See you next week!

Update (added this paragraph that was accidentally cut during my editing phase): Why bother using Dropbox in your app when iTunes backs everything up during a sync anyway? Well there are lots of reasons:

• Not everyone syncs on a regular basis; shocking I know
• If a user deletes an app, it deletes the data too, next sync, the backup is deleted too, if the user decides to put your app back on their phone, they have to start from scratch
• Using Dropbox allows multiple devices to access the same data, play a game on your iPad, and continue later on your phone
• It may be your app, but it’s the users data, so making it easy for them to access is a good thing

¹ Note that the above point about checking for modified data files etc is vital even if you're not syncing to Dropbox, it's trivial for users to access/modify your data files through jailbreaking or even iTunes backups. Another issue is that the Dropbox folder is exposed to unknown other apps that might try to use the data contained within maliciously, scan for emails to spam, or account passwords etc. Those apps could be Windows malware etc so definitely encrypt sensitive data.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

For this week's iDevBlogADay post, I'm going to give you some numbers. A different set of numbers than usual, not sales numbers (unfortunately they've not been interesting enough to publish yet); I'm going to give you the number of visits to my other iDevBlogADay posts so far.

I love being a part of the iDevBlogADay rotation, it's forcing me to write and communicate more with the iOS community (I'm usually a very quiet person). I appreciate the opportunity to be able to give a little something back. To that end, I want to maximize the reach and the impact of the little that I do get to write. So, following the numbers, I'm going to have a tiny survey for you. I'll publish the results next week and then use the information gained to create a series of posts that should interest and help, the most people.

Here are my numbers so far (all stats current as of Jan 30th, 2011).

The most successful post (judging solely on web traffic) was the Tips & Tricks post. By far, nearly double the traffic of the second most popular post about reducing piracy. The Tips post had a tonne of people tweeting the link.

My theory, is that the Tips post had 9 pretty different tips, and so there was 9 times as many chances for a topic to be interesting to someone. That's why it was linked to more often than the others. The second, regarded piracy, a topic almost every developer is concerned with.

I have no idea if the stats I'm seeing are similar to others, I only have about 200 followers on Twitter, which is pretty low. But then again, I don't say much, so it's not surprising.

So, please help me by answering the 6 questions in this survey so that I can write on topics that are the most interesting to you!

Thanks!

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.