Thursday, December 22, 2011

HTML5 history support in mobile browsers

For those of you who don`t know theres a new HTML5 API out there for handling the browsers history. (eg. what happens when the user presses back, or reloads the page)

It provides the following functions:

  • change the current history entry (replaceState)
  • add a new history entry onto the stack (pushState)
  • receive an event if the stack has changed(user pressing forward or back)
  • Get the size of the history stack
  • go forward and backwards in history
Together this set of apis provides a nice way to handle the android back button inside a web application. You can actually mimic the behavior of a native app with the back button, as long as android supports the html5 history api.

I was very pleased to see support for this in android 2.2 and android 2.3, but was kind of worried to see that this was not working properly in android 3.x. But I wasn't too worried, because android 3.x was rushed to get out the door and never really had that much devices ( see: http://developer.android.com/resources/dashboard/platform-versions.html)

When I installed android 4.0 last week on my phone I was very surprised to see that mgwt used a fallback mechanism (introduced for the few android 3.x devices) to get the back button working. So I did some digging and was able to find out that that android 4.0 does not support html5 history api.


Why is HTML5 history support important?
If you want to use the back button properly with your android web app, you need to get an event when the user presses that back button. If the browser does not support the html5 history api you can still get an event by using a hashtag mechanism in the url (like GWT has done for quite a long time), but you will not be able to change the current entry on the history stack. So you will get inconsistencies when trying to mimic the behavior of the android activity stack.
The second thing is performance: It seems that the history pop event fires immediately, while the hashtag mechanism needs on my phone at least one second before the gwt app sees the action. This leeds to a serious sluggish feeling when using the back button. I haven't had the time to look into this maybe there is something that can be done about it.

But:
There is a discussion in the gwt contributer group ( https://mail.google.com/mail/#label/gwt-contrib/1345fe21e2ad68ed) that discusses if we can implement a history replace mechanism on top of the hash tag mechanism so there might be a way to get some decent behavior in web apps inside android 4. 

This leaves me wondering what google is doing with android and why it is so hard for them to have a matching browser to apples mobile safari. This is working properly on android 2.2 and 2.3, why is it not working in android 4?

Also there wasn't any issue on the android tracker regarding this. I will be doing some more research and post a bug report eventually, so that we can get this fixed some time in the future... 
Someone else already file a bug (see http://code.google.com/p/android/issues/detail?id=23979)

Also I will try to find a way to get the best possible current solution for mgwt web apps (note: with gwt-phonegap you can get a direct event if the user presses the back button).


1 comment: