Very slow launch of stack data, from a Splash stack

[trevix]

I am using, for mobile, the Splash method for my standalone. A splash stack that launches the real stack (named "ReferiTOP").

On the very first launch of the standalone, the splash stack copies the folder containing the ReferiTOP stack (and other stuff) to the Documents folder (so that I am able to save changes).
After that and on subsequent launches, the Splash stack opens the ReferiTOP stack using a "go stack filepathOfReferiTOP" and hide the Splash stack.

The problem is that timing between the "go stack filepathOfReferiTOP" command and the PreOpenStack of the ReferiTOP stack is around 13 seconds!!
Too much in my opinion (the ReferiTOP stack is 18 MB).

Either I am doing something wrong or I should use, on the Splash stack preopenstack, this line (if it is correct. Can I use a path?)

Code: Select all

set the stackFiles of me to "DataStackName,filepathOfReferiTOP"
--ex.: set the stackFiles of me to "ReferiTOP,/data/user/0/com.trevix.it.segnapunto/files/Referi_/ReferiTOP.livecode"

Thanks for any help.
Trevix

[richmond62]

At the risk of telling you something you both know and have already thought about I'll tell you a short story:

I got fed up with Splash stacks and opted for something else:

An image on the main stack that is displayed for a short while before it disappears.

[trevix]

Hello.

An image on the main stack that is displayed for a short while before it disappears.

I am not sure to understand.
The reason for me to use the Splash method, is that I need the standalone to be able to update itself, downloading updated ReferiTop stacks from the cloud, without the user having to update from the Apple or Google store (the Android hardware is out of reach or the user doesn't have a google account)

Regards
Trevix

[richmond62]

Here's a "bog basic" stack with a splash screen that disappears after 2 seconds.

I need the standalone to be able to update itself

I am sure you can do that via a substack that is NOT the one displayed after the splash.

[Klaus]

Not sure, but looks like you are only passing the STRING -> filepathOfReferiTOP instead of its content.

Try this:

Code: Select all

put "the/long/path.livecode" into filepathOfReferiTOP
set the stackFiles of me to ("DataStackName," & filepathOfReferiTOP)

And where is that stack located? In what specialfolderpath?
And be aware that you can only modify/update/write/save if the stack is in e.g.:
specialfolderpath("documents") where we have write permission!

[dunbarx]

Richmond.

I do not understand. I use splash stacks, but never display them. They are only a vehicle to "hold" the executable, so changes to my working stacks can be saved without issue.

We all know this.

So what do you do? Save into external files? Is there any other way to save changes?

Craig

[trevix]

Not sure, but looks like you are only passing the STRING -> filepathOfReferiTOP instead of its content.

Try this:

Code: Select all

put "the/long/path.livecode" into filepathOfReferiTOP
set the stackFiles of me to ("DataStackName," & filepathOfReferiTOP)

And where is that stack located? In what specialfolderpath?
And be aware that you can only modify/update/write/save if the stack is in e.g.:
specialfolderpath("documents") where we have write permission!

Yes Klaus. I am doing all you said.
I am saving to specialfolderpath("documents") and I can pass the correct path to the stackfile property (for simplicity I shortcutted my post).
My questions, apparently not very well expressed, were:
- Can I solve the long delay using the stackFile property?
- Am I allowed to set the stackFile property second item as a path? In the dictionary it is stated:

..the short name of a stack, a comma, and the name of the file that contains that stack.

I read that the second item should be a file name, like "ReferiTOP.livecode", not a full path like "...path.../ReferiTOP.livecode"

May be I should have just tested it. Would be nice tough to know if I stand correct. Thanks

[trevix]

Doesn't work (in order to shorten the delay.)
I guess that using stackFiles or opening a stack using the full file path, is the same thing.

Off course I understand that launching a compiled standalone or a LC stack from a compiled standalone, is not the same thing.
Didn't know how slow the second would have been...

After all this work on changing my app to a Splash method, I found myself with an app that loads in more then 13 seconds.

[richmond62]

My apps save to text files.

[jacque]

The stackfiles is just a convenient way to specify a file path but it doesn't change the way the stack is loaded. My guess is that the stack is large enough that it takes a long time to read into memory. If you open the stack directly in LC, does it also take 13 seconds to open?

Also, is the delay only on first launch or does it happen every time? If only the first time, it is probably still copying the stack to the documents folder.

[dunbarx]

Jacque.

What would a stack have to be burdened with to take 13 seconds to open? A million images? The largest stack I ever made is about 6MB, and it contains no images, music or audio files at all. Only half a dozen substacks, with buttons, fields, scripts and a couple dozen native graphics.

It opens instantly from the finder in a new session where LC opens alone. I do have a fairly fast Mac.

Craig

[trevix]

My app ("Referi" on the stores) is full of libraries (Bluetooth, check Wifi and internet, Analytics, Azure, FM, etc), runs on mobile and the data stack is password protected. Lot of stuff before it can get to a rest...
On second launch:
On the Mac with LC open takes 12 seconds (8 sec if the data stack is not password protected).
On a fast Android 14 phone, takes 23 seconds (password protected).
On a not so fast Android 11 mobile, takes 34 seconds (password protected).

My real problem is the 10-13 seconds, from when the Splash stack launches the data stack to when the PreOpenStack of the data stack start running (nothing is loaded yet on the PreOpenstack).

Having so much to deal with in the launch process is something I have to cope with, considering what the app does. What I don't understand are these 13 seconds needed after the "go stack...".
Unless this is due to the password protection. But I think that, using a splash method, II need to do it, if I don't want to give away all my work.
Any suggestions are welcome.
Trevix

[SparkOut]

The OP said this is for mobile. Modern devices are pretty powerful but don't compare with a desktop these days.

I wonder also about the data being saved in the stack that takes so long to open, and how. Embedded images are one possible culprit. Another thing that might be relevant is whether there are many fields containing text, especially formatted text on the first card? The engine has to pre-render field content, so moving data out of fields and storing as custom properties or in text files might be the way to go. Separate the data from the display anyway.
I once had a splashstack app that saved a new card for each new product into the working stack. 30 cards was enough to cripple it. Redesigning the working stack to have one main display card and reading stored data into the fields and image placeholders when changing product, instead of changing card, was exponentially more efficient than the traditional use of a stack like a "card database". On mobile.

[trevix]

There is nothing in between my "go stack XX" and the PreOpenStack of stack XX.
The XX stack opens on a card with a logo (small size) and at the beginning of the preOpenStack there is a timer log script line to see how long it takes.

I did a test on Android 11, using a NON password protected XX data stack and I con confirm that the long 13 seconds delay is due to the password protection.

May be I should compile also the data stack (it does not need to save changes in my case. It only gets replaced by a newer version, if needed).
And, somehow, launch it from the Splash stack.
Anyone is doing this?

Trevix

[jacque]

Interesting. You could try setting the passkey of the stack before the "go stack" command and then at the end of the preOpenStack handler set it back to empty. I don't know if that will work but it's an easy experiment. Also, you could try locking messages and the screen before opening the stack. You'd need to specifically send the preOpenStack message in that case.

Just some thoughts.