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++みたいにコードを書こう!
関数呼び出しのコストは半端じゃない
