The challenges of building a cloud-based app

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


  • Automatically generate a unique identifier for each user.
  • Force the user to register for an account.
Automatically generate a unique identifier


  • 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.
  • 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



  • 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


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.






Why didnt you just title this article "building an android app? I would have save time and not read it.

Tony Hopkinson
Tony Hopkinson

None of those are specific to the cloud, been about ages en masse or individually. Uniquely identify users, what without a cloud you don't have to do that? The three real challenges for writing for the cloud, are If you go down easy street and drop into monolithic it will hurt real quick, Reorganising the traditional design approaches business software design to take advantage of it. And employing cookie cutters to do the back end will fail. The bit people keeping trying to ignore about the cloud, it's a different platform...


If given the option, would you prefer to store your data in the cloud or keep it localized on your device? Or would it depend on the type of data being stored?

Editor's Picks