Saving data/settings

[Richard Gaskin]

pink wrote:

 > I'm interested in learning how people save data and settings for
 > applications, especially on mobile devices.
 >
 > The method I have been using is to create an invisible data stack
 > and save the data as custom properties. I like this the most because
 > I tend to put most of my data and settings into arrays, and this
 > requires the least amount of steps and no encoding to read and write.
 >
 > Reading and writing to a text file also works, but does require some
 > sort of encoding and decoding to save arrays.
 >
 > I've experimented a little bit with local database files. In
 > particular I've tried Andre Garzia's database library, and
 > Livecloud's local database, both of which are pretty nice.
 >
 > I'm curious what everyone else uses, and what do you think are the
 > pros and cons of different methods?

There are may ways to store data, each with its strengths and weaknesses.

I don't believe in "best", a "one size fits all" that'll cover every 
need.  App requirements are far too varied to limit oneself to just one 
storage method.

"Best" is what's best for your data structures.

If you need to store LC objects, you'll want to use a stack file.

If your data is a good fit for "normalization" via relational tables, 
use SQLite for local storage, or MySQL or postpreSQL for servers.

If your data can be well expressed with key-value pairs, use arrays 
locally, and a key-value store like CouchDB or MondgoDB for servers (I 
hear there's a great library available for using CouchDB in LC <g>).

With any of them, it'll probably be useful to write getter/setter 
accessor handlers for them, so all the specifics of access are handled 
in one place. With accessors, you can write just a single line to get or 
put data anywhere throughout your code.

With that convenience in place, you won't need to worry about things 
like arrayDecode/arrayDecode, you can just include those in the 
accessors you'll need to handle path stuff and other details, so 
everything is in one place.

Sufficiently generalized accessors may even allow you to change the 
storage mechanism later on without changing any other code beyond those 
two accessors.

Lots of options.  Total freedom.  The world is your oyster.

Let your app's business logic be your guide.  Choose the storage model 
that fits your data structures, not the other way around.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com