[TIMOB-13175] iOS: TableView setData() is broken on 3.0.2.GA
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2013-03-26T17:32:09.000+0000 |
Affected Version/s | Release 3.0.2 |
Fix Version/s | Release 3.1.0, 2013 Sprint 07 Core, 2013 Sprint 07 |
Components | iOS |
Labels | 3.0.2, merge-3.0.3, qe-testadded, regression, setdata, tableview, triage |
Reporter | Ygor Lemos |
Assignee | Max Stepanov |
Created | 2013-02-20T19:12:31.000+0000 |
Updated | 2013-10-01T08:52:05.000+0000 |
Description
I have always used setData() to dynamically change or empty tableViews (even the ones which are not on foreground at any given time).
Ti 3.0.2.GA has broken this completely.
First I always get the following error when I use setData() with no parameters or a empty list:
[INFO] : PiniOn/1.1 (3.0.2.GA.5a77fe7)
[INFO] : 2013-02-20 16:06:11.101 PiniOn[29457:c07] *** Assertion failure in -[UITableView _endCellAnimationsWithContext:], /SourceCache/UIKit_Sim/UIKit-2380.17/UITableView.m:909
[INFO] : 2013-02-20 16:06:14.937 PiniOn[29457:c07] *** Assertion failure in -[UITableView _endCellAnimationsWithContext:], /SourceCache/UIKit_Sim/UIKit-2380.17/UITableView.m:1070
Second, when I issue setData() it doesn't redraw the tableView automatically anymore. It seems I have to redraw the whole screen so the new data can get rendered every time. (like reopening the window which the tableView is on again after a setData).
Looking at the source changes since 3.0.0 and the Assertion failure on TiUITableView.m it looks like it is something related to sections (which I don't use in this case).
I have tested this in 2 big projects I'm working on (AirportChatter / PiniOn). All tableViews that uses setData dynamically are breaking with 3.0.2 on both projects.
This may be related too: https://github.com/appcelerator/titanium_mobile/commit/7c476f0695c0855da9b13fde034575bd59f0172e#iphone/Classes/TiUITableView.m It seems that the way tableView data was rendered severely changed.
One suggested workaround is to try:
This forces a different code path. Does this help? Also, can you please add a sample piece of code?
I tried this sample (modified from KS), I am not seeing an issue. Sample code would be super helpful.
Hi Eric, I don't have a simple test case except from the actual source of two already published apps... I can try to make a TC here. I think that the main reason that you're not experiencing the problem with this testcase is because you're never changing from the main window nor drilling down to another window where the tableview should be... also in my apps I use the setData() with Ti.UI.TableViewRow objects not with simple dictionaries containing the title... this may lead to another code path... anyways... will try to reproduce in a general test case... but I guess other devs will have the same problem soon...
Thanks Ygor, let me try setting the rows and adding some windows.
@Ygor: great apps! you did everything in Ti? even the graphs in PiniOn? About your assertion problem. I fixed this in my private branch. I cant really make a pull request as i rewrote a lot too much in tableviews :s The problem is that numberOfRowsInSection can be called while modifying sections. What i did is use a boolean "settingData" that i set to true while replacing the tableview section data. If settingData is true then numberOfRowsInSection return 0. That should fix the assertion failure
Hi Martin, Yes, both are made 100% with Titanium :) Cool, do you have the intention of promoting this fix up to the main tree? As of now I don't realy need to go to Ti 3.0.2.GA but I'm worried with the future... I think others with complex TableViews (pre-cached by events for a smoother UI/UX) may suffer with this too...
@Ygor and @Martin. If there is a regression we will be addressing it. But we do not yet have a good test case that demonstrates the problem.
Tried with another sample code (using tableViewRows too) but was not able to reproduce. APP.JS file
WIN2.JS file
@Federico: first i am sorry as i wont have the time to investigate it. But to me the problem has nothing to do with windows or something else, but more about the "duration" of the setData. AS Ingo said a simple solution to that problem is a setData([]). To me if you want to reproduce it, create a tableview with something like 300 rows, custom rows, where the setData computation would be long enough for a "numberOfRowsInSection" to be called while setting Data. That my take on this.
Can I give access to an appcelerator engineer on my private github project so he can see the codepath causing this error?
Ygor, sure. Try https://github.com/eric34 for now.
just added eric34 to my ios project so he can pull the code and read the flow... let me know if you need a walkthrough on the app flow... also, if you need more people to access it... just beware that this is production code... thanks!
any news on this one? Kinda worried on not being able to move forward on Ti versions due to this...
@Ygor, Hello. I'll be working on this tomorrow morning. I'll report back.
Hello all, The cause of this has been discovered and dev is creating a pull request. My examples had no search feature. New sample code being created and will be incorporated in future test runs. Meu português está melhorando.
Reproducible test case:
PR https://github.com/appcelerator/titanium_mobile/pull/4029
@Eric Hey Eric and Max, thank you very much for solving this!!! Eric, Nice that we could also improve your Portuguese in the process :) Thanks!
Its working as per the test case given by Max. Environment used for verification - Titanium SDK: 3.1.0.v20130405170202 Titanium Studio:3.1.0.201304011603 Device : iPhone iOS 6.0, ipad4 iOS 6.0