[0]mitc - 日記
2011/11/06(日)Google Developer Day 2011 Japanに参加しました
| Google Developer Day 2011 Japan | 公式サイト |
|---|
行ってきたので感想を書きます
■ 基調講演
10分前に会場入りしたところ既にメインホールが埋まっており別室で中継映像を視聴。
ちょっと残念な感じなので来年があれば早めに行った方が良さそう。
- Android Marketキャリア課金による売上高が半分近く
- 多分日本国内の話
- 何を全体とした時の半分?
- 数が多いことは間違いない
- ICSの紹介
- だいたいEngadgetとかに書いてある話
- 「色々できるようになった反面、ユーザのプライバシーには注意する必要がある」的な話
- 「カレンダーAPIはあるけれど予定の書き込みなどスケジュールを直接触る場合は裏でやるよりインテントを使って標準のカレンダーアプリを呼び出すなどユーザにわかりやすい形にした方が良いだろう」的な話
- 今重点的に取り組んでいることはChromeとAndroid
- Chromeの話
- 現在の世界におけるモダンブラウザ使用率は62.27%。日本国内でも60.83%
- ChromeのActive Userは2億人
- 例の3D螺旋本棚のデモ
- ブラウザ上のアプリはこの本棚みたいにクラウドの力を引き出すことができるのですと言っていたけれどもネイティブアプリケーションでも別にできると思った
- Chrome搭載の開発者向けツール
- 圧縮JavaScriptコードを展開する機能が追加されたらしい
- WebKitの機能なのでSafariでも使えるらしい
- DOMインスペクタでカラーコードを指定しやすくなった
- 開発者ツール上でのCSSの変更履歴が残るのですぐ戻せる
- Chrome Frame
- インストールすることでIEの中身がChromeになる
- バージョンアップで管理者権限がいらなくなった
- とはいえそもそもインストールさせないといけない時点で導入させるのは厳しいでしょうね
- Chrome Web Storeも近い将来日本で展開する
- Chrome AppをWeb Storeで配信するとユーザエンゲージメントを向上できる
- AppEngine
- 色んなアプリがAppEngineで作られている
- 新しい要素
- Google+
- ユーザにフォーカス
- Googleの様々なサービス+you
- +1は広告、検索結果や様々なウェブサイトに設置されており一日50億回以上押されている
- Google+ APIはOAuth2+RESTful+JSONで構成される
- クライアントライブラリも色々な言語に対して作られており呼び出しはシンプルで簡単
- APIが使いやすいことはプラットフォームとして非常に重要だなあ
- Hangouts API
- ビデオチャットを含むサービスを作るのには便利なのかな?
Three More Things
- Google内の開発の話
- なにごともエンジニアありき
- 百聞は一デモに如かず
- 議論してばかりいても話にならない。まず手を動かして作ってみる
- 日本で「イケる!」と思ったら世界のみんなも同感かも
百聞は一デモに如かずというのはまさにその通りだなあと思いました。
見習わないといけない姿勢。
■ Androidの最新情報
http://www.google.com/intl/ja/events/developerday/2011/tokyo/agenda/session_2004.html
最新情報というのは要するにIcecream Sandwichの話であって、だいたいAndroid DevelopersのAndroid 4.0 Platform Highlights辺りに書いてある話ではあります。
日本語資料:http://y-anz-m.blogspot.com/2011/10/android-40-paltform.html
Converged Platform
- 色んなデバイスが集まってくるプラットフォーム
- スマートフォンやタブレットだけでなくテレビとか色々
- スマートフォンとテレビではディスプレイのサイズも違うし最適なUXは異なる
改善点
- アプリ側からナビゲーションバーを消せる
- ActionBar
- Honeycombアプリの上の方にあったあれ
- 画面サイズによって良い感じに表示を変更できる機構がある
- 通知
- スワイプで個別に消せるようになった
- Honeycombで通知の右端に×ボタンが付いているような感じか
- 通知をカスタマイズできる
- Large icon
- Actionable Buttons
- 今までは通知をタップしてアプリに飛ぶとかしかなかったのが色々できるようになる感じか
- Launcher Widgets
- ListView, GridView, StackViewを使えるようになった
- 大きさを変更可能になった
- HoneycombでGMail Widgetのサイズをタップ&ドラッグで変更できたような感じ
- Fragments
- ちゃんと使ったらスマートフォンなど画面の小さなデバイスでは画面遷移で、タブレットなど画面の大きなデバイスでは一つの画面内で複数の画面を配置できる
- Android1.6以上で使える互換ライブラリがあるので既存のアプリにも適用できる
新要素
ActionBarはGingerbread以下では自力実装になる
→Fragmentみたいに互換ライブラリを用意しない理由は何だろう
■ Androidの優れたユーザエクスペリエンス
http://www.google.com/intl/ja/events/developerday/2011/tokyo/agenda/session_2001.html
#1 Be fast
- IO処理をUIスレッドで行わない
- ANRを出さない
- StrictModeを使う
- AsyncTask, IntentService, Loaderについて学ぶ
- TraceViewを使う
- 0.2秒以上かかる処理ならプログレスバーを出した上でユーザがキャンセルできるようにする
#2 Be usable
- 少しでもマニュアルが必要になるなら何かがおかしいと考えるべき
- UI Patterns
- Action Bar
- Multi-Pane Layouts
- Application Navigation
#3 Be beautiful
- Typography
- Color
- Layout
- Motion
- etc...
デザイナーの方とコラボレーションして見た目も美しいアプリにすべき
#4 Be Android
- Don't just port your UI over from another framework
- Be consistent with Android UI best practices
- Don't screw up the back button
- Consider App Navigation UI Pattern
- Don't build your own lists or menus or buttons or sliders or preferences
タイトルバーに戻るボタンがあってハードウェアの戻るボタンは違う動作をするとかそういうのはよくないよねと。
iPhoneアプリのUIをそのまま持ってきたりとかもやりがちですよね。
#5 Listen to your users
ユーザの動向を収集して積極的に改善する
アプリケーションはできるだけ早くリリースして頻繁にアップデートする
Unified UI framework for phones, tablets and more.
- Navigation Bar
- Honeycombで戻るボタンなどが出てきていた場所の呼び名
- Recent
- Richer Notifications
- ビジュアルテーマ
- Device Default
- Hollo
- どんな端末でも同じように見せたいならHollo、端末ごとのデフォルトスタイルを適用したいならDevice Defaultを使う
- 新しい解像度が増えた
- xhdpi
- Galaxy Nexusなど
- Launcher iconが更に高解像度を要求するようになった
- ldpi 36px, mdpi 48px hdpi 72px, xhdpi 96px
- 端末にメニューボタンが必須でなくなった
- メニューボタンを搭載しない端末が存在することになる
- メニューではなくアクションバーのメニューアイコンを使うことになった
- 従来のメニューボタンで出すメニューは通常はアクションバーのメニューに吸収されるので問題無いが、メニューボタンの押下をonKeyDownでフックしていた場合はICSでは修正が必要
- sw600dpというResource qualifierが増えた
- Action Bar
- バー左端のアプリケーションアイコンはアプリケーションのホームボタンとして使う
- 真ん中のところ(View Detail)はタブを置いたり検索バーを置いたり好きに使える
- Action Buttons
- Action Barの右端のところにあるボタン類
- アプリケーションができることをボタンやメニューの形で表現すべき
- 一番端のメニューはGingerbreadまでのAndroidにおいては"Option Menu"と呼ばれていた
- 現在のアプリケーションの状態をAction Barで表現する
- アプリケーションの状態が変化したのにユーザにフィードバックしないのは良くない
- Stacked Action Bar
- 画面内に表示する場所がなくなると2列になるような感じで表示領域に応じていい感じにしてくれる。属性を指定するだけでOK
- Split Action Bar
- 画面内に表示する場所が無い場合に画面の下の端にAction Barの続きを表示するような感じ
- APIが10以下、Gingerbread以前ではOSで提供されていないから自分で実装するしかない
- App Navigation
- Notification, Widgets, Recents、いろんなところからユーザはアプリにやってくる
- BackだけでなくUpというナビゲーションをオススメする
- Upの流れイメージ「Contacts(Contacts) -> Contact details(Contacts) -> Compose email(GMail app) -> [UP] -> Gmail(Gmail app)」
- current applicationの上位階層へ行くのがUp
- multiple-apk supportをリリースはしたができれば使わないで下さい
- misc
- aim for a single APK
- use the compatibility library
- customize visual design completely, if straying from Holo theme
- support both landscape and portrait
- use dp/sp (not px)
- extract dimensions for phones and tablets
- /values/dimens.xml
- /values-lagrge/dimens.xml
- use theme/style/etc to reduce redundancy
- marry OS visual style with your brand/identify
- /drawable-hdpi/
- /drawable-large-mdpi--v11/(honeycomb)
- /drawable-v14/(icecreem sandwitch)
- create 9-patch bitmaps
- それぞれの画面サイズごとのビットマップを作らなくてもいい(?)
- See also: http://code.google.com/p/android-ui-utils/
- API level 11以上≠タブレット
- DON'T assume API level >= 11==tablet
- DON'T assume xlarge == tablet
- xlargeでなくlargeのタブレットもある
- Example: code.google.com/p/iosched
The Developer's Guideは読んどいた方がいいでしょう。
■ Chromium 開発を支えるクラウドの技術 - Googleのクラウドコンパイラ
http://www.google.com/intl/ja/events/developerday/2011/tokyo/agenda/session_11113.html
Cloudを活用したCIの話
cloud compiler: goma
GOMA is tremendous productivity boost!
Chromeの開発サイクル
コーディング -> Build&Test -> Code Review ->[LGTM]->Repository(Buildbot)-> コーディング
- 110CL/day
- 平日は200CL弱
- 7分半ごとにCLがコミット
- timezoneも限定すると非常に短期間の間にCLが行われる
ChrominiumをビルドするのはそこそこのノートPCで3時間半かかる
→Xeon X5650 2.67GHz 6cores * 2cpus 12GB memory, HDD→93分
15分もかかると手元でBuild&Testするのがとても苦痛
distcc -a fast, free distributed C/C++ compiler
→コンパイル作業を分散させる
→しかしプリプロセスを手元でやるので変更に弱い
distcc-pump
そこでinclude_serverを作った
Build speed: 50%(linuxのカーネル)/200%(samba)
distcc/distcc-pumpは十分な数のサーバーを正しくセットアップする必要がある
→セットアップが簡単ではない
もっとたくさんのコンパイラサーバを身近に
→クラウドを使えばいいじゃない
gcc -> [compiler proxy] -> cloud -> gcc,g++ + cache
.......|->local server
make->gcc,g++->compiler proxy->subproc->g++
................|
................->Frontend->Executor->memcache
Include Processorは早くてだいたい正しいこと
- >必要なinclude fileが取れればいい。余分なのがあってもいい。
- >#if, SSE, double array
ローカルがincludeを全部やって必要なファイルをremoteに上げる
clang: LLVMのコンパイラ
Mac OS X用のバイナリを吐かせるには？
クロスコンパイラ→アップルが提供しているMac OS X用のコンパイラをLinuxでビルド
→しかし吐き出すアセンブラコードが違うとかよくわからないトラブルがあった
→→maloader(Mac用のwineみたいなの)で解決
compiler proxyとFrontendはRPC over HTTP
networkは信頼できない
→retry, timeoutをどうするか
→ローカルでもビルドを行なってリモートと比べて先に結果が来たほうを使う
cloud compiler
今のところここまでの大規模開発に関わることは無いのですぐに活用できるノウハウといった類ではありませんが、タイムアウトの取り方が興味深かったです。
■ イグナイト
http://www.google.com/intl/ja/events/developerday/2011/tokyo/agenda/session_8001.html
このプレゼン形式、面白かったです。
両手が開くのでジェスチャーなんかが自然に入ってくるし、一部でつっかえてもスライドが切り替わるから話を打ち切って次に進めざるをえないため、見ている側からすると見やすいし。
もちろん、内容を伝えることが目的ならデメリットも多いと思いますが、ライトニングトークみたいな感じの場なら良さそうだなあ。
#1 飛行石の話
これ:http://www.youtube.com/watch?v=tVVP8hKao4A
#2 ガジェットOSの話
RSSリーダーじゃダメだったのかな
#3 Chromeのオーディオアウトプット先の話
確かに音関連が充実していますよとうたっておいて出力先を選べないのでは片手落ちなのかも
#4 AOSPにContributeの話
AOSP->Android Open Source Project
最後に少しだけ触れていたプロジェクトの色々細かい事情というところが一番の障壁なんじゃないかなあ
#5 死海文書オンラインコレクション
語りが面白かった
#6 Introducing Google APIs Discovery Service
こういうのがプラットフォームから提供されているとすっごく便利ですよね。
私もRemember the MilkのAPIを調べていた時に大変助かりました。
■ まとめ
参加者2000人、運営100人の大規模イベントでした。会場は人人人で、あちこちに行列ができていましたよ。
講演内容は、特にAndroidに関しては公式ドキュメントに書いてあることがメインだったかなあという感じ。でも、講演で開発者に直接伝えたいような重要なことならドキュメントが公開されているべきなわけで、当然といえば当然かな。公式イベントだってことですね。
未来のことももうちょっと知れたらよかったですが、ICSが出たばっかりだし、優先度がICSの紹介メインになるのは仕方ないか。
来年もAndroidに関わっていればまた行きたいな、ということで関係者の皆様本当にお疲れ様でした、ありがとうございました。
[2]コメントを書く
■コメント（0件）
■トラックバック（0件）
[9]ログイン
[*]検索