That's right folks...I refactored my lazy-loading mess (albeit, working mess) of custom code and globals into a proper jQuery Mobile widget for lazy loading listviews. The idea is to enable the widget on index pageinit, and then track instances of pages that contain listviews that can all be independently lazyloaded with the main widget instance. I have a working version already, but need to add some other functionality (and documentation) before I would feel comfortable releasing it. Give me a week or two and I should have something up on github to share with the community. I'm trying to gauge interest, so if you're interested, respond to this post and let me know.
This is my first topic here on the jQuery Mobile forum, and it is also the first time I'm publicly showing the project I've been working on. Hopefully you don't think it sucks.
I think it's well known that there are some challenges to overcome around transitions and the blinkyness/jumpiness that is often experienced before and after a transition. The JQM team has provided the option to default to none if desired, which improves the user experience on Android, but it would be nice to smooth out the transitions a bit more, even when running on Android or other 3d challenged devices.
So, first the demonstration using jquery.mobile-1.1.0.js from the officially released JQM v1.1:
Now, for the demonstration using the customized version of jquery.mobile-1.1.0.js that uses the jQuery plugin "ScrollTo" (http://flesler.blogspot.com/2009/05/jqueryscrollto-142-released.html) to provide a callback to the scroll as well as easing, which actually uses another jQuery plugin "Easing" (http://gsgd.co.uk/sandbox/jquery/easing/). In this case, I'm using the "easeInOutExpo" algorithm. Note: while recording the videos (this one in particular) I made it a point to only use the down arrow button in the footer or the actual scroll bar to scroll manually (although, I messed up and did the two finger scroll in the first video above - i.e. while I was on the queue page - but didn't feel like starting it over). The rest of the scrolling you see is being handled automatically by the modified transition phases.
This was a bit of an experiment to see if I could take control of the necessary scrolls both before a transition (scrolling back to the top) and after a transition (when going back - i.e. the scroll back down to the last scroll position of the previous page when returning to the page). This video was taken in the best of circumstances (i.e. in Desktop Chrome running on OSX). In my limited testing, it seems to "kind of" improve things on the worst of circumstances (Android 2.x) but can still seem jumpy if the frame rate of the animated scroll isn't good enough to keep up.