Question

I have a PhoneGap App using jQuery Mobile.
At a certain page, I cannot let the user go back to the last page he visited.

The pages order is like this:

(1)index -> (2)listing items -> (3)form submited -> (4)sucess page

What I need: I want to clear all history when the user is at page 4 and set page 1 as it were the last and only visited in case of the user tries to go back. Maybe that’s not totally possible, then I would accept any suggestion.

I imagine jQuery Mobile stores navigation history in some kind of array, and I hope someone can help find that. Thanks in advance!

EDIT:
I’m using multi-page template, which is a single html page, where certain divs works as pages managed by jQuery Mobile.

Answer 1

Basically you have two history “pots” you need to tamper with. Browser and JQM.

JQM urlHistory
You can modify JQMs urlHistory very easily. From the JQM code:

urlHistory = {
    // Array of pages that are visited during a single page load.
    // Each has a url and optional transition, title, and pageUrl
    // (which represents the file path, in cases where URL is obscured, such as dialogs)
    stack: [],
    // maintain an index number for the active page in the stack
    activeIndex: 0,
    // get active
    getActive: function () {
        return urlHistory.stack[urlHistory.activeIndex];
    },
    getPrev: function () {
        return urlHistory.stack[urlHistory.activeIndex - 1];
    },
    getNext: function () {
        return urlHistory.stack[urlHistory.activeIndex + 1];
    },
    // addNew is used whenever a new page is added
    addNew: function (url, transition, title, pageUrl, role) {
        // if there's forward history, wipe it
        if (urlHistory.getNext()) {
            urlHistory.clearForward();
        }
        urlHistory.stack.push({
            url: url,
            transition: transition,
            title: title,
            pageUrl: pageUrl,
            role: role
        });
        urlHistory.activeIndex = urlHistory.stack.length - 1;
    },
    //wipe urls ahead of active index
    clearForward: function () {
        urlHistory.stack = urlHistory.stack.slice(0, urlHistory.activeIndex + 1);
    }
};

So all of the above functions are available and can be called like this for example:

$.mobile.urlHistory.clearForward();

To monitor your history, put this somewhere and listen for pageChange (once transitions are done) to see what is inside the urlHistory:

$(document).on('pagechange', 'div:jqmData(role="page")', function(){
    console.log($.mobile.urlHistory.stack);
});

From there you can start to see what should be in the history and clean it up as you need.

I’m using this a lot for my own navigation layer to modify what is stored in the urlHistory and what should not be stored. Sync-ing with the browser is the difficult part…

On sync-ing with the browser:
In my navigation layer I’m only removing double entries from the urlHistory, so there is always a page to go to (and not two), when you click the browser back button. In your case, you will presumable have 4 entries in the browser history, but if you remove 2 entries from JQM urlHistory, you will have two pages “not to got to” when the back button is clicked. So if your browser history looks like this:

www.google.com
www.somePage.com
www.YOUR_APP.com = page1
    page2
    page3
    page4

And your remove page2 and page3, clicking back-button should result in:

1st back-click = page4 > page1
2nd back-click = page1 > www.somePage.com [because you removed page3]
3rd back-click = www.somePage.com > www.google.com [because you removed page2]

A theoretical workaround would be:

1. keep a counter how “deep” you go into a page
2. remove pages from JQM urlHistory and get a “jump” value = counter-removedPages
3. on next browser back click, do jump x window.history(back) and only let one JQM transition pass. You url will unwind page4>page3>page2>page1 in one step and you only allow JQM to do a single transition from page4 to page1
4. check what’s in the urlHistory and clean up after your “triple back”

Beware this is not an optimal solution and you have to consider a lot of things (user clicks somewhere else before going back etc). I tried forever to get something like this to work in a more complicated setup and eventually just stopped using it, because it never worked as it should. But for a simpler setup it may very well work.