「mixi Engineers' Seminar #2」参加メモ

http://atnd.org/events/16917

開発者のためのiPhone⇔Androidアプリ移植のポイント

赤松洋介さま（サイドフィード株式会社）

http://www.slideshare.net/yoski/iphoneandroid-8455306

  • TwitCastingやっている
  • 会場参加者：iPhone開発者1割、Android開発者3割
  • 今日の資料はiPhoneからAndroid開発の流れ
  • Androidへの不安
    • 画面作成面倒、遅い、端末依存、Java遅い
  • 移植の手段
  • 結論 コード移植
  • 準備
  • Activity - View Controller
    • Activity間の呼び出しは難しいので、iOSでController間の呼び出しをしていると苦労する
  • Inteface Builder
    • 座標固定に注意
  • ソースコード移植
  • Point
    • JavaとObj-Cで共通の物も多い
    • NSString => String
  • リソース移植
    • 変換ツールを作成
    • 表示文字列はすべてリソース化。%@ -> %1$s
  • 画像など
    • ファイル名に-が使えない
    • @2xアイコンはdrawable-hdpiに
    • 国際化対応はAndroidの方が簡単。フォルダ名を-jaとかするとよい
  • ひたすら猿作業で移植
  • よかった点
  • 良くない点
  • 気づいたこと
    • 多言語化がすごい楽(XMLやフォルダ名で吸収してくれる）
    • ThreadとHandlerの扱いが楽。iOS4も^{block}でちょっと楽になった
    • ほかアプリとの連携が楽。Activity素晴らしい
  • Design
    • XMLでいろいろ定義。iOSみたいにボタン押したときの表示などが用意されていない。
  • はまったとこ
    • Memory管理
      • Out of memory !
    • バイナリ周り。unsignedがない。Big Endian
  • 共通コード
    • C言語で書いていると、Android NDKでコードを共通化できる
    • HTMLはWebViewベースの箇所はほぼそのまま利用可能
  • 端末の設計思想
    • メニューボタンと戻るボタン
  • 反省
    • メニューがあるのでツールバー隠す＞たくさんクレーム来た
    • ユーザには設計思想を押し付けるな
  • テスト環境
    • iPhoneはシミュレータが高速
    • Provisioningが面倒
    • Androidはシミュレータ動かん。端末のデバッグ簡単。apk配布楽
  • 端末依存
    • コードは正しくてもアプリは動かない
    • 毎月Android端末買いたしてます
    • それでも、ドキュメント豊富。yanzm女神
  • 審査
    • Androidは審査不要
    • Appleの審査は約2週間。最高42日待った。
  • まとめ
    • 画面作成。癖はあるけど大丈夫だった
    • アニメーションはXML書けば大丈夫
    • Java速かった
    • 端末依存ひどかった。
質疑応答
  • Q. Objective-CからJavaに移植するときの正規表現って何パターンぐらい作ったのか？
  • A. 作ったのは20パターンぐらい。YES/NOをtrue/falseに変換とか、-(void)をvoidにするとか

Windows Phone 7 アプリケーション開発概要

高橋忍さま（日本マイクロソフト株式会社）

  • まだ出てないけど・・・
  • ユーザのためのスマートフォン
  • メトロデザインフレームワーク
  • ライブタイル、ハブ
    • ライブタイルにプッシュ通知で情報更新できる。現在の気温とか運行情報とか。
    • パノラマインタフェース。横長の巻物のような画面
  • ハードウェア
    • WVGA800x480、4ポイントマルチタッチ、CPU世代、5つのセンサー、500万画素以上の内蔵カメラなど厳しく規定
    • これらにより、13端末ほどでているが、ほとんど機種依存は心配しなくて良い
  • Windows Phone 7 アプリケーションプラットフォーム
  • Marketplace
    • トライアルができる
    • トライアルだったらという判定がAPIでできる
    • 24000本(6/29現在)
  • APP Hub
    • アプリケーション管理
  • アプリケーションの申請プロセス
    • Appleと同様
    • だいたい2,3日で公開される
    • 開発者登録は$99/1年
      • 品質面のテストもしてくれるので、質のいいテスターを雇ったと思えば安い
    • 70%収入シェア

mixi x Androidの深イイ話

藤崎友樹さま （株式会社ミクシィ）

  • たんぽぽグループ
  • 2010年末 Android向けアプリケーション「mixi」の提供を開始
  • 開発の経緯
    • 連絡先連携のデモが評判に
  • 2010年10月
  • 開発環境
  • Jenkins(旧Hudson)
    • テスト結果をグラフ化してくれる
    • +Android Emulator Plugin
    • +Matrix Build
    • 環境の違いによる問題を発見
  • 開発要員
    • 2010年: 2人
    • 2011年: ほぼ1人
    • mixi API SDK for Androidは別チームで開発
    • 複数人での効率的な開発手法を模索中
  • mixi for Androidの紹介
    • 2010/12/24 1.0リリース
      • 17回アップデート
    • タッチでマイミクとか
    • SoftBank 007SH - 見た目ガラケー。中身はAndroid2.3
      • ソフトキーをエミュレート
    • 横向きをサポート
    • 大事にしたこと
      • 使いやすさ。Androidらしい導線、UI, UX
      • 機能の積極的な活用。ブラウザを超えたところにある体験を追求
  • ネイテイブアプリ開発に求められること
    • スマートフォン向けWeb開発との違い
      • フロントエンド＋ブラウザ自体の開発
      • ネイティブ機能の開発
    • ブラウザ自体自分で作る
      • Web上の画像をダウンロードして表示
      • 6kバイトの画像を3Gでダウンロードすると1〜6秒からかかる
  • Android: 非同期処理は大前提
    • メインスレッドを止めない
  • 非同期処理を簡単にする道具
    • AsyncTask
    • IntentService
  • キャッシュも欲しい
    • 毎回取得は困る
  • 自分で作れ！
  • java.util.concurrent.Executor !
  • 既存ライブラリあった。Droid-Fu: WebImageView
  • キャッシュがあふれる。調べると嘘 Expires
  • ネイティブ機能の活用
  • ネイティブクライアント
    • 見せ方を変えるだけではない
    • サービスの再考も必要（プッシュ）
    • Webの延長とは考えない
  • 現状の「スマートフォン開発」
  • 書ける
    • GUIプログラミング
      • イベントドリブンなコード
    • マルチスレッド
  • 念頭に置く
    • ライフサイクル
    • 空間効率
    • 時間効率（バッテリー）
  • やってみないとわからないことだらけ
    • mixi API SDK for Android
      • ユーザのログイン手続きを省略できる
      • OAuth周りをハンドリングしなくていい（トークンのリフレッシュも自動）
  • まとめ
  • 「スマートフォン」にできること
    • 生活をかる
    • 概念を変える
質疑応答

Q. プッシュサービスでプロフィール画像が変わった際にキャッシュをクリアするという使い方はありか？
A. 今のところは予定はない。
Q. 端末や、対応するバージョンの方針は？
A. 最初はOSのバージョンだけ。2.2以上で作っていたが、当時まだメインが2.1だったため、2.1もサポート対象とした。対応機種はそれほど意識していない。
Q. テストは何機種ぐらい実施したか？
A. マーケットで使われている機種がわかるので、上位機種をいくつか選んでテストしている