Get requested API data into local Data Source and Data Viewer List

Dear thunkable community,

I am trying to retrieve some data I requested via an API and parse it into a Data Viewer List. For that I followed the official documentation and created a local data source called “ControllerList”. The point why I’m doing this is because I need a key-value mapping of my data. I can’t store the info in a normal list as I would lose assignability for further API queries.

My approach is the following:

And the data source looks like this:

Regarding the API response, I created a variable (type = empty list) and as soon as I send the GET message I will save the response into this variable with a for-each loop. Unfortunately, the app doesn’t want me to get things work. It crashes or the data loads not as expected.

For better understanding I shared an example (Thunkable) and would be happy if anyone could help me out here. Maybe even @catsarisky :slight_smile:

Please note: There is also a normal “List Viewer” where I tried to fill in my response data (with variable “TestList”). But this didn’t work as well.

Many thanks,
Pieve

1 Like

You’re seeing this in Live? Download? Web preview? Web app? Could you add information on which (and specific version of Live and/or OS) ? :slight_smile:

@pieve: This crash doesn’t look to be related to the datasource bugs. It’s an API parsing problem.

Here’s what you need:

FYI, the code you shared and the image you posted don’t match - I’m guessing you were making changes! :slight_smile: You were really close on parsing, but notice that I’ve put not calling Web_API until you’re done deleting rows. (Not because calling WebAPI would be a problem, but because creating rows would be.)

2 Likes

@catsarisky Ahh I see that looks like it caused the problem. :slight_smile: To be honest, I made some changes to the example, trying out things in an isolated environment hihi. This time I made another, where I won’t make any changes: Thunkable

The problem still exists in some ways. As you can see the data loads (now I changed it to the real API URL I am using), but the Live App in Version 279 still crashes:
ezgif.com-gif-maker

On Live Test and Preview in my web browser (Google Chrome) the app won’t even load.

1 Like

This indicates a problem in parsing or assigning of wrong API response keys to your variables (list or object).

Yep - this API response is more complicated. It’s an array of arrays (of arrays?), and actually SOME values are OK in your loop (if you add a wait block, you’ll see several values appear before it crashes the app. However, something in the loop that way you currently have it (in the copy link you shared second) doesn’t have the properties you’re trying to assign…

2 Likes

In the API response id=17 has uid of null and this is whare it fails.

So your loop will create 3 rows and will fail in the forth row.

You can fix it with the following
image

1 Like

… and you might want similar blocks around the other two values, if there’s a chance of them also being null!

1 Like

Well… you both @catsarisky and @muneer helped me to save the problem! Many many thanks for that. :slight_smile:

First things first: My “table delete and API call” process was barely correct. The solution here was to delete the table of the local data source first and only then (when the table rows are surely deleted), proceed with the API call.

The second problem was, that there was an object property with NULL which caused the app crashes in the end, as I tried to fill it in to my local data source table. Before I saw your answer @muneer I first thought it would be the content of the property, as UID contains a MAC address with semicolon (FF:FF:FF:FF:FF:FF) separated chars → My thoughts: Could cause some kind of parsing error. Tested this by assigning the properties one by one, only this UID property caused crashes. But you were right, it’s all about NULL.

Debugging at Thunkable is not yet so intuitive as I am used to in real programming languages. Maybe something that could be improved.

However, once again many thanks and I am surely adding the test logic into each property I am trying to write into my table!

2 Likes

I definitely wish for a stack trace from time to time! Failing that, adding wait blocks, writing values to labels, and making the phone vibrate or alert when it hits a certain point are all good.

This difficulty in debugging is part of why I try to only post GitHub bugs if I’ve got a really minimal example that exhibits – it makes it a whole lot easier to point and say “yeah, it’s this block and it’s definitely broken, not something I’m doing wrong”. And ya know, half the time when I build the minimal example it works /fine/ and then I realize what was wrong with my original code.

2 Likes