Hi, I’m (still) a Thunkable n00b and haven’t been able to find a solution to this problem. I’m sure it’s simple, but I’m learning and could use some more help.
So, I’m building a lake data and local weather app for a friend with a lake house. The APIs I’m calling are returning “null” when there isn’t any info surfaced (i.e. for cloud cover and precipitation).
Instead of “null”, I’d like to display custom text like “Clear” or “None,” but I haven’t been able to find a solution in the docs or here.
Your if block is checking to see if null is true. I’m not even sure what that means. Computers are very literal so even though you’re thinking “I want to check if this cloud coverage value is null,” the actual blocks you used are just checking to see if the value null equals true or false. It has no idea that you want to refer to the API/JSON response at that point. There’s no context for that if condition.
What you want to check is if a specific (named) JSON property is null. So you’ll need to use the equals block from the Logic drawer.
What is the name of the JSON property you want to check and what is the value you want to check for? Is it null, is it zero, is it a blank string (“”)? If the name is data[1].cloud, then you would add that to the if condition. Also, double-check the spelling because when I looked at the Weatherbit documentation, it seems like that property might be called data[1].clouds.
Ahhh, ok. I appreciate you clarifying the process. Now it makes sense as to why it was failing – it didn’t understand, even though it was perfectly clear in my brain.
The 1st JSON property I want to check is data[1].clouds (good catch on my typo, thx) and it was returning the value null. And the 2nd one is from a different API and was returning a blank string.
Do you know if there’s another topic that shows how to use the equal block to replace the null value with “Clear” and how to handle a blank string? If so, will you point me in their directions, please?
I added error checking because it’s important to do that when using an API, especially because attempting to parse JSON data that doesn’t exist can crash an app. But for testing, you could certainly leave that out if you prefer.
P.S. The test block is kind of fun to use once you get used to Thunkable more. You can use it to make more efficient code – or at least to reduce the number of blocks needed. Here’s another way to do the same thing as above:
Hmmm. Well, this is weird. The 2nd API I’m using liked those blocks for all of the different states (ice, snow, rain, freezingrain)… except for null.
For null, I had to switch equal to not-equal to get “None”. BTW, I’m fine with this, because the output is what I’m looking for. But could it (will it) create problems later?
Using equal
Output is “Label”
Using not-equal (and showing blocks for other states)
There’s a difference between the green null block and the text string “null” which you used. Please try the green null block and see if that works better.
Null is the absence of a value. The text string “null” is a value with four characters so it’s not going to work properly if you in fact don’t get a value from the API.
