There are many reasons for making your rich app store its data/settings server-side in the cloud. The most compelling reason, in developer Kyle Miller's opinion, is convenience for the end user.
We are quickly getting to the point where owning multiple Android or iOS devices is more of the norm. I find the ability to seamlessly use a single application between multiple devices the biggest deciding factor when choosing amongst several options. It's definitely one of the main reasons I'm a huge Google Apps/Android fan; the integration between the two is so flawless that anything else seems inconvenient. The ability to switch between phone/tablet/computer while using Gmail or GTalk in the middle of composing an email or having a conversation is a luxury I've become accustomed to and one I'm not willing to part with any time soon.
While this is convenient for the end user, it adds a few layers of difficulty for the developer. In this post, I'll discuss the higher-level difficulties in building a cloud-based app, as well as provide several tips.
Uniquely identifying your users
One of the biggest struggles in enabling a server-side back-end to your app is determining how you are going to uniquely identify your users. There are two broad options to consider from the start of this decision making process:
- Automatically generate a unique identifier for each user.
- Force the user to register for an account.
A great article in the Android Developers Blog covers techniques to track unique application installations, and the same tips can be used for this case. In brief, the options available are:
- TelephoneManager.getDeviceId() -- The biggest issues with this method are that Wi-Fi-only devices or music players don't have this type of unique identifier, and since this value persists between device wipes, if the device changes owners you could expose the previous owner's data.
- Mac Address -- A device's Wi-Fi or Bluetooth hardware will contain this value, but Google doesn't recommend using it because not all devices have Wi-Fi. Moreover, if the user doesn't have Wi-Fi turned on, the hardware may not report this value.
- Serial Number -- This option has been available since Gingerbread 2.3 via android.os.Build.SERIAL. As of the latest data reported by Google, only 18.6% of Android devices are running Gingerbread. However, this also poses the same potential downfall as the previous options since this value is persisted across device wipes/owners.
- ANDROID_ID -- If you are going the route of auto-generating a unique ID, Google and I recommend this method. This value is generated the first time a device boots up and will be reset if the device is wiped. The downfalls are that it is "not 100% reliable on releases of Android prior to 2.2" and "there has been at least one widely-observed bug in a popular handset from a major manufacturer, where every instance has the same ANDROID_ID." Oops.
The main deterrent from going the route of auto-generating a unique identifier in my own development is that my tablet and phone would both be considered different users, and I wouldn't be able to share the same data between them.Force the user to register for an account
I believe that forcing the user to register for an account will ultimately lead to a better end-user experience, because the user may log in to the same account from multiple devices and see the same data regardless.
However, in my experience, the major hurdle is actually getting people to register. I have discovered a few secrets that will aid in this, but I still see this as an obstacle to overcome.
- Authenticate the user, and therefore allow the person to re-use an existing login through other mediums such as Twitter or Facebook. In my previous App Builder post, I provided sample code and instructions on integrating Facebook logins/queries in your Android application. This is great for the end user because they don't need to create yet another login and password to remember or, even worse, risk giving a re-used password to an untrusted source. It's also great for you because it gives you access to other basic information about the user without the user ever manually entering that into your application.
- Provide a "Browse" mode in your application. It's nice to be able to at least take a "tour" through an application that requires a login; this can help you decide if it's something you want to use and therefore are willing to create an account for -- even if most or all of the features are locked out. Ultimately this will lead to a slightly higher conversion rate, but not nearly as much as the previous tip.
- Make the registration process as painless as possible. If you require the user's email, one thing you can do from Android is automatically pre-fill this field by requesting permission to access the user's Google account information and grab the primary Google email that is logged into the device. In most cases, this will likely be the email address the user wishes to register with, so all they must enter is a password.
Formatting transmitted data
Another thing you must decide is how you are going to format the data that is sent between the mobile device and your server(s). The two main options that come to mind are XML and JSON.
Ultimately, I decided on JSON formatting for several reasons. I had been building all my server-side back-ends in PHP/MySQL, and PHP's json_encode method makes packing objects a breeze. Furthermore, the JSONObject and JSONArray classes in Java make interpreting this data on the mobile device just as easy. I also feel that JSON is a much more lightweight protocol than XML.
Designing your application to store its data in the cloud puts more of a burden on you, but I believe that the benefit to the end user is enough that it justifies taking the time to design your app with this in mind. There are a lot more intricacies involved than what I discussed above, but the ones listed should be the first ones you consider.