What's the preferred way of updating the content of a TableView? I have an app with a Grouped TableView that is frequently updated. It wouldn't be unusual for the view to go through several hundred updates in 30-45 minutes of normal use. The two choices seem to be:
- Storing a reference to the Labels and TableViewSections (for updating the headerTitle) and updating the text? This seems the most efficient approach, but it doesn't always place the text in the right location when I do this - sometimes it will be slightly outside the row. There's also a visible vertical redraw that doesn't look good.
- Recreating the entire TableView from scratch each time? This appears to work, but isn't very elegant and I seem to run into problems with my app working on a first generation touch (memory usage issues, I assume).
Is there a third option I'm not considering?
re-creating your table view data array and using setData is the way to do a wholesale replace of the data in the table view with our API. If that route doesn't seem to scale up with your data, you might consider pushing new rows into the table view rather than replacing all the data, or incrementally adding rows to the table so you don't push x amount of rows at the same time (a pagination approach). If you want to grab a build from master, you can get a preliminary 1.3.3 to test with and refer to this example from the unreleased version of the Kitchen Sink to see how you might implement this dynamic scrolling functionality with your data.
I'm hoping that the issues you've mentioned as option 1, with regards to the TableView layout messing up when you alter something (like a text string) in the table by reference, gets fixed in the upcoming 1.4.x release. I was doing something similar in an app, manipulating text that I put in a table by reference. It was working fine in mobilesdk 1.3.0, but some rows in my table started looking misaligned in 1.3.1. I haven't retested under 1.3.2. I would agree that option 1 would be preferable to option 2 for the sake of speed and memory usage. I didn't uncover a 3rd work-around. Sorry, I know this isn't the most helpful answer, but you have company.