[TIMOB-71] Implement TableView data updating (Android)

Here are commits http://github.com/appcelerator/titanium_mobile/commit/00022a41e290a6b22a21f2f12b42527a5343b2c0"> http://github.com/appcelerator/titanium_mobile/commit/00022a41e290a...
http://github.com/appcelerator/titanium_mobile/commit/dfaf1ed0c05c7eea0cac0e53291a75fff040a920"> http://github.com/appcelerator/titanium_mobile/commit/dfaf1ed0c05c7...
And and email to try and figure out what the API is.

These are all the features that we can access for the iPhone. Whether or not we do is what I'd like to consider. ReloadRowsAtIndexPaths would be useful for single or several rows' data changing, in an animated way. Insert rows and delete rows are similarly important to expose. I'd really not want to simply change the javascript object and bulk upload again, because 1) the JSON encoding is expensive, 2) the JSON decoding is expensive, 3) -[reloadData] on a UITableView is expensive, 4) doing -[reloadData] during an animation or user interaction puts the UITableView into a very strange/buggy/unresponsive state.

However, it might be good to not expose beginUpdates and endUpdates, unless doing multiple row animated edits simultaneously causes crashing.
- Hide quoted text -

On Jul 28, 2009, at 9:26 PM, Don Thorp wrote:

it seems complex, could we not simply do a setData and take in a new model? Maybe with a selected item?

On Tue, Jul 28, 2009 at 11:18 PM, Blain Hamon bhamon@appcelerator.com wrote:

I started working on allowing modification of TableView after its creation. I found and squished a few bugs that were introduced when I added views to userWindows.
Here are the native iPhone commands:

- (void)reloadRowsAtIndexPaths:(NSArray*)indexPaths withRowAnimation:(UITableViewRowAnimation)animation
- (void)insertRowsAtIndexPaths:(NSArray *)indexPaths withRowAnimation:(UITableViewRowAnimation)animation
- (void)deleteRowsAtIndexPaths:(NSArray *)indexPaths withRowAnimation:(UITableViewRowAnimation)animation

These are obvious ones to keep, but importance should be placed in that these actions, if not atomic or are delayed, are kept properly serial as to avoid race conditions.

- (void)reloadSections:(NSIndexSet*)sectionswithRowAnimation:(UITableViewRowAnimation)animation
- (void)insertSections:(NSIndexSet *)sections withRowAnimation:(UITableViewRowAnimation)animation
- (void)deleteSections:(NSIndexSet *)sections withRowAnimation:(UITableViewRowAnimation)animation

These I'm not so sure about how to expose them, or if they are only for sectioned views, or are they done automatically, but they would be needed when the header and footer are changed.

- (void)selectRowAtIndexPath:(NSIndexPath *)indexPath animated:(BOOL)animated scrollPosition:(UITableViewScrollPosition)scrollPosition
- (void)deselectRowAtIndexPath:(NSIndexPath *)indexPath animated:(BOOL)animated

These might be useful, although for the most part, we already control this (The deselection is done during a click, and selection is only by the user's actions)

- (void)beginUpdates
- (void)endUpdates

This becomes a sticky wicket, as beginUpdates delay all the actions/animations as well as the reindexing.

So given rows of [A, B, C]
and delete of index 0 and 1, without beginUpdates and endUpdates, would be:
[A,B,C] -> delete index 0
[B,C] -> delete index 1
[B]

vs.

[A,B,C] -> beginUpdates
[A,B,C] -> delete index 0
[A,B,C] -> delete index 1
[A,B,C] -> endUpdates
[C]