[TIMOB-7796] Android: Accessing row and rowData properties has different results for TableView
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | High |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2012-04-20T16:25:28.000+0000 |
| Affected Version/s | Release 1.8.0.1 |
| Fix Version/s | Release 2.0.2, Release 2.1.0, Sprint 2012-08 |
| Components | Android |
| Labels | api, parity |
| Reporter | Varun Joshi |
| Assignee | Ping Wang |
| Created | 2012-02-23T17:39:49.000+0000 |
| Updated | 2012-05-23T12:40:07.000+0000 |
Description
The sample case is the KitchenSink app on Android. Please follow these steps to reproduce:
1. Navigate to Resources/examples/table_view_basic.js and table_view_api_basic.js files
2. Go to showClickEventInfo(e, islongclick) function
3. Add a small line to access the e.row.title and e.rowData.title properties.
The issue is that with the tableview created in table_view_api_basic.js file, the title can be accessed through both e.rowData.title and e.row.title but in table_view_basic.js file, this is not the case.
Please clarify about this issue.
Neeraj and Varun, this issue is invalid. Starting from 1.8 SDK, when rows are created explicitly (by using "createTableViewRow"), they can be accessed in event listener as "e.row", while when they are created implicitly (by using JS object, like { title: "Table view row" }), then "e.rowData" has to be used. Before 1.8 there was no difference between this two.
The row property should exist regardless of how the table view row was created. The rowData property should only exist when the old method of row creation is used (via setting the data property on the TableViewProxy).
Ah, I see, thanks for clarifying that. Could that be mentioned in documentation?
Will do.
+1 on adding that to documentation - just ran into this problem tonight and finding issues between android and iOS recognising rowData.
Tested with 2.1CI 2.0.2CI with the client's code. Working fine. Closing as per Alan's request.
The classname property does not stay consistent in both cases since we manually set it to normal in one of the cases. There is a bug filed for this: TIMOB-9208