Hello Thunkers !
Sometimes an application needs to dynamically build, populate and display a local table on the screen.
And I noticed that doing so, DVL become slow in showing results.
So I made a simple app to exemplify that, building a table with only 30 rows/9 columns with no other beautify than changing every row color. And still for that it requires more than 10 seconds to display it (on a real fast phone, a Qualcomm Snapdragon 888 Octa-core RealMe GT edition).
This is the link to app, for those interested: https://x.thunkable.com/projectPage/6260e6b8b0ac710011170d36
And this is the result, for those that want only to watch how it works:
I remember I talked with @Thunkable_Staff about it on some Thunkable Hours and someone already said that something is not going quite right when bulding DVL, as it supposed to do. Ok, i get this (you can even see in my .gif that speed slows with every row added, like some unnecessary loop occurs there). @domhnallohanlon , @jared any news about solving that ?
Thank you my Thunkable friends for your time reading this.
But you’re also deleting and then creating all of the rows. So the actual display of data in a DVL would be much faster if it’s simply synced to existing data.
Are you not happy with how slow the row creation is or how slow the actual display of the DVL is?
thank you for your intervention but I too always delete the lines associated with a DVL before creating them
maybe the documentation needs to be reviewed… for beginners as me
it’s like the refresh data block a prominent forum member told me it’s not necessary
… as I said, in my case, is a dynamically build data, so building data every time from scratch is a must… Of course that if I would know that data I wouldn’t build it every time and would be much faster to display a known number of rows. But is not the case here.
I don’t know exactly what is slowing the process, as both are done simultaneously - populating the local table and customizing the DVL after each row. In my example is only a bit of customization, in my actual app there’s many to customize though, not only some color.
I’m guessing that creating rows in local table is a big part of time there, as working in Thunkable with LocalDB instead of Local Table was way faster. Unfortunately there’s no way to link LocalDB to a DVL, so linking to a local table is a must.
is there any chance that constructing the data in the cloud and sending it back to the phone would be quicker? or do you only pull data to the phone and insert it into a table?
I did exactly that. My data is already in the cloud. I keep it as JSON on Firebase - and getting from Firebase a huge amount of data as JSON works really fast, like a charm… (an user inputs some data, other users will see some results of inputs).
I only take it entirely as a variable and only populate the table linked to a DVL. So, time is not consumed to get the data, but display it as customized DVL.
Slow speed of creating rows/displaying a customized DVL is the issue. Is not an issue of calculating the data, as you can see it in my test app from this post.
I participated in that topic and I tried that method, then I compared results and unfortunately didn’t noticed an improvement. Using ID’s to customize DVL is a clever idea indeed, good to use in some other projects, but without any speed improvement in my case.
I think that @muneer tested also
Anyway, instead of thinking of workarounds all the time, I`d rather come back to my initial thought about it. I bet that some unnecessary loop is occurring when displaying a custom DVL that can be solved by your engineering team, when they have time to look into it. If I remember right, that was said by @arun in that Thunkable hours Later Edit: why I’m mentioning loop. As you can even see in my posted .gif, with every new built/displayed row time is increasing for the next, like the code is coming back to display from the beginning each time. And that should not be the case, as every new row has the same data “complexity” as the previous.
Is there any chance that you could share a copy of json data with me so that I could do some testing for myself? When I use the method that I am mentioning I see rows appear extremely quickly so I am wondering if there’s anything we can do to help you out
Thank you for your help.
You can use my test example from the beginning of this topic.
It’s really the same thing. The only difference is that instead of giving a cell an absolute value like in my example, will get an object property from JSON already extracted from Firebase.
But if is still not enough, I can give you the link to my real app (but there there’s so much to handle that will occupy a lot of your time and I don’t deserve it )
I can confirm that using local table with empty rows really works well with default DVL layouts viewing couple of columns of data but when you start to use your own layouts having 8 or 10 columns for each row the situation is not at all the same.
Custom layouts involving handful of column responds much slower in all cases and if you try to go through something like 200 rows to determine which should be visible and which should be hidden then the speed issue is noticeable.
You are right.
Just tested and got the same result. In terms of speeding is way better.
But this workaround gets other issues as result is not a consistent table that can be entirely scrolled vertically/horizontally (and even with first column frozen)… Maybe it can be worked further to include more containers and so on but… imagine the pain when you have to include this in a way bigger app, and not in a tiny example like this …
Because in my app, this is the kind of table I need to handle (24 columns/undefined rows number)
Don’t waste your time with this
As I said, maybe engineering team will have time somehow to look into DVL and the way it displays and correct the “looping problem”
and someone already said that something is not going quite right when bulding DVL, as it supposed to do. Ok, i get this (you can even see in my .gif that speed slows with every row added, like some unnecessary loop occurs there).
)