![]() In order to overcome the limitations in the first approach, I introduced two lists that each installation of the client uses for accounting when synching. Approach #2 - Hybrid server state and queued client state I wasn’t happy with the fact that this wasn’t truly sync. These limitations prevented me from publishing this solution. If two clients were synching, one client could delete a photo then another would simply re-upload it when synching.Ad hoc deletion requests that failed would result in re-downloading the next time a sync occurred.This worked very well and didn’t require any complicated state accounting, but it had two major limitations. Whenever a photo was deleted, an ad hoc deletion request would be kicked off. Whenever a new photo was taken, a sync would be kicked off and the (Local File Exists, Remote File Doesn’t Exist) state in the above matrix would upload it. When kicking off a sync, first the contents of a user’s Dropbox/Apps/Close-up directory are listed, then the following steps are applied for each file in the merged set of local and remote files. The first approach I took was very simple. Files containing sync metadata could break if different versions of the app changed formatting or if a user was to open a file and monkey with it. Only photos are stored to Dropbox - Only the photo content from Close-up would be stored in Dropbox, not other metadata or files. ![]() Thumbnails are not uploaded to Dropbox and clients won’t show photos from Dropbox until they’re fully downloaded. Files must exist in all locations - In order to show a file in the Close-up client, it must be downloaded locally and thumbnailed.Files are not versioned - Once a photo is taken it cannot be modified, only deleted.Constraintsīefore starting, I laid down a couple constraints that allowed me to simplify how sync would work. The Sync API is way cool, and insulates developers from basic operations, but it was still several months from being announced. The act of synching is left to the developer. The Core API has a few fundamental operations like listing directory contents, uploading files, downloading files, and deleting files, but as Drew Houston put it during DBX it’s a “batteries not included” solution. I chose to use Dropbox before their super simple Sync API was introduced, so I had to come up with a synching system of my own that wrapped their basic Core API. Not to mention Dropbox is awesome and I’m a supporter of their product. I settled with using Dropbox since it gives users ownership and access to their content outside of the Close-up app, the SDK was very friendly, and because it was a free solution. I really wanted to use iCloud, but after several false starts I felt it wasn’t worth the effort.
0 Comments
Leave a Reply. |