Google Developer Day2009に参加してきました。
遅くなってしまったのですが、講演を聴きながらとったなぐりがきのメモを公開します。
HTML5
・HTML5はアプリケーションプラットフォーム アプリケーションを動かすための標準プラットフォームを定義する規格へ ・ユーザーにとってのメリット オフライン関連機能 SVG, MathML, canvas, audio, videoなどによる表現力向上 メニュー,フォームの強化による利便性向上 スクリプトコード現象によるアプリケーションのロード高速化と動作高速化 ・開発者にとってのメリット プラグインを使わないと実現できなかったことの一部がHTMLとスクリプトで可能になる 例) Gmailの複数アップロードでのFlash使用など メニューやフォーム検証などに大量のスクリプトコードだったのが、HTMLの記述だけで可能に 規格で曖昧だった点や、まったく標準規格が存在しなかった部分が規格化されることで、ブラウザ間の非互換が減少 ・HTML5の新機能 Web Workers マルチスレッド Web Socket サーバーとのメッセージ交換 Web Storage クライアント側へのデータ保管 アプリケーションキャッシュ フォームの強化 メディア要素 アプリケーション向け要素 構造化向け文章 ドラッグ&ドロップ機構(API) contenteditable属性の標準化 ドキュメント間メッセージング ルビ data-*属性 アプリケーション依存のデータを埋め込む SVGとMathMLの埋め込み ・HTML5は10年ぶりのHTML新バージョン HTML4, XHTML1.1, DOM Level 2 HTMLを包括し、機能を加える規格 XHTML2および、XFormsは含まない W3Cの規格となるが、実作業はWHATWG(Apple, Opera, Mozilla) ・HTML5は4つの規格で構成 HTML5 Web Storage Web Workers Web Socket The Web Sockets API 今年の10月くらいに最後のDraft ・新機能 Web Workers バックグラウンドでスクリプトを実行する仕組み 毎回新しいスレッドを生成するWorkerと、複数のウィンドウで共有できるSharedWorker ウィンドウを閉じても動き続けるpersistent workerを議論中 Web Sockets 専用のプロトコルでサーバと文字列の送受信をする仕組み HTTPではないので、サーバ側での実装も必要 XMLHttpRequestと比べると、オーバーヘッドが小さくリアルタイム性が高い Web Storage ページ遷移しても消えない、クライアント側のデータ格納機能 データ形式の違いで2Type storage型 window.localStorage サイト別に保持される、key-valueペア。cookieと同じような感じ。 window.sessionStorage サイト別、かつウィンドウ別に保持されるkey-valueペア。 Database型 localStorageと同様、サイト別に保持される記憶領域 SQLが使用可能 同期実行型と非同期実行型の2つのインターフェイス アプリケーションキャッシュ キャッシュしても良いURL、しないで欲しいURLを宣言 オンライン時にキャッシュされていないURLを先読み、オフライン時にはキャッシュを使う フォームの強化 input要素の新タイプ search email time datetime-local number color フォーム検証機能 フォームがsubmitされる前に、各フィールドの最小値、最大値、文字列パターン、入力必須かチェック <input type="url" placeholder="デフォルトメッセージ" pattern="https://???"> メディア要素:canvas スクリプトによる2次元グラフィックス描画 video,audio img要素と同じように、srcを指定 メニュー要素 あらゆる要素にコンテキストメニューを定義 ツールバーを簡単に定義 datagrid要素 まとまったデータを表現する リスト構造、木構造、表を扱う ソートや編集が可能 progessとmeter 構造化文書向け要素 section, article, aside, header, footer, nav, timeなど 文章の見た目にはほとんど影響がない HTMLソースの可読性向上など
ソーシャルWebの可能性
ユーザーレビュー コメント ソーシャル化によってサイトの認知を高める mixiアプリ ECサイト ・大量のレビュー ・まったく異なるレビュー ・友人のレビュー ・すべてのレビュー ⇒自分の友人関係(ソーシャルグラフを利用) OpenID Webにおけるシングルサインオン 認証=異なるWebサイトにおける識別子(ID)の共有/統一 IDはURL形式 必ずしもユーザー情報が必要なわけではない アウトソースみたいな形 OAuth アプリケーションに対して、APIの利用権限を与えるプロトコル 認可/承認 OpenID OAuth Extension OpenIDとOAuthをハイブリッド化 Google Friend Connect
Androidのデータ共有
■Intent Intent.putExtra() タイプの異なる一つ以上のデータを渡したいとき IntentにIntentを渡したり、バイナリデータも HOMEのショートカットアイコンも、Intent.putExtra()でバイナリデータ(アイコン)を渡してる あんまり大きいサイズは渡せない(ハードに依存) byte[] binary data bitmap serializable Object Bundleも便利 ■SharedPreferences マルチプロセスには現在、非対応 MODE 同一アプリ内なら、MODEは気にしなくてよい ファイルのパーミッションで管理されている 実際はFile /data/data/application_name/shared_prefs/***.xml ■Content Provider Activity.managedQuery cursorのライフサイクルをActivityが管理 SQLiteDatabase 共有は必要ないけど、sqliteを使いたい場合 ■Web server(cloud) データはサーバーへ java.net.HttpUrlConnection UI Thread(main thread)でhttp送受信はNG サーバーからのレスポンスが得られるまでの間、threadが止まる ⇒ANR dialog (Application Not Responding) Androidが,ANRを出す条件 ユーザーからの入力に対して、5秒間反応しない BroadcastReceiverに対する処理に10秒以上かかっている ANRを避けるために ユーザーに待ってもらう Progress barやProgress Dialogを表示させる backgroundで通信 Threadクラスを継承したり、Runnable interfaceを実装する形で通信処理を行うクラスを別スレッド化しておく ■速度 Intent ⇒ SharedPref ⇒ ContentProvider ⇒ Http HTTPが一番遅い ただし、ハードによる ■メリット Network 記憶容量を気にしなくてよい データの永続性が端末に依存しない 共有範囲が自分の端末に限定されない ■デメリット Network 時間がかかる 処理時間が推定しづらい UXに注意を払う必要がある バッテリーに難あり ■まとめ SDカードも ハードウェアや、実行環境によってメリット、デメリットは変わるため、複数のデータ共有の方法を知っておくことは大事
Androidのゲーム開発
ゲームグラフ 背景、キャラクタのサブグラフ 「経過時間」を入力することにより、フレームスキップ(コマ落ち、処理落ち)しても自然に動く。 スレッド スレッドは3つ メインスレッド ゲームスレッド レンダリングスレッド 高速なゲームを作るには、パフォーマンスと拡張性/保守性のバランスを取ることが重要 ゲーム中には、メモリ確保や開放はしない DDMSを使ってメモリの使用状況を確認 C++みたいにコードを書こう! 関数呼び出しのコストは半端じゃない