[TIMOB-1069] table view rows with scroll view crashes when simply scrolling the table view
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Trivial |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2011-04-17T01:55:07.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 1.4.0 |
| Components | iOS |
| Labels | ios, iphone, mobilesdk, scrollview, tableview, tableviewrow |
| Reporter | Nolan Wright |
| Assignee | Blain Hamon |
| Created | 2011-04-15T02:43:07.000+0000 |
| Updated | 2011-04-17T01:55:07.000+0000 |
Description
http://helpdesk.appcelerator.net/tickets/2844">http://helpdesk.appcelerator.net/tickets/2844
test case attached to ticket. each row has a unique class name but for some reason our code complains that it doesn't
Attachments
| File | Date | Size |
|---|---|---|
| app.js | 2011-04-15T02:43:07.000+0000 | 2222 |
| default_app_logo.png | 2011-04-15T02:43:07.000+0000 | 87937 |
Mail that was sent to the customer:
It appears that, for some reason, UITableView (The underlying iPhone class) treats the strings in the ClassName as identical. I'm not sure why this is, (It might be that it stops looking at the string after a set number of characters) and I'll look into it, but in the mean time, here's a workaround:
Remove the custom className from the tableRow's creation. When the className property is missing, Titanium actually generates a classname of its own internally (Using the memory pointer as the unique key -- which is faster than UUIDs as a bonus), and the warnings and crashes went away.
Hey Blain,
Thanks for getting back to me. I tried the workaround (eliminating the className property altogether) and I still get the "different layout than expected error" and a crash if I scroll all the way to the bottom and all the way back to the top in the app.js I attached to my ticket (I've attached it here as well). I also tried manually specifying a short, unique className and still got this behavior in the attach app.js.
It's strange, I believe I've only seen this behavior when a ScrollView is present in a table row, but with it in there className seems to be totally ignored.
2010-06-02 20:38:42.504 TableViewTest[603:207] Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: ' -[UIScrollView transferProxy:]: unrecognized selector sent to instance 0x5333fd0'
Meant to attach the app.js file.
Okay, I did a regression test. App.js crashes in 1.3, and does fine in HEAD. The difference being the fix/test for un-named classes happened some time since then. (I need to write these things down)
A few solutions: 1) Either pull from HEAD and build a fresh post-1.3 build of Titanium, or 2) have Nolan provide you with same.
Another workaround would be that the identifier doesn't need to be wholly unique, just unique within that table view. So if you were to simply have the row number (With no preceeding common text) as the className, or a counter if you intend to modify rows later on, that should be sufficient for unique rows.
(from [97825f3c1179e136a01e83741bbc0614f3b372fd]) Closes #1069 , with debugging cleaned up: TableViewRows were looking at the TiUIView's subviews, instead of the views of their proxy's children. Most times, this is okay. But things get very confused very quickly with scrollable/scrolling views. http://github.com/appcelerator/titanium_mobile/commit/97825f3c1179e136a01e83741bbc0614f3b372fd"> http://github.com/appcelerator/titanium_mobile/commit/97825f3c1179e...