Appcelerator Blog

The Leading Resource for All Things Mobile

How-To: Persist Complex JavaScript Objects

0 Flares 0 Flares ×

Everyone who has developed a Titanium application is likely familiar with the Properties API, which allows you to store key/value pairs without needing to use a local SQL database to store that information.  This is a great way to store a few configuration options, but once your application needs to store more than a couple values, storing each value individually can be a bit tedious.

However, if you combine the Properties API with Titanium’s built in JSON serialization capabilities, you can create a very flexible means of storing complex JavaScript objects.  Let’s say we have a JavaScript object which contains user preferences for a game we’re writing in Titanium:

var userProfile = {
  handle: "megaGamer17",
  soundVolume: 10,
  fullGore: true,
  achievements: ["most_deadly", "lemming", "flawless_victory"],
  xboxLive: {
    username:"handyManny12",
    someRanking:12
  }
};

So we have quite a bit of configuration information about our user, and the structure is complex enough where it would be annoying to have to model it in a relational database. This is the perfect situation to use JSON+Properties to store this information. To persist this JavaScript object, you would combine the two APIs like so:

Ti.App.Properties.setString("userProfile", JSON.stringify(userProfile));

This is using the built in JSON namespace to convert the userProfile JavaScript object to a string, and then storing that string in a property so we can access it later. To pull the data back out again, we do something very similar:

var userProfile = JSON.parse(Ti.App.Properties.getString("userProfile"));

Now we have a fully hydrated JavaScript object to work with. The other benefit of using this approach over a SQL database or individual properties is that your data structure is easy to evolve. So if your user profile changes to allow additional properties, like:

var userProfile = {
  handle: "megaGamer17",
  first_name: "Kevin",
  last_name: "Whinnery",
  soundVolume: 10,
  fullGore: true,
  achievements: ["most_deadly", "lemming", "flawless_victory"],
  xboxLive: {
    username:"handyManny12",
    someRanking:12
  }
};

You don’t have to worry about migrating your database or adding code to access additional properties – you can just start using those properties in your code right away (bearing in mind that if you’re updating an app in production, those values will be undefined initially). It’s not rocket science, but this technique is just the ticket for storing complex objects without having to resort to a SQL database.

0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×

8 Comments

  1. Matthew Lieder

    What are the disadvantages to using the properties API? My app has a list of 100+ objects that it needs to store locally for offline access and I’m trying to figure out the best way to do that. I’d love to just put it in Properties and not have to deal with creating and migrating tables, but I’m worried that Properties might not be as reliable or performant as the database? Or is that really not the case?

  2. Kevin Whinnery

    That’s a situation where a database will be a better solution – with that much data, you’ll get better performance from a database.

  3. Masood

    I have a related question. What is the best practice to store sensitive information e.g. password to a web service?

  4. Matt

    localStorage+JSON is pretty handy too…

  5. Interesting approach there. I use property lists for this sort of thing.
    ~~~
    var myList =[];
    myList.push({param1:”First”, param2:”Second”, param3:”Third”});
    myList.push({param1:”1st”, param2:”2nd”, param3:”3rd”});
    Titanium.App.Properties.setList (“myListProp”, myList);
    ~~~

    Then to retreive the data:
    ~~~
    var newList = Titanium.App.Properties.getList (“myListProp”);
    Ti.API.info(‘should return “2nd… : ” ‘+ newList[1].param2);
    ~~~

    I use this exclusively to maintain a local cache of data pulled from a range of web services.

    cheers,
    Chris.

  6. sj101

    Is there a limit to how much can be stored in the properties? Are they loaded from a files when called upon or are the settings loaded into memory when the app loads?

  7. Ryan Gartin

    Very interesting…I will keep this in mind and see if I can cut down on server calls.

    Thanks Kevin!

  8. Kevin Whinnery

    @sj101 – I’m not aware of an upper bound on what you can store in Properties, but SQL databases will certainly perform better for large data sets.

    @Masood – your local database and app properties are not encrypted by default – you would have to use an encryption algorithm on any value you store (assuming your app was ever compromised).

Comments are closed.

Sign up for updates!

Become a mobile leader. Take the first step to scale mobile innovation throughout your enterprise.
Get in touch
computer and tablet showing Appcelerator software
Start free, grow from there.
0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×