Which would be better performance wise?
I have created a quiz game with only a few screens but with a lot of code to make the transitions from one question to another (800+ Blocks ). I tried to limit the components, but the code itself is making both the app and the Thunkable platform to run slow.
Did anyone else experienced something similar while creating code heavy apps?
And would it be better to divide each question into different screens?
Thanks
I experienced something similar and I had to change to having multiple screens with fewer items/blocks. It seems to have helped quite a bit from a speed standpoint. I was experiencing significant delays on the platform when trying to edit the code blocks but when I split things up it became much more responsive. There is still a significant delay when adding/deleting/renaming components.
Good to know, though I wish thunkable had a “Copy Screen” function.
Did you also notice any app performance improvements after?
Yes, the app performance itself seemed to improve as well; however, I am noticing problems with the app slowing down after it running for a couple minutes.
I’m am convinced that my app is too involved for the Thunkable platform. There should really be some communication from Thunkable on app limitations rather than having people pay for a Pro license on a half-baked offering, investing time creating screens, find out that the platform can’t handle very much on one screen, invest even more time in redoing multiple screens (because there is no copy functionality) and then come to realize all the time and money has been wasted.
I found these references that show this issue has persisted for quite some time without being addressed. I hope future users see this before investing too much time in a complicated app. For simple functionality Thunkable is great…but for larger projects (“larger” is still pretty small in this case) I have to recommend people look elsewhere:
I disagree.
While the speed of the platform and making changes is an issue on some machines and browsers, you should limit the number of screens whenever possible. Now this is a little different in X vs Classic.
Screens require reinitialization of components, etc, and make your app larger, and more difficult to manage. You should view Screens as separate mini applications.
I would always err on the side of one screen if possible.
I have a classic type app with nearly 4k blocks. One screen.
I think the difference may lie in Classic vs. X. I too had a very involved app in classic that worked well. It had quite a few screens with MANY blocks per screen and I never had an issue with it. However, when trying to port that over to X the 1st screen became unbearable to make changes to (from a browser standpoint) and the app performance was hindered as well. I proceeded to break the 1 screen up into multiple screens and it greatly improved on the web platform and the app performance improved as well. However, now I am seeing that after a few minutes and testing the app it becomes bogged down and less and less responsive. I was thinking it might have something to do with there being multiple screens open in the background (I experienced this in Classic and there is a close screen option there that eliminated this) but X doesn’t have the option to close a screen. I then proceeded to test the app without changing screens…simply typing in an input box, deleting the text and continuing to enter and delete the text until it became very unresponsive (about 10 cycles of text).
Do you have any utilities installed to see what memory or cache is being used on your device.
I would start your app, then do a snapshot of the memory and cache, do your test to get it unresponsive, and see the memory and cache
Appears to be a resource leak for sure.
Does it happen in Android and IOS the same?
I’ve only started testing on Android. I tried clearing the cache, testing and then checking the cache again and there wasn’t anything of particular note (see screen shots below - cached increased by 356kB). It seems like the text input fields are really what cause it to slow down. I tried creating a new app with just 1 input field and it doesn’t slow down like my more complicated screen does (543 blocks). A text input on a screen with 256 blocks performs much better; however, after a couple minutes of constant text input entries it begins to slow down.
Do you have a loop or a rogue timer?
What about memory and CPU usage?
No loops or timers are used. RAM usage went up by about 220MB when Live View was started and then fluctuated about 50MB. No other app performance is affected, only the Live View app. I tried download the APK to the phone as well to see if it might just be a Live View thing but the APK responded the same.
My more complex screen has 10 animations on it and it appears that those help promote the app slowing down (I don’t think it’s the only reason though because the screen with about 250 blocks has 1 animation and it slows down as well…it just takes longer). You can try testing this app https://x.thunkable.com/copy/63884810e68791dd2bfc864878ea30e4 to see if you see similar issues. Just type a lot of text in the input field, press & hold to delete & keep redoing it and you should see a marked slowdown in performance.
