B4A App starts with tiny (minimized) screen and waits 15 seconds before showing the real size screen.
Using a phone with Android 8.1.0. The Layout is for size 720x1440.
What could be wrong?
The silence on this thread is because you haven't really given us much to work with. Your screen looks pretty good, so presumably you're an experienced programmer. Perhaps it's just that you're under pressure and are experiencing brainfreeze. Happens to the best of us ;-) Here are some random ideas, hopefully one of them will spark an aha! moment
Does it gradually increase to the larger size, or stay small for 14 seconds and then jump to large size?
First thought would be to search for Sleep statements. Did you use any during earlier debugging?
Second thought would be to track down the point of execution where it changes from small to large.
- Log the start and end of the initialization code.
- Log a main-loop counter.
- Log every LoadLayout call.
Third thought is that perhaps your program is using 100% of available CPU, thus nothing left for background/UI/low-priority tasks.
- What happens if you put a Sleep(100) millisecond delay after the LoadLayout (which will give the UI a chance to update the display).
- What happens if you put a Sleep(20000) 20 second delay after the LoadLayout - does it still grow large at 15 seconds through the 20 second delay?
This seems to be a great community.
To be honest, I even didn't expect an answer. So Thank you very much.
I will take your advises into account.
But first of all I installed the app to an old Samsung node with Android 6.0.1 and the result is:
The first screen is not so small as on the other phone (Gigaset 100) and the delay before the right size is shown is only 1 second.
I'm also using text to speech in this app and the difference between the phones is: It takes two minutes to speech output on the Gigaset after the first click on the relevant button, then the speech comes synchronously after button clicks. This effect in not on the Samsung. The speech starts immediatley after relevant button click.
It seems to be that the Gigaset processor is extremely slow.
The advantage of pessimism - life is full of bonus surprises!
also using text to speech in this app ... two minutes to speech output on the Gigaset after the first click ... Samsung. The speech starts immediately after relevant button click. It seems to be that the Gigaset processor is extremely slow.
What about after the second click? Is it possible that the language data is preinstalled on the Samsung, but has to be downloaded on demand to the Gigaset? Or that the libraries work differently in some fashion? How can we pin down that the two-minute delay on the Gigaset is a processing-speed delay, and not a download delay? Do other voice-output apps have the same speed difference between the two phones?
It is realy the TTS lib which makes trouble.
My app has three modules: main, seite3, seite4.
Text to speech is only used in module "seite3". But unfortunately I had the lines
"Private tts As TTSID" and
also in the main page. Now I deleted both lines from main and now the app starts immidiately with the right screensize.
During start of module "seite3" however it takes now the 15 seconds again (on the GIGASET) because of initializing the tts.
Well I have to check now if it is possible to preinstall the tts-Library on this phone.
Its always helpfull to talk about such challenges with others instead of trying to solve everything on your own.
The Gigaset GS100 phone seems to be a budget phone with a slow CPU/GPU and slow internal memory. Is it going to be worth the effort to try to get your app running better on this when the performance seems to be already acceptable with on an outdated Samsung and probably better still on more recent mid-range phones?