I like that.
So far I was writing my own history controller to make sure I get the history I want, wiht the option to jump back to certain places.
But never used the history states.
Man - this really rocks and is so simple.
Porbalbly an override would do for the launch method.
About Android. Usually I add a event listener to Ext.Viewport.down('button[ui=back]') and do: setHidden(true).
As Android usually should be only used with the hardware back-button.
My way to do this is to listen to the hashchange event and pop the active item from the sencha history. At the same time I keep the sencha history to a minimum, so that sencha does not get confused, with what to do. So basically I keep it like a hashmap.
Why pollute your application with a bunch of routing logic if it's not needed? This is the most elegant solution I've found and it works beautifully across many devices.
Also, my blot post talks about using with NavigationView...I wouldn't want to do this at the Viewport level because I want back button to be different depending the NV tab I'm on. Does that make sense?
Thanks for sharing, this is an awesome and elegant idea!
I'm working on a ST app, that exists since ST1 and isn't still 100% MVC; that's why I had my own simple history for my back button. It's just an array of view IDs. But I never thougt about this history solution. It was really easy to implement on top of my back button logic and brings a big improvement for my Android customers.