Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

参戦してきた

プログラム http://www.html5.jp/blog/2009/09/13/html5-3days/:title=html5勉強会

HTML5 tech talk

HTML5で作るオフラインwebアプリケーション

  • 白石俊平
  • html5-developer-jp (Google準公式コミュニティ)管理人
  • 株式会社あゆた取締役
  • Google社認定API Expert
目次
  1. イントロダクション
  2. オフラインWebアプリとは
  3. 実現するためのAPI
    • アプリケーションキャッシュ
    • web Database
    • web Strage
    • web Workers
  4. HTML5時代のWebアプリアーキテクチャ
イントロダクション
  • html5-developer (2009/07/11公開)
    • 現在1300人
  • Google Trendで見ると日本と韓国で異様に盛り上がっている
  • 今後のHTML5を引っ張っていくのは日本だ

オフラインwebアプリとは
  • HTML5関連のAPIはGearsからの影響が顕著にあらわれている
  • Gearsを使用したアプリは多くない
  • 普及していない理由は下記
    1. ニーズが顕在化されていない・・・常時接続だろJK
    2. ブラウザプラグインというアプローチが阻害
    3. 開発の知識をもった人材が不足していた
  • ニーズ：モバイルネットの普及
  • ブラウザプラグイン：ブラウザ自身による実装
  • 知識と人材の不足：標準化により開発者人口が増加
  • Open WebによるRIA開発で行きましょう
実現するためのAPI
  • アプリケーションキャッシュ
  • Web Workers
  • Web Strage
  • Web Database

アプリケーションキャッシュ

CACHE MANIFEST
# version: 200909241051

hello.html
hello.js

  • text/cache-manifestというMIMEタイプ、UTF-8で公開する
  • としてheadで記載
    • manifestファイルの変更を確認し、キャッシュしなおす
  • アプリケーションキャッシュがあると開発しづらい
    • 開発時
      • アプリケーションキャッシュを使わない
      • manifestファイルを動的に生成する
  • アプリケーションキャッシュの動作をJavaScriptで制御する
Web Databse
  • フルSQL
  • domain restrict
  • one domain has n-DBs
  • one DB has n-tables/n-indexes/n-view
  • 非同期形APIと同期型API
    • 非同期APIはコールバックで受け付ける
    • 同期APIはワーカ内でしか使えない
Web Storage
  • key-valueストレージ
  • domain restrict
    • LocalStorage:永続
    • SessionStorage:ウィンドウ生存中
  • file://だとwebkitでは正しく動作しないかも･･･
Web Worker
  • バックグラウンドで動作するスレッド
  • 現在のJavaScriptはすべてがUI処理の一環として処理される
    • 処理が重いのでブラウザが死ぬる
  • 今後もっとがんばりたいよね？
  • スレッドとは厳密な意味で異なり変数を共有できない
  • window, documentといった変数も不可
  • ワーカ間のデータ共有にはメッセージングのAPIを用いる
    • worker→UI threadに投げる
  • 開発時
    • workerの処理はデバッガで追うことができない
      • メッセージングのコードはすぐ複雑になる
      • メッセージフラグが必要となり膨大なswitch-caseなどになりがち
      • AlexService･･･Web Workersのオブジェクト処理ライブラリ
HTML5時代のWebアプリアーキテクチャ
  • 理想的なオフラインWebアプリを実現するためには
  1. メリット
    • ローカル内で処理が可能で、オフラインでもほぼ完全に動作する
    • ローカル内で処理が完結するため、高速でリソース消費量も少ない(まじで？)
      • DBアクセスはゼロ距離だから確かに速いはず
      • サーバ間通信も制御可能
  2. デメリット
    • あれー

  • 問題点
    • ノウハウの蓄積が少なすぎる
    • 下記要件が混ざることによる困難さ
      • DBをローカルに持ち込む設計手法
      • 差分アップロード/ダウンロード処理の設計と実現(高速かつフェイルセーフを実装必須)
      • クライアント状況に応じた処理の切り替え
        • オンライン/オフライン
        • ローカルDBがある/ない/あるけど容量がいっぱい
        • データ変更の衝突
Alexing Framework
  • Open Web Architectureに従ったアプリケーションの雛形を数分で開発可能
  • サーバ上にJava Classを作成、Alexingを通すことでJavaScript Classとして操作可能
  • サーバ側：データモデルを定義するだけ
  • クライアント側：RESTfulがいい具合にやってくれる
質問
  1. ワーカーの処理時間は制御できるの？
  2. オフラインWebアプリとクライアントアプリの差異は？
    • インストールの手間
  3. メリットであった状況判断については、モバイルデバイスが富豪的になる前提？
  4. デバイス情報を取得するAPIが必要
    • それがChromeOSか！？