Appcelerator tableview click event getting wrong row in Android when using className

0
votes

I'm using Ti SDK 5.2.2, Studio 4.5.0 and I am using standard code (not Alloy).

Background I have an App with 5 tabs in a tabgroup. The first tab/window contains a table that is created by pushing multiple custom tableViewRows into an Array and then into the table. I then insert or append additional tableViewRows to the table as necessary. Each of these tableViewRows consists of 3 main views (added vertically) containing in total 1 imageview and 10 labels (some are custom font instead of using additional pictures) the total height for the rows is either 260dp or 460dp. I have to use the className in the row creation for Android to help it become responsive and not crash if the table gets too long (around 50-60 rows). iOS is fine. Btw the other 4 tabs also contain tables just more static in nature, smaller with less/no interaction available.

Problem Only in Android. Even with only 10 items in the list, the click/singletap event on the row returns incorrect info sometimes. This doesn't happen all the time, but when it does, I end up updating the wrong row based on a users click. I can clearly see that the e.index, e.row sent back are from the next row. This usually happens after scrolling FAST-ish to the bottom of the table and then back up (note only 10 rows in the table for this test).

Funnily enough, the e.source is always correct, so if I add the same id to the row and to the label/icon I am clicking, looking at e.source.id and e.row.id will be different.

Has anyone seen this before? Is is an undocumented feature of className? Does anyone have a simple workaround? Bare in mind that I am also inserting rows into the table from time to time so I can't simply add an index to a ref since it will change. The best I have come up with is the try to calculate the index by looping through the actual data in the table (i.e. through self.data[0].rows) on every click to match what I am looking for and then move on.

[Edit: I've found a few references to Ti.UI.SIZE causing this sort of issue over the past 2 years, but have confirmed that removing the 2 I had (only on labels with parent views that have a specified height) did not make the issue go away]

TLDR: The module I am using to access a pull to refresh in Android is causing the issue on aborted pulls. [com.ezziprod.pulltorefresh]

1
androidindexingtableviewappceleratorappcelerator-titanium
Can you add your code ? To handle the clicked row, i suggest you to listen the click event of the TableView and get the date you need with e.row or e.rowData inside the callback click event. Then, try to add touchEnabled : false on the child element of your TableView – Thomas Lemaitre
I'm not sure adding my code is going to help since my app has 1000s lines and this is a small part. click/singletap there is no difference in the result. My problem is that e.row and e.rowData inside the callback event (rare occurance) is for the wrong row (as described above). Setting touchEnaabled to false for any of the child elements invalidates what I am trying to achieve - i.e. I WANT the user to be able to click on this label and for an action to occur. I will try to create a full test case to show the problem without sharing sensitive code. Perhaps you misunderstood my question? – Brad White
If this ends up being a bug/issue - I will definitely raise a JIRA ticket (and link here) - just wanted to see if it was expected behaviour .... – Brad White
If you create a small sample application with the tableview only and the required listeners, can you reproduce the issue? – Soumya
I was doing just that and it lead me to the issue. Sorry for wasting your time @ThomasLemaitre and Soumya. I am using a module to simulate Pull To Refresh for Android (com.ezziprod.pulltorefresh) and this seems to be increasing the indexes of rows in the table. All is well for full pulls to refresh, but on an aborted pull (such as fast scrolling to the top may trigger), the indexes remain incorrect. I'll take it up with the author. – Brad White

1 Answers

0
votes

I would replace the TableView with an ListView and using "itemIndex" instead of "index".

I guess that will fix your issue.