Mixing jQuery Mobile and ASP.NET WebForms

I’m going to depart from my usual post subjects and get a little more technical.  I recently had an unpleasant experience trying to use jQuery Mobile with ASP.NET WebForms.  If you're thinking about doing the same, I recommend stopping right now and start using ASP.NET MVC.  To see why, read on.

To start, before I had gotten into jQuery Mobile, I had assumed that it was simply a slimmed-down version of jQuery built specifically for mobile devices.  I was wrong.  JQuery Mobile is built on top of traditional jQuery, and it is intended to simplify the styling of web sites to make them look and behave more like native mobile applications with as little development effort as possible.  For example, by only adding “data-role=’listview’” to a <ul> tag, you can specify that the <li> tags underneath show up in a typical mobile stacked list.  (You can check out the jQuery Mobile documentation to see an example.)

Anyway, I started with a typical login control on the first page, created some list pages, and created a couple of data entry pages.  It worked extremely well at first.  All of my page navigations loaded smoothly into the next page, and the user interface styling happened exactly as advertised.  Fantastic!  I was quite pleased at this point.

Then I added a “Logout” LinkButton.  It wouldn’t post back.  In order to get the page transitions to work, jQuery Mobile, when navigating between pages, loads the next page using JavaScript, then slides the new page into the view of the user.  JQuery Mobile was apparently doing its magic on all hyperlinks on the page, including my LinkButton.  A Google search gave me several suggestions on making it work, ranging from unbinding the control to adding an attribute “data-role=’none’” to the control.  None of which worked.  So I made the logout button redirect a page that logged the user out of the application.  That’s not how I would have liked to implement that functionality, but it’s better to have full functionality with a less-than-ideal implementation than an ideal implementation with a less-than-ideal set of features.

So then I started working on the data entry pages.  On one page, the user is required to enter a zip code, and a dropdown is populated with the matching counties.  Since I didn’t want to fight ViewState or turn it off altogether, I decided to use an UpdatePanel to refresh the values.  Changing the text of the zip code textbox didn’t cause a postback, but instead caused JavaScript errors.  The errors made no sense to me, so I went back to Google.  It didn’t take long (about 2 minutes, I think) for me to realize that UpdatePanels and jQuery Mobile really can’t work together.  Even if I had been able to get the JavaScript working, the CSS classes that jQuery Mobile would add to the page elements would be lost when an UpdatePanel is refreshed.  Sigh.  That wasn’t a huge deal – I turned off ViewState on the dropdown, bound it on every page postback, and wrote my own AJAX (using the ASP.NET AJAX stuff) to populate the dropdown.  I don’t like UpdatePanels anyway, so I wasn’t too heartbroken.

Then I went back to the list pages.  The navigation was working well, but I needed to give the users the ability to claim items off the list.  We wanted a certain look, so I used ImageButtons for the task.  Unfortunately, there were errors in the postback process, which made it difficult for the browser to send back the CommandName and CommandArgument from the ImageButton properly.  Ok, so time to do that manually too, using hidden fields to store what would have been the CommandName and CommandArgument that should have been returned by using the button.

Then I noticed that after I had logged out, I couldn’t log back in.  I did some digging, at it appeared that the AJAX load of the page confused ASP.NET into thinking that any postbacks after logging out should go to the logout page first.  So no matter what happened, the user would be logged out immediately after trying to log into the application a second time.  Then I noticed the same problem on some of my list pages – the browser would try to post back to the page in the URL, not the page on the screen.  At that point I gave up and removed the jQuery Mobile from the application.

JQuery Mobile seemed like a great tool with a lot of promise.  It did not mix with ASP.NET WebForms, however.  JQuery Mobile was built for a pure web environment, not a web environment with the goofy postback model that WebForms uses.  If you're looking to do mix the two, save yourself some time and frustration and skip one or the other.  The next time I do a mobile web project, I will definitely use ASP.NET MVC with jQuery Mobile.  The integration between the two should be much more natural.