Android Question Can we make a clone of a customListview

[Jeanc161]

Here is the problem..
I have a Main and a Service module + other class module in the same code block
Let say i have a panel containing a Customlistview object Called TOC that i populate with items. But the same customlistview is use for other layout such as a menu list, and a search result list. The problem is when i minimize the app, i loose this customListview and have to rebuild it from the ground up. The same is also true if i load a layout for the search result that appear in the same panel as the TOC Panel.

I also have defined Global Vars in the service that hold my TOC content and Menu content and the Search result content as objects, wich is keept when the app is minimized and i do not need to load these values again in a list using Custom Type structure.

So what i want to be accomplish is to Build the TOC content from the Main at startup, also the menu content at startup, wich can take some time to load into the customlistview item by item and save it to the service module so that it could be reused when needed.
So i'm wondering if it is possible to make a copy of this TOC customlistview or the MENU listview and saved it to a variable in the service module to be keept in memory so that i don't have to load it item by item again, but just swap the object from the service module to the main Customlistview object wich is store in a panel on the main display area.

I've been told that you can't store view object in global vars, but can we save the CustomlistviewObject as global object to the service module and been able to reload that object in the main module when we want to display the TOC object, without reloading item by item, but just as a global object that we can swap. The TOC must be loaded once and the same as the menu, the search result object is build when we make a search, but that panel can be sidebar using the B4XDrawer that we swap into view with a right to left or left to right gesture.

Anybody have any idea on how to do this, that will save me a lot of time rebuilding each Listview when the application resume. ???

 

[Jeanc161]

Maybe you could a simple entry is only text with some parameters infos defined by the user type toc see previous post

The entry consist of couple of fields but you could simply enter any type of text since ther are no bitmaps or anything special about it.
the entry is mostly the same width and the same height, I will try later on if i can make a bigger space or adjustable height, if the methods for calculation line height is doing it's job correctly, so far no luck, but the customlistview is supposed to be able to take different height for each layout that we load into the customlistview.
I include a screen shot of the TOC displayed on the device, so you can have an idea about the list wich is very simple.

Use the method in the ScrollChange to give you the information for scrolling direction if needed, i try that method and it is pretty accurate to define the scroll_up or scroll_down action on the list. Any way see the code that i posted it might give you and idea.

Also try not to do a big list of items for testing, beleive me it is very long when you scroll, test, scroll, test try to make a 150 items and scroll maybe 20 to 25 items at a time, it will be less anoying when you test, and if it work, the try a bigger list, then a more bigger list to see it's behavior.

Also if u use the .Clear method of the label in the customlistview, it will give you a glitch on display when you scroll or display new or old items

Keep me posted if you can find a solution.

Have fun !

Sorry for the image size i did'nt resize it first...

 

[emexes]

Have fun !

lol

tomorrow (well, later today...)

 

[emexes]

Try this. It creates some demo TOC data (8000 entries in 10 ms: seems too fast to be true), and then initializes the CLV with the first and last 20 entries, and every 30th entry in-between.

Then, as you scroll through the CLV, each time the VisibleRangeChanged event is called, it adds any missing entries to the CLV. Eg, for VisibleRangeChanged(100, 110) where CLV index 100 is TOC entry 1111, then it would ensure that TOC entries 1111..1121 were loaded into the CLV at indexes 100 to 110.

It works mostly ok, perhaps even good enough. During scrolling, sometimes higher-numbered items are visible, but when scrolling stops and it realigns itself with the first item, those higher-number items disappear off the bottom of the CLV. You might be able to get rid of this artifact by doing the alignment with the middle item rather than the top/first item, but... I'll leave that fun for you

If this solves the problem of quickly loading large CLVs, we now have the issue of it taking a long time to scroll through this large CLV of 8000 items. I added a translucent green scroll overlay thing that directly positions the CLV directly to anywhere from start to finish. A long-click on the CLV will hide/show the scroll overlay.


This screenshot shows the CLV as initialized, at the top. The numbers down the right-hand side are: 0 = CLV first-visible/top item index, 6 = CLV last-visible/bottom index, 305 is the number of items loaded into the CLV (approx. 20 + 8000/30 + 20), and 8000 is the number of entries in the TOC.

This screenshot shows the CLV positioned half-way though, at TOC entries 4227..4233 of 8000. Key thing to note is that we have only loaded 867 items into the CLV, ie not all 4233 entries.

This screenshot shows the CLV positioned at the end/bottom. Only 1289 items loaded into CLV, not all 8000.

 

[Jeanc161]

I will take a look and come back to you...

 

[Jeanc161]

emexes I tried the solution that you posted, it works but...

In the scrolling down it scroll quite smootley, it flicker from time to time but that is not too bad, the problem is when you scroll up, i looked at the code and it does not seem right, the scrollview flicker a lot, and the app even crash a couples of times when i scrolled up.

It is still loading too many items on scrolling, and it takes time in the Up Scroll so the listview quind of look jam and when you tried to swipe it again, then it crash, simply crash no warning no log entry nada, it just scrash, so it seem it is still trying to load too many items, and it slow down too much. And that i tried it on my table wicht have a quad core processor at 2.xxx ghz and 4g of ram, and it is pretty fast normally.

So that was a solution but not fail proof. Gonne have to do something else for the scrolling and load as many few items as possible. Currently i made a solution to scroll down very fast using only 20items at a time and it runs smooth, i also save some pointers so when i need to reload the listview it load less items

So i will keep continue trying to find a better solution for my app. I thank you emexes for your time and effort in hopefully trying to find a solution for that problem, it was pretty much appreciated.

So back to the drawing board If someone else has a solution you want me to try lest me know i will test it.
Thanks all

 

[emexes]

I tried the solution that you posted, it works but...

<thumbs-up> what could possibly go wrong?

the problem is when you scroll up, i looked at the code and it does not seem right,

Which bit of the code doesn't look right?

the app even crash a couples of times when i scrolled up.

That's useful to know. I tried it on two phones, never crashed. I am using B4A 9.00 and xCustomListView 1.70.

It is still loading too many items on scrolling

If you scroll up slowly, yes, it will load every element. It is only when you scroll fast enough to get the 1-in-30 elements to the top of the display range that it will start skipping loading elements that are not needed for display.

And that i tried it on my table which have a quad core processor at 2.xxx ghz and 4g of ram, and it is pretty fast normally

My two devices were both phones. Perhaps the displayed size or number of displayed elements of the CLV makes a difference.

 

[OliverA]

1) You folks are over-complicating this issue
Or
2) I'm oversimplifying it
Since we are only dealing with text, I'm only lazy loading forward. Once loaded, I don't care. The lazy loading example by @Erel deals with panels that contain a lot of info (in this case pictures), so it makes sense to clear out panels. I don't think it does in this case. Use the Global preLoadCount to determine how far ahead the list is loaded. The code may have some indexing errors, so please look over carefully.

 

[emexes]

1) You folks are over-complicating this issue
Or
2) I'm oversimplifying it

as best I can see, you've saved four lines in InitialLoad(), and added two lines to CustomListView1_VisibleRangeChanged(), and so the difference between overcomplication and oversimplification is two lines. That reminds me of the U2 plane, which was so finely strung that in a turn, the outer wing would be buffetting and the inner wing stalling (or something like that - I just found out that this can't-please-everybody situation has a name: "coffin corner").

The problem with loading *all* elements (whether initially all-at-once, or gradually by lazy-loading) is that it takes a long time to scroll through thousands of elements.

 

[emexes]

My two devices were both phones. Perhaps the displayed size or number of displayed elements of the CLV makes a difference.

I tried it on an old (~2015) tablet and it works fine too, both before and after I altered the layout anchoring (no change to code).

What error did you get when it crashed? Or better yet, the 20 log lines prior to crash also.

 

[emexes]

So back to the drawing board If someone else has a solution you want me to try let me know i will test it.

Assuming I'm allowed to enter another candidate into this lottery (given that it differs significantly from earlier entries)... give this a burl.

I'm sure there are already similar controls about, and this one looks pretty good:

https://www.b4x.com/android/forum/threads/lib-chargeable-ultimatelistview.22736/

but try the attached one anyway. Experiment with both standard and long clicks. I originally just had the standard clicks, without lazy loading of CLV, and it worked a treat. Adding the long click caused delays, which I solved by adding lazy loading. In fact, I was a bit lazy about the implementation of it too, so it'd be more accurate to describe it as lazy lazy loading ;-)

Anyway, I'm still worried that if the first demo didn't work on your tablet, then perhaps this one won't either. All I can say is: it works here, and most excellently too.