jQueryMobile makes it easy to build a cross-platform mobile app. It’s currently on version 1.0.1 and there are still some major areas where it just doesn’t do its job very nicely. The biggest bugbear is page transitions. This is where I think the jQM team should be focusing right now because it’s so central to any kind of app.
The main problems
First off, not all transitions are rendered smoothly on all mobile browsers. Some of them will wobble and go into reverse and it’s just plain terrible. Others just demand too much from the rendering engine. So stay away from the ‘pop’ and ‘fade’ transitions unless you are only publishing to one platform and it works while testing and you’re sure all devices and OS versions will be equally accommodating.
A related problem is that even without complex code, a simple $.mobile.pageChange() command sometimes takes a while to kick off, and the user is left wondering why nothing happens on the screen. I’ve implemented a 10ms vibration for my Android app to reduce this uncertainty, but it’s still not nice. It is not enough that a button should visually change after a click: if jQM can’t kick off the page transition quickly, it should put a gray overlay on the page, or implement some other immediate visual reassurance.
The main cause
One major cause of these transition problems, as far as I can tell, is that most browsers do not take kindly to jQueryMobile’s habit of animating DOM elements that are not currently in view. They will tend to bring these elements into view even while jQueryMobile has other plans about what to put on the screen at that time. The slow response to pageChange() may be because the jQM team are careful not to start animating too soon for this reason.
If you have specified anything visual to happen in the pageShow() or pageBeforeShow() event handlers, particularly if it’s graphic animations or changes to form elements, you’re in for a very messy transitions. I’ve worked around this by setting a window.setTimeout() function for about 1 second. This hardly disturbs the user, and it makes sure that your animations are kicked off only after jQueryMobile has finished with its page transitions.
Ideas about a solution
The way to go, in my opinion, is to do something about the way pageShow and pageBeforeShow() are fired and sequenced.
1. jQueryMobile should make absolutely sure that all synchronous commands inside pageBeforeShow have completed before it begins the animations for the page transition. Of course it’s impossible to detect and wait for things like animations, but things like form.reset() should be allowed to do their job before the transition starts.
2. For asynchronous code fired from the pageBeforeShow event, the user should be given the option of opening with preventDefault() and closing with a resumeDefault() at the true end of the asynchronous chain, for example when doing localDatabase operations or timed screen animations.
3. The pageShow event should truly only begin when all transition animations have completed. Currently this is not the case, and animations inside pageShow will sometimes cause the viewport to briefly jump back to the previous page.
One workaround might be to bind all the pageBeforeShow and pageShow stuff using $(document).on(‘page[before]change’). The problem is you would have test what the “to” page is every time this event fires, so it will be a pretty big chunk of code for one event handler if you have different pages that need different work done. I haven’t tested this and it’s a labor-intensive change, but I’m interested to hear if anyone has any luck with this.
Now let’s hope somebody is listening!
