Hi, in the last couple of days, there have been crashes when testing apps using the mobile Thunkable live app. The Desktop live tests not responding, these apps were working fine before.
I attempted to build a fresh project to find out if any components were failing due to Thunkable’s update. The simple app with buttons and labels were working fine, until when I add Web_API components. It crashes my android thunkable live app on phone. But the strange thing is that even when I delete the WEB_API component, it still crashes.
But undeterred, I used the “preview” button on the deign page to do testing which at this point is still working, so I can continued to work on my projects. Then I realized that all my Web_API blocks did not work anymore. Upon more tests, the set URL block is not putting text URL into the blocks. Again, the strange thing is that putting URL in design page works, but this limits my API use as I needed to put variables into the URL (e.g credentials).
Sharing here, in case people who are experiencing similar cases are still wondering what happened. Hopefully the community find other broken things and feedback to the Thunkable Teams.
How I wish it was an app specific issue for which we will have ability to solve. This one is bigger than than. Seemed to affect all apps across many users.
I just hopped back in to work on the API version of my app. I have my own API that does not require a key and would never face expiration. When I go to the URL, my data displays fine. When I put it in the app, I get nothing. I pulled a line out of the API call to change a label to different text and it works fine. As soon as I put it into the API call block, I get nothing.
@muneer, does this not work in the web app version? Last month, when I did a lot of work, it was working great. I just logged back in to try continuing to work on it and I can’t do anything now. Do I really have to put the live app on my phone just to test my API data is coming into my app? Is there a reason for that?
I confirm the presence of a crash in Android. But now the applications are being launched.
Regarding the fact that some blocks may not work after updates to Thukable X. Unfortunately, this happens quite often and your debugged applications may stop working with something.
How to solve it? Only by displaying the data on the screen at each step. The problem may not be only in Thunkable. The problem may be with the API, with insufficiently reliable blocks in your project, with incorrect data, etc.
Why are you trying to find an error, but you don’t use the error block? This is one of the most important blocks.
Remember the main rule - always drive the error block to the screen when debugging a project.
After the last update, I see a problem with Live Test on Android 9. For the test, I use my ACtech demo 2020 application and it took a very long time to load. But when you try to open the screen with a canvas, the application simply closes without any error message. You need to look at this in more detail.
Yes. A simpler application with a canvas has opened, but the sprite display and hide blocks do not work in it. I will try to look at this in more detail, as well as the problem with the WebAPI.
A simple app with WebAPI works for me. So, the problem is related to the fact that something is happening in a large application that causes the crash of screens with canvas and WebAPI. I’ll watch it.
My research has shown the following. In order for the screen to be displayed completely, I place all the components on it in the Column, which I make invisible at the start. After that, I display this Column and all the elements are shown at the same time.
If the app contains only this screen, then everything works fine, but in my complex application, the block that makes Column invisible causes a crash with an error to access memory. I can’t explain this behavior, but it suggests that the larger the project, the more unstable it is and there is an access to memory that should not be accessed.
Simply put, if you have one screen running, this does not mean that such a screen will work steadily in an application with 20-30 screens.