ionic-framework: $state.go('mylocation', {}, {location:'replace'}); ignored by back button.

@jorgecasar Super hacky but it’s definitely the path of least resistance. Thanks for the tip. The new syntax after beta.14 is:

$ionicHistory.currentView($ionicHistory.backView());
$state.go('bla', ..., {location: 'replace'});

Hi again, after some interesting reading of the ionic code, specifically the $ionicViewService I found this solution, replace the currentView with the backView, that it’s exactly location replace does:

$rootScope.$viewHistory.currentView = $rootScope.$viewHistory.backView;
$state.go('bla');

Enjoy!

Mine solution:

$ionicViewService.nextViewOptions({
    disableBack: true
});

$state.go('app.playlists');

I have tried every trick under the sun to prevent a view from being cached (including most of the suggestions above), but it still is being cached. Really annoying and kind of a showstopper for developing a proper flowing app. When one has to do all kinds of workarounds to get something like this working, the option of just developing the app in native becomes more and more viable. I know the platform is open source and developed by a bunch of very clever developers (for which I am very grateful), but this problem in the platform really needs to be addressed.

Starting my second project a year later and I can’t believe something as fundamental as keeping synced states between the native history API and the Ionic history provider aren’t solid yet.

Am I doing something wrong?

A use case:

Let’s say I have a state that is presented to a “first time user” by checking for a localStorage variable. This page happens to be a form for user settings. Once a user submit this form, he is redirected to the main “home” screen.

Clicking “back” would not make any sense because the user would be going back to this form he just filled out. I would expect the function that handles submit to contain something like:

$state.go('home',{},{location:'replace'});

However going back to this form in the future should also be possible so adding a blanket statement to say you can never go back would not be good either.

Having the ability to tailor the history through the $state provider is really what were looking for here.