Those of you who have read my last thread about event listeners have seen my frustration. When I finally found a work around, this involved navigating between screens without the use of the Navigator containers.
Now I have a new problem. When I navigate between screens using buttons instead of the navigators, my ‘on start’ block executes on every landing in addition to the ‘on open’ block.
Go back and forward in the sample app above to see what I mean.
So… now I have phantom Variables that I can’t delete (thread gone unanswered), Event listeners that are riddled with bugs (also no resolution) and now screen execution codes that fire when they aren’t supposed to.
These are fundamental issues that are common to all features. Variables and screen manipulation are the essence of any programming language and/or platform yet still, Thunkable decide to roll out fresh features before addressing significant bugs with the existing ones. I am at a loss as to my next step.
thanks for your response @v.krishna but I need my script to run on start of the screen only. I will add a trigger variable and if then statement to the ‘on open’ if I must but I have used these two blocks successfully in the past.
Where are the troubleshooting docs you are referencing?
hi, actually I an referring to the link in the thunkable docs and even me I used to face the same problem as you the link:https://docs.thunkable.com/troubleshooting#live-test-android just check this out and see , the problem you are facing is some what related to this
and even my app should not have a navigator becoz is some what related to some official thing. So… I too didn’t used an navigator and instead used the 'navigate to “screen name” ’ block
My experience has been that the sequence of events in Thunkable (event listeners, on open/start), external application events (eg google sheets updates), etc., change on a regular basis. Other subtle changes in variable declaration, JSON object parsing, list management, etc. also change.
These changes appear to be related to release (major and minor) of both the web develpment platform, as well as the Live Test environments (android, iOS, and Web).
I am working on my second MASSIVE application (10+ screens, 10,000+ blocks). My experience has taught me that the simplier you keep your app the better. Sophisticated real-time updates and rich user experiences are, at best, “brittle”. Although Thunkable X has been in production for several years, it is best to treat Thunkable as “perpetual beta”. The production code base changes rapidly, with little notice or considerations for backward compatibility. While developing my second massive app, taking this approach has made my app more stable and greatly reduced the per capita profanity in my home.
I don’t mean this as a disparagement of Thunkable. I continue to believe that Thunkable has unbelieveable potential to transform app development. But tempering your expectations will go a long way in improving both your apps and your mood.
Thanks for the insight. My project/app is similar in size to yours however I have already reduced the Thunkable part dramatically by using API’s and NodeJS functions in Firebase. I chose Firebase only because of the Thunkable interface.
It is a shame that such fundamental components such as Variables, screen navigation and Event listeners can’t have more vigorous quality control by the developers. Thunkable seems to be a great concept with remarkable potential but not suitable for developers seeking commercial use.
I am forced to look at Cordova and HTML5 even after spending over six months developing my Thunkable app. I can personally forgive the bugs and I love the challenge of finding workaround solutions however, upon release and product launch, a reputation is only as good as the weakest link in any project.
I think every developer has its own preferences and wishes. Personally I wish that there would be more energy to solve basic errors and less energy in developing components like “video recording” that are -at least in my view- less important.
I also discovered the bug that the block “when screen1.starts” gets executed more than once. I think this happened approx. 10 days ago.