[TIMOB-1561] iOS: Running animation and closing a window causes a crash sdk 1.4 iOS 4
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Trivial |
Status | Closed |
Resolution | Cannot Reproduce |
Resolution Date | 2012-07-25T16:58:59.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | iOS |
Labels | n/a |
Reporter | ctredway |
Assignee | Neeraj Gupta |
Created | 2011-04-15T02:56:05.000+0000 |
Updated | 2012-07-26T22:22:04.000+0000 |
Description
See this help desk ticket for reference.
The customer reported that when an animation is running and the window is closed, the app crashes. I verified this is the case. Attached code shows this.
Attachments
File | Date | Size |
---|---|---|
resources-2.zip | 2011-04-15T02:56:05.000+0000 | 140419 |
resources-9.zip | 2011-04-15T02:56:06.000+0000 | 140345 |
http://developer.appcelerator.com/helpdesk/view/34191" title="Here is the link to the help desk ticket">Here is the link to the help desk ticket
Ticket's name is misleading; this has to do with a view containing a tableview being closed while the tableview is undergoing an operation which changes the number of rows. This causes an internal consistency problem.
I'd like to add that it only crashes when properties are defined on the tableview, before or after creating it.
Just a note that there's a problem with the JS code that might be obfuscating the real issue; the append/delete actions are performed on different threads and this screws up the order of operations (for example a row might be attempted to be deleted which hasn't really been appended yet).
There is (likely) no way for us to work around this. All table operations need to be performed internally on the same thread or it may raise consistency errors. I'll spend more time on this issue if I'll be able to before the 1.5.0 release or if there's a different sample that demonstrates the issue which doesn't involve timers.
I faced that issue and to avoid that I added a delay (SetTimeout) between the append/delete loops. If you try doing that without the delay it will surely crash because of the reason you said.
My workaround for the current state of the issue is to replace the window back button with a button that sets a variable to true that will break any of the append/delete loops and then closes the window.
The other way is by not adding any properties to the tableView and use it as it is created. No separatorStyle, no backgroundColor, selectedBackground, nothing. This way it is just too plain simple to actually use it in a more refined app but at least it won't crash at all.
My app is live at the Appstore, but my back button (workaround) works in 1 out 3 actions only.
I just can't get rid of the setTimeOuts between delete/appends to prevent the inconsistency issue you mentioned from happening. If I delete/append on a single thread, slow delete animations will hold it back and inconsistencies will occur crashing everything. If I could turn off animations this would work, but as of right now I've learned that it is not possible.
I got rid of the main SetInterval though.
Multithreading tableview/animation problem.
Well. I ran the test on SDK 1.8 and now I only get a warning: [WARN] Table view was not in place before insertRowBefore was called. (Tell Blain or Steve to fix it!) But it won't crash the app. I guess you have indirectly fixed it.
Do you have a small set of sample code that demonstrates the issue?
it's already attached to this issue.
Cannot reproduce in SDK 2.2.0.f9e938d on iPhone Sim 5.1. Likely fixed as part of a slew of other tableview issues.