「developer meeting」なんてタイトルが付いているセミナーに俺なんかが参加していいの？とか思いながら、「Xperia触ってみたい！」という思いから参加してきました。
下記にまとめてみますが、あくまで私の個人的な理解ということで、プレゼンターの意図と異なってたらごめんなさい。
そのうち、「技術資料 - 日本Androidの会（日本アンドロイドの会）」にアップされるのかな？
「Mobile World Congress 2010」レビューと，メディアからみたAndroidの魅力
日経BPの方がに行ってみてのレビューということで現地での模様を紹介されてました。
今までと違い、今年はハードウェアよりもアプリケーションに重点を置いた出展、関係者のプレゼンが行われてたようで、2010年はデベロッパーの年になるでしょうという話。
また、日経BP社 ITproが主催する「Android Application Award 2010 Spring（A3、エーキューブ）」の紹介もありました。
受賞すれば海外に羽ばたくチャンス！ですが、今の私には縁のない話です＞＜
矢吹さんのセッション
テックファーム株式会社の矢吹さん（@michiyasu0106）のプレゼン。Androidアプリを作成するにあたってのポイントの紹介でした。
以下、スライドのタイトルと概要。
シンプルがぶち刺さる
- 幕の内ではだめ
- 無骨だけど、でっかい鮭おにぎりであるべき
あまり多くの機能があると、本当にやりたいことがぼやけてしまう。
機能毎に理由を付ける
- 無駄な機能を減らすために何故この機能が必要か？をくり返す
UIは実際に書いてみる
- 853×480（デバイスの液晶と同じサイズ）の紙を用意する
- デバイスに貼り付ける
- 画面を描いてみる。
こうすることで、ボタンの押しやすさや見えやすさが明らかになる。
ソニエリ色を出すと良いことがある
最後に
Xperiaが発売されることで、Androidの未来は明るい。
世界に向けたムーブメントを日本から起こそう。
また、現在PICT RHYTHMというアプリを開発おり、開発者のTwitterアカウント（PICT RHYTHM）も公開しておられるみたいです。
次からは日本Androidの会メンバーのセッション
続・Android開発のお作法
有山さんのセッション。
自由に開発が出来るAndroidですが、それでも最低限のお作法がありますよ。ってことで、機能面に関する不文律の話でした。
GPSをつけっぱなしにしない
現在位置の取得は結構バッテリーを食うので、必要な時にだけ位置取得するようにする
サービスによる定期実行は必要最小限に留める
- 本当にServiceでないとだめなのか？
- 定期実行なら、AlarmManagerで代用可
ユーザへの通知はNotificationを使用する
- 直接Activityを起動しない
Androidはマルチタスクなので、自アプリのウインドウを強制的にアクティブにするようなやり方は行わない。例えば、緊急の電話をかけようとした時に、あなたの作ったアプリが前面にしゃしゃり出てきたら…
SDカードの容量を考える
SDカードの空き容量が減ってきたらどうするのか？を考えましょう。
最悪なのは、ユーザへの通知なくSDカードを食いつぶすようなアプリ。
バッテリが低下した時の対処内容
GPSや常駐アプリに関しては特に重要。ユーザに問い合わせを行う等、ユーザ視点で考えましょう。（アプリの実行中止、GPSの位置情報取得間隔を広げる 等）
ネットワークへの接続手段を考慮する
海外では3G通信に関して、定額サービスが提供されていない国もあるのでその辺を考慮しましょう。
Logの出力をしない
リリース版では不要なログを出力しない（ログ出力は最低限に）。
定数などでログのOn/Offを切り替える様にしておきましょう。
Adnroidアプリ開発の…（以降失念、すみません＞＜）
赤井さんのセッション。
簡単すぎるが故の懸念…
十数年前にも同じような話があったね。そう、VBことVisual Basic。
おかげで、プロじゃない人でも簡単にアプリが作れるようになった。
そのおかげで中途半端（例外処理が考慮されていない）なアプリが氾濫した。
結果的に、不安定なアプリが異常終了を多発するせいで、一般の人からしたら、「Windowsって不安定だよね」と。
高解像度アプリってどないして作るん？
原さんのセッション。
HT-03Aは320x480、一方のXPERIAは480x854
端末によって解像度が異なるわけで、アプリを開発する上で、その辺をどう工夫するかというお話。
レイアウトファイルの対応
サイズの指定に注意。
テキストサイズの指定には「sp」*1を使いましょう。
キャンバス描画の対応
場合によっては座標を画面の解像度によって補正する計算が必要。
絶対座標の指定ではなく、「画面サイズの何％の位置」というような指定がいいかも。
スクリーンサイズの取得はViewクラスのonSizeChangedメソッドで取得できる。*2
他には
他に注意する点として、
- ユーザビリティ
- 画像リソースの扱い
画像リソースを大量に扱う場合、画像サイズに依存した設計にすると画面サイズ毎の画像が必要になってしまい、アプリのサイズが大きくなってしまう。
- 1.5以下のユーザへの配慮
世界の1/4のユーザは1.5以下を使用しているので、有料アプリの場合は特に、対応バージョンを上げる場合はユーザのことを考えよう。
例えば、いきなり1.5以下のユーザを切り捨てるのではなく、次バージョンから1.6以上対応にする等アナウンスをした上で移行を行うとか。
ウキウキView 今後の発展
ブリリアントサービスの杉本さんのセッション。
ウキウキViewというアプリの紹介でした。
ちょっと内容は違うけど、こんな感じ「UKIUKI VIEW」
ライトニングトークス
日高さん
「日本Androidの会 デベロッパー倶楽部」、通称「デ部」の方。
AndroidでUstreamBoxという、複数のカメラを切り替えてUstreamへ配信する機械を作ろうという活動内容の紹介でした。
アプリ作ろう！じゃなくて、ハードも作ってしまおうというのがすごい。
発表の中では今までメーカに頼まないと出来ないようなことが、Androidによって出来るようになったそうです。
麻生さん
Androidは携帯だけじゃなく、いろんなものに使える！という社長の決断の元、Androidの開発を始められたそうです。
会社で堂々といじれるのはある意味うらやましい。もちろん、仕事なんでいろいろ大変でしょうけど。
中原さん
前日の21時にLTの依頼を受け、酔った勢いで承諾。AM3:00まで資料作ってたという強者ｗ
なんと3日で乗り換え案内アプリを作っちゃって、それがdocomoのアプリケーションガイドブックに紹介されてるんだからすごい！
[Android]乗換案内アプリ(TransitEX)がdocomoのアプリケーションガイドブックに紹介されました！ « ヒューマンクリエイト開発メモ
そして、「私はJavaがキライです」という爆弾発言ｗ（ちなみに、Cで作られてるそうです）
楽しい方でしたｗ
お触りタイム
さて、待ちに待ったお触りタイム。
ご自身で開発されたアプリをインストールしても良いですよーといわれても、開発したことないし＞＜
なので一般ユーザの視点でぐりぐりしてきました。
コンパス
ちらっと、Xperiaにはコンパス機能が付いてないという噂を聞いていたのですが、ちゃんと付いてました。ホッ
文字入力
片手でもって、親指で入力するのは辛いかなぁと思いましたが、まぁなんとかなりそうな感じ。入力予測の候補も出るし。
でも、句読点の入力だけは文字の間隔が狭すぎてきびしかった。「。」を入力しようとして「、」になることが数回。ムキーってｗ
入力方式変えたら何とかなるのかもしれません。
動画再生
YouTubeも特に引っかかったりすることも無く、つるつる再生できてました。まぁ、ネットワークがWiFiだったせいもあるのかな？初めてスマートフォンを触ったので良くわかりません＞＜
その他インプレはいろんな人が書かれているので、そっちを見てもらった方が良いですねｗ
注）天然オイルは飲み物です
感想
初めてセミナー（勉強会）に参加したけど、面白かった。もちろん、？？なことはたくさんありましたが…
いろんな人と技術的な話で盛り上がりたいと思った1日でした。
そのためにはまず自分がスキルアップしなきゃ＞＜
