Skip to main content

First Impressions of jQuery Mobile 1.0a4.1

I just finished my first project using jQuery Mobile 1.0a4.1.  I am not new to JQuery in general, or to mobile frameworks, as I have built other projects using jQTouch.  What is contained herein are my thoughts about having used JQM (how I will refer to jQuery Mobile from now on) and some of the pitfalls I faced.
The first few things I noticed about JQM that jumped out and made me want to use it for my project were:
  • Support by Adobe announced in the new Dreamweaver (even though I don't use dreamweaver, this is a good sign of community buy-in)
  • The REALLY nice theming engine.  This is top shelf -- easy to use, easy to understand, easy to customize, sort of...
  • The prefetching of pages so they can be animated all within one DOM
These were tantalizing features and warranted exploring in something other than a 'hello world' app.  While this blog entry may seem like lots of 'gripes' -- I actually found JQM to be quite nice to work with.  In fact I do recommend it for developers.  My writing may focus on the problems, but that is only to help others who have the same problems.

Problem 1: Scalable background

The first challenge I had (and I still am not sure I have figured it all out) was that the nicely drawn gradient background didn't scale to fit the background.  This was VERY noticeable on the iPad, where the background stops about 2/3 of the way down the page, and shows an ugly gray background, although I also experienced it on an iPhone and my Android phone.

I used all my google-fu and couldn't come up with any documentation or Q/A, discussions, etc. where others solved this issue, so as is typical, I banged my head and worked through it.

I since came up with a rather ugly css fix (with consequences) by adding the following to my site-specific css:

.ui-page {
    min-height:100% !important;
    height:100% !important;
}

.ui-body-a {
    min-height: 100% !important;
    ...
}

This was more of a desperate attempt to get the CSS to yield to my control.  The result was that pages do in fact scale and fit the screen so that the nice background gradient works as intended. 

The consequence is that the really nice "loading" widget that comes up when new content is being loaded (an ajax call, ironic when you look at the next item), no longer is a nice roundy box in the middle of the page, but rather is a silly post that shows up vertical in the middle of the screen.  This was much less annoying than the background cutting off short, so I opted for the weird loading widget to stay.

Problem 2: Ajax loaded content breaks the DOM somehow

Part of my mobile app is dynamic.  Wow, what a concept! As is oft my desire, I tried to make the mobile app layer as business-logic-free as possible, allowing the other back office systems to do the heavy lifting.  It was not to be in this project.

I attempted to do a rather simple ajax call to a remote page passing in URL variables, expecting back well formed html content to insert into a DIV jQuery style.  No problem, added my code, made the remote page give me what I wanted, tested, and it all works, or so I thought...

My web app called the remote service, retrieved the data I wanted, and returned it to me, and I successfully inserted it into the DIV I wanted on screen.  Any other day, I'd call it done and move on.  JQM for some reason absolutely hated what I was doing.

The form is of course on a sub-page of my app, so I go to the main menu, navigate to the form (JQM gives me my nice transition, and shows me a 'back' button since it tracks history).  All good.  If I hit the back button before searching, it all works great.  But... if I actually do a search (and insert results into the inline DIV), it appears to work visually, until you try to use the 'back' button and realize that the ajax call you did hosed the history in the JQM app!

I spent many hours on this, and once again, found no solutions by anybody else on the net for this issue.  I didn't have any of these troubles when working with jQTouch.

Ultimately I abandoned the inline-ajax-results solution and opted to make a server-side page that did the remote server call for me, and then I just did a JQM form post to the new JQM page.

The end result looks the same, but it means that there is some business logic in the mobile app now (the part that calls the remote service) instead of doing it all with javascript.  Weird thing is that my javascript all worked, it was just JQM that puked all over my effort.

Problem 3: Transition flicker after form submits

This is a crazy one, and I haven't found a solution to this yet.  If you navigate the JQM app, everything is peachy, transitions are nice and smooth, all until that dreaded form...

Once you submit the form (whether there are results displayed or not), all the JQM transitions are somehow internally hosed.  The transition from the form page to the results page is now jerky and has lots of flicker, and if you go back to the main screen (back buttons all still work), navigating to any other page has the same jerky flicker type of transition.  A reload of the web app clears it all up, unless you use the form again.

There were a few suggestions posted online about adding some webkit css changes to different containers, and other items, and I was even concerned that my previous hacks above might have contributed to the problem, so I tried all the suggestions and even backed out my other changes, but was never able to overcome this issue. Suggestions are welcome.

Things I like about JQM:

I have to say that from start to finish, JQM sped up all the development.  The built in layout bits are great, particularly the grid layouts, and the swatch based themes.

As an example, I really liked one of the built-in themes, but needed to just tweak a few of the items to use my color scheme, so I included the JQM css file, and then included my own CSS file after, and simply overrode the styles I wanted to change.  Browsing through the css file for JQM showed that it is very well organized, and easy to pick out bits to override in my separate css file.  The benefits of doing it this way are that you don't need to duplicate and host all the little icon images and such for buttons, tool bars, etc.

The list formatting makes it almost comical how easy it is to make nice looking layouts, roundy borders.

The pre-fetching system with ajax calls for page links is brilliant, and really does make it easy to put together a nice mobile or tablet skin for a web application.

Summary

I probably said it all already, but jQuery Mobile is really quite nice.  It still has some rough edges, and some growing up to do with weird layout bugs, but at the same time it is cutting edge and gets 90% of the job done VERY well.  I highly recommend it.  Next on my list is a PhoneGap project.  Stay tuned.

Popular posts from this blog

Making Macbook Air with 128GB SSD usable with Bootcamp

I recently got a new Macbook Air 11" (the 2012 version) and loaded it with goodies like 8GB ram and 2GHz Core i7.  What I DIDN'T upgrade was the internal SSD.  My config came with 128GB SSD and I refused to pay $300+ to upgrade it to 256GB.  Yeah I know, some call me cheap, but SSds cost $75-$150 for 240GB, so adding another 128GB for $300 seemed way too steep for me.  I figured "ok, I'm going to make 128G work!"

Here is the story of how that went...

Installing python 3.4.x on OSX El Capitan

I love "brew" package manager, but sometimes being too progressive breaks things.  I have several python apps that I maintain that get deployed to AWS using Elastic Beanstalk.  AWS eb can deploy with python 2.7 or 3.4.  Any recent 'brew install python3" will get 3.5.1. #annoying

Dell XPS M1330 + Snow Leopard Hackintosh

I have been working with a Dell XPS M1330 laptop for a few years now.  It doesn't quite match up to the newest notebooks in terms of performance, but it certainly still has some life in it.  I had previously installed OSX 10.5.x on it as an experiment, and had moderate success.  I decided to revisit this idea again to install Snow Leopard (OSX 10.6) on the Dell M1330, and keep some notes for those of you brave enough to Hackintosh your own machine...