Hints to speed up launch- SOLVED!
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- VIP Livecode Opensource Backer
- Posts: 474
- Joined: Thu Sep 04, 2008 6:23 am
- Location: Melbourne Australia
Hints to speed up launch- SOLVED!
Hi Everyone,
OK I have got the test button working and can "test" my app on my device.
I am using a splash stack to provide a non=blank screen during startup.
But still, there is a minute of looking at it before the main stack opens.
I placed a spinner widget on the splash stack and it stops after just a few seconds making me think the other stack is launching (I used the lesson script to send the Open Stack command after 2 secs)
I have tried breakpoints in the OpenStack handler of the main stack to try and see via the debugger what is going on but I have yet to get the remote debug working (yes it is included) I also have a few "Answer" calls in my handlers to know when they are being called (given I can't get the remote debug working, but even these aren't being called.
My app does open after about 150 secs but has obviously skipped a few handlers as the controls are misplaced.
So I guess I am after some ideas as to what could be slowing things down so much.
on opening the main stack I read in some custom properties to set up some arrays, read a text file (maybe 1000 characters) and then just put one of the array entries into a field on the first card (there are only three cards).
All pretty trivial, yet confounding.
Are there things I shouldn't do in the OpenStack or opencard handlers
OK I have got the test button working and can "test" my app on my device.
I am using a splash stack to provide a non=blank screen during startup.
But still, there is a minute of looking at it before the main stack opens.
I placed a spinner widget on the splash stack and it stops after just a few seconds making me think the other stack is launching (I used the lesson script to send the Open Stack command after 2 secs)
I have tried breakpoints in the OpenStack handler of the main stack to try and see via the debugger what is going on but I have yet to get the remote debug working (yes it is included) I also have a few "Answer" calls in my handlers to know when they are being called (given I can't get the remote debug working, but even these aren't being called.
My app does open after about 150 secs but has obviously skipped a few handlers as the controls are misplaced.
So I guess I am after some ideas as to what could be slowing things down so much.
on opening the main stack I read in some custom properties to set up some arrays, read a text file (maybe 1000 characters) and then just put one of the array entries into a field on the first card (there are only three cards).
All pretty trivial, yet confounding.
Are there things I shouldn't do in the OpenStack or opencard handlers
Last edited by jameshale on Wed Dec 22, 2021 2:03 pm, edited 1 time in total.
-
- VIP Livecode Opensource Backer
- Posts: 9663
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Hints to speed up launch
Perhaps it is widgets that are causing the delay? i build Windows standalones constantly, developed on a Mac, a splash stack that navigates to a mainstack that contains seven substacks, and the "app" opens instantly on a dozen different machines.But still, there is a minute of looking at it before the main stack opens.
Craig
-
- VIP Livecode Opensource Backer
- Posts: 474
- Joined: Thu Sep 04, 2008 6:23 am
- Location: Melbourne Australia
Re: Hints to speed up launch
@craig quite possible.
When the app finally does open I notice some of the controls are missing.
In an effort to try to find the source of the slow launch I began commenting out all the handler calls in the open card and stack handlers.
Didn’t seem to make much difference speed wise bur visually things changed as some handlers moved the controls.
The missing controls were still absent but I could see a paler square over the background image where they were supposed to be.
These all corresponded to widgets.
Yet I created a test stack that I built for android with a svg widget in the middle of the screen with a script to beep and then quit. Loaded this on to the android device and it worked fine. In my problem app I reposition the svg widgets, else all is the same, to me, so why they disappear in my slow app and not my test app???. And is this anything to do with the slow launch? I will be changing the svg widgets for buttons antest some mote.
When the app finally does open I notice some of the controls are missing.
In an effort to try to find the source of the slow launch I began commenting out all the handler calls in the open card and stack handlers.
Didn’t seem to make much difference speed wise bur visually things changed as some handlers moved the controls.
The missing controls were still absent but I could see a paler square over the background image where they were supposed to be.
These all corresponded to widgets.
Yet I created a test stack that I built for android with a svg widget in the middle of the screen with a script to beep and then quit. Loaded this on to the android device and it worked fine. In my problem app I reposition the svg widgets, else all is the same, to me, so why they disappear in my slow app and not my test app???. And is this anything to do with the slow launch? I will be changing the svg widgets for buttons antest some mote.
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Hints to speed up launch
I suspect the slowdown may be related to the time it takes for the splash app to load the working stack. But Android doesn't use splash screens, so you don't need it, that's strictly an iOS requirement. The reason the splash image is available in the standalone settings is because LC used to insert one in the community edition.
Try building the working stack directly as the standalone. Include all the widgets. They're missing in your current implementation because they're in the splash stack which isn't in use.
Try building the working stack directly as the standalone. Include all the widgets. They're missing in your current implementation because they're in the splash stack which isn't in use.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 474
- Joined: Thu Sep 04, 2008 6:23 am
- Location: Melbourne Australia
Re: Hints to speed up launch
@jacque, the splash stack was an attempt at solving a long wait with a black screen on loading the app. I.e. something to, see while the app loaded.
I had included the svg widget library in the standalone settings for the splash stack, but they would not show in the main stack. I have now replaced the svg widgets with buttons and gif icons. The controls now appear as expected. However the 2 plus minute wait for the stack to load is still there.
I will try removing all opencard/stack code to see if it is just that stack itself that is the problem.
Will report back.
I had included the svg widget library in the standalone settings for the splash stack, but they would not show in the main stack. I have now replaced the svg widgets with buttons and gif icons. The controls now appear as expected. However the 2 plus minute wait for the stack to load is still there.
I will try removing all opencard/stack code to see if it is just that stack itself that is the problem.
Will report back.
-
- VIP Livecode Opensource Backer
- Posts: 474
- Joined: Thu Sep 04, 2008 6:23 am
- Location: Melbourne Australia
Re: Hints to speed up launch- SOLVED!
Well cutting out handlers called during the opencard/stack handlers located the problem handler.
Reviewing it I realized it was unnecessary as I had forgotten I could store an array as a custom property (doh!)
It is now down to a 10 second launch, which is fine.
Thanks for your comments and hints.
I was able to make some streamlining because of them.
Reviewing it I realized it was unnecessary as I had forgotten I could store an array as a custom property (doh!)
It is now down to a 10 second launch, which is fine.
Thanks for your comments and hints.
I was able to make some streamlining because of them.