store data

[francof]

Hi all,
can I, in run mode, store a string of data into a label or a field so that it will not lost when app is closed, and data will be available next time I open it?

franco

[Klaus]

HI franco,

standalones cannot save themselfes, maybe that will answer your question


Best

Klaus

[francof]

HI franco,

standalones cannot save themselfes, maybe that will answer your question


Best

Klaus

unfortunately

ciao
franco

[jmburnod]

Ciao Franco,

unfortunately

Yes, but you can store your data to an external file and import it at preopenstack.
Best regards
Jean-Marc

[SparkOut]

I think you might have imagined the wrong answer though.

It is not possible for a standalone to save changes to ITSELF. It is certainly possible for a standalone to save data to another file, whether text file or a separate stack.

Look up the "splashstack" technique to see how you can achieve what you need. (I would try and give some examples but using mobile phone here, it's a pain).

[dunbarx]

Sparkout points out the simplest way to "save" a standalone.

The "splash"stack is simply a stack that is saved as the actual executable. This is all done in the "Standalone Settings" stack. You then add any number of other stacks to that stack file, and save the whole. You can then navigate to the "other"stacks from the splash stack, either explicitly or invisibly. All those other stacks can be saved between sessions.

It is certainly possible to also read and write data to external files; these act the same way, in that they are not the executable file, but rather external files.

Craig Newman

[francof]

ciao all,

Ciao Franco,

unfortunately

Yes, but you can store your data to an external file and import it at preopenstack.
Best regards
Jean-Marc

you are right, but I would prefer to avoid to use an external file. it could be accidentally deleted.
I will try to use the suggested "splash stack"

thanks all, regards.
franco

[jmburnod]

Hi All,

you are right, but I would prefer to avoid to use an external file. it could be accidentally deleted.
I will try to use the suggested "splash stack"

Yes, you're right for this point but I choosed external file way because I think (but i'm maybe wrong about that) it is easier to put the contents of users
outside the standalone when you have to update the app.

Best regards
Jean-Marc

[francof]

ciao Jean-Marc,
hai nuovamente ragione: you are right again!

I've made a test with "splash stack" following this lesson
http://lessons.runrev.com/m/4071/l/1737 ... pplication

but in this way I must upload on the pc (or device) the original file "Main Application.livecode" together the standalone (or .apk) one:
I do not really like this.

best
franco

[SparkOut]

There is a bit missing from this lesson.
You can "bundle" the data stack with the standalone apk, by adding it in the standalone builder. That will include it in specialFolderPath("engine"). This is not a writeable directory, so you can copy the data stack to specialFolderPath("documents") on first run of the app.
I am using a phone to visit the forum, otherwise I would put up a little demo.

[francof]

Hi SparkOut,
thanks for info.
when you can, that little demo will be very appreciated.

best
franco

[jmburnod]

Ciao Franco,

You can use something like that:

Code: Select all

global gMyFolderDataPath
on exportMydata
   put specialfolderPath("documents") & "/" & "MyFolderData" into gMyFolderDataPath
   put gMyFolderDataPath & "/" & "myPrefs.txt" into tPrefFilePath
   put the uMyPrefs of this stack into url ("File:" & tPrefFilePath)
end exportMydata

on importMyData
      put gMyFolderDataPath & "/" & "myPrefs.txt" into tPrefFilePath
      set the uMyPrefs of this stack to url ("File:" & tPrefFilePath)
end importMyData

This one manage one customprop of the stack but you can store also images, sounds and movies with the same way.

Best regards
Jean-Marc

[FourthWorld]

I've made a test with "splash stack" following this lesson
http://lessons.runrev.com/m/4071/l/1737 ... pplication

but in this way I must upload on the pc (or device) the original file "Main Application.livecode" together the standalone (or .apk) one:
I do not really like this.

It may be helpful to keep in mind that this is a feature of operating systems, not LiveCode. All modern OSes prevent apps from being modified while they're running.

So what we have here isn't especially onerous, it's just how software works.

As you build more apps you'll find it's helpful to separate code, UI, and data as much as practical, so you can change any one of those and the impact on the other two is minimized if not eliminated.

All of the OSes LiveCode runs on help us separate data by providing recommended folders for storing it, with less restrictive permissions than the folder where executables are stored so security is maintained where needed but lightened up where not.

In LiveCode, the specialFolderPath function provides a way to obtain the paths to the folders the OS recommends for storing writable data.

The format of the data is up to you and your options are nearly infinite, including text files, binary files, encoded arrays, database files like SQLite, or even stack files.

If you want to store your data in a stack file the clone command can be especially useful, allowing you to set it up how you want it and then make a copy of it on the fly, setting the fileName property and then using the save command to write it at that location.

In some cases you may choose to store UI objects in a stack file that contains the user's data. But as Jean-Marc noted, over the life cycle of the app you'll likely find it simpler to store data outside of UI elements to make upgrades simpler for both you and the user. This means a little extra work up front to page data from wherever you store it into the UI stacks and collect it again to write out to whatever you're storing it in, but over the long run this modest effort pays for itself many times over.

[francof]

thanks all for your tips and remarks. now I'll think about, even if it seems easier to store data into an external file.

ciao
franco