Debugging Crashes in live view

Questions about Thunkable
1

Hey Guys,
I have been working on an app for several weeks and did never get the live view to crash. But since some days the app crashed regularly. Sometimes right after start and everytime when loading one special screen.
I have checked all blocks but can not find a problem. What bothers me: the crash on the startscreen does not happen everytime and when I download the app on my android, it does NOT crash at all…

Any ideas where to look? (Can’t share the code as I use lots of api requests with keys)
Any help is welcome!

2 Likes
2

Look for somewhere where you’re feeding a block something it can’t handle. Getting object properties of a non-object, getting item 4 of a two item list, inserting a list item into a variable that doesn’t have a list, setting something to a variable that isn’t defined, etc.

If you have a consistent crash on one screen, I’d start unplugging blocks until it stops crashing. Then look at what you unplugged most recently.

3 Likes
3

The first thing comes to mind is stored variables. Are they used in your app and how are you handling them?

The other thing is the famous API and next is computations that would lead unexpected results.

1 Like
4

Ah, the API. The perpetual enemy and bane of any Thunker. That’s a very likely possibility.

2 Likes
5

I make heavy use of them. What thinks should I look out for?

1 Like
6

Always check if the stored variable is null before performing any operation on it.

Thunkable cannot correctly add a list to any variable that is null. If you are trying to add a list to app variable or stored variable then check if null first and assign it Empty List block first.

2 Likes
7

Thanks for the advice! When initializing a stored variable, would you recommend to assign it an empty text/list/object instead of null?

2 Likes
8

Yes,
Thunkable does not know what to do when it encounters null. This is the reason you get the crash.

So unless you do not deliberately want a null, you should avoid it in the code.

1 Like
9

Do this:

1 Like
10

You can try my method of debugging:

1 Like
11

Hi Muneer,
I have a “followup question”:
When you told me about the problems thunkable has with null I changed the initialization of my variables to an empty string (the red textblock).
I just found a bug in my code where it always crashed:
I assignet an “app variable” with an empty string to the “open link” block. When this block get call it crashes. So iam curious: do I need to check EVERY variable bevor using it? If so, what do I need to check? null, empty string, anything else?

thanks in advance :wink:
greetings Torben

1 Like
12

Not for everything.

  • The object blocks like get property will crash if the object is null.
  • The API response will crash the system if you try to use anything in it and it happens to be null.
  • Using the stored variable while null.

Now your telling me using the open link block crashes the system.

But certainly not for everything.

13

Well, it’s probably not going to be a good user experience if your user presses the button and nothing happens because the variable isn’t set, either. It makes sense to either prevent lack of data (i.e. by setting defaults that cause sensible behavior in the app) or to give a human-readable error message (“please enter your email before continuing”). When you check variables, you’ve got an opportunity to provide a user-friendly response from the app, not just to prevent it from crashing.

1 Like
14

Well it depends:
Let’s say you have a form. You ask for several inputs which you save in an object or separate variables. Some are optional. If the user leaves the input blank, you store “null” or an empty string. If this leads to problems down the road in thunkable, it is a problem.