Persistence on iOS (and Android)

Ben Rubinstein benr_mc at cogapp.com
Sat Jan 26 14:22:28 EST 2013


Thanks Jacque (and thanks Monte) - I don't need to do anything in the 
background, I just want to save state so that the app appears to have been 
suspended rather than shutdown.  Thanks for clarifying what messages to use 
and that they are reliable.

Is there consensus on the best way to do this - text file, database, or do 
everything in a dynamic stack that's saved (back to the old splash-screen app 
approach)?  My app will have a SQLlite database that it's using anyway - I can 
use that, to minimise the datafiles that I'm storing, but is there any reason 
to think that it would be better/quicker to use a simple text file which can 
just be overwritten, rather than updating a database?  And is there lore on 
doing everything in a read-write stack, saved on shutdown?

Also - is the story the same on Android?

Many thanks,

Ben

PS - Colin, this might make a useful chapter in the next edition of your 
excellent book, hint!


On 25/01/2013 19:42, J. Landman Gay wrote:
> On 1/24/13 5:23 PM, Ben Rubinstein wrote:
>> Is there such a thing as suspend/resume on iOS, or just startup and
>> shutdown?
>>
>> As far as I can see, when a LC app is suspended and resumed, it's in
>> every way restarted.  Unless we save our state explicitly in a
>> file/database/stack, and then reconstruct it on startup.  Is that
>> correct, or am I missing something?
>>
>> If that is correct - is the shutdown message a reliable signal that our
>> app is going to be backgrounded, on which we can save whatever data we
>> need to restore state?  Or do we have to save at every change in state,
>> just in case we're about to be suspended?
>>
>> ... and is it the same approach on Android, or do we have suspend/resume
>> there?
>
> There's no suspend/resume, apps always quit. You'll need to save the current
> state so that the next time it opens you can reset everything. Startup and
> shutdown are reliable messages though, and you can plug into those.
>





More information about the use-livecode mailing list