Mobile Cloud Services: Data Persistence Across Devices

Fast speed dataflow.


As always, we are looking at ways to empower the mobile developer to transform the world through innovative and leading-edge technologies.  Cloud services are a great example of integrating easily scalable features in your application, such as custom data and user integration.

In response to developer requests, we’ve integrated  Appcelerator Cloud Services into the ToDo List sample application, available within Titanium Studio.  This provides user tracking and cross-device data persistence. When finished, we’ll have created a very simple event-driven application that allows users to create a new user, log in to the application with an existing user, and manage a single list of tasks that will remain persistent across multiple devices running iOS, Android, and/or Mobile Web.

Mobile Cloud Services

The Basics

The sample that we are basing this application on is the Todo List application available in the Samples section of Titanium Studio. While this sample is a basis for what we are doing, it is not required in order to follow along. However, if you’d like to see the original project, you can import it from Titanium Studio, or you can view the project on GitHub.

The project we are about to build is also available in our TodoListACS repo on Github. Please be aware that if you import the project from GitHub, you will need to copy the tiapp.example.xml file to tiapp.xml and enable ACS in order to get your own set of ACS project keys.

The Breakdown

There are only 6 files that comprise the TodoListACS app and most of them are UI related. We’ll step through them one at a time and briefly describe whats going on.


There is nothing exciting going on here, we’re just bootstrapping the application. Regardless, here is the code.


This is where we build out our tabs and the windows attached to them. Notice we make a quick adjustment for Android to add a menu option for adding new tasks. We will listen for the open event on the entire tab group so that we know it’s ok to open up the login window.


The ListWindow will control the list views for both completed and uncompleted tasks. There are quite a few things to take notice of in this module. First, notice that we use a simple flag passed into the module to let us know which list we are dealing with. Different options are used when a user clicks on an item in the todo list rather than the done list. We also add a listener on the todo list for newly added tasks. Rather than making a second call out to ACS to get the task list, we simply append the newly added ACS task to the table view. Finally, we add one more app-level event listener to update the task lists. Whenever a task is deleted or marked as completed, we query ACS for the task list and separate them by their status.


The added window is a simple modal form with a single text field for adding new tasks


The login window is another modal form for entering a username and password. Once a successful login is registered, this window receives an event that closes it.


This is the module that brings it all together. This module would replace the db.js file in the original sample application. The first part of this module deals with users and authentication. When the login window is displayed pass the credentials to the login method, however, if the user does not exist, we immediately pass those credentials along to the register method to create a new user.

The second section of this module uses ACS objects to create and track the tasks for the logged-in user. Cloud calls are asynchronous so whenever a call is returned from ACS we fire an event to let the application know that the call has been completed and to update the UI as necessary. For example, when we call the fetch() method, we query ACS for all the users’ tasks, when that call is returned, we fire the ‘app:update_tables’ app-level event with the list of fetched tasks. The ListWindow module is listening for this event and displays the tasks accordingly.

The Exercise

While this pretty simple example is complete, there are a few things that could be expanded upon as an exercise for the reader.

  • Logout – There is a logout method in todo, js, but it has not been implemented into the UI. Adding a logout that re-activates the login window should be a simple task.
  • Sessions – Currently you must log in every time you start the app. A quicker way would be to store the ACS session and restore the session on startup if the user had not already logged out.
  • Sharing – A bit more advanced would be to add a sharing feature that allowed users to share their tasks with other users.