コンピュータクワガタ

かっぱのかっぱによるコンピュータ関連のサイトです

Android Bazaar and Conference 2011 Winterのメモと感想（3）

Android

Android Bazaar and Conference 2011 Winter

http://www.android-group.jp/abc2011w/

の感想の3回目です。今回は、

HTML5によるリッチクライアント開発手法についてあれこれ
白石俊平さん（html5-developers-jp管理人）

のメモと感想となります。
次回はないかもしれませんｗ

ustのアーカイブに残っているため以下をご覧いただければ、実際の講演内容を見ることができます。

HTML5によるリッチクライアント開発手法についてあれこれ

発表者の方は、HTML5開発者コミュニティ、html5-developershttps-jpの管理人だそうです。
https://groups.google.com/group/html5-developers-jp?hl=ja

また、以下の本の著者だそうです。

HTML5&API入門

HTML5&API入門


持っていない本かつ、古い本でもないので今度買いますｗｗ

本日のアジェンダ
  • Web開発/HTML5の基礎知識
    • Web開発の基礎知識
    • HTML5の基礎知識
  • HTML5によるRIA開発
    • 僕に語りうること
    • JavaScriptによるRIA開発
    • 既存のWeb開発パラダイムからの脱却
    • オフラインWebアプリ

ということで始まりました。

Web開発の基礎知識

WebアプリはHTMLとCSSとJavaScriptできている。
それぞれ以下の役割を持っている。

HTML
文書内容と構造
CSS
見栄え
JavaScript
振る舞い

昔は、HTMLで見栄えも行っていたり、またJavaScriptが悪とされていた時代があったということでした。たしかに、昔はJavaScriptは危険なものであまり使わないほうがいい、またサイトでもできるだけ使用するなと書いてある本もあったりもしました。しかし、Ajaxの登場で大きく局面が変わり、今ではJavaScriptなしのWebサイトはありえないという時代になっています。

Web開発の基礎知識
  • Web関連技術は、様々なオープン標準によってさせられている。
  • HTML5は、HTMLとDOMに関する最新のアップデートバージョン
HTML5って、なんだろう？
  • HTML（Hyper Text Markup Language）の最新バージョン
  • W3C（World Wide Web Consotium）で標準化作業中
    • 2011/5/22に仕様が確定する（Last Call）予定
  • Webブラウザによる実装も着々と進行中

補足説明として、『いまのところ、HTML5の仕様確定の時期は守られそう。ただし、確定するだけで完成ではない。その後、ブラウザベンダに実装を進めてもらい問題がないか確認してもらう。その間にテストケースを作成し、そのテストケースを満たす実装が2つ以上出てきた時に仕様が完成、勧告となる。』とのことでした。
また、When can I use...（http://caniuse.com/）というサイトでブラウザの実装状況を確認できるということでした。
サイトを見ると、ChromeやSafari、Firefoxの次のバージョンではHTML5の実装がだいぶ進んでいることがわかります。OperaとIEが若干遅れているかなという感じです。

どこまでがHTML5か？
  • HTML5と呼ばれている技術は、実際には様々なプログラミング環境を総称した物。
  • HTML5と一般的に呼ばれる範囲
  • 以下を含めてざっくりとHTML5と呼んでしまうことも

HTML5を厳密に言うと、以下の仕様書の部分のみということでした。
http://www.w3.org/TR/html5/

HTML5 & APIが可能にすること
  • HTML5とそのAPIは、Webアプリをこう変える
    • より美しく、インタラクティブに
      • canvas・・・2D、3DのビットマップグラフィックAPI
      • SVG・・・ベクターグラフィックAPI
      • video/audio・・・動画・音声
    • 操作性とリアルタイム性をより高く
      • Web Workers・・・バックグラウンド処理を可能に
      • WebSocket・・・リアルタイム性の高い、新たな通信形式
      • Server-Sent Events・・・HTTPベースのサーバプッシュ
    • オフラインでも利用可能に
      • アプリケーションキャッシュ・・・オフライン利用可能なキャッシュ
      • Web Storage・・・簡単に利用出来るストレージAPI
      • Indexed Database API・・・ブラウザ組み込みのKVS
      • File API・・・ファイルの読み書き
    • Webサービス間の連携がされに容易に
      • Cross Document Messaging・・・Webページ間のメッセージ通信
      • Cross Origin Resource Shareing・・・オリジンを超えたHTTP呼び出し
    • プラットフォームとのより深い統合
      • Drag & Drop API・・・ドラッグ & ドロップ処理
      • Geolocations API・・・位置情報取得
      • Device APIs・・・モバイルデバイス向けAPI群。カメラやセンサー、コンタクトリストへのアクセスなど

File APIや、Drag & Drop APIは先日このブログで書いたエントリーHTML5でローカルファイルのドラッグアンドドロップで画像ファイルを表示でやっていますので、興味があったらご覧ください。
Android向けというか、モバイルのプラットフォーム向けに、カメラやセンサーなどが使用できるためかなりネイティブアプリに近い事ができるようになってきたということです。

デモのサイトは以下。付箋のデモはどこかわかりませんでした。
http://www.html5rocks.com/
http://www.craftymind.com/factory/html5video/CanvasVideo.html

気になったのは、モバイルデバイス向けAPI群。カメラやセンサーを制御できるらしいということで仕様を探してみましたところ、ありました。
http://www.w3.org/TR/dap-api-reqs/
まだ使えなさそうな感じです。

ここから、HTML5によるRIA開発の本題に入りました。

ぼくに語りうること

仕様自体が非常に幅広い内容のため、発表者の方もすべてを把握していないという前提で、ということです。

JavaScriptによるRIA開発
  • 動的「すぎる」言語
    • 人によってコーディングスタイルがバラバラ
    • →複数人での開発に支障が出る
    • トップダウンでの迅速なコーディングには向いている
  • 非同期処理中心のプログラミング
  • 言語自体のモジュール性が低い
    • 基本的には、ファイル分割と<script>タグによるロード
    • モジュール性を補完するライブラリはいくつか存在する
      • Dojo Toolkit
      • Google Closure Library
      • RequireJS

自分の経験からも同様のことが言え、この動的「すぎる」言語というところが非常に共感を得られます。
また、モジュール性が低いのも非常に問題で、おそらくそのせいもありJavaScriptの開発環境が整ってこないんだと思います。それでも最近は以前よりはるかに整ってきているようですが、使ったことがないので知りません。

アプリケーションアーキテクチャの現状

クライアントサーバ
↓
Web MVC
↓
↓←←←←イマココ アーキテクチャ移行中
↓
Rich Internet Application
↓
Offline Web Application

まさに、イマココです。個人的には、ブラウザを固定できるのであればこのブラウザで！ということでやってしまうのもいいのかなと感じています。
IEでないと見られないというようなサイトも今は殆ど無いと思いますので。

リッチクライアント以前のアーキテクチャ - Web MVC型
  • サーバサイドで、テンプレートエンジンによりHTMLソースを動的に生成。RDBをデータソースとして利用
  • ほとんどの処理はサーバで行う（シン・クライアント）

リッチクライアントの世界になったところで、この部分がなくなることはないですので、重要性は変わりません。

リッチクライアントのアーキテクチャ
  • クライアントでできることはクライアントに、サーバにしかできないことはサーバに
  • サーバとクライアントは、インターネットを介して必要なデータとリソースをやりくり

どこまでをクライアントで、どこまでをサーバでという切り分けが一番重要かなと思います。適材適所。

まとめ
  • Web 1.0・・・テンプレートエンジンによるHTML生成
    • HTML内にUIとデータが混在
  • HTML5・・・UIとデータを分離
    • Web APIを通じたデータの読み書き

基本はこの手法だが、次なる課題は

  • HTTPリクエストが増えすぎる
    • キャッシュ、キャッシュ、キャッシュ
  • 検索エンジンとの相性が悪い
    • URL Fragmentの活用
    • （まだ調査中）

HTTPリクエストの増大は、大きい問題だと思います。Googleのサービスも基本的には最初から全部を読み込まずにAjax等で順次読み込んでいます。Googleのインフラがあってもある程度時間がかかる（待つというレベルでもないですが）ので、安易に行うとトラフィックが過多になりかねないと感じました。

キャッシュとオフライン技術
  • HTML5時代のキャッシュ技術
    • HTTPキャッシュ
      • 静的なリソースのキャッシュは容易だが・・
      • 動的なリソースのキャッシュを適切に行うのは難しい
    • アプリケーションキャッシュ
      • アプリケーションリソース（HTML/CSS/JavaScript/画像...）をまるごとキャッシュできる
      • 利用は容易だが、運用上の注意が必要になることも
    • ローカルストレージ
      • Web Storage/Web SQL Database/Indexed DBというAPIがある
      • 動的なリソースのキャッシュに向いている
      • 同期処理とは切っても切り離せないので、実は利用が難しい

キャッシュの部分は簡単な解決は難しいかなと感じました。フレームワークでということもおっしゃっていましたが、個人的にはフレームワークレベルでの解決も難しいんじゃないかと思います。

どのキャッシュ技術を、いつ用いるか
  • 静的なUIリソース（HTML、CSS、JavaScript、画像...）
    • 永続的なリソースは、アプリケーションキャッシュを利用出来る
    • 半永続的なリソースは、HTTPキャッシュを利用出来る。
  • サーバから読み取ったでデータ（動的リソース）
    • 変更頻度が非常に低いデータは、静的リソースに埋め込めばアプリケーションキャッシュを使える。
    • それ以外のデータは、HTTPキャッシュを使う
    • オフラインアプリも視野に入れるなら、ローカルストレージを使う
  • クライアント側で生成されたデータ（動的リソース）
    • これをローカルストレージにキャッシュすることで、完全なオフラインWebアプリを実現可能
    • 同期処理が難しい
      • 同期処理中にネットワークが切断されたら？
      • データ更新の衝突が発生したら？

最後の方はキャッシュを中心に話されていました。いまいちピンとこなかったのは、ごっついオフラインアプリケーションを作っていないからかなと思ってみたりしました。すこし、ローカルストレージを使ったものをつくってみようかなと思います。