If you have a ListView bound to a DataSource with endless scrolling enabled, once you reach the end of the DataSource, you cannot get it to load additional pages of data again. This becomes an issue when you change the data in your ListView by re-querying the data source (through the "filter" and/or "query" functions on the DataSource object).
In our specific scenario we have 2 views. The first view, "View A," contains inputs. The second view, "View B," contains the ListView that is bound to a DataSource and has endless scrolling enabled. When the user enters data in the inputs on View A and clicks the submit button, we call the query() function on the DataSource passing the data from the inputs and navigate to View B. The user can then click Back, change the search parameters on View A, hit Submit again, and view the results of the new parameters on the ListView in View B.
This works great, as long as the user never scrolls to the end of the data in the DataSource. Once they do this once, they can never scroll beyond the first page of data again without restarting the app.
Is this just a limitation of the ListView and endless scrolling, or are we missing something?
Thanks,
Jonathan Marston
In our specific scenario we have 2 views. The first view, "View A," contains inputs. The second view, "View B," contains the ListView that is bound to a DataSource and has endless scrolling enabled. When the user enters data in the inputs on View A and clicks the submit button, we call the query() function on the DataSource passing the data from the inputs and navigate to View B. The user can then click Back, change the search parameters on View A, hit Submit again, and view the results of the new parameters on the ListView in View B.
This works great, as long as the user never scrolls to the end of the data in the DataSource. Once they do this once, they can never scroll beyond the first page of data again without restarting the app.
Is this just a limitation of the ListView and endless scrolling, or are we missing something?
Thanks,
Jonathan Marston