HTML5 3days Tech Talk に参加してきた
html5-developers-jp 主催の HTML5 3days Tech Talk の 2日目に参加してきました。HTML5 に関して全く知識の無い状態での参加でしたが、わかりやすい説明で話にきちんとついていくことができました。せっかく勉強会に参加したので、ちょっとずつでも HTML5 に触っていこうかなと思いました。
勉強会で話を聞きながら取っていたメモを載せてみます。
html5 で作るオフラインwebアプリケーション
講師:白石 俊平さん
HTML5は日本が熱い! HTML5 のグループ登録者が増えている。 国で見ると、日本と韓国で盛り上がっているようだ。 日本がHTML5をひっぱっていくぜ。 オフラインwebアプリケーションとは、そのまんま、オフラインで動作するwebアプリケーションのこと。 2007 年に Google Gears が出た。 HTML5 関連の API は Gears からの影響が顕著に表れている。 しかし、Gearsを使ったアプリケーションはそんなに多くない。 普及していない理由 - ニーズが顕在化していなかった - ブラウザプラグインというアプローチが普及を阻害 - 開発の知識を持った人材が不足していた しかし時代は変わる! - モバイルネット端末の普及 - ブラウザ自身による実装 - 標準化により開発者人口増加 もう普及するしかないだろ! オフラインwebアプリケーションを実現するためのAPI アプリケーションキャッシュ アプリケーションに必要なリソースをローカルにキャッシュするための仕組み キャッシュマニフェストファイルを作成する マニフェストを text/cache-manifest MIMEタイプで公開 webアプリケーションのhtml要素にmanifest属性を追加してキャッシュマニフェストのURLを指定する。 キャッシュマニフェストとは - キャッシュするリソースを書き連ねただけのファイル - 文字コードはUTF8 - 1バイトでも変更があればリフレッシュされる - コメント内にバージョン文字列を含めたりする。 でも、キャッシュがあるととても開発しづらい。 デモ1 hello1.html の中で とか書いてた。 manifestファイルでは hello1.htmlをキャッシュする指定 キャッシュするから、マニフェストファイルを変更しないと再読み込みしても内容が変わらない。 デモ2 アプリケーションキャッシュをjsで制御して、自動更新するデモ マニフェストファイルが更新されていたら、新しいファイルを取ってくる。 web database クライアント上で動作するRDB SQLを全てつかえる オフラインwebアプリケーションを作る上で中心的なテクノロジ ドメインごとに領域が分れる。 ひとつのドメインにつき複数の領域を持てる 非同期と同期方のAPIがある 非同期APIは常に利用可能 結果を全てコールバック関数で受けらねばならないのでコーディングが面倒 同期API ワーカ内でしか使えないが、コーディングが楽 デモ java script にSQL文を書いている safariの開発者コンソールにデータベースという項目ができてるよ web stroge キーバリューストレージ web database より簡単に使えるよ ドメインごとの領域 ストレージは二種類 localstroge 永続期間無制限 session stroge ウインドウごと、ウインドウを閉じたら消える localstroge.key = "value" var k = localstroge.key web worker バックグラウンドで動くスレッド JSで時間かかる処理を行なうとブラウザがかたまる 使うには注意が必要 スレッドとは厳密には違い、変数を共有できない window documentなども不可 JSフレームワークを使用している場合は注意 ワーカ間のデータの共有にはメッセージングのAPIを用いる。 ワーカの生成 new Worker(scriptURL) メッセージ送信 worker.postMessage(message) メッセージ受信 worker.onmessage(message) つらい点 workerの処理はデバッグで追うことができない -> fakeworker.js evalとsetTimerによるweb worker の実装 メッセージングのコードはすぐ複雑になる。 複数のメッセージをやりとりすると長大なswitch-caseなどになりがち -> alexService ライブラリ作ったから試してみて。 HTML5(open web platform) 時代のwebアプリアーキテクチャ 理想的なオフラインwebアプリを実現するには大幅に変更する必要がある オフラインで動作する必要がある クライアント内で処理が完結する必要がある 処理結果の いままでは サーバに処理が集中 これからは ローカルDBとデータを読み書き 任意のタイミングでローカルDBとの差分をDL/UL ロジックの大半はローカルに存在する。処理が重くなるのでWorkerを使用。 これらをopen web architecture(仮)ととりあえず呼ぶ 利点 オフラインでも完全に動作 高速でリソース消費量も少ない ユーザ、もしくはプログラムにより差分UL/DLのタイミングを制御可能 スマートフォンモバイル向け オフラインでのweb利用 あらゆるデスクトップアプリをWebベースに ARアプリなどでも応用 センサーやGPSから得たデータを素早く、記録し、後にアップロード サーバからまとめてデータを得てキャッシュしておいてカメラ画像に重ねて表示 問題点 世界的にみてノウハウの蓄積が少なすぎる スクラッチから設計・実装するのは非常に困難 DBをサーバだけでなくクライアントにも持つ事が前提となる設計手法 差分UL/DL処理の設計と実装(高速かつフェールセーフに) クライアントの状態に応じた処理の切り替え データ変更が衝突したら 解決策 初公開 Alexing Framework 作成中のオープンソースフレームワーク「Alexing」(仮称) クラウド向けRESTfulライブラリ+HTML5 O/Rマッパ ここでのO/Rとは Object/Relational Object/RESTの双方を表わす
Canvasチュートリアル
講師:羽田野 太巴さん
資料がここで公開されています。
http://www.html5.jp/blog/2009/10/04/html5-3days-tech-talk/
Canvas Webページに図を描く canvas要素にAPIが用意されている JavaScriptからAPIを通して図を描く Canvas SVGの比較 Canvas JavaScriptを使って描画 描いてしまった図を個別に認識できない (円とか?) 描画そのものは高速 ピクセル操作が可能 SVG XMLのマークアップで図を表現 JavaScriptから各要素にアクセス可能 要素が多すぎると重い ピクセル操作はできない Canvas は個々のピクセルを扱う描画を得意とするだろう。 ウィジットは向いていないだろう Canvasの枠組みだけでは、ボタンなどを認識できない コントロール部分をHTMLで実現するか、ウィジット全体をSVGで描画した方が良い。 ブラウザの実装状況 IE以外は実装済み IE は ExplorerCanvas excanvas.js があるよ マークアップをHTML5にするべき? XHTML1.0 HTML4.01でも動作する doctypeがなんであれ、Canvasをサポートしたブラウザであれば動作する でも、HTML5以外のマークアップでCanvasを用いたら非準拠になるね canvas要素 canvasの描画の前にcanvas要素のコンテキストを取得する。 コンテキストに定義されているメソッドやプロパティを通して実現する。 var canvas = document.getElementById('sample') (この部分のコードをメモできなかった) パス ctx.beginPath(); ctx.moveTo(20,20); ctx.closePath(); ctx.stroke(); 座標系は、左上端が0,0で、右下に向って数字が大きくなっていく。
ここから先は、このメソッドでこんなのが描けるよ、といった話が続いた。Macbook の電池が切れちゃったので、ここでメモはおわり。
勉強会というものに参加することもはじめてだったのでどきどきしましたが、とてもよい時間を過ごすことができました。これからは他の勉強会にも積極的に参加してみたいなと思いました。
