Android Question Displaying 900 records within scrollview too slow

[sconlon]

One function of my app is to display a list of around 900 customers from an SQLite db within a vertical scrollview (on a Sanei N10" tablet). I run a query to get the records (which have 13 fields) into a custom type list (of 6 fields) and then display the records from the list within a For loop by programmatically adding views to the scrollview's panel. The whole process takes about 10 secs which seems quite long even on the Sanei tablet (running ICE) which I know is not the fastest. So I was wondering if it could be speeded up somehow. Any advice would be welcome.

Thanks.

 

[Erel]

10 seconds sounds quite slow for 900 records. Are you loading any images?

You can use TableView instead. It should be very fast.

 

[sconlon]

10 seconds sounds quite slow for 900 records. Are you loading any images?

You can use TableView instead. It should be very fast.

Thanks Erel. I'm not loading any images and code snippet for each of the 5 columns displayed is something like:

                Dim label1 As Label
                label1.Initialize("")
                label1.Text = curcust.name
                label1.Gravity = Bit.OR(Gravity.CENTER_HORIZONTAL, Gravity.CENTER_VERTICAL)
                label1.TextSize = oTextSize
                label1.TextColor = Textcolor2
                pnlUsers.AddView(label1, columnleft, 0, udColWidths(1), RowHeight)
                columnleft = columnleft + udColWidths(1)

I'll give tableview a try.

 

[canalrun]

The whole process takes about 10 secs which seems quite long even

I recently experienced something similar using the Nexus 7 tablet. I haven't done any investigating, but saw something unexpected.

I have an SQLite database with about 500 records. I am using a TabHost with an embedded ScrollView. I populate Panels in the scrollview with records from the database.

I was surprised that it took about 5 seconds to populate and display. It also crashed regularly showing the "Your app has closed" message right after displaying the scroll view – this is software that has been used for about a year. I had increased the database size from about 350 records to about 500 records and added the manifest setting for Target Version 14.

I removed the Target Version 14 and it now works 100%, but I'm still surprised it takes 2 or 3 seconds to populate and display – this is roughly half the time it took with the Target Version 14 manifest setting. It seemed to take less than one second when I had 350 records in the database. Also, no more crashes.

I wonder if you can quickly try removing the manifest setting for Target Version 14, if you have it set, and see if you notice any differences. I have not investigated this at all. It was just something unexpected.

Thanks,
Barry.

 

[sconlon]

I don't have Target Version 14 set.

 

[eps]

I always found it slow as well, so stuck with ListView. There is UltimateListView which Informatix has created and optimized. I am about to purchase this for use in a couple of my Apps. It might be worth looking at.

 

[canalrun]

I always found it slow as well, so stuck with ListView. There is UltimateListView which Informatix has created and optimized. I am about to purchase this for use in a couple of my Apps. It might be worth looking at.

Thanks, I will consider giving that a try.

Barry.

 

[fabio borges]

I had the same problem and I solved changing to tableview. When you use scrollview you have to add many other views like labels, edittexts to show your data and this views make loading to slow, I had tested that. If you put the same content in a unique view you will increase the loading performance for sure. It is the tableview principle that load only views visibles on the screen becoming load time so fast.

Sorry for my english.

 

[Informatix]

I had the same problem and I solved changing to tableview. When you use scrollview you have to add many other views like labels, edittexts to show your data and this views make loading to slow, I had tested that. If you put the same content in a unique view you will increase the loading performance for sure. It is the tableview principle that load only views visibles on the screen becoming load time so fast.

The problem is not exactly that one. You can have many views in each item. The problem is with the number of items. Let's say that creating a view takes 1 ms. If you have 10 views in a item, your item needs 10 ms to be ready. If you fill a scrollview with 900 items, then your list will be ready after 9000ms (9 sec.), which is too long. With a listview (or tableview which is built upon a similar principle), you create only a limited set of items and you reuse them when they are off screen. In the case of a listview (or UltimateListView), if the screen can display only 10 views, then only 10 items are created (tableview creates 2 or 3 times that number if I remember correctly). 10 items x 10 views in our example will need only 100 ms. And these 10 items will be constantly reused to avoid creating items again.

 

[canalrun]

The problem is not exactly that one ...

Interesting. The trick is to populate and display items "on demand". I bet that gets tricky.

In your UltimateListView does it allow for images to be changed after they are created and displayed. For example, I have a "checkbox" represented as an image shown as either a "checked" or "unchecked". If the user clicks on an "unchecked" item, it is changed to "checked", and vice versa. Can an image associated with a list item be changed (say in response to a click)?

 

[Informatix]

In your UltimateListView does it allow for images to be changed after they are created and displayed. For example, I have a "checkbox" represented as an image shown as either a "checked" or "unchecked". If the user clicks on an "unchecked" item, it is changed to "checked", and vice versa. Can an image associated with a list item be changed (say in response to a click)?

The ULV populates the items in real-time. Nothing is filled in advance because the ULV doesn't hold any data, contrary to a listview. If you change a data (the state of a checkbox or the URL of an image for example) and force a refresh of the ULV, the item will display the new value/state.

 

[canalrun]

The whole process takes about 10 secs which seems quite long...

I just tried a little test. I disabled and made not visible the ScrollView while populating. This decreased the populating time from 4.9 seconds to 1.8 seconds.

sv.enabled = false
sv.visible = false

  ...
  populate sv
  ...

sv.enabled = true
sv.visible = true

Barry.

 

[sconlon]

I just tried a little test. I disabled and made not visible the ScrollView while populating. This decreased the populating time from 4.9 seconds to 1.8 seconds.

I tried that and it did reduce the time from 10 to 6 seconds which is definitely an improvement. I haven't had time to try the tableview or listview yet but will report back when I do.

 

[Erel]

TableView (like ListView and ULV) doesn't create a view for each item. It recycles the views as needed. It can handle tables of any size (more than 100,000).

 

[eps]

I tried that and it did reduce the time from 10 to 6 seconds which is definitely an improvement. I haven't had time to try the tableview or listview yet but will report back when I do.

Have you optimised your DB and added indexes as well?

 

[canalrun]

Have you optimised your DB and added indexes as well?

Actually no - adding an index on my "Order By" field would probably help.

What I did do is insert some very rough profiling code using DateTime.Now. I no longer have the exact numbers, but in the 1800 milliseconds it took to read the database and populate my scroll view, it was something like 100 ms to read the database and 1700 ms to populate the scroll view. Accessing the database is not the time-consuming portion. I got close to a factor of four improvement when I disabled and made not visible the scroll view during populating.

Barry.

 

[eps]

Actually no - adding an index on my "Order By" field would probably help.

What I did do is insert some very rough profiling code using DateTime.Now. I no longer have the exact numbers, but in the 1800 milliseconds it took to read the database and populate my scroll view, it was something like 100 ms to read the database and 1700 ms to populate the scroll view. Accessing the database is not the time-consuming portion. I got close to a factor of four improvement when I disabled and made not visible the scroll view during populating.

Barry.

Fair enough! To be honest this is why I don't use ScrollView - there are some better options around...

 

[canalrun]

Fair enough! To be honest this is why I don't use ScrollView - there are some better options around...

Yes, I agree. The reason I am using scroll view is that I populate the scroll view with panels that contain a few labels and an ImageView "checkbox" where I display an image corresponding to either a checked or unchecked checkbox. If the user clicks the item the check changes from checked to unchecked and vice versa. Long clicking an item brings up an editor to change other values associated with the item. The database holds all the information corresponding to the item.

I really miss the FastScroll from ListView, and I see the "Add..2" methods that allow an object to be associated with each item in the list.

Can I ask? Can the items within a list view be updated in real-time (for example my "checkbox" changing in response to a click). I suppose if it were fast enough I can just redraw the ListView.

Are there other options for a list or scroll type view? Are they just built upon ListView or ScrollView?

Barry.

 

[eps]

There are a lot of other options.

ULV, TableView, GridView and so on. Some of these have been re-engineered and improved on the performance and other issues associated with either ListView or ScrollView.