View
16.948
Download
0
Category
Preview:
Citation preview
HTML5で作るオフラインWebアプリケーション
白石俊平@あゆた
自己紹介
html5-developers-jp（Google準公式コミュニティ）管理人
株式会社あゆた 取締役（Webアプリ開発のお仕事募集中です！）
Google社公認 API Expert（HTML5）
2007年、Gearsの書籍を執筆しました。
最近まで、Gearsでオフラインアプリ開発をひたすらやってました。
今日のお題
イントロダクション
オフラインWebアプリとは
オフラインWebアプリを実現するためのAPI
アプリケーションキャッシュ
Web DatabaseWeb StorageWeb Workers
HTML5時代のWebアプリアーキテクチャ
初お披露目！・・・の何か、のデモ
イントロダクション:HTML5は日本が熱い！
html5-developers-jp、2009/7/10 開始
グループ登録者数の推移
7月末・・・687人
8月末・・・1,051人
9月末・・・1,304人
Google Trendで見ると、日本と韓国で異様に盛り上がっている感じ。
今後のHTML5を引っ張っていくのは日本だ！
オフラインWebアプリとは
言うまでもなく、「オフラインでも動作するWebアプリケーション」のこと。
2007年、Google Gearsの発表により一躍脚光を浴びる
HTML5関連のAPIは、Gearsからの影響が顕著に表れている
Web Workersの仕様書にもGearsの文字が
オフラインWebアプリとは
しかし、Gearsを使用して作られたオフラインWebアプリはそう多くない。
Google Docs, Gmail, Google Reader, Remenber the milk...
あまり普及していないのは以下のような理由だったと考える
ニーズが顕在化していなかった・・・現在に比べ、PCからの常時接続なネット利用が大きな割合を占めていた
ブラウザプラグインと言うアプローチが普及を阻害
開発の知識を持った人材が不足していた
オフラインWebアプリとは
しかし、時代は変わる！
こうなったら、もはや普及するしかない！！(？)
ニーズが見えない
ブラウザプラグイン
知識と人材の不足
モバイルネット端末の普及
ブラウザ自身による実装
標準化により開発者人口が増加
オフラインWebアプリを実現するためのAPI
アプリケーションキャッシュ
Web Workers
Web Storage
Web Database
アプリケーションキャッシュ
オフラインWebアプリを実現するため、アプリケーションに必要なリソースをローカルにキャッシュするための仕組み。
アプリケーションキャッシュ
実現するための手順は以下の通り。
キャッシュマニフェストファイルを作成
マニフェストを「text/cache-manifest」というMIMEタイプで公開する
Webアプリのhtml要素にmanifest属性を追加し、キャッシュマニフェストのURLを指定する（例: <html manifest=”hello.manifest”>）
CACHE MANIFEST
# version: 200909241054
hello.htmlhello.js
キャッシュマニフェストとは - アプリケーションキャッシュ
キャッシュするリソースを書き連ねただけの単純なテキストファイル。
文字コードはUTF-8でなければならない
1バイトでも変更があると、キャッシュがリフレッシュされる。通常は、コメント内にバージョン文字列を含めるなどの運用を行う。
CACHE MANIFEST
# version: 200909241054
hello.htmlhello.js
アプリケーションキャッシュのデモ(1)
単にアプリケーションキャッシュの動作を確認するためのデモ。
アプリケーションキャッシュがあると、開発がめちゃくちゃやりづらい
開発時は、「アプリケーションキャッシュを用いない」もしくは「マニフェストファイルを動的に生成する」などの配慮が必要
アプリケーションキャッシュのデモ(2)
アプリケーションキャッシュの動作をJavaScriptで制御し、「自動更新」機能を実現したもの。
5秒おきに強制的に更新チェック。更新が利用可能（updateready）になったらリロードを行う。
個人的には、GearsのResourceStore相当の機能（キャッシュの動的な追加・削除）が欲しいところ。
Web Database
クライアント上で動作するリレーショナルデータベース。
SQLをフルに使える。
オフラインWEBアプリケーションを実現するための中心的なテクノロジー
クライアント
アプリケーションデータ更新
データ取得DB
サーバ
BrowserexampleA.com
DB1
Web Database
ドメイン（オリジン）ごとに領域が完全に分かれる。他のサイトが作ったDBにはアクセスできない
1つのドメインにつき、複数のDBを持つことが出来る。
DBの中には複数のテーブル／インデックス／ビューを持つことが出来る
DB1
Table1Table1Table1
exampleB.com
DB1
DB1
Table1Table1Table1
Web Database
非同期型のAPIと同期型のAPIがある。
非同期APIは常に利用可能だが、結果を全てコールバック関数で受け取らねばならないのでコーディングが面倒
同期APIはワーカ（後述）内でしか使えないが、コーディングはやりやすい
var db = openDatabase(...)db.transaction(function(tx) { tx.executeSql(“...”, [...], function onSuccess(tx, results) { ... }, function onError(tx, error) { ...}});
var db = openDatabaseSync(...)db.transaction(function(tx) { var results = tx.executeSql(“...”); ...});
Web Databaseのデモ
マイコミジャーナルで公開したものと同じです・・・(汗
SafariにDBに関する設定画面やDBビューアがついてるなんて、知ってましたか？
Web Storage
キー・バリュー型のストレージ。Web Databaseに比べて簡単に使えるのが利点！
ドメイン（オリジン）ごとに領域が異なる。
ストレージは二種類
LocalStorage・・・永続期間無制限
SessionStorage・・・ウィンドウごと・永続期間はウィンドウを閉じられるまで
Web Storageのデモ
Web Databaseと同じサンプルを、Web Storageで書き直したもの。
localStorage、sessionStorageと言ったグローバル変数を通じて簡単に値の読み書きができます。
// localStorage/sessionStorageと言ったグローバル変数を// いきなり利用可能localStorage.setItem(“key”, “value”);var val = localStorage.getItem(“key”);// 上と同じ意味のコード。プロパティとしてのアクセスが可能。localStorage.key =“value”;var val = localStorage.key;
Web Workers
バックグラウンドで動作するスレッド。
現在のJavaScriptは、全てがUI処理の一環として動作するので、長時間かかる処理を行うとブラウザが固まってしまう。
複雑化の一途をたどるJavaScriptアプリにとっては、今後必須となるテクノロジー
Web Workers
利用に際してはいくつか注意が必要。
「スレッド」とは厳密な意味で異なり、変数を共有できない。
→「window」「document」と言った変数も不可。JSフレームワークを使用している場合は注意！
ワーカ間のデータ共有にはメッセージングのAPIを用いる
UI Thread
Workercreate
postMessage
postMessage
DOM(window,
document)
manipulate
Web Workers
利用に際してはいくつか注意が必要。
「スレッド」とは厳密な意味で異なり、変数を共有できない。
→「window」「document」と言った変数も不可。JSフレームワークを使用している場合は注意！
ワーカ間のデータ共有にはメッセージングのAPIを用いる
UI Thread
Workercreate
postMessage
postMessage
DOM(window,
document)
manipulate
Web Workers
利用に際してはいくつか注意が必要。
「スレッド」とは厳密な意味で異なり、変数を共有できない。
→「window」「document」と言った変数も不可。JSフレームワークを使用している場合は注意！
ワーカ間のデータ共有にはメッセージングのAPIを用いる
UI Thread
Workercreate
postMessage
postMessage
DOM(window,
document)
manipulate
×
Web Workers
ワーカの生成: new Worker(scriptUrl)
ワーカへのメッセージの送信: worker.postMessage(message);
ワーカからのメッセージ受信: worker.onmessage(event);
ワーカでは、postMessageとonmessageをグローバル関数として扱い、生成元と通信が可能。
worker.onmessage = function(msg) { ...}function a { worker.postMessage(...)}
onmessage = function(msg) { ... postMessage(...)}
ui.js worker.js
Web Workersのデモ
またもマイコミのサンプルから・・・(汗
どんな巨大な数を入力してもブラウザが固まりません。
Web Workers開発の問題点
Web Workersを使ったアプリ開発のツラい点
Workerの処理はデバッガで追うことが出来ない
メッセージングのコードはすぐ複雑になる
複数のメッセージをやり取りすると、長大なswitch-caseなどになりがち
Web Workers開発の問題点
Web Workersを使ったアプリ開発のツラい点
Workerの処理はデバッガで追うことが出来ない
メッセージングのコードはすぐ複雑になる
複数のメッセージをやり取りすると、長大なswitch-caseなどになりがち
拙作のライブラリを試してみてください(^^)
Web Workers開発の問題点
Web Workersを使ったアプリ開発のツラい点
Workerの処理はデバッガで追うことが出来ない
メッセージングのコードはすぐ複雑になる
複数のメッセージをやり取りすると、長大なswitch-caseなどになりがち
→ fakeworker.js・・・eval()とsetTimeout()によるWeb Workersの実装
拙作のライブラリを試してみてください(^^)
Web Workers開発の問題点
Web Workersを使ったアプリ開発のツラい点
Workerの処理はデバッガで追うことが出来ない
メッセージングのコードはすぐ複雑になる
複数のメッセージをやり取りすると、長大なswitch-caseなどになりがち
→ fakeworker.js・・・eval()とsetTimeout()によるWeb Workersの実装
→ AlexService・・・Web Workersのオブジェクト指向化ライブラリ
拙作のライブラリを試してみてください(^^)
HTML5時代のWebアプリアーキテクチャ
ここからは、HTML5(Open Web Platform)時代のアーキテクチャについてお話しします。
自身の開発経験に基づく、私見もかなり入ってます。
HTML5時代のWebアプリアーキテクチャ
• 理想的なオフラインWebアプリを実現するためには、Webアプリのアーキテクチャを大幅に変更する必要がある。
• なぜか？• →オフラインで動作する必要がある• →クライアント内で処理が完結している必要がある。• →処理結果の永続化も含め、ほとんどのロジックをクライアント上で実現する必要がある。
従来のWebアプリ・アーキテクチャ
• サーバと直接データを送受信
• ロジックの大半はサーバに存在
クライアント
DB
アプリケーション
アプリケーション
データ更新 データ取得
サーバ
HTML5時代のWebアプリアーキテクチャ
• ローカルDBとデータを読み書き
• 任意のタイミングで、ローカルDBとの差分をダウンロード／アップロード
• ロジックの大半はローカルに存在。処理が重くなるのでWorkerを使用
クライアント
DB
アプリケーションデータ更新
データ取得
サーバ
DB
Download/Upload
アプリケーション
HTML5時代のWebアプリアーキテクチャ
• ローカルDBとデータを読み書き
• 任意のタイミングで、ローカルDBとの差分をダウンロード／アップロード
• ロジックの大半はローカルに存在。処理が重くなるのでWorkerを使用
クライアント
DB
アプリケーションデータ更新
データ取得
サーバ
DB
Download/Upload
アプリケーション
以降、Open Web Architecture(仮)と呼びます
Open Web Architectureのメリット
• ローカル内で処理が完結するため、オフラインでもほぼ完全に動作する
• → ネットワークが不安定でもアプリの動作に問題が生じない
• ローカル内で処理が完結するため、高速でリソース消費量も少ない
• → 良好なユーザビリティ
• ユーザ、もしくはプログラムにより、差分アップロード・ダウンロードのタイミングを制御可能
• → ネットワークの状態や電池残量に応じてDL/ULを行う／行わないなど
Open Web Architectureのメリット
• ローカル内で処理が完結するため、オフラインでもほぼ完全に動作する
• → ネットワークが不安定でもアプリの動作に問題が生じない
• ローカル内で処理が完結するため、高速でリソース消費量も少ない
• → 良好なユーザビリティ
• ユーザ、もしくはプログラムにより、差分アップロード・ダウンロードのタイミングを制御可能
• → ネットワークの状態や電池残量に応じてDL/ULを行う／行わないなど
スマートフォン、ネットブック向けに最適化できる！
Open Web Architectureによって広がる可能性
• オフラインのWeb利用• RSSリーダー、ブログ、ニュース・・・• あらゆるデスクトップアプリをWebベースに置き換え• AR（拡張現実）アプリなどでも応用• センサーやGPSから得たデータを素早く記録し、後にアップロード
• サーバからまとめてデータを得てキャッシュしておき（地域データなど）、カメラ画像に重ねて表示、など
Open Web Architecture採用の問題点
• 世界的に見てノウハウの蓄積が少なすぎる。これに尽きます。
• 以下のような要件が組み合わさると、スクラッチから設計・実装するのは非常に困難
• DBをサーバだけではなくクライアントにも持つ事が前提となる設計手法
• 差分アップロード／ダウンロード処理の設計と実装（高速、かつフェールセーフなことが求められる）
• クライアントの状態に応じた処理の切り替え
• オンライン／オフライン状態
• ローカルDBがある／ない／あるけど容量いっぱい
• データ変更が衝突したら？
• etc, etc...
Open Web Architecture採用の問題点
• 世界的に見てノウハウの蓄積が少なすぎる。これに尽きます。
• 以下のような要件が組み合わさると、スクラッチから設計・実装するのは非常に困難
• DBをサーバだけではなくクライアントにも持つ事が前提となる設計手法
• 差分アップロード／ダウンロード処理の設計と実装（高速、かつフェールセーフなことが求められる）
• クライアントの状態に応じた処理の切り替え
• オンライン／オフライン状態
• ローカルDBがある／ない／あるけど容量いっぱい
• データ変更が衝突したら？
• etc, etc...
こうした問題に対するソリューションは？
世界初公開！Alexing Framework!!
• 弊社で作成中のオープンソースフレームワーク「Alexing」（仮称）のデモになります。（まだ試作段階）
• クラウド+Ajaxのアプリを、異様に簡単に作れます。オフラインにも対応
• Open Web Architectureに従ったアプリケーションのひな形を数分で作成できます。
Client
DB
アプリケーションデータ更新
データ取得
Cloud
DB
Download/Upload
アプリケーション
Alexing
Alexing Frameworkのコンセプト
• 一言で言うと「クラウド向けRESTfulライブラリ + HTML5 O/Rマッパーライブラリ」
• ここで言う「O/R」は、「Object/Relational」と「Object/REST」の双方を表す
• 基本的な準備作業は、クラウド上でデータモデルを定義するだけ
• すると、クライアントからそのデータモデルを（あたかも）直接操作できるようになるだけではなく、オフライン編集も可能！
Client
DB
Cloud
DB
Java Class
class Greeting
Alexing Frameworkのコンセプト
• 一言で言うと「クラウド向けRESTfulライブラリ + HTML5 O/Rマッパーライブラリ」
• ここで言う「O/R」は、「Object/Relational」と「Object/REST」の双方を表す
• 基本的な準備作業は、クラウド上でデータモデルを定義するだけ
• すると、クライアントからそのデータモデルを（あたかも）直接操作できるようになるだけではなく、オフライン編集も可能！
Client
DB
Cloud
DB
Java Class
class Greeting
Alexing
JavaScript Class
Sync Engine
Middleware
class Greeting
Alexing Frameworkのコンセプト
• 一言で言うと「クラウド向けRESTfulライブラリ + HTML5 O/Rマッパーライブラリ」
• ここで言う「O/R」は、「Object/Relational」と「Object/REST」の双方を表す
• 基本的な準備作業は、クラウド上でデータモデルを定義するだけ
• すると、クライアントからそのデータモデルを（あたかも）直接操作できるようになるだけではなく、オフライン編集も可能！
Client
DB
Applicationedit
retrieve
Cloud
DB
Java Class
class Greeting
Alexing
JavaScript Class
Sync Engine
Middleware
class Greeting
Alexing Frameworkデモ(1)
• デモの流れ
• クラウド上にクラスSimpleGreetingがあり、以下のプロパティを持ちます。※現在、サーバ側はGoogle App Engine/Javaで実装しています。
• 自動採番されるID
• 文字列型content、
• 日付型date
• このクラスに対して@OfflineCapableを付与するだけ
• →これで、オフラインWebアプリの基本的な枠組みが完成！
Alexing Frameworkデモ(2)
• SimpleGreetingをオフライン編集できるようになっています。
• サンプルツール、Alexing Consoleでいじってみます。
• 当然ながら、サーバを止めてもアプリを使い続けられます。
Alexing Frameworkデモ(3)
• クライアント側では、SimpleGreetingクラスに対して以下のようなAPI呼び出しを行えます（一例）。
• class.find()・・・IDによる検索
• instance.save()・・・オブジェクトの保存
• instance.remove()・・・オブジェクトの削除
• ローカルDBとクラウドDBの同期も簡単です。
• database.synchronize()
Alexing Frameworkまとめ
• Alexingを使うと、（オフライン）Webアプリ開発はこうなる！
• サーバ側では、データモデルを定義するだけ
• クライアント側では、高度に抽象化されたAPIを利用してそのデータモデルをいじくれる。RESTful！オフライン対応！
• ローカルDBのスキーマ管理や同期処理など、難しい部分は全てAlexingまかせにできる
• Alexingのロードマップ
• 2009年中・・・オープンソースとして公開
• 2010年Q1・・・バージョン1.0リリース
• 乞うご期待！
ご清聴ありがとうございました。
Recommended