HTML5+CSS3 |
Webアプリケーション編
|
Lesson 02 | HTML5を使った Webアプリケーション事例紹介 |
|||
制作・文 | 外村和仁(ピクセルグリッド) |
ここでは、HTML5の機能を使ったWebアプリケーションを紹介する。また、HTML5を使ったデモ的なアプリケーションや、機能をサポートしていないブラウザに対しては別の手法で代替えするフォールバックという方法で対応している例もある。 |
ロケタッチ
http://tou.ch/
ロケタッチ【1】 はライブドアが運営するサービスで、位置情報APIを使った代表的なWebアプリケーションといえる。このサービスでは自分が今いる場所を登録し、写真やコメントを共有することができる。このサービスではネイティブアプリや、いわゆる「ガラケー」と呼ばれる携帯電話(ガラパゴス・ケータイ)に対応しているが、スマートフォンのWebアプリケーションではHTML5 の位置情報APIが利用されている。位置情報APIは【2】のように利用する。これをiPhone で実行すると【3】のような表示になる。
このように、navigator.geolocation.getCurrentPositionを使うことで、簡単に現在の位置情報を取得できることがわかる。
位置情報APIは現在の位置を取得するgetCurrentPosition の他に、現在地の取得を監視するwatchPositionというメソッドも提供している。watchPositionは【4】のように使用する。
getCurrentPositionは一度だけしか位置情報を取得しないが、watchPositionは周期的に位置情報を取得できる。これにより位置情報を監視し、移動した位置を記録するアプリケーションの作成などに役立てることができる。また、watchPosition に対してclearWatchというメソッドを使用すると、位置情報の監視をストップできる。これはwatchPositionが返す一意なIDを引数として渡す。具体的には【5】のようなコードになる。
位置情報API はスマートフォンなどのモバイル端末でのWeb アプリケーションととても相性がいいといえる。
【1】ロケタッチ(http://tou.ch/)
【2】
【3】iPhoneで実行例。位置情報を取得できる
【4】
【5】
github
http://github.com/
githubはソースコードを共有するサービスだ。github ではページの切り替えにhistory.pushState という技術を使っている。これは履歴管理のための新しい仕様である。【6】のページをhistory.pushStateに対応しているブラウザ(執筆時点ではGoogle Chrome 10、Safari5、Firefox 4、iOS 4.3)で見ると、ソースコードのファイルやディレクトリ部分をクリックした際に、リロードなしでページが切り替わり、さらにURLも変化するのがわかる。また対応していないブラウザでは通常通りのページ遷移が発生し、サイトの閲覧には特に問題ないような配慮がされている。なぜこのような仕様が必要なのか、順を追って説明していく。通常の、リンクを押すたびにリロードしてページ遷移する方法は、すべてのコンテンツを毎回サーバにリクエストし、毎回画面の書き換えが発生する。それに対して、必要な情報だけをAjaxなどで取得しJavaScriptで画面を書き変えるという方法だと、サーバへのリクエストを減らし画面の書き変えも最小限で済むので速度が向上し、より快適な体験を提供できる。
単にJavaScript でコンテンツを書き変えるのはあまり難しいことではない。jQueryを使って書くと【7】のようになる。簡単なアプリケーションであればこれでも問題ない。問題になってくるのはブラウザの戻るボタンを考えなければいけないときだ。【7】の例では、単にクリックされたときにコンテンツを切り替えているだけなので、ブラウザの戻るボタンや進むボタンを押してもボタンを押す前の状態に切り替わることはない。そのために考えられたのが「hashchange」を使う手法である。
現在、その手法を採用しているWebアプリケーションでもっとも有名なサイトはTwitter のサイトだろう。Twitter の公式サイトを使ってみるとわかるが、Twitter のサイト内のリンクであればリロードは発生せずにコンテンツだけが切り替わる。その際、URLは#(ハッシュ)以降の文字列だけが切り替わっている。これはハッシュの値が変わってもページの再読込みが発生しないというブラウザの特性を利用した手法だ。また、hashchangeというイベントを使い、ハッシュの変更を監視することでブラウザの戻るボタンや進むボタンに対応している。この手法を使うと先ほどのコードは【8】のように書くことができる。
ボタンがクリックされたときはハッシュの値を書き変え、画面の変更はhashchangeのイベントハンドラに記述する。hashchange のイベントハンドラは、戻るボタンや進むボタンを押したときにも実行されるので戻るボタンや進むボタンにも対応できる。ここでは単純にハッシュの値をコンテンツに入れているだけだが、ハッシュの値を元にAjaxでコンテンツを取得してコンテンツを書き変えるというのが一般的だろう。
また、hashchangeイベントはInternetExplorer 7 以下などの古いブラウザでは対応していないので、それらのブラウザでも対応したいときは「jQueryhashchange event」というjQuery のプラグインなどを利用するといいだろう(http://benalman.com/projects/jquery-hashchange-plugin/)。
これで問題は解決したかに思えるが、hashchange の手法でも解決できない問題がある。それはハッシュの値はサーバに送信されないという点だ。これは検索エンジンからアクセスされたときに、サーバが適切なコンテンツを検索エンジンに返すことができないという問題につながる。Google はこれを解決するために、「#!」で始まるハッシュの値をクエリストリングに置き換えてアクセスすることにより正しいコンテンツを取得するという仕様を発表している(http://code.google.com/intl/ja/web/ajaxcrawling/docs/getting-started.html)。
具体的には「#!key=value」というハッシュは「?_escaped_fragment_=key=value」というクエリストリングに置き換えられる。クエリストリングはサーバに送信されるため、サーバ側でクエリストリングを見て適切なコンテンツを返すような仕組みが実装されていれば、検索エンジンに正しいコンテンツを伝えることが可能になる。たとえば次のようにTwitterのURLは置き換えられる。
・普段ユーザーが目にするURL
http://twitter.com/#!/hokaccha
・検索エンジンがアクセスするURL
http://twitter.com/?_escaped_fragment_=/hokaccha
【6】github(http://github.com/)
【7】
【8】
このように、ハッシュを用いた画面遷移はサーバ側にハッシュの情報が送信されないという問題点がある。元々ハッシュはこのような利用を想定されていていないので問題点がでてくることは当然かも知れない。上記のGoogle の対応の例はやむを得ない対応といえるので、今後このような形式を積極的に使っていくことはおすすめできない。
そこで登場したのが「history.pushState」、「history.replaceState」という新しい仕様だ。これらを使えば、URLを変更してもページのリロードが発生せず、ブラウザの戻るボタンや進むボタンを押したときの履歴にも残るという理想的な動作を実装できる。
hisotry.pushState は履歴を追加してURL を変更するもの、hisotry.replaceStateは現在の履歴を書き変えるものだ。どちらも使い方は同じで、第一引数にイベントオブジェクトに渡すデータ、第二引数にはタイトル、第三引数に変更するURLを指定する【9】。
戻るボタンや進むボタンを押されたときにはpopstate というイベントが発生し、そのイベントオブジェクトのstateプロパティにpushStateなどで登録したデータが格納されている【10】。
先ほどのコードをhistory.pushStateを使うと【11】のようになる。
hashchangeのときよりやや処理が長くなっているのは、pushStateを呼んだときにはpopstate イベントが発生しないからだ。そのためボタンをクリックしたときにもコンテンツの書き変えの処理を実行する必要がある。今回の例ではhistory.replaceStateは使っていないが、これは履歴を追加するのではなく、現在の履歴を変更する場合に使われる。
このように、新しい履歴管理の機能を使えばこれまで実現できなかったスムーズできれいなページ遷移が実装できるようになるだろう。
【9】
【10】
【11】
JWT
http://jwt.co.jp/
JWT(http://jwt.co.jp/)というサイトはアプリケーションというよりは通常のWebサイトに近いが動画の再生にvideo要素を使用している。【12】 はiPadで動画を再生している様子だが、PC で見るのと同じように再生できている様子がわかる。この動画のコンテンツは、video 要素に対応しているブラウザではvideo 要素を使って動画を再生するが、video 要素に対応していない古いブラウザではFlash を使って動画を再生するというフォールバックを行っている。これにより、video 要素に対応してないInternetExplorer やFlashに対応していないiOSのブラウザでも同じように動画を再生することが可能になる。このような動画再生においてフォールバックを行うことができるライブラリはすでにいくつか公開されているものがある。その中の一つである、「jme」というプレイヤーについて説明しよう(http://www.protofunc.com/jme/index.html)。
jmeはjQueryのプラグインとして提供されており、jmeサイトのトップからzipをダウンロードすると、Flashで再生する場合のプレイヤーなども同梱されている。最も簡単な使い方は【13】 のようになるだろう。
jmeEmbed()というメソッドを呼ぶことで、自動的にvideo 要素で再生できないプレイヤーはFlashに置き換えてくれる。PCとスマートフォンのソースを分けることなく、一つのソースでマルチデバイスに対応したいときにはとても有用だろう。また、jme はvideo だけでなくaudio 要素にも対応している。このように動画、音声の再生を簡単にフォールバックすることができる手法はクロスブラウザ、クロスデバイスの対応において重要なものであるといえる。
【12】iPadでの動画再生
【13】
>>目次に戻る