I have an iOSTable that displays some data. I have a method that refreshes this data by removing all the data and reloading the table (it’s only a small table). I want to retain the scroll position in the table so that I can ScrollToRow immediately after the refresh to prevent the table from jumping back to the first row. However, while I can store the currentSection and currentRow in the Table.Action method if the user taps on a row, I can’t see how to get this information if the user doesn’t tap but, instead, merely scrolls the table. There isn’t a Table Scrolled event or, for example, a FirstVisibleRow property. Has anybody had to solve this?
ScrollPosition is a long standing request. Let us hope at some point Xojo realizes total lack of interest for iOS users will not be good for its image. Jason King posted a declare that might do.
https://forum.xojo.com/30269-iostable-did-scroll-to-bottom/4
The way we handled this in the xdc app this year was to store the data in an array of classes and then load the data on demand. When the user scrolls they always get the most up to date data.
Thanks Greg but that’s not my scenario. I’m using the iOSTable to display data which is just a few rows more than an iPhone 6/6s screen size (so not many rows but more than a screen so capable of scrolling). When the user taps the Edit button on the view they are taken to another view to edit the data. When they tap Done on that view to return to the previous (display) view, I refresh the iOSTable in that display view and, if the user happens to have scrolled to the bottom before tapping Edit, this causes the iOSTable to “jump” back to the first row.
I think if I change this view to use the iOSTableDataSource interface then maybe I can use the ReloadData method on the table to reload each row without the table’s visible rows changing and thus preventing the table from jumping around. Still, it’s a pretty big refactor for a small table that really doesn’t need the interface for any other reason…
Jason, Have you looked at the thread I linked to ?
Yes, thank you Michel. I don’t think it will help my case unfortunately.
[quote=318146:@Jason Tait]Thanks Greg but that’s not my scenario. I’m using the iOSTable to display data which is just a few rows more than an iPhone 6/6s screen size (so not many rows but more than a screen so capable of scrolling). When the user taps the Edit button on the view they are taken to another view to edit the data. When they tap Done on that view to return to the previous (display) view, I refresh the iOSTable in that display view and, if the user happens to have scrolled to the bottom before tapping Edit, this causes the iOSTable to “jump” back to the first row.
I think if I change this view to use the iOSTableDataSource interface then maybe I can use the ReloadData method on the table to reload each row without the table’s visible rows changing and thus preventing the table from jumping around. Still, it’s a pretty big refactor for a small table that really doesn’t need the interface for any other reason…[/quote]
FWIW, once you start using tables with a datasource, you may find that you don’t want to go back. That said, you could probably subclass iOSTable and override the methods for adding rows to add to an array instead.
I have multiple views in my app that use a datasource with data provided by a SQLite database (acting as an offline cache for data from our web services) so I’m sold on datasources. But, as the documentation states, for small tables with only a few rows, the datasource isn’t necessary. Except, that is, when it gets around a functionality issue as in this case.
One of the main reasons I did almost never use iOSTable in my latest app is precisely because it is toyishly indigent.
Most of places where I need serious grid, and even tables that have the minimum ScrollPosition, I use in fact HTML.
From what I remember, the concept of a non-data source table is something that we added to make them behave more Xojo-ish.
Thanks for your insight Greg. I’ll bite the bullet and refactor even the small tables to use a datasource interface.