API Development

Using App Properties Instead of Sqlite to Store Local App Data

In many cases, and when developing apps with Titanium, there is the need to store data locally on devices — this could be an API token, or cached data from remote APIs, or data that may have shipped with the app, or even local settings.

Typically and in the past I’ve seen plenty of examples of apps by developers where they use Sqlite databases to store data offline. In these cases, they may have data that’s shipped with the app, such as country / city lookups, or a database of locations or users OR they are syncing data with a remote API and caching it in a database locally.

This is all fine and good, but there are plenty of times where storing this information in databases feels like overkill.

Don’t get me wrong, databases are great ways to store data, especially if it’s a lot of data and you’re looking to retrieve information quick using SQL queries etc, but databases can have some disadvantages:

Firstly, they need to be installed when the app first runs — most of the time this is easy and fast, but for large databases there can be a slight delay as the app first runs as it copies the data into place.

Secondly, and for me most importantly, databases require “migrations” if you ever need to change or add specific data. For example, if you add a new column or table in a database, you’ll need to do this using a migration that would update the database from version 1.0 to version 1.1 for example.

If you’re using remote APIs or caching data, it can be even more complicated, as you have to read the remote data using a REST call, then iterate through the data and cache this locally in a database, meaning deletion of entire tables, insertion of new rows of data, or worse, adding only the changes which means comparing data from the database to the REST data response — all of this means multiple database calls which can be time consuming and require a lot of code.

So, how can you reduce some of this effort and provide a smoother developer experience?

For me, I tend to use local property storage to save data locally and find it has several advantages over Sqlite:

  • App properties can be used to save values like numbers, strings, etc., but also objects – so JSON data. This means in most cases you can call data from an API, and save it immediately to a local property, caching it for later use. This is easy, fast and requires less code.
  • There’s no need for migrations when working with JSON objects. If you need to add a new property, you can just do it on-the-fly — no need to compare versions or do migrations.
  • Working with App properties is fast — the API is simple and you can use tools like underscore to quickly search for, manipulate and manage JSON data.

This is all great so far, but one thing to note about App properties is that whilst there isn’t a specific limit on the amount of data you can store in properties, an application’s property data is loaded into memory as the app launches, and exists there until it closes. This allows for rapid access but could increase the baseline memory used when the app is running.

Despite this, and in most cases working with local properties, I’ve never had any significant issues with speed or performance, and find that I can end up writing less code, and deal with less issues when I need to update or manipulate the data.

The good news is that you can use a combination of app properties and SQL databases! Using Alloy data binding, it’s easy to migrate from one to the other, leaving most of your Alloy Views and Controller code unchanged.

If you’re looking to develop an app and need to store or use local data, consider if you need a database before you start, as you may find you can achieve what you need using just app properties, writing less code, and having less challenges as you develop the app further.

You can read more about App properties here:

Lightweight Persistence with the Properties API