It might not be something of importance but remember that nowadays Thunkable servers are slower on performance and your changes might not take effect immediately.
there are times that I had to close and test again 2 or 3 times to see the affect of my changes.
I have seen the refresh block crashing the app but when I insert a wait block just above it, seems to fix the issue.
I noticed that with the web app deployments, so I am trying to be mindful of that. However thanks for the reminder as it wouldnāt hurt to wait a bit longer.
Great point. When in doubt, I do something obvious like change the screen background color - then Iām sure Iāve got the updated version ā or not!
I have tried a few things and have had no luck. But in case something pops out at you, let me know. Here is what I have done at this point. (FYI, I took @catsarisky 's advice and started changing background colors to make sure my updates were going through). IDK where to go from this point.
UPDATE: I removed my screen from the top navigation, therefore removing the top navigation from the screen, and it worked without crashing. Any thought on why?
I had problems one time with top navigation and a navigate to block another screen. Iām trying to reproduce as a sample project and canāt get it to do soā¦
Hmm. My older project (both are snap to place) has a different style ānavigate toā block, that will /not/ navigate to a page within a top navigator (but doesnāt crash - at least in iOS) ā itāll only navigate to the top navigator. The project I just made has a slightly different looking ānavigate toā block that doesnāt navigate to navigators. Butā¦ neither one crashes (on iOS), so Iām stumped at least until Iām home later tonight and have my Android device to test on. Hey @jane , did the ānavigate toā block get a stealth overhaul?
The navigator component acts weirdly. I tested it last week.
It seems to be ok with some screens and not the other. I had an empty screen that crashes the app every time but failed to pin point the error behind it. I ended up removing the navigator and adding it again and it worked with me. Iām now testing it on daily basis waiting to witness it crash again.
I donāt know about the stealth, but I think I got tunnel vision and I have found the problem. I was bested by a web viewer. After my tests today, I found out that my settings page was what was giving me issues. My settings page had a VISIBLE web viewer, but once I removed it and made it a button to push to open the link in a browser, everything is working. Sorry I didnāt catch this earlier. Based on the suggested troubleshooting in this form, I was looking for a NON-Visible web viewer on the pages I was directly navigating too. My guess is with the navigation, it might āloadā all of the pages in the navigation (which is where my settings were), and that is what broke it. So even though I was not navigating directly to my settings, the web viewer there broke it.
Never the less, this presents a different issue as a visible web viewer was crashing the app. But that might be a issue for another topic.
So. I canāt replicate this crash on my Android 7 testing device. I was going to file a bug report with a sample project, but I canāt make it crash. What am I missing?
(I also canāt make it crash with a non-visible webviewer, so maybe Iām just doing something wrong!)
Interesting. I wanted to post a sample project that crashes over on Github because I donāt think thereās a good clear one, especially not one involving the webviewer in a navigator that bnice found today, but without being able to trigger a crash, I canāt. If youāve got time and inclination, I hope youāll post a Github bug report.
You were right. The web viewer cannot be invisible (even if it is visible in a row or column that is invisible)
He tried to have the web viewer inside a column row and made the container of the web viewer invisible and the app kept crashing although the web viewer itself is visible. Which is weird enough for me and the same screen runs perfect on Android 7.