Retaining the data after the application is closed

[pkmittal]

Hi, I experimented with specialfolderpath("documents").. I could read and write using absolute path.. Thanks to Claus for helping me on this

I think the data would be lost when we close the app.. Is there a way so that we can retain and use the data when the application is launched next time.. Do we need to install and store the app on SDCARD for that? How do we do it? Any standard way or example of doing it.

[Mark]

Hi,

Once you have written data to a file, that file will continue to exist when the application is closed.You can read the data from the file when you open the app. The app doesn't need to be stored on the (internal) SD Card.

Kind regards,

Mark

[pkmittal]

Thanks.. What is the difference between storing data on SD card and in documents folder?

[Mark]

Hi,

You're asking the wrong question. I think you need to ask what's the difference between installing an app in the default location versus the SD Card. There isn't much of a difference, except that it is a different hardware component, similar to storing something on the internal hard disk of your computer vs. an external hard disk.

The second question should probably be where is the physical location of the documents folder? Frankly, I'm not sure, but I think it is /mnt/sdcard/Android/data/<app bundle id>/files/. I'd have to test this, though. /mnt/sdcard is the built-in SD Card.

The last time when I tried, I couldn't easily put files in a different directory, but I think it should be possible to use an absolute file path such as /mtn/externsdcard/myfolder/myfile.xyz, which would be on the external SD Card if you have one.

Kind regards,

Mark

[townsend]

And then there's the question about how to save the data.

Of course the simplest way to use a splash screen and have your main app as a sub-stack.
This way you can save the data of all objects in one fell swoop with one line of code.

Code: Select all

on mouseUp
   save stack "anyName"
end mouseUp

[Klaus]

Hi all,

standalones (= mainstack and its substacks!) cannot be saved!

Even if you add the stacks to save as separate files via "Copy files",
you need to copy them to the documents folder, too, to be able to "save"
them, since you cannot write (= save stack!) in the ENGINE folder.

Best

Klaus

[Mark]

Klaus is right and from your answer, I'm not sure that you understand what's going on, "townsend". Any file needs to be saved in the documents folder and I explained where I believe the documents folder is located, but that isn't really relevant. Just remember that you need to save any files in specialfolderpath("documents"). If you do this, your data won't be lost.

Kind regards,

Mark

[townsend]

Thanks for the correction Mark-- Klaus--

Just trying to be helpful. Now I've learned something important.
Only desktop deployments can save and retrieve sub-stacks.

[Klaus]

Only desktop deployments can save and retrieve sub-stacks.

Not really

Standalones cannot save themselves, neither on the desktop nor on mobile devices on no platform!

And remember that on modern multi-user OSses like Win7 and OS X, only users with
ADMIN permissions are allowed to write (save a stack) in the "Application" folder!


Best

Klaus

[sturgis]

I think the issue here is a matter of semantics. So.. A substack is by definition a sub of the main stack, IE part of the stack. There is an option in standalone preferences to break out substacks into their own separate stack files (In which case they are no longer substacks they're mainstacks in their own right.. if I understand this correctly) and yes if you make a splashstack that a) copies the stack you want to be able to save from engine to the documents folder then yes it should be able to open it and save it as you are talking using the splashstack. But its not a substack at that point.
I don't let the engine split stacks for me, I just make the splash and then setup separate stacks by hand and add them with the copy files pane.

Did a test, created a splashstack (that I don't leave up long enough to notice) added a stackfile to the copy files pane, put in an openstack handler (might work with preopenstack) and it works ok. So yes if you want to store data in a stack file it works.

Of course flat files and databases work equally as well.

The script I use to flip to the second stack is this:

on openstack
if there is not a file (specialfolderpath("documents") & "/mystack.dat") then
--you would probably want to create a folder and place the stack file in there instead of the document root like I did. DOH
put URL ("binfile:" & specialfolderpath("engine") & "/mystack.dat") into URL ("binfile:" & specialfolderpath("documents") & "/mystack.dat")
end if
open stack (specialfolderpath("documents") & "/mystack.dat")
send "closeme" to this stack in 50 milliseconds
end openstack

command closeme
close this stack
end closeme

For testing I just put a field with a "textchanged" handler in it so that every time the text is modified the stack saves itself. Works like a charm.

If you do things this way make sure you force the inclusion of all externals that are needed for your app in the splashstack.

Also note, if you're planning on doing something like this for IOS too i'm not sure what apple would have to say about it or if its allowed.

Also,

Thanks for the correction Mark-- Klaus--

Just trying to be helpful. Now I've learned something important.
Only desktop deployments can save and retrieve sub-stacks.

[Mark]

Hi,

Personally, I prefer to save stacks in custom properties, so I can do this:

if not (there is a file myPath) then
put decompress(the cStack of me) into url ("binfile:" & myPath)
end if

Apple seems to allow this. It would only be a problem if you download the stack from a server or if you allow the user to write his or her own code, which would be saved in the stack.

Kind regards,

Mark