Persistent data in mobile apps.

[Tribblehunter]

Hi all.

Have searched for this but not clear in my head, so I thought I would ask the users.

Building mobile app. User has to enter information which is stored when app closes so settings etc are the same when app is next ran. Also for if app closes unexpectedly.

Unsure if SQlite is the way to go or custom properties. Or is there something I missed?

'A shove in the right direction enabling you to learn is always better than being told the answer and not finding out for yourself'.

[sefrojones]

Here's a simple example of how to save the state of your app by writing to a .txt file in the specialfolderpath("documents")

http://lessons.runrev.com/m/4069/l/1522 ... ile-device


This should lead you in the right direction!

--Sefro

[Tribblehunter]

Thanks Sefro.

That is exactly what I am looking for. Been building in app inventor for a while and now transferring all programs to Livecode........ and re-writing quite a bit of them as well!!

[Tribblehunter]

Now i am further on!!

Would it be better to use sqlite for this? I have information which I need to assemble that will need to be emailed once app has run. (used the tinyDB in app inventor for this in the previous version of this app). It would also hold the persistent data too.

[Simon]

Hi Tribblehunter,
I think this depends on how much information you are storing, 5,000 lines of text can open in very little time.
I use both text files and sqlite, I like the text files because it takes very little to view their contents (while debugging). But if the person at the other end of the email is used to getting a db then you should probably stick to sqlite.

You can attach a db to you stack when you deploy your app so you don't have to create it each time and it can already hold values. If you need help on that just ask.

Note: Android Mail has a 5 MB attachment cap on it.

Simon

[Tribblehunter]

Now that will work. Email consists of info in email as text (easy to read) and in an attachment to be imported into database.

Good point about text file also. Didn't consider the need to read it easily.

I see busy times ahead!!

Brian