2

I have made my application using TListView to show the main dataset as a listing as way to navigate the records. I have used LiveBindings with the Sync <-> * connection.

The major problem is that it loads the entire table into memory. That is slow most of the time, and now taking it to android even worst.

I have not found any example on how to page it. I am not using sql, I am using a custom DataSet (Aurelius) that retrieve the records on demand.

Since I have not found any documentation I have no starting point or code to share.

How to make TListView load records on demand?

PS. there is a similar SO question, but that could be solved by SQL statement. I don´t have SQL available and I wonder if with the actual version of FMX that could be a better approach.

Community
  • 1
  • 1
Eduardo Elias
  • 1,742
  • 1
  • 22
  • 49
  • It should be possible to use `LiveBindings` to sync the loading from the database. See [updating-listview-item-attributes-on-the-fly-when-using-livebindings](http://delphi.radsoft.com.au/2013/09/updating-listview-item-attributes-on-the-fly-when-using-livebindings/). See also [Mobile Tutorial: Using LiveBindings to Populate a ListView (iOS and Android)](http://docwiki.embarcadero.com/RADStudio/XE6/en/Mobile_Tutorial:_Using_LiveBindings_to_Populate_a_ListView_(iOS_and_Android)). – LU RD Sep 07 '14 at 21:22
  • @LURD Thank you, I am using LiveBindings already, I have edited my question to state that, because I was supposing that LiveBindings would be the default standard for FMX. Using the Sync property of TListView does work, but it loads the entire DataSet, I want that it loads what is needed to display, or at least a small number (pages) – Eduardo Elias Sep 07 '14 at 22:54
  • 1
    to the downvoter: please justify your down vote. Certainly you know the answer of my question, since you found it wrong. – Eduardo Elias Sep 07 '14 at 23:04
  • Rather than focus on the control, try focusing on the actual problem. I would create a GUI class that holds a sub-set of the data and loads the data on demand. You can then bind any GUI control to this class and will make life easier should you decide to replace the `Listview` with a different control. You can then also re-use this class on a desktop app should you need to do so. – Andy_D Sep 08 '14 at 09:35
  • @Andy_D I believe this is right now out of reach of my knowledge. I have not found information enough about how the interaction of LiveBinding/ListView/BindSource occurs. I see there is not much on the ListView side, as you stated correctly. – Eduardo Elias Sep 09 '14 at 01:51
  • 1
    @eelias There's a good article on the MGM (Model Gui Mediator) pattern here : http://www.andypatterns.com/files/91751232001357AndyBulkaModelGuiMediatorPattern.pdf Whilst using this approach will effectively replace live bindings, I've found live bindings to be slow and messy. I use an object persistence framework (tiOPF) for my applications and it comes with mediators for most of the common GUI controls and writing new ones is very straightforward. – Andy_D Sep 09 '14 at 08:13

1 Answers1

-1

¨Your problem is not in listview, but in your dataset. Configure the dataset properties:

  1. FetchOptions.AutoFetchAll=Disable
  2. FetchOptios.RecRowSet=20;//The number of rows per page
  3. FetchOptions.Fetchmode=fmManual

in a button, or in a ListViewl.PullRefresh Event*

begin
FDQuery.EmptyDataSet;
FDQuery.FetchNext;
end

  • Pullrefresh event means you push down in listview to get new records, very common in Iphone/Android Apps. Require PullToRefresh property checked as True
  • I downvoted your answer because your statement "¨Your problem is not in listview, but in your dataset" is simply untrue. In FireDAC (which you are obviously referring to), datasets very well support fetching on demand. The problem is instead in Listview and the BindListLink mechanism in Delphi. There is no feedback between the control and the binding, that more items are needed when scrolling. Your manual approach does not work either, as there is no event like "need more data" in the listview to determine when the user scrolled to the end of the list. – Olaf Monien May 02 '19 at 15:54