How to modify jQuery mobile history Back Button be

Question

I'll start this off with I have researched a bit, but no solution that solves what seems like it should be a simple JQM modification.

I have a wine review webapp that has the following view user flow: http://5buckchuck.com/

Wine type > Wine list > Wine Details > Wine review (redirect via django backto ) > Wine Details updated from review

What I want to happen is when the user presses the back button it should go back to the wine list. What currently happens is the the Wine Detail view is reloaded. It takes pressing back three times to get back to the Wine List. :-(

My thoughts to solve this were two:

1. Splice the last 3 items from the history stack, if the last items in the history stack was Wine Review. I had a hard time trying to introspect the last history object to get the pageURL. I have a feeling that this solution is a bit too fragile though.

   var last_hist = $.mobile.urlHistory.getActive();
   last_hist.data.pageURL;
   

2. The second thought was to override the back button behavior so that the back button from the Wine Detail view would always go back to the Wine list view

   $('div#wine_detail').live('pageshow',function(event, ui){      
     $("a.ui-btn-left").bind("click", function(){
       location.replace("/wines/{{wine.wine_type}}/#");
     });   
   });
   

There is probably a better way to do this, but I'm a bit out of ideas.

Update: So I continue to hack on this with somewhat negligible results. On thing I have found was this is what I basically need to work: window.history.go(-3)

from the console it does exactly what I need.

So I tried binding it the the back button like such:

$('div#wine_detail').live('pageshow',function(event, ui){
  var last = $.mobile.urlHistory.stack.length - 1;
  var last_url = $.mobile.urlHistory.stack[last].url;
  var review_url = /review/g;
   if (last_url.match(review_url) )
     {
       $('div#wine_detail a.ui-btn-left').bind( 'click', function( ) {  
         console.log("click should be bound and going back in time...")
         window.history.go(-2);
         });
   }
   else
   {
     console.log('err nope its: ' + last_url);
   }
 });

No dice, something interupts the transaction...

Answer 1

Why not have a back button in the header section of your page? Something like this:

<div data-role="header">
    <a data-direction="reverse" data-role="button" href="#winelist" data-icon="back">Back</a>
    <h1>Wine Detail</h1>
</div><!-- /header -->

Answer 2

I have seen similar issues before when using jquery mobile and it is addressed in the documentation. When setting up your Javascript "at the beginning of your page" use pageinit instead of ready or maybe in your case pageshow. I think this will address your issue without having to workaround the history queue.

Answer 3

Okay so the solution was close to the update I posted. The issue with the previous solution was that there were to many things bind-ed to the "Back" button. While my new bind action may have been working sometimes, the other actions would take place too, I tried unbind() but still no worky.

My solution is a bit of smoke and mirrors. I check to see if the the previous page was the review page and then if so, I swap out the old back button for my new faux button with the history back step like so:

$('div#wine_detail').live('pageshow',function(event, ui){
  var last = $.mobile.urlHistory.stack.length - 1;
  var last_url = $.mobile.urlHistory.stack[last].url;
  var review_url = /review/g;
  if (last_url.match(review_url) )
    {
      $('a.ui-btn-left').replaceWith('<a href="" id="time_machine" class="ui-btn-left ui-btn ui-btn-icon-left ui-btn-corner-all ui-shadow ui-btn-up-a" data-icon="arrow-l"><span class="ui-btn-inner ui-btn-corner-all"><span class="ui-btn-text">Back</span><span class="ui-icon ui-icon-arrow-l ui-icon-shadow"></span></span></a>');

      $('#time_machine').bind( 'click', function( ) {  
        console.log("click should be bound and going back in time...")
        window.history.go(-3);
        });
    }
  else
    {
      console.log('err nope its: ' + last_url);
    }

It looks exactly the same, and no one is the wiser. it could probably be improved by using the the jQm method pagebeforeshow so user could never see the swap. Hope this helps someone.

Answer 4

I'd prefer not to splice/pop/push with the urlHistory. How about redirect on pagebeforechange like so:

$(document).on("pagebeforechange", function (e, data) {

    var overrideToPage;

    // some for-loop to go through the urlHistory TOP>DOWN
    for (var i = $.mobile.urlHistory.activeIndex - 1; i >= 0; i--) {
        // this checks if # = your target id. You probably need to adapt this;
        if ($.mobile.urlHistory.stack[i].url = $('#yourPageId').attr('id')) {
            // save and break
            overrideToPage = $.mobile.urlHistory.stack[i].url;
            break;
        }
        // set new Page
        data.toPage = overrideToPage;
    }
});

This captures your back button changePage call and redirects to the page you want. You could also just set data.toPage = winelist directly of course.

I'm only doing this with #internal pages, but it shoudn't be so hard to set this up with winelist.html etc.

For more info, check the event page in the JQM docs

Answer 5

If you have the situation that you want the close button refer to an arbitrary (not the last) page, you could also change first to the target page and open the dialog afterwards. Therefore the close button at the dialog will open the target page.

// First: change to the target page
$.mobile.changePage('#target_page');

Afterwards open the dialog like this.

// Second: change to the dialog 
window.setTimeout(
   // for some reason you have to wrap it in a timeout  
   function(){
      $.mobile.changePage('#dialog');
   },
   1
);

Now you can open the dialog and the close button will open #target_page.

Advantages:

• solution works for single dialogs rather than removing all close buttons from all dialogs
• seamless integration on a single point of code
• history manipulation is not needed

Answer 6

I wrestled with this recently as well. After thinking about it, I realized I could rewrite my JQM application to use Pop Up "windows" for those pages that I didn't want in my history. This ended up being an easier and cleaner fix than mucking around with browser history.

Now users can intuitively use the browser back button, and I don't have to code application back buttons.

The only thing you have to ensure is that the popups don't themselves make it into the browser history, so make sure to set the "history" option to false like so:

$('#some_popup').popup( { history: false } );