Fix for scrollable view memory issues? - Will Pay
i have tried everything i know to free up memory on my app including using the removeView method to remove all but 2 views at a time and it doesnt help at all.
appcelerator quoted me $350/hr for 'architecture support' which i think is steep. anyone have a fix that they would share for less?
5 Answers
-
This is well known Ti bug and not "limits of the platform". Scrollable views are one of the most basic UI elements of iPhone so this issue should be top priority for Ti dev team anyway.
After month of fighting with Ti bugs and "limits of the platform" (like documented features which actually don't work as advertised and non-answered error tickets on lighthouse) I am also starting to look at Obj-C.
-
Thank u. The issue is I've asked here and have seen numerous others with the same unresolved issue. I imagine that it's not that hard a fix and would hate for appcrlerator's team to tell me it took 3 hrs and bill me $1000+ for an app that I probably won't make a great deal of money on.
So I tried to incentivize the community to help.
-
Sean
You haven't posted any working code yet. If you want to do so, and image assets are required to demonstrate the issue, it would probably be best if you zip the project (or a stripped down version of it) and upload it somewhere.
-
I have blogged my answer, have a look
http://shakilspace.blogspot.com/2011/02/appcelerator-titanium-scrollview-swipe.html
-
Sean
This Q&A forum is intended for people to describe requirements that are possible within the limits of the platform, so that everyone can discuss possible solutions in a public space so that others may benefit in future.
You are welcome, for free, to post some stripped-down, working code (so that it can be dropped into a project and it runs without modification), and someone in the community, I am sure, will try to help you.
The advantage, I imagine, of employing the development team's skills directly, via one of the support plans, is that you will almost certainly get a workable solution, even if it involves reprioritization of existing tickets or enhancements to the codebase.
I'd recommend at least trying the first suggestion. If you are pressed for time or unwilling to share some example code, then the latter is your most reliable option.