extremely SLOW on iPad - Titanium.UI.View objects amount restriction?
We are developing SQLite database based application for iPad, which requires option to display rather large SQL datasets.
For data representation we are using Titanium.UI.ScrollView object and dynamically created Titanium.UI.View objects which represent rows in SQL dataset. 3 Titanium.UI.Label objects, 1 Titanium.UI.ImageView object and another Titanium.UI.View object with 4 Titanium.UI.ImageView objects used as tapable action buttons.
If user taps our touches any of the Titanium.UI.View objects placed in the Titanium.UI.ScrollView object it opens additional Titanium.UI.View object containingTitanium.UI.WebView with the additional information from the SQL dataset mimicking master-detail view relation.
The problem is - it looks and works great (read rather fast) in iPad simulator, but when installed on device it randomly fails to start (it freezes displaying application startup image) and when it starts it is very slow - select form SQLLite and then creation of 30 described Titanium.UI.View objects and placing them in the Titanium.UI.ScrollView takes about 5 seconds but 100 SQL rows can take up to 30-40 seconds. With 100 rows when Titanium.UI.ScrollView.ScrollTo function is called from detail view to move to next or previous Titanium.UI.View object in the ScrollView there is some (noticable) delay till scrolling starts and scrolling looks clumsy.
We did experiment with filling the Titanium.UI.ScrollView with 100 described objects without the SQL and result is the same - meaning it's not the SQL to blame.
So the questions are:
- How much Titanium.UI.View objects can be used in iPad app to get decent performance?
- What can be possible reason for random app startup failures. It looks like some memory buffer overflow - but we can not determine what exactly causes it.
- Is there some way to debug application on iPad - like using Titanium debug console ?
2 Answers
-
The number of UI elements are not something that it can be counted I think. All depends on what type of view is.
A webview will put way more load on the device than a simple view.Maybe you could optimise the code trying to reuse the webview for example. If there is only one view visible at a moment there is no reason to create 100 webviews.
Try to use exact sized images and optimized ( http://imageoptim.pornel.net/ )
You might try to cache some stuff, like the sql results.
Try to reduce the "fancy stuff", no rounded corners, opacity/transparency should not exist, and so on.
Later you can play with this or use some background images that emulate the rounded corners, etc.Maybe instead of the scroll view you could use a table, and set the same className to all the rows, to take advantage of the rendering engine.
For debugging should be enough to open the project and compile it with xcode in device-debug mode and gdb console should be there.
Hope it helps:)
-
Richard,
I have an iPad app in store with functionality like yours – but with 5 sets of scrollviews, sum of 100 views total (image+label+text), and each opens webview on click.
For storing data, i just stored one xml file, and opted not to cache any data so we can get it up fast and running. Initially, i was planning to implement that though but the lack of Ti folder controls put the idea to rest. Also, some of the webview may contains too many images and that's definitely no no for caching. In the future, i may try to store just texts.
Check it out, it's a free app, see the performance any better than yours?
(FYI, the new version 1.02 has slightly different looks than the screenshots in itunes. Apple changed the rule recently that you can't longer change images once it's in review and forward, lesson learned)http://itunes.apple.com/app/slashgear-for-ipad/id375037413?mt=8