オフラインWeb開発
自己紹介
- @kyo_ago（本名です）
- 最近もらって嬉しかったプレゼントはシリコンウエハー
最近注目される
「Offline Web applications」
「Offline Web applications」
とは
厳密には
ただ、今回は
「オフラインで動作するブラウザアプリケーション」として使います
（文字的には間違ってない。。。！）
「オフラインWebアプリケーション」の歴史
初期
「オフラインFlashゲーム」
（従量課金回線や時間制定額回線向け）
しかし
常時接続が一般化し、ブラウザ上のオフライン動作の需要は減少
（逆にネイティブアプリケーションすらオンライン動作を要求）
そして
「スマホの普及」
PCとモバイルに見る「常時接続」の差
「回線の安定性」
PC
- 一度繋がれば比較的安定して接続できる
- 主にユーザが回線の接続、切断を行う
- ユーザは基本的に現在オフラインかどうかを意識して使用する
モバイル
- 一度つながっても頻繁に切断される（エレベータの中など）
- ユーザが移動しなくても回線が切れる（乗り物での移動中など）
- ユーザは現在オフラインかどうかを意識することが難しい
モバイル環境では回線状況によらず動作することが求められる
<閑話休題>
設計思想
「まず、オフラインで動作させられないか検討する」
出来ない場合、「段階的にオンライン要素を取り入れていく」
結果
「モバイル環境で使いやすいアプリが出来る」
</閑話休題>
選択肢
「オフラインWebアプリケーション」に価値はあるか？
「オフラインWebアプリケーション」に価値はあるか？
- アプリケーションの種類によって価値は異なる
- 価値は「ネット上のデータへの依存度」に反比例する
- 「今実装されていない」!==「価値がない」
ではどういった種類のアプリケーションで価値がでるか
「ソーシャル性の低いもの」
（一人で使うツール、ゲーム、投稿、読み物系）
「ソーシャル性の高さと、オフライン機能の価値は反比例する」
「ソーシャル性の高さと、オフライン機能の価値は反比例する」
「オフライン機能」
「オフラインは機能」
「オフライン動作」を機能の一種として考える
「ある機能の価値」は提供するものによって違う
「機能毎の相性」
（オフラインとソーシャル）
で、
ここまでは「アプリケーション自体」に対しての話
エンジニアのスキルから見た「オフラインWebアプリケーション」
エンジニアのスキルから見た
- 検討する余地は非常に大きい
- 「オフラインWebアプリケーションの問題」は「キャッシュの扱い」が大きい
- 「キャッシュをどう扱うか」はエンジニアのスキルとして非常に重要
- 検討するだけでも価値はある（アプリに「オフライン機能」を追加するとしたら？）
<閑話休題>
「オフラインWebアプリケーション」の種類
分類してみた
オフライン時の動作
- すべての機能を提供できる（サーバと通信しない）
- サーバ通信をキャッシュしてオンライン時に同期する
- 独自のオフライン表示を出す
- ブラウザのエラー画面を出す（オフライン機能を持たない）
「オフラインレベル」的に用語化すると扱いやすくなるか
</閑話休題>
選択肢
いつ始める？
ブラウザ上の「オフラインWebアプリケーション」の需要は今のところ高くない
ただ、「キャッシュの活用」や「通信エラー処理」という意味では重要
他に、ブラウザアプリケーションや、アプリ内WebViewにも重要
選択肢
どう実装するのか
「オフラインWebアプリケーションは難しい？」
「AppCacheの仕組みを使う」だけならそこまで難しくはない
「必要なオフラインレベルを見極めつつ、各種APIを組み合わせる」のは難しい
注意点
ポイントは3つ
1. 「回線が切れる前提のアプリケーション構築」
1. 「回線が切れる前提のアプリケーション構築」
- 「繋がらない」!==「エラー」
- 「なぜオフラインなのか（本体の設定？、回線切断？、サーバからの応答がない？）」
- 「どうしたらいいのか？（設定を変えてくれ。回線つないでくれ。あとで再施行してくれ）」
2. 「安全な再接続」
2. 「安全な再接続」
- 投稿を再送信しても2重投稿されない
- 送信完了するまで何度も送る
- 失敗すること前提の多重送信
- ユーザに「再送信しても安全である」ことを伝える
3. 「ユーザによる送信状況のコントロール」
3. 「ユーザによる送信状況のコントロール」
- ローディングにキャンセルボタン
- 「失敗しましたが、再度送信しますか？」
- タイムアウトを短くして、頻繁にユーザへ確認する
- タイムアウトを徐々に長くする
選択肢
開発のどのタイミングで実装するか
「キャッシュをどうするか」は設計時に考える
ただし、実装はあとで行う
（早く実装すると開発の支障になりやすい）
できるだけキャッシュに依存しない実装が理想
部分毎に付け外しできる形でキャッシュを実装する
おすすめは「シングルページ構成で実装し、キャッシュは最後に実装する」
<閑話休題>
ネットワーク通信以外の「キャッシュ」
通信以外にもキャッシュはある
通信以外のキャッシュ
- 表示キャッシュ
- DOMやCanvasの内容をキャッシュする
- パフォーマンスに影響する要素ではあるが実装は難しい
- 計算結果キャッシュ
- クライアントサイドで重い計算をすることは少ないが、たまに必要になることも
</閑話休題>
選択肢
どう実装するのか
キャッシュのパフォーマンスは「初期ロード時間」と「リロード時間」を分けて考える
初期ダウンロード時間を管理する
（「初期化に時間がかかりすぎてキャッシュがない方が早い」状態に注意）
初期表示に必要なダウンロードとキャッシュのダウンロードを分ける
「ログインページ」や「アカウント情報の入力ページ」でキャッシュを取得する
（「ユーザが頑張っている（＝機械が暇）」時を考える）
「通信の数を減らす」===「データを一括で読み込む」===「部分キャッシュが困難」
リクエスト時にクライアント側で必要なデータを選択して取得できる形式が良い
AppCacheはすべてのデータをダウンロードしないと使えない
（データが多いといつまでもキャッシュが使われない可能性がある）
選択肢
どう使ってもらうか
「オフライン動作」も「機能」なので使ってもらわなくてはならない
（趣味で実装するなら使われなくてもいいけど）
「オフラインで動作する」ことをユーザにどう知らせるのか
（「オフラインで動作しますマーク」とかあればいいのか？）
「ブラウザ上でリッチな体験」はあっても、「オフラインで使う」ことは少なかった
ユーザにどう説明していくのか
現時点では「細かくキャッシュを制御する」くらいがいいか
選択肢
セキュリティをどう確保するか
「Firefoxがユーザに許可を求めるわけ」
「オフラインアプリに指摘されるセキュリティ上の問題」
「Application Cacheはまずいのか」
詳しくは非Webで
ご清聴ありがとうございました
