- This topic has 21 replies, 4 voices, and was last updated 12 years, 3 months ago by
.
-
Posts
-
Team-
Ok, here’s the problem. I have a long list of approx 1200 items. Each list item is a bar with an action. I broken down the total list alphabetically with separate screens for A-C, D – G, etc, so no one screen contains more than approx 250 items. A ‘summary’ screen has buttons to access the A-C screen, etc.
Problem: If I run the test center on just the A-C screen for example with +/-250 items, and test on my iphone, scrolling is fast and smooth as silk. When I run the entire list through the summary screen accessing the entire list, the scrolling is realllllllyyy jumpy and slow. I’ve stripped out all images, but I am using the lastest version with customized/colored bars. Also within each screen (like A-C), I’ve grouped list items into 75+/- scrolling panels – perhaps all items from a lengthy list should be in a single panel?
Thoughts or help?
Mike
I need to check but I think the list scroller algorithm is optimized to be performant up to 100-200 items. As you start to go beyond that and upward towards 1000+ items it will probably require a different scroller implementation optimized towards an infinite scroll model. I’ll discuss with our dev team for advice they may have. I was recently working on large list but partitioned my list contents to load a subset of data, e.g., A-L, M-R, S-Z ranges.
Hi Wayne-
Thank you for your quick response.
I’ve split the list down into 5 groups by name (alphabetically). Each group (A-L, etc) is allocated into a separate screen, and one ‘summary’ screen has navigation buttons to go to the 5 screens with the list items /data (actually each of the 1000 list items are linking to screens with addresses – so it’s a lot of list info with a lot of links). In the test center, running all screens together, the scrolling really bogs down when you navigate to the list screens. In the test center, is all data ‘loaded’ when the run is complete, or is data loaded when the navigation is activated to go to the ‘A-L’ screen (for example)? Because the whole app bogs down, I’m guessing I’m hitting some sort of limit on the max number of list items or links, regardless of how the list is broken down / allocated across different screens.
I’d really appreciate your help 🙂
Mike
Performance can depend upon many factors. I assume the entire list is already in the DOM which will consume some space. I will discuss with our lead dev on this (note he is out on vacation for another week).
Good Morning Wayne-
Just thought I’d check in and see if there’s any progress with the scrolling issue.
I’m now using 2.1, and it’s the same problem. To replicate the problem, it’s really easy. Create 2 scrolling screens. Move a list widget to one of them, copy/paste entries until there there a few hundred entries. Then save/rename the screen until there are 6 duplicate screens with a long list on each. Go back to the first screen, add 6 nav buttons, link the screens, run it, try in on an iphone, and you’ll see the scrolling is jumpy/slow.
Let me know what you think, and thank you for your help 🙂
Mike
I have a similar problem, but my lists are not as long. They have between 20 to 60 items and the scrolling motion is not very smooth.
It’s been tested on an iPhone 3GS and 4S with the same results.
Hi RCS,
Could you provide us the details about the SO on your devices? Also if you can share an example design file, it will be very helpful to replicate the issue. If you want to keep the data in privacy send it via support at genuitec dot com. Use title “mobione data from RCS”. Thanks for your assistance.
Good Morning Octavio-
I emailed you the mobi files for my epic scrolling project, and more info is included in the email to your support address. Let me know what you think & find; this one is about ready to be wrapped up.
Thank you for your help-
Mike
Sorry for hijacking this thread. I redid my tests on an iPhone 4 and the scrolling is smooth. On the iPhone 3GS and on older Samsung Galaxy S, the scrolling is a jumpy. It looks like it may be related to processor speed. I will try to bundle up a test project and submit it.
I noticed that MobeOne uses the iScroll javascript library. Do you know if there are any plans to update to the version that was released in March?
You are correct re: impact of processor speed on scrolling performance. Also there is a diff in the JS engine used in mobile safari and in the UIWebView. Seems that UIWebView is limited to the older less optimal apple javascript engine. We plan to reeval the iscroll version soon (no definite date atm).
Hi Wayne-
Does your previous post mean I’m out of luck, or is there any status / work-arounds / solutions to my scrolling problem? The bottom line is I simply cannot upload to the app store as is….I’ll get crucified in the reviews.
Let me know your thoughts-
Mike
We haven’t forgotten. No progress yet. Been chasing down some regression layout issues in 2.1 that have top priority atm for immediate rollout once fully resolved.
Hi Mike,
We have researched this and in general long list depending up on how they are constructed can be resource and computationally intensive, especially on the current class of device processors. For example use of gloss or gradient backgrounds can dramatically increases the performance load on the device if used for long lists. MobiOne apps leverage the device’s webkit rendering engine. When drawing each gradient element WebKit allocates bitmap with size equal to HTML element’s size. So, when there is hundreds of elements on page WebKit needs to allocate hundreds of bitmaps. We are looking into accessing more hardware-based acceleration but that is currently a research topic that may or may not be successful.
The primary suggestion we can give is: avoid use of gradients or gloss effects for long list. Instead switch to solid color background.
