GDD2010JPに参加してきました。
平日の昼間でしたが、GDD2010に参加してきました。
簡単にですが、下記メモです。
基調講演
▽Chrome &HTML5
- 人々がWebの上で生活し始めている
- Webがアプリケーション化する
- それに対応するのがHTML5
- HTML5によりWebがパワフルに
- W3C活動報告
- HTML5でいこう
- 進むブラウザの対応（HTML5）
- IE9
- FF
- Opera
- Safari
- Google Chrome
- 実用に耐える高いパフォーマンス
- 実用化に向けてのフェーズ
- ハードウェアとの連携
- GPUアクセラレーション
- ローカル資源の活用
- 画像のファイルサイズなど
- CSS3のトランスフォーム
- 音声認識による検索@ブラウザ
- デバイスオリエンテーション
- デバイスの方位をDOMイベントとして定義
- マイクアクセスおよび音声認識
- @speech属性の追加
- <input type="search" name="q" speech required onchange="startSearch">
- ファイルアクセス
- File API
- FileSystem API
- 課題（webアプリケーションの課題）
1. みつけやすさ
2. 再アクセスの容易さ
3. マネタイゼーション
- Chrome Web Store
- スマートフォンで加速するモバイルHTML5
- 北米では、HTML5のトラフィックが従来のものを超えた
- Input
- Google日本語入力
- Mozc
- Google日本語入力Cloud API
- Transliteration API
- 本日公開
- バックエンドのみ
- フロントエンド/web uiは後日公開
- 10/23にコードリーディングを含む、テクニカルイベント開催
▽Android
- Why?
- Tim Bray
- spectral souls
- New In Android
- Market search suggestions
- New "similar" tab in Market display
- Comments visible in Market publisher site
- Error reports in Market publisher site
- Android Market licensing server
- Unbundled apps.For example new Gmail last week.
- Cloud to Device messaging.For example, Chrome to phone.
- Tethering and portable hot spot (usb, wifi)
- Android and Japan
- モトヤフォント
- アプリのダウンロード数は世界第2位
▽Cloud Platform
- Google App Engine
- Easy to build
- Easy to manage
- Easy to scale
- 90K developers
- 130K apps active every week
- 5.5B pageviews / week
- Japanese success story (use GAE)
- エコポイント
- mixiFESアプリ
- Google App Engien for Business
- SSL and SQL
- Technical support
- Formal SLA
- centralized admin console
- enterprise pricing
- Domain Console
- IT予算の60%は保守
- Roadmap
- Full MapReduce
- Datastore dump and restore
- Background servers & Reserved instances
- Real time Channel API
- Built in OAuth & OpenID
- Make you smile :)
- CLOUD PORTABILITY
- OPEN STANDARDS
1. Data portability
2. app portability
- GWT ♥ Roo
▽石原直樹さん
高性能な Android アプリを作るには (ティム ブレイ)
- Reacting to events quickly
- Don't hog the event looop("main" / UI) thread!
- SQLite
- Use indexes(see EXPLAIN & EXPLAIN QUERY PLAN)
- For logging, consider file-append rather than database-write
- sqliteはindexをはるとselectは早くなるがupdateが遅くなる
- AsyncTask
- Must be called from a main thread
- IntentService
- is a base class for Services that handle asynchronous requests on demand. Clients send requests through startService(Intent) calls;
- UIスレッドには絶対に重い処理を置かないで！
- UI Tips
1. Immediately, disable UI elements
2. Briefly, a spinner in the title bar
3. if more than 200msec, show a ProgressDialog
4. in AsyncTask onPostExecute, cancel alarm timer
- Performance Advice
- "Premature optimization is the root of all evil." -Donald Knuth
- Profiling Tools
- Traceview
- Log.d() calls with a timestamp aren't terrible
- Extreme profiling: Aggregate user profile data
-
ここちよい Android - おもいやりの UI デザイン(adamrocker、矢野りん)
- 物販アプリ「DropCart」
- UX(User experience)とは？
- ユーザへの”おもいやり”
- 気持よくさせるのではなく、不快にさせない
- 不快ではない＝違和感がない
- 静的・動的な資格情報に対して「違和感のない」体験を提供する
- アニメーションを資料したインタラクション
- グラフィックによる世界観
- SimejiにおけるUXの考え方
- ユーザの脳への”おもいやり”
- 設定変更
- 何が変わったのかを認識するには時間が必要(ダイアログあり)
- 脳への負担
- おもいやり１
- 脳の処理負担を軽減するため、変化は操作に対して時間・距離的に近くする
- モバイルにおける課題
- ディスプレイが狭い
- 手が邪魔
- Simejiの解決策
- 4次元の活用
- ゆとり
- おもいやり2
- 脳が処理する時間的な余裕を与える
- おもいやり3
- 自然な動作表現
- フィッツの法則
- ヒックの法則
- テスラーの複雑性保存の法則
- SimejiのUXにおけるグラフィックデザイン面の工夫
- グラフィックデザインのねらい
- 情報の理解を助ける
- 好きになってもらう
- Simejiデザイン方針
- フラット
- スタイルを単純にしてスキンを目立たせたい
- シンプル
- アイコンのもつ意味をストレートに伝えたい
- ラブリー
- 毎日使うものだから、愛着を持って欲しい
- Mies van der Rohe
- "Less is more."
- アイコン
- 苑の大きさが目安
- もともとマルイデザインは目安より一回り小さく
- "God is in the detail."
- "Form follows function." 形態は機能に従う
クールな Android アプリを作るには (安生真、山下盛史 @yyaamma、江川崇 @t_egg)
<江川崇 : IMoNi>
- IMoNi
- 非公式i-モードクライアント
- 技術的な仕組み
- Intent
- Action, Category
- Uri
- MIME
- Content Provider
- 標準(Contacts, SMS, Mediaなど)
- 独自
- 共有ダイアログについて
- 面倒と考えるか、汎用的と考えるかは様々な観点があり、賛否両論わかれるところだが、いいところもたくさんある。
- Uriがおすすめ
- ex) IMoNiでは、mailto:スキーマに対応したアプリからメール送信できる機能を設けている
- 振る舞いと情報を包含している(ReSTFull)
- 有名アプリの威を借る
- 有名アプリに規制すると付加価値が上がる
- 連携もIntentを使えば実装は楽
- ex) マッシュルーム
- IMoNiのマッシュルーム「Emoji picker」
- 標準装備されている仕組みに乗る（１）
- 標準のContent Providerに突っ込むといい
- IMoNiではメールの新着通知をSMSのDMに
- 標準装備されている仕組みに乗る（２）
- Intent Filterを標準のアプリにあわせておくといい
- ギャラリー、連絡先など
- 標準装備されている仕組みに乗る（３）
- 自分のアプリが持っている情報も、標準の仕組みで公開できるようにしておくといい
- 独自に作るのは面倒だが、いい面もある
- Global Searchに対応
- 批判は目につきやすいが、何も言わないけど分かってくれる人もたくさんいることを忘れずに。
- 開発者と開発者
- アプリとアプリが人と人とをつなぐ
- ex) IMoNi x デコ美
- http://goo.gl/HUZG
- まとめ
- Androidの緩やかにつながる仕組みを使いこなしているアプリはクール
- Share Dialog はいい側面も悪い側面もある
<山下盛史 FxCamera>
- FxCamera
- 370万
- 20万アクティブ
- The Developer's Guide
- UIガイドライン
- Appleの Human Interface Guidelineはとても参考になる
- そのままではなく、参考にする感じ
- あえて標準部品を使う
- Backキーを使う
- 開発者的にはonResume()とか
- ユーザーが期待・想定しているのは大抵の場合、「戻る」「Undo」
- 画面/ユーザー操作の階層に合わせる
- Menuキー
- 実装はアプリ次第なのでアプリによってoption menuが出る場合とでない場合があるし、同じアプリでも画面によって出る場合とでない場合がある
- 積極的に活用する
- menuキー使うのが必須なつくりにすれば押して貰える(ブラウザ、Gmail)
- 一切使わない
- officialのtwitterアプリ
- うまくハイブリッド
- よく使うものだけ出すとか
- 落ちないこと
- Config Change
- 見落としがち
- Activityの強制再起動
- orientation
- keyboard, keyboardHidden
- サポートがしっかりしていること
- webページとして作るのがおすすめ
- アプリ更新しなくてもいつでも更新できる
- メールの対応が楽になる（リンク教えるだけ）
- iUI http://code.google.com/p/iui/
- カスタムスキーマ
- http://bit.ly/fxcameratest
Android でリアルタイムゲームを開発する方法: リベンジ (クリス プルエット)
- リベンジ
- ワンダのレプリカ島
- Androidのゲーム開発
- 端末の種類が多い
- 第一世代
- HVGA(480x320)
- OpenGLES1.0/ 1.1
- HT03A
- 第２世代
- OpenGL ES2.0, 1.1
- WVGA(800x480)
- 端末の特徴
- 画面サイズ、解像度
- インプット機能
- トラックボール、十字キー、キーボード、マルチタッチ
- ＡＰＩ的に対応しやすい
- MotionEventかKeyEvent
- OpenGL
- テクスチャフォーマット:ATITC? PVRTC? ETC1?
- OpenGLバージョン
- GL_EXTENSIONS?
- 端末のバージョン
- Android1.5 12%
- Android1.6 18%
- Android2.1 42%
- Android2.2 29%
- HeightMapProfiler
- パフォーマンスを高める方法
- 必ずVBOを利用
- VBOの数を減らす
- 浮動小数点数の頂点を利用
- テクスチャコンプレッションならETC1
- 2DならOpenGLのdraw_textureエクステンション
- 30ヘルツで遊べるようにプランニング
- 第一世代端末から第二世代端末までランタイムでスケール
- GL_EXTENSIONSは役に立つ
- 第二世代のみの端末用ゲームなら、GLES2.0を使用
- GLSurfaceView (Androidのclass)
- 操作設定は必要
- 端末がわからないため、Configure Keyboard的な画面とか
- あとから付けるのは大変
- PHPxJSでテストゲームを作った
- 死んだところをサーバーに投げる
- 死にやすいところをヒートマップ
- 改良
- O3C Client Interface
- "It's not really about innovation so much as exploring interestingness."
- 楽しいゲームには「革新」より「面白さ」のほうが大事
- Androidマーケット
- ユーザーランキング第二位
- ダウンロードが一番多い（5月くらいから倍になっている)
- インプレッションは一番高い
- リンク
- http://code.google.com/p/apps-for-android/
- http://replicaisland.net/
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++みたいにコードを書こう!
関数呼び出しのコストは半端じゃない
Google Analyticsを使ってアクセス解析をしてみる
はてなは簡単な設定で、Analyticsが利用できるのがいいですね。
そんなわけで、日頃どんな人たちがこのサイトを見ているのか確認してみます。
世間のブラウザシェアだと、IEを使っている人が圧倒的に多いですが、はてなは圧倒的にfirefoxユーザーが多いんですね。
あと、Google Chromeが12.42%と、まだ出てきたばかりなのにこの比率はすごいですね。
ちなみに、私は先日までGoogle Chromeを使っていたのですが、amebloが編集できないなどの理由で、
firefoxに再び戻ってきました。
Googleによると、ChromeのRSS対応予定などが発表されていますが、ブラウザだけでなく、
コンテンツを提供するサイトの対応状況によっても、ブラウザ選びが変わってくるのではないんでしょうか。
結局Google Gearsってなんなの？
最近ではあまりラボの進歩があまりないように見えるGoogleですが、
そのGoogleのGrearsっていうのが、結構いろんなところで見かけるようになりましたね。
例えば、
- Google Reader
- Google Docs
- WordPress.com — Get a Free Blog Here
- Remember The Milk: Online to-do list and task management
なんかが結構有名ですね。
サービスによって、Gearsの使い方が結構いろいろあります。
その前にどんな機能が実際あるのか？
Google Gearsの機能
- オフライン時のために、サーバーのリソースをキャッシュに保存
- クライアントサイドのDBを持つ
- スレッド機能
というのが、3大要素ですかね。
Google GearsってWebアプリケーションをオフラインで使えるようにするものってイメージが結構
あったりしますが、他にもいろいろ使い方があります。
例えば、Wordpressなんかではローカルに管理画面で読み込むデータをキャッシュすることにより、
管理画面の高速化をやってたりします。
オフラインにするというだけでなく、既存のWebアプリケーションにもいろいろと適用することができるんですね。
また、クライアントサイドのDBというのが、Sqliteなので、
Gearsの中でデータベースを作ったりということができるようです。
詳しくはこちらを参照。
基本Gearsはクライアントサイド技術なので、javascriptを使用します。
javascriptをガシガシ書くのが好きな人はいいと思います。
また、GoogleのAndoroidでも、mobile用のgearsが搭載されるらしいので、
まだまだいろいろ期待できそう。
Google Gadgetにタブを追加してみる
Google GagetでAPIで取得したデータなどを表示するのはできましたが、
よくあるガジェットにはタブが採用されています。
このタブの仕組みがよくわからなかったのですが、
意外に結構シンプルな仕組みで実装できました。
tab.xml
<?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="タブサンプル" height="140" scrolling="true" > <Require feature="tabs" /> </ModulePrefs> <Content type="html"> <![CDATA[ <script type="text/javascript"> var tabs = new gadgets.TabSet(__MODULE_ID__, "Two"); function init() { tabs.addTab("1つ目", { contentContainer: document.getElementById("one_id") }); tabs.addTab("2つ目", { contentContainer: document.getElementById("two_id") }); } gadgets.util.registerOnLoadHandler(init); </script> <div id="one_id" style="display:none">１つ目のタブの内容。</div> <div id="two_id" style="display:none">２つ目のタブの内容。</div> ]]> </Content> </Module>
解説
の部分でタブを表示するのに必要なライブラリを読み込む。 - gadgets.TabSet() コンストラクタ を使用して、tabs オブジェクトを作成。
- addTab() 関数を使用して個々のタブを追加。タブの内容は、idをもとに要素の内容を追加する。
これでこんな感じでタブが作れます。
Google Gadget上でいろいろやってみる2
前回は足し算スクリプトなる、足し算ガジェットを作ってみましたが、今回もjavascriptとgadgetの勉強という名目のもといろいろ作ってみたいなーと。
今回はおみくじgadget。
ソースはこんな感じです。
<?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="おみくじ" /> <Content type="html"> <![CDATA[ <script type="text/javascript"> function fortune(obj){ var message = new Array(4); message[0] = "大吉!"; message[1] = "小吉"; message[2] = "凶"; message[3] = "大凶…"; var rand = Math.floor( Math.random() * 4 ); obj.box1.value = message[rand]; } </script> </head> <body> <h1>おみくじプログラム</h1> <div class="form"> <form name="frm1" action="" method=""> <input type="text" name="box1" value="今日の運勢は…" /> <input type="button" name="calc_btn" value="占う" onclick="fortune(this.form);" /> </form> </div> ]]> </Content> </Module>
これをインポートしてやると、こんな感じに表示されます。
やべーすごい簡単。
ということでもう少し難しいことできたらいいなと。
