got sync? why the best informational smartphone apps use synced offline data
Smartphone app usage and of course smartphone app development is taking off worldwide. There have been 5 billion iPhone app downloads of over 225,000 apps. There are converging on 100,000 Android apps. Rhodes is being used for thousands of developers to write apps for iPhone, Android, BlackBerry and Windows Mobile devices. Despite this growth of apps and success of the smartphone developers are just starting to understand how to build good informational smartphone apps (as opposed to games which are a more mature mobile segment). There’s a wide disparity on app stores in adoption and quality of those informational or transactional apps.
One very important distinguisher of better quality informational apps is synchronized offline data. Specifically giving your users the ability to read and work with their information when disconnected. The widespread failure of mobile web browsers to make a dent in enterprise smartphone app usage demonstrated that user’s want to interact with data locally before trusting that their changes are applied. Just as all mobile email clients use synchronized data, study after study shows that users won’t interact with their app backends unless the data is made available locally. Even in the cases where data is just read or downloaded (such as a newspaper app with articles or an RSS reader), having the data cached and available offline is very valuable and is almost universally done among the higher rated reader apps.
So how do you as an informational app developer do this? At a high level there are three options:
1) write the synchronization yourself
If you want to provide incremental data updates you’ll need some kind of server logic hosted somewhere to figure out the deltas to send to the device. If you want to do it bidirectional data sync it becomes even more forbidding, especially if you want to handle or prevent conflicts. If you want to do “push sync” it becomes extremely impractical
to write this yourself. If you are talented enough to do any of the above your talents are better applied writing great apps then squandering them to avoid buying a sync server license.
2) use a “first generation” sync server
Sync servers for mobile apps have been around for a while. Pumatech’s IntelliSync was a huge business before being bought by Nokia and discontinued. These days Sybase does a great business around mobile synchronization. So does Antenna (note that servers for PIM and email sync such as Funambol are not included here as “sync servers” – we are referring to sync servers for arbitrary structured data not PIM information). There are many other sync servers that got their start ten to fifteen years ago. We certainly recommend this option over writing your own or not doing sync at all.
3) use a sync server targeted at the modern smartphone
RhoSync was written from the ground up to target the modern smartphone. For one, modern smartphones all have push APIs built in. iPhone has had push since the 3.0 SDK. BlackBerry introduced push into their latest BES server. Use of push-based sync let apps receive data updates near realtime AND insures that battery life is not drained on the devices due to the need to constantly poll. Finally modern smartphones are more than an order of magnitude more powerful which allows the sync and database handling to be tuned to these devices, which are very different from the featurephones that earlier sync servers were targeted at.
RhoSync has many key aspects that alleviate the fear that some modern developers have about sync:
1) it’s open source under the GPL
There is no lockin to proprietary vendor technology. IntelliSync users faced a lot of pain when Nokia discontinued that product. RhoSync enjoys many key contributions from the wider open source community
2) it’s much less expensive than earlier sync products
RhoSync licenses start at just $10,000. As the numbers of users grow the price per user drops drastically to as little as $0.16 per user
3) it’s much easier to write for than other sync server yet released
The typical RhoSync source adapter is less than a page of Ruby code and four significant methods: query, create, update and delete. The experienced mobile developer is usually stunned by how much simpler we have made the process.
4) the programming model of the client app is usually drastically simplified
At least with the Rhodes framework, if you use synchronized data (which is NOT required, you can connect Rhodes apps directly to your backend application if you wish) you have a much easier development effort. You can just assume that all of your data is available locally in your database. There is no effort expended in connecting over http or https and parsing either XML or JSON. RhoSync does all of that work for you. The data is all available in the local database. And you can use the ORM (Rhom) to access it without writing SQL.
To see an example of development of a RhoSync app, consider attending tomorrow’s free training webinar where we will show building a synced data app for BART train schedules in a handful of lines of code. And the resulting app is usable by occasionally disconnected harried commuters wherever they are.
