Mobile apps are hard enough to build. Adding even one library to your toolkit can add time to your building process. So what is MobileSync and why should you put time into it? The short answer: sync provides access to distributed data without the customary burden of network programming at every step of the way. If your application is making network calls to get and save user data, using a sync library like Couchbase Lite may cut down on your development time and frustration, while giving additional benefits like a snappier, more reliable user interface.
Sync means different things to different people. Probably the most widely known sync system is the Dropbox cloud service, which is used to synchronize and share files across many computers. As long as you have enough space to keep up with your Dropbox, it’s a great way to share files with a team.
The difference between sync and ordinary cloud data storage is that sync proactively brings data to the device, whereas cloud storage is typically accessed on a request-by-request basis. In Dropbox, you can edit and create new files, even when you are offline. When you reconnect, any changes you made will sync to the cloud, and any new files will download. This means the user (and the application programmer) never has to worry about the current status of the network connection.
With database sync (like Couchbase Lite), mobile application developers can depend on having structured data available locally, rather than having to make individual network requests triggered by each user input action. So developers can focus on business logic, not network APIs.
The prime benefit of sync is this abstraction over the network layer, letting application developers interact with data regardless of network connection status. If this is the big benefit, what kind of apps should use sync?
* When user data (written content, drawings, game data, etc.) needs to be available across devices and operating systems, with a minimum of server side coding.
* Users want to edit data when they are disconnected, and reconcile it with the system of record when they reconnect. (Airline pilots, resource extraction, delivery, health-care, etc.)
* Applications with complex data types (and simple data flows). If you’re doing a turn-based word game with integrated messaging and a bunch of in-game analytics, sync can simplify things. We hope to have an example app for this use case soon.
* Content delivery like magazines etc. If you are delivering something like an HTML5 interactive magazine, sync can make it easy to add interactive content.
If you build apps like this and want to use sync, you need to ask yourself one question: “Can I predict which data matters for each user?”
Some apps it’s pretty easy: in a game app, it’s state of the games you are in, and user profile data for your opponents; in photo sharing, it’s the recent photos from each of your friends; for a pilot, it’s the data about today’s flights.
Other apps are harder to tell: an existing web app already using a relational database will take more work to get sync-ready than an app already using JSON document storage. Or if your app has to run complex backend logic to validate each request, it might not be as easy to enable sync. Similarly, sync won’t help for a user’s initial search query on a topic. But if your app features saved searches, sync may be a good way to incrementally update result sets.
There is a big community using Couchbase sync technology. Join our mailing list to get to know us, or try this tutorial if you are ready to get started.
The thing with Sync that I\’m struggling with is if I use one bucket – wouldn\’t that whole bucket need to sync…(the users specific data plus all the other users data) I guess there must be selective filters on what is synchronized. The bucket per user seems improbable as I want to have a minimum of 2,000 users… I don\’t want to manage that and then figure out how to size them properly… need to investigate this :)
The sync gateway will allow clients to filter what they sync. Documents in the bucket are tagged and assigned to \’channels\’, and a client making a sync connection specifies what channels it\’s currently interested in. There are also ACLs controlling which channels a user is allowed to see.
This is all in active development and pre-alpha, but you can read an overview in the project\’s README: