Kamishiba URLs look like
We are using hash-bangs which are hated by some. I’ll like to outline why we use them despite their unpopularity.
- The most important reason is because we want to allow offline viewing. We thought over many alternative ways to do this, but our conclusion was that we needed a boot loader that we could keep in Application Cache. In the above URL,
http://mbsj2012.castle104.com/jais the bootloader.
/ja/presentations/3366is where the content resides.
- The stock Android browser for version 4.0 and above do not support popState. Neither does IE9 and below.
Obviously, the first reason is the most important for conference systems because the network connection is generally very unreliable. The only solution to do offline apps without a hash-bang scheme is outlined in Jake Archibald in A List Apart, and it’s a good solution. However, as Jake himself admits
The experience on a temperamental connection isn’t great. The problem with FALLBACK is that the original connection needs to fail before any falling-back can happen, which could take a while if the connection comes and goes. In this case, Gotcha #1 (files always come from the ApplicationCache) is pretty useful.
Unfortunately, a temperamental connection is exactly what you get at conferences. We need a solution that allows us to programmatically define when to
FALLBACK using either a timeout or the results of previous requests.
Below our some of our thoughts about the hash-bang and how we are providing solutions to its ill effects.
- We think that the hash-bang is necessary to provide a better experience to users. Offline viewing is the most important but there are other smaller things.
- Although a hash-bang webpage requires two HTTP requests for the HTML, the first request is for the boot loader and will be stored in Application Cache. Hence the first request is local if the user has visited this website before. As a results, only one HTTP request goes over the network.
- Although many people state that the hash-bang is temporary and that widespread popState support will make it unnecessary, I disagree. Hash-bang is the only way I know of that will support offline websites.
- GMail still uses hash-bangs for most of their stuff. Obviously, GMail doesn’t want bots crawling their website.
Interchangeability of regular URLs and hash-bang URLs
From regular URL to Kamishibai URL
This will be done within Rails and will be simple rerouting on the server. 302 redirects generally honor the hash fragment, so everything should be OK.
- Rails will receive the regular URL.
- If the browser that requested it is supported in Kamishibai, then redirect to the corresponding Kamishibai URL via 302. If the browser is not supported, then it gets a regular HTML response. (this may be implemented with a Rails
before filterbecause not all actions can be converted easily).
From Kamishibai URL to regular URL
- Rails will receive the Kamishibai URL.
_escaped_fragment_ scheme. We should redirect any of these requests to the regular URL version (using 301 redirects).