Question

I want to implement a jQuery Mobile application without browser history navigation (feel free to ask why). I can generate pages on the fly, insert them into the DOM, and bring them up with changeHash set to false, then clean them up in the pagehide event handler, and all is well in the world. Until I use a widget like selectmenu that invokes a dialog. The dialog’s close function explicitly invokes window.history.back(), and my world implodes.

Is there a simple workaround for this issue?

If not, should jQM be adapted to gracefully support nav-less apps, or is jQM fundamentally unsuited for this kind of application?

Answer 1

I learned not to use changeHash=false for this purpose. Make sure that the current page is always at the top of the history stack. In my case, it’s the only item on the stack except when dialogs are invoked. So far, this seems to be working like a champ:

function showNewPage($page) {
  $page.appendTo($.mobile.pageContainer);
  $('.ui-page-active').bind('pagehide',function(){$(this).removeWithDependents()});
  $.mobile.changePage($page);
  $.mobile.firstPage = $page;
}

The new page is created without a hash, so the URL never changes. Since I’m actually replacing the first page, I had to update $.mobile.firstPage. The call to removeWithDependents() instead of remove() cleans up the dialogs that are created by selectmenu.

Fortunately, it’s a lot more concise than I anticipated, just a bit of a pain for a newcomer like me to piece together. I’ve seen a few comments advising not to “hack” jQM in this way, but I think there’s way too much value in jQM to constrain it to a traditional server-dispensed presentation model.