Yea, I know android version messed with me, but that’s because I was trying to grab device ID (our app is used on company devices) and the newest updates to some of them wouldn’t allow it, Android doesn’t allow you to pull IMEI numbers anymore.
1 Like
Your testing list is weird. My moto E5 Plus has worse specs than the Nokia 6.1 Plus. that phone shouldn’t have any issues if it’s just the math.
But the resolution & ppi density ?
I wouldn’t think that should have anything to do with it really. I could be wrong, but you would think that the processer would do the math either way and the display size/DPI/aspect ratio wouldn’t be causing your app to stutter like that.
Just a random thought. That’s all I have been doing. A lot of weird thoughts & experiments.
URL not found issue when I tried to update the other comment with this image. So I’m updating it as a new comment 
and what purpose does Screen1 have? Splash screen?
you might want to merge both screens, show your splash screen part and at the same time prepare the main screen part
Taifun
@Taifun
If screen2 issue cant fixed then merging both screens will only cause more issues na ?
If screen2 issue cant fixed then merging both screens will only cause more issues na ?
Btw I have already tried this. I used Juan Antonio’s ‘Renombrar’ software to rename Screen2 to Screen1 & then deleted a sceeen within Kodular.
preparing your main screen takes its time… there is nothing to be fixed… but as already said you can first display a splash screen and then start your procedures to prepare your main screen while the splash screen is showing…
Taifun
1 Like
I think you didn’t notice what I mentioned. I already tried that. But it increases the duration of cold start white screen.
I found a way to solve this issue. The delay in Screen Initialization is due to the amount of math it has to do. So if we do all these math on Screen1 itself we can then transfer the final values to Screen2. So Screen2 wont have to do any math & it will eventually speed up the process.
But I have a few doubts:
- Which is the fastest way to transfer data between screens?
i. storing all calculations in a list and open another screen with a start value ?? or
ii. TinyDB ?? - If I create too many global variables will that cause any delay in Screen initialization time ?
1 Like
there should be no diference… just store all information in a list and transfer it
why do you have to create many global variables? store everything in only one variable and use lists
Taifun
My doubt is will that cause any issues ? especially in terms of screen initialization time ? If so, I have to make changes to my older blocks.
you have to experiment yourself… let us know, wha you find out…
my suggestion is to use only one variable and store the information in a list
Taifun
1 Like
The white flash is still there even though it’s duration is slightly reduced.
I still think the “white flash” is the background before your gradient fills in. Use an image that matches your gradient (Even if you still use your gradient extension) and that should go away.
A good way to test this is make your background a different color and see if that changes the color of the flash.
It is not too many at my opinion.
But if some procedure is too slow you can use a clock to fire some of them after a few seconds. But if it the procedure giving problem is the responsive_sizing I think you should otimize it because it really must start first…
I tried all available methods. Even tried changing the position of blocks. But the white flash is still there.
Responsive Sizing procedure is the one that is causing the issue (that’s why I created a test aia deleting irrelevant blocks. This aia just has the basic ui & responsive sizing blocks only). Btw I did my best to optimize it. No idea how to improve it.