Offline Html5 3days

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アプリケーション」のこと。

2007年、Google Gearsの発表により一躍脚光を浴びる

HTML5関連のAPIは、Gearsからの影響が顕著に表れている

Web Workersの仕様書にもGearsの文字が


しかし、Gearsを使用して作られたオフラインWebアプリはそう多くない。

Google Docs, Gmail, Google Reader, Remenber the milk...

あまり普及していないのは以下のような理由だったと考える

ニーズが顕在化していなかった・・・現在に比べ、PCからの常時接続なネット利用が大きな割合を占めていた

ブラウザプラグインと言うアプローチが普及を阻害

開発の知識を持った人材が不足していた


しかし、時代は変わる！

こうなったら、もはや普及するしかない！！(？)

ニーズが見えない

ブラウザプラグイン

知識と人材の不足

モバイルネット端末の普及

ブラウザ自身による実装

標準化により開発者人口が増加

オフライン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





UI Thread

Workercreate

postMessage

postMessage

DOM(window,

document)

manipulate

Web Workers





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などになりがち






拙作のライブラリを試してみてください(^^)






→ fakeworker.js・・・eval()とsetTimeout()によるWeb Workersの実装







→ fakeworker.js・・・eval()とsetTimeout()によるWeb Workersの実装

→ AlexService・・・Web Workersのオブジェクト指向化ライブラリ



ここからは、HTML5(Open Web Platform)時代のアーキテクチャについてお話しします。

自身の開発経験に基づく、私見もかなり入ってます。


• 理想的なオフラインWebアプリを実現するためには、Webアプリのアーキテクチャを大幅に変更する必要がある。

• なぜか？• →オフラインで動作する必要がある• →クライアント内で処理が完結している必要がある。• →処理結果の永続化も含め、ほとんどのロジックをクライアント上で実現する必要がある。

従来のWebアプリ・アーキテクチャ

• サーバと直接データを送受信

• ロジックの大半はサーバに存在

クライアント

DB

アプリケーション


データ更新データ取得

サーバ


• ローカルDBとデータを読み書き

• 任意のタイミングで、ローカルDBとの差分をダウンロード／アップロード

• ロジックの大半はローカルに存在。処理が重くなるのでWorkerを使用

クライアント

DB


データ取得

サーバ

DB

Download/Upload



• ローカル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






Client

DB

Cloud

DB

Java Class

class Greeting

Alexing

JavaScript Class

Sync Engine

Middleware

class Greeting






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アプリの基本的な枠組みが完成！


• SimpleGreetingをオフライン編集できるようになっています。

• サンプルツール、Alexing Consoleでいじってみます。

• 当然ながら、サーバを止めてもアプリを使い続けられます。


• クライアント側では、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リリース

• 乞うご期待！

ご清聴ありがとうございました。

Documents

Offline Html5 3days