Appcelerator Entourage

This was posted to appcelerator's Q&A here. Note the suggestion to try a heavyweight window that did not solve the problem. This code seems so straightforward to me that I'm pretty convinced it has be a Titanium bug.

We have a mobile Android app with a tableview that sometimes has many (800+) rows, and when it does, it will load and run fine the first time, but then crash the second time (it can sometimes take a few reloads depending on the number of rows, etc.). The example code below with 1500 rows is crashing consistently on the second showing. The UI gives a generic "your app has stopped unexpectedly"; the trace shows "Out of memory on a nnnn-byte allocation". This example code is a bit more simple than our real app which has more data on each row and has more windows, etc., so I think that's why I had to bump the number of rows up to reproduce the problem.

Note that each of the tableview rows consist of a view with 2 stacked labels. I wasn't able to reproduce the bug with more "plain" rows. Based on ddms memory dumps of our production app, it looks like it's the tableview rows that aren't being released.

We've seen the suggestion to display the data in "paged" chunks, but we don't want to do that just to avoid memory issues (leaving aside the question of it being a better UI for our users). If there's a memory leak, paging the data will just delay the inevitable. We have a separate (native objective-c) iPhone version of this app that runs fine with the ginormous tableview. This Titanium Android app is a re-write of our iPhone app.

This is the last bug preventing the release of our app....

Link to code: https://gist.github.com/934847