Making back button work and changing $.mobile.urlHistory?

[John5269257]

Hi

My app changes pages by setting a localStorage variable as a key then calling Appery.navigateTo(). The Pageshow event calls a service with the key and the page is populated. This is how one of your earlier basic tutorials worked.

When I have to call the same page with different data, I still set the localStorage variable as a key, but use Appery(pagename).trigger("pageshow") to refresh the content.

This works very well, but 'back' behavior is a problem - only transitions between page types is captured. The setting and reading of localStorage, not surprisingly, seems to be invisible.

I could build my own back/forward navigation, but I'd prefer to make the standard back button work properly, and I'd like some guidance as to the best approach:

One approach would be to pass a query string to the new page, rather than a localStorage variable, so all urls are different. This, I hope, would force each change into history.
(I'm not using a multi-page template)

Question: Can I pass a query string with Appery.navigateTo() ?
Question: Could this work with .trigger("pageshow")?

Another approach could be to alter $.mobile.urlHistory, and change the current url to one with a query string.
Question: is it possible to change the current entry in this manner?

The other alternative is to maintain my own history array - to build back/forward handling in the app itself, but I'd prefer to make the built-in functions work.

I'm sorry for the long question, but I would imaging Appery folk will have come across this issue before (although i can't see anything relevant in the forum).

Thanks for your help
John

PS - Love the new syntax checker

[Kateryna Grynko]

Hi John,

We'll look for a solution.

[Maryna Brodina]

Hello! Sorry for a late reply. You described almost all possible ways, but I'll add some more information.
1) One approach - Appery.navigateTo() is just wrapper with additional logic for method described here http://api.jquerymobile.com/1.3/jQuer..., so it's not possible to send additional data through method.
2) Another approach - it's possible with jQueryMobile methods changePage and navigate, but in this case you take full controll over the page. The method of switching pages in jQM has its own features - if the browser supports modern HistoryAPI, then jQM while navigation between app pages (which are in fact separate html-documents) loads these pages with AJAX and link them to the current document. Thus, your application always works within one page, so instead localStorage you can store data (current session which doesn't require long storage) in global JS-variables and also pass them between pages. But since there is no guarantee there is HistoryAPI, that kind of storage might be dangerous because in this case, the transition between the pages will be done with a complete reloading of the entire document and JS-environment .

You can forbid Back button in browser. To do that add one parameter where you invoke navigation manually preAppery.navigateTo('Screen', {changeHash: false});/preFor Back button on device you can handle Backbutton event.

We would recommend to store in localStorage structure which describes current app condition. It might include:

• current page
• some additional data
  So your application at any time has to know what is happening, what operations are not completed, to know what to do next. This makes your app logic more complicated, but other ways seems to be worse.

[John5269257]

Thanks Maryna - As you suggest, I'll try the least-worst option of maintaining my own history.
John

[John5269257]

Hi - Some progress in building 'back' handling. A question please:
I'm using:
$(window).on("navigate", function(event, data){
var direction = data.state.direction;
});

to capture back events, but the browser back button, which usually returns 'back', sometimes returns undefined.
I can't find a way around it. Are any other approaches possible?

I'm disappointed that I have to do a lot of work to rebuild basic browser functionality, and I'm surprised other people haven't had the same problem. It makes me think I'm doing something fundamentally wrong. What's best practice?

As ever, thanks for your help.
John

[Kateryna Grynko]

Hi John,

We'll look for another solution.

[John5269257]

Thanks Katya

If I can add more considerations:
I've been experimenting with using a multi-page template. Could this be a route to more effective back button behavior?
I also need to add the ability of bookmarking pages.

It's ok If this means I have to use a different inter-page navigation mechanism.

So basically I'll consider any approach that leads to sensible back/forward navigation and bookmarking. Any pointers would be gratefully received.

Thanks
John

[Maryna Brodina]

Hello! I'm sorry, but custom app logic is outside the scope of our support. This link should help http://msdn.microsoft.com/en-us/libra...