Dealing with state in modern Apps (1/2)

Too many Apps are designed for single device usage and they don’t allow me to share and store data across devices. This not only makes the configuration of a new/additional device painful but in my case, it also makes me decide against a re-purchase of certain Apps. Take for instance Angry Birds: When I switched from my HTC to my Nokia, I basically lost all my unlocked levels. I wouldn’t mind purchasing the game a second time but I have definitely no interest in replaying all the different levels again… this would be just too painful. While upgrading a device is normally not a daily routine, the inability to share data across devices becomes a painful shop-stopper for sequential and simultaneous device usage. There are examples of Apps which preserve state across devices but the trend will go towards seamless cross device usage which will lead to the ability of sequential and simultaneous device usage:

For gaming/entertainment that means PLAY – PAUSE – RESUME
carry the game progress across screens

For productivity this means WORK – SAVE – SYNC
carry the workflow state across Screens

Unfortunately, today’s reality looks different: Only a few Apps take advantage of services but most store their data directly on the device. The reason for this is either the App doesn’t need to share/store information or more likely the reduced complexity to develop and test the App because there is no need to establish a communication with the service and no user authentication/authorization is required. Beside not supporting cross device and App scenarios, many devices have limited storage capacity and query capabilities, so it might become tricky to either store all collected data and/or making good use out of it.

On the other side, a service enables a seamless cross device and upgrade experiences and helps to overcome local storage constraints. This doesn’t mean that the only storage is in the cloud. It’s a best practice to reduce network dependency and leverage a combination of local storage and service capabilities.

Windows Azure provides the flowing storage options:

Windows Azure storage options

Windows Azure storage options

  • Tables are designed for large scale NoSQL data and have a very favorable price point (7 cents / GB). Storing large scale of data requires the developer to understand the concepts of data partitioning (more about this in a future post). Tables can store up to 100 TB and support either local or geographical redundancy. A unique storage account key grants access via REST and managed APIs.
  • Blobs are the preferred way to store files , whether these are images, text or media documents. Similar to tables, blobs can store up to 100 TB, support local or geographical redundancy and the storage account key grants access via REST and managed APIs.
  • Queues are a great way to implement reliable, persistent messaging between apps and services. Each message can store up to 64KB. The number of messages is unlimited. As with tables and blobs, a unique storage account key grants access via REST and managed APIs.
  • SQL databases provide the capabilities of a fully fletched relational database-as-a-service. The rich transactional support helps writing LOB services. Another great feature is SQL Data Sync, which enables hybrid scenarios through the synchronization of Windows Azure SQL databases and on-premise SQL servers. The current size limitation of SQL databases is 150GB and the cost per GB is between 10$ (the first GB) and 1$ (each GB above 50GB). The database connection can be established using ADO.NET, ODBC, JDBC, Entity Framework and php drivers for SQL server.

But with all these options, how do I pick the one which suits me the best?
Since there is no simple answer to this question, I will cover this is in a future post