Data Viewer List - Incomplete list shown

[rojroj101s]

Very sad this problem has not been resolved. I had to cancel my pro subscription and started to rebuild by app on Bubble.io because my app cant function with this bug. That was and still is very very very painful.

[paulovaz72]

EXACTLY the SAME Problem I’m having!

When I pull down the Data Viewer List in execution time, the first line simply desapear!!!
And while I don’t pull down, the first line does not respond to the “Click” blocks.

In fact the data viewer is a very crucial component, but very limited for who wants to work with native solution to display / manipulate data… I miss a index propriety for the row… editing capabilites and LocalDB connection instead the poor Datasource (another very limited component)…

Anyway, someone have an idea how to solve this issue?

I’m very excited with Thunkable, but if this problem has no solution I’ll need to change of dev platform

[paulovaz72]

Very very frustrating work for weeks in a project, and after yor re-check 1.000 times your blocks, loading strategy, dealing with the sync problems, you discover that the Dataviewer component is buggy…

Hope the dev team solves and improves this CRUCIAL component, otherwise I will disencourage serious projects to adopt Thunkable!

[rojroj101s]

Dear Thunkable Staff,

If your looking into this issue at all, I found that when you test your app on the computer the data viewer works fine. As soon as I use the thunkable live app. It does not work. It also does not work when submit my app to the app stores.

Also, the computer doesn’t have a refresh button because I cant use my mouse to swipe down to refresh. If I could I would and see if refresh also produces the bug. Which also makes me think this bug is related to the block swipe to refresh. This block might be coded into the data viewer poorly which is producing the bug. I also feel like this bug happened around the time the swipe to refresh button was released or updated.

[Michael_Rogulla]

Hi all,

I have to add that there are some more unsolved problems: I’ve written an app, that uses a Data Viewer List (DVL) which is connected to a Local Data Source. On app startup I get all data from an airtable database and populate the Local Datasource. Pros: I can change the data in the Local Data Source, for example to set a flag like “visited” or “my favorite” which is not possible when using airtable directly. Cons: it takes some time to populate a Local Data Base. But in the end for me the DVL works, even with more than 10 entries (works on iOS and Android, live or downloaded).

When using an airtable directly with a DVL you could build an app in minutes. Connect your DVL with a data source from airtable and off you go. But click on an entry of a DVL, get an ID and get a new problem: on first access it takes a long time (approx. 0.6 … 0.8 seconds) for each element to fetch. That does not seem very much time but it adds up when you want to show maybe the whole list on a map. I opened/reopened an issue #542 a long time ago, and got no response. Not even a notice. Why?

For me it is very sad that I cannot do real debugging, I would love to dig into the internals to find out where the problem lies. Maybe that way it should be possible to speed up the support process.

[tatiang]

I’ve read through your issue (I added a link to your post right above this) and commented with my experience. The DVL tasks are much faster on my device. So it’s either an iPhone 8 issue or an issue with the blocks you’re using. Can you post a screenshot of your blocks?

[info5958]

Hi all,
the problem is about the repeat cycle, all repeating cycles in Thunkable does not wait that the blocks inside the cycle finish before to start another cycle.

So, if you interrogate DB like Firebase or do others blocks task, you have to put a wait block, but not inside the interrogation DB or others task block but after those, to the last block before the end of repeating block, in order to stoping the repeating and give to the previous blocks the time to finish their job.

Thanks
Bye

[muneer]

@info5958

if you interrogate DB like Firebase or do others blocks task, you have to put a wait block

This is NOT entirely correct. When you use the Realtime DB blocks to retrieve data from Firebase then you will need to make sure whatever you are doing inside the blocks is completed because these blocks are asynchronous. However, you can choose to get the data from Firebase using Cloud Variables which are synchronous by nature and will wait until the block completes its task before giving control to the next block in your code.

You have the choice but I see a lot using the asynchronous blocks for the wrong choices of actions.

[info5958]

It sound good
can you post an example about Cloud Variables used in Thunkable in that way ?

Because i can not find variables named Cloud or similar but then i think my mistake.

Thanks
Kind regards

[muneer]

Check this example by @jane

Chat app In Thunkable drag and drop

Hi there, This realtime DB block is the same as this cloud variable block: [image] [Screen Shot 2021-05-24 at 8.00.32 AM] And this realtimeDB block is the same as this cloud variable block: [image] [Screen Shot 2021-05-24 at 8.01.27 AM] I am using dynamically named variables here, so you don’t even need an initialize block! Does that help you understand how to use cloud variables instead of the Realtime DB component in your Drag and Drop project?

You can also see the tutorial video signup using cloud variables

Manage Signed In Users' Data with Cloud Variables

Hi there, Thunkers I have previously shared a Sign In Video Tutorial for Drag and Drop UI which used stored variables to save the sign in details between app sessions. We now also have a video tutorial to save user details such as name and profile picture to the cloud using cloud variables! Check it out here: [Cloud Variables - Save User Data to the Cloud in Thunkable Drag and Drop UI] This includes the chapters: 0:00 Cloud variables vs Stored Variables and App Variables …

[tatiang]

I provided an example here, too:

Saving partial data below a Firebase key?

Thunkable X is the current and only version of Thunkable available right now. I think what you are asking is if this can be done in the older “Snap to Place” (StP) interface instead of the newer “Drag and Drop” (DnD) interface. In both interfaces, you can find it near the bottom of the variables drawer. The set app variable "name" to [ ] block can be configured so that it says “cloud” instead of “app”. And then you enter the path to the Firebase node in the “name” section, as I showed above. […

[Michael_Rogulla]

Hi @tatiang thank you for the reply. I try to make a short description of my app:

• I use a data source, which is connected to airtable (I made an example app to show some restaurants in San Francisco, that’s why it is named “SFRest” ):
  

• use a data viewer list and connect it to the data source. That’s all.

• go to the “Blocks” section. The data source is listed within the blocks and understands the ID which gets returned after clicking an item in the data viewer list. I measure the time for execution (interesting: the “seconds since 1970” are precise up to milliseconds, they are not integers!). Here is an example block:
  

  

When you test this block you can see that after clicking an entry from the data viewer list the first time it takes some noticeable time. Now you can click on other items, but when you click on an entry the second time or so, the results come without delay! For me it is a bug (or an unneccessary delay) in the first click. This shows that Thunkable app can be very fast but in some places a “handbreak” is active.

This delay also happens in “swipe left” or “swipe right” blocks, because there is also an ID, and fetching the information for this ID is also delayed the first time.

[tatiang]

And I’m not seeing that delay. So again, it could be your device although I would think an iPhone 8 would be fast enough.

You’re getting four values from Airtable every time you click a DVL item. That’s going to take a little time. What happens if you replace those four blocks with set LabelName's Text to make text from list [list of values in SFRest-->Places]? Because that’s a single call to Airtable that gets all of the values you need. I understand why you have it set up the way you do but I think you should test this with the list of values block (and for now, remove the other Airtable get value calls) and see if it’s noticeably faster.

[Michael_Rogulla]

Hi! Yes, I can definitely speed things up by using the block “get row object”, that way I only have one delay accessing the data source and can get the information from the object. All I wanted to show is the delay when accessing an item for the first time.

For a single entry this delay might be ok, but…

• not everybody has the last and fastest iPhone / Android phone
• when you have 20 restaurants in your data source and want to show all of them on a map, then you get the delay multiplied by 20. And there are cases with >>20 datasets.

[tatiang]

I understand about different devices. And I’m not suggesting you should only develop apps for the newest phones. Rather, that’s one variable… device type. Another variable is how many calls you’re making to Airtable.

And maps are a whole other issue in the sense that you’d need to show your blocks for those, too.

Hopefully someone else with an older device can confirm what you’re seeing because I don’t see a difference between 20 and 50 rows.

[muneer]

@Michael_Rogulla

This shows that Thunkable app can be very fast but in some places a “handbreak” is active

That is an interesting situation. However, I have a theory to explain it although I wish I’m wrong.

I think the delay that you notice it at first is due to the fact that the blocks are actually retrieving data from the table. Subsequent attempts the data is being fetched from the cache making if very fast.

How can we verify that this is not the case?
Start your app as normal and click the line in the DVL to read the data for the first time and note down the delay.
Now, access your tables directly from Airtable dashboard and change a values in one of the columns you retrieved in your app.
Click the same line again in the DVL and check if the changes have been reflected in your app.

These steps will show if the first time really takes longer or it is just that subsequent times never goes back to the table to read it and therefore seems faster.

I’m anxious to know your results.

[Michael_Rogulla]

Hi @muneer, thank you for the constructive response. I tested my app on iOS (with the companion app) with an iPhone 8, I tested it on Android (companion app) with my Samsung S20 and I tested it in Thunkable by pressing the “Preview” button. The results are approximately all the same for the three environments.

My app shows a DVL, below come 4 labels (here I show name, address, URL and phone of the clicked item of the DVL), a label to show the delay in seconds and a button that performs the block “data viewer list - refresh data”, because in “Preview” mode I cannot swipe down the DVL.

When clicking an entry of the DVL I fetch the 4 fields by using “get value from SFRest”. I know that the delay is 4 time higher but the measure of the delay is more precise (just divide the result by 4). The 4 fields show up in the 4 labels.

Here are the results:

• click on an item the first time gives a total delay of 2.6 … 3 seconds
• click on an item the second and all following times gives a delay of 0.30 … 0.4 seconds.

Then I changed something in Airtable, let’s say the name of a restaurant, and afterwards in my app I clicked the “refresh” button. Here are the results:

• click on an item gives a delay of 0.3 … 0.4 seconds, even the “first” time after refreshing.

The only difference: the item in the DVL shows the changed names, but the result from “get value from…” shown in the 4 labels do not change. Only after a complete restart of the app. It looks like in Thunkable there a two data sources: one gets filled up with data when starting the app and which is connected to the DVL, the other data source gets data, when a user clicks an entry for the first time by the “get value from…” - block. So the delay is possibly caused by filling rows of the local data source. BTW this is possibly the behaviour I described in my issue #542 where I annotated that local data sources seem to work very slowly.

I hope I described everything correctly. I haven’t inserted pictures of my blocks, because the structure is totally simple.

[kartik14]

@DuMonster

Until recently both have functioned properly, but now when the screen loads only the first 10 items show. Refreshing using the swipe down method will load a large blank area where the rest of the items should be.

I am facing this exact same issue on all 5 DVLs in my app. I really hope Thunkable fixes this ASAP As more and more users have been reporting this issue.

@wei @domhnallohanlon @cassandra @tingccc

---

Edit : After some de-bugging, I found out that if any of the visible 10 items is clicked, the DVL then shows the complete list. But if refreshed (when complete list is visible), it again shows only 10 items and a huge blank area. And if I click on an item in the 10items+blank area list, the list becomes normal again (shows all items). Strange…

[muneer]

This means the get value from block uses the cache to present data and this is the reason of the sudden change of performance on clicks after the first one.

[Michael_Rogulla]

Hi @muneer , I have no direct insight in Thunkables internal structures, I would suspect that the “cache” is empty on app start and the delay is caused by filling the cache row by row with every click. Is that what you also suspect?

To make things a little bit clearer:

• when working with a DVL you need a Data Source.
• You have three choices in creating a Data Source:
  – Airtable, Google Sheet, “My Own Table” (I think this is a local data source)
• I never worked with Google Sheets, I can only tell what happens with Airtable and “Create my own Table”.

1. Create a Data Source from Airtable is easy, and afterwards just connect the DVL. Pros: easy handling, Cons: the mentioned delay when accessing data with the “get value from …” block
2. Create a Data Source as “My Own Table”. Things are a little more complicated: on app start you have to populate your Own Table by yourself, and filling Your Own Table takes a significant delay. This is my way: on app start I fetch all rows from an Airtable Database with the block “call Airtable1 GetAllRows” and have to loop over the resulting array of objects and copy the needed fields into my Own Table, row by row with the block “create row in …”. This is time consuming, but it improved. Half a year ago this initial loop took >10seconds in my app, now it takes approx. 4 seconds. I think that Thunkable did some internal improvements because I never changed the blocks. Pros: when clicking on DVL items the response is super fast and I can loop over all items in no time (for example to display a map with all locations) Cons: it takes some time during app start. It needs some animation on your front screen so the user don’t get too bored.

I hope that the local data base gets even more speed up improvement. I don’t know how to address the technical support from Thunkable… @Steven are you still there? Sorry for addressing stafft directly but on github I get no response, and this issue is definitely nothing the community could solve.