2. Johannes Barop
● Mail: jb@barop.de
● Google+: http://bit.ly/jbarop
● Github: https://github.com/jbarop
● LinkedIn: https://www.linkedin.com/in/jbarop
● Freelancer
● Focus on Java and GWT
● GWT experience since 2008
● Hacking at GWT internals since end of last
year
3. Browser history
● GWT applications usually consist only of a
single page
● Applications should meet the user's
expectations compared to traditional web
pages
● URLs...
○ Identify a unique resource
○ can be linked, bookmarked and shared
4. GWT Standard History Mechanism
● GWT uses the fragment identifier (#) to
provide a history state
● Chosen because updating the fragment
doesn't causes reload
● This is a hack
5. GWT Standard History Mechanism
● Fragment identifier is optional and isn't a part
of the URI itself
● "http://example.com/app.html#page_1"
and
"http://example.com/app.html#page_2"
reference the same resource "app.html"
6. GWT Standard History Mechanism
● Many user agents do not send the fragment
to the server
● No simple server redirect possible
● Supporting crawlers not straightforward
https://groups.google.com/forum/?fromgroups#!
topic/google-web-toolkit/w2h-b8OSm2s
https://groups.google.com/forum/google-web-
toolkit/w2h-b8OSm2s?fromgroups
7. HTML5 History API
● Function: window.history.pushState
● Event: onpopstate
● Browser Support:
○ Chrome: 5
○ Firefox: 4
○ Internet Explorer: 10
○ Safari: 5.0
○ Opera: 11.50
○ Mobile: It's tricky
● Support for non-pushstate browser needed