Android で 画面の回転や状態の復元まで考えた Fragment の使い方のガイドライン（自分用メモ）

Fragment を使った画面を作る際に、どのように作ればうまい具合に画面の回転や状態の復元を扱えるかという自分用のメモです。

最初にまとめ

• 基本方針として可能な限りすべての管理を当該ActivityのFragmentManagerに任せると楽
• ActivityのフィールドとしてFragmentを保持するのはバッドノウハウな気がする
• onCreateとonDestroyが呼び出されたからといってインスタンスが生成破棄されているとは限らない、これらはFragmentManagerのタイミング次第

最終的に実装したコードは以下のような感じになりました。

• Activity例: MainActivity.java
• Fragment例: NetworkMapFragment.java

今回の発端

ActionBarのタブに2つのFragmentを格納し、片方はListView, もう片方はGoogle MapsのMapViewを突っ込むようなUIを作っていたのですが、Androidは素人なもので普通に作っていると画面回転とタブの切替時にうまいこと状態を復元するのがなかなか手こずってしまいました。というわけで良いプラクティスを考えてみることにしました。

Activity と Fragmentのライフサイクルを復習

Activityは画面回転時に一度破棄されてしまいます。このような場合はActivityのFragmentManagerが現在管理しているFragment（バックスタックに入っているものが含まれるかどうかは未検証）については、Activity破壊時にFragmentManager経由で自動的にonSaveInstanceが呼び出され、Activity復旧時に自動的にonCreateとonCreateView経由で復元が試みられます。

これとは別に、Activityは破棄されないがFragmentは破棄されるケース、例えばActionBarのタブを切り替えたりNavigationDrawerを選択するなどして同一のActivity上で別の画面Fragmentに遷移する場合もあります。

上記いずれの場合も、可能な限りテキストビューの入力内容やリストのスクロール位置、地図のカメラ位置などを保持することをユーザーから期待されるため、状態の復元が必要になります。画面を回したりタブを切り替えたらスクロール位置が先頭に戻ったらユーザーはイライラするでしょう。

状態の保存はBundleとonSaveInstanceStateを使い、復元はonCreateとonCreateViewを使うのが楽です。

解決策

画面回転などActivity自体の破棄と再生成が自動的に行われるケースであればFragmentManager管理下にあるFragmentについて自動的に再生成が試みられるため大して難しくはないと思います。タブを切り替えたりするケースについては、以下のいずれかが良さそうな気がしています。

• 解決策1: すべてのFragmentをFragmentManagerにattachされた状態のままにし、タブが切り替えられたら見せないFragmentはhideする
• 解決策2: 必要に応じてFragmentManagerにattach/detachを行い、そのかわり自分でBundleを作りonSaveInstanceStateを呼び出す

1のメリットはタブ切り替え時に復元がそもそも発生しないため管理が簡単です。確実に動作しますし、再生成も必要ないためパフォーマンスも良いです。デメリットはFragmentおよびFragmentが抱えるView構造をすべて保持し続けるためメモリを大量に消費します。

今回採用した解決策2のメリットはタブ切り替え時にFragmentのView構造をすべて捨てるためメモリが効率的です。MapViewはどうしてもメモリを大量に使うためいくらhide状態とはいえあまり他のタブの後ろにおいておきたくはなかったのでこうしました。デメリットはやはり複雑になります。今回はFragmentのインスタンスフィールドとして一時的にBundleを保持していますが、これは正直なぜFragmentがタブから外れてDetachされてDestroyされてるのにメモリ上に残ってるのかわかりづらい変な挙動になるので、Activity側かまたは何らかのマネージャクラスに任せてしまうべきではないかと思います。・・・ってそれがFragmentManagerなんですけど。もっとうまいやり方で出来そうな気がするんですが・・・

Android で Dagger DI を使いやすくするライブラリを書きました

Daggerというsquare社がオープンソースで提供しているAndroid向けDI (Dependency Injection)フレームワークがあります。

• 公式ページ
• 非公式日本語訳ドキュメント

これを試しに自分のAndroidアプリで使ってみようと思い立ったのですが、幾つか問題が発生しました。

• DI自体の概念が難しい
• そもそもドキュメントを読んでもDaggerの使い方がよくわからない、公式のサンプルを真似してみても正直いまいちわからない
• AndroidでDIを行うとなるとandroid.content.Contextの注入が必須になるのだが、Contextは動的なインスタンスであるためDIでの取り扱いが難しい

そこで四苦八苦しながら動くようになったものをライブラリとして公開し、少しでも簡単にDIのメリットだけを享受できればと思いまして DaggeredAndroid なるものを作ってみました。

使い方とかはREADMEを見てください。全部英語ですがすみません(´･_･`)

AndroidでDIを使う際のメリットは主に以下のとおりです。

• オブジェクトをメンバに接続するだけのコードを無くせるので、コード量が減る。
• シングルトンの取り扱いが楽になる。
• Contextの取り扱いが楽になる。
• Moduleを差し替えればインスタンスが安全に差し替わるので、テスト環境を作ったり、本番と開発環境を分離したりなど、環境の差し替えが楽になる。テスト時のみModuleを上書きすることもできる。

Android の TextView.setText() が遅い場合の原因と対処法

AndroidでTextViewを使っている時に、setText()に数百行単位のテキストを渡すとメインスレッドが1秒弱完全に固まってしまうという現象に見舞われてしまいました。昔の2.3端末ではともかく、手元の最新鋭機Nexus 5 (Android 4.4)でこんなに遅いのでは話になりません。しっかりと原因を調査し対処法を考えることにしました。

まずググってみると出るわ出るわ同じ問題。やはりみんな同じ場所で躓いているようです。

• android textview settext slow
• android textview settext 遅い

しかしながらいまいち具体的な原因がググっても見つかりません。そこでtraceviewを取ってみました。

すると原因が一発でわかりました。android.graphics.Paint.getTextRunAdvances()です。

• ドキュメント
• ソースコード（4.0.1のもの）

Nexus 5では高速化のためJNI経由でネイティブ実装が呼び出されているようですが、それでもまだ間に合わないぐらい遅いようです。それもそのはず、このメソッドは与えられた文字の幅を計算するメソッドです。すなわち数百行のテキストのサイズを計算するため時間がかかっているようです。iOSで例えるならCore TextのCTGryphを計算するようなもの、UILabelのsizeThatFitsを呼び出すようなもので、非常に時間がかかってしまいます。

そこで対処法として、setText()でテキスト全体をセットし直すのではなく、TextViewが裏で保持しているテキストの一部だけを書き換えたり追記したりすることで一度に計算されるテキストのサイズの量を減らして高速化する事を考えました。iOSの場合はUITextViewにはsetText相当のプロパティしか用意されていないので、そのようなことをするのはdelegateを経由してみたりUIKeyInputプロトコルを自前で用意したりなどと困難がつきまとうのですが、Androidの場合は最初からTextViewの裏で保持しているテキストを自在に書きなおすための仕組みが用意されています。

そのためにはまずTextViewの裏で保持されているテキストを「編集モード」にしなければなりません。XMLでandroid:bufferTypeをeditableに指定するか、またはsetText()の第二引数にTextView.BufferType.EDITABLEを指定すると、テキストが編集モードで保持されるようになります。

そうするとgetEditableText()でTextViewが裏側で保持しているテキストが編集可能な状態で取得できます。あとはこのEditableオブジェクトに対して好きなように加工を行うだけです。単にテキストを追加するだけならTextView.append()を実行しても同じ結果が得られます。

こうすると数百行程度であればそれほど遅くなくテキストの追加ができるようになりました。しかしながら1000行を超えてくるとこれでも速度が足りなくなるので、自前でTextViewをサブクラス化して作っていくか、またはListViewにして一度に表示するテキスト量を減らすのが良いと思います。

Objective-🍣

全く新しい、真にユニバーサルな言語へ。

皆さんiOS開発の際にお世話になっているObjective-Cですが、一部の開発者の方々から以下の様な否定的な意見をいただくことがあります。

• とっつきにくい
• 文法がキモい
• @や[]がキモい
• シグネチャが無駄に長い
• Apple製品でしか使えない

確かにObjective-Cは習熟すればこれらの欠点を補って余りある素晴らしい言語ですが、これからの更なるモバイルアプリの世界の拡充のためにはより一層多くの開発者に愛される言語になる必要があると私は考えました。

そこでこの度ご紹介するのがObjective-Cをさらに使いやすく、さらに親しまれるように、全く新しく一から作りなおした新言語

Objective-🍣

です！

Objective-🍣とは

以下の様な特徴を持つ言語です！

• 驚異的に短く、真にユニバーサルな、洗練された文法を持ちます。これまでのプログラミング言語は基本的に英語による記述を強いるものでした。Objective-🍣は真に全人類にとってユニバーサルな絵文字をサポートすることで、この問題をすべて解決しました。Objective-🍣の親しみやすい文法にはすべてのプログラマがシンパシーを感じることができます。
• Objective-Cと100%のランタイム互換性を持ちます。新しいiOSが登場してもその瞬間からあなたはObjective-🍣の圧倒的なパワーを手にすることができます。

さっそくObjective-🍣で書かれたサンプルコードを見てみましょう！拙作確率計算機のコードをObjective-🍣に書き換えてみました！

before

after

なんというこれまでにない全く新しいソースコード！あのキモかった@や[]、長ったらしいメソッド名がその姿を消しています！そのあまりの美しさには全プログラマが歓喜の涙を流すこと間違いありません！

Objective-🍣の導入方法

こちらのobjsushi.hをあなたのプロジェクト上でincludeするだけで使用できます！簡単ですね！

Objective-🍣を使ってみる

それでは早速ビルドしてみましょう！

あれ

えっちょ

＼(^o^)／

ちなみに日本語セレクタ自体はXcode 5以降で普通に使えますよ。

お詫び

こちらの記事にはiOSならびに最新のMacでのみご覧になれる文字（具体的には🍣）を多数含んでおりますことをお詫び申し上げます(´･_･`)

iOSアプリ「確率計算機」をリリースしました

iOSアプリ「確率計算機 (YourLuck)」をリリースしました。
ガチャのドロップ率と試行回数からドロップ期待値を計算するアプリです。
無料です。
https://itunes.apple.com/jp/app/que-lu-ji-suan-ji-gachano/id838156105?mt=8 (JP store)
https://itunes.apple.com/app/id838156105?mt=8 (Universal)

機能

シンプルイズベストなので、以下の２つだけです。

• 確率計算・・・何回ガチャを回したら、最低でも1個はドロップするか、確率を計算します。
• 期待値計算(v1.1.0以降)・・・ガチャを指定された回数だけ回すと、一体何個ぐらいはドロップするのか、ドロップする数を計算します。

使い方

特別なことはなにもないのですが、以下のように操作します。

期待値計算モード(v1.1.0以降)

画面左下のこのアイコンを押すと、期待値計算モードに切り替わります。通常の確率計算モードでは「指定された試行回数分だけガチャを回したら最低でも１個はドロップする確率」を表示しますが、期待値計算モードでは「指定された試行回数分だけガチャを回したらだいたい何個ぐらいドロップするか」を瞬時に計算する事ができます。同じモンスターを複数体狙っている時などに便利です。

FAQ

Q: 用語が難しくてよくわからんのだが

A: めっちゃバッサリ言うと以下のとおりです。

• ドロップ率・・・ガチャのドロップ率です。そのまんまですね。
• 試行回数・・・何回ガチャを回すかです。
• 中央にでっかく出る%・・・指定したドロップ率で、指定した回数だけガチャを回したら、100人いるうちここに出ている数字の人が最低1回は指定したドロップ率の何かが出る、という意味です。30%だったら100人のうち30人が最低1回出ます。運がいい人であれば2回以上出るかもしれません。

Q: 絶対確実って表示されてるのに表示されてる試行回数分だけ回しても出なかった！詐欺だ！！！

A: 申し訳ありません(´･_･`) これには幾つか理由があります。

• 確率は確率なので、例えば98.7%で絶対確実と表示されても1.3%の人、1000人に13人の人は外れてしまいます。これは年末ジャンボ宝くじを1枚だけ買ったら5等3000円が当たった、ぐらいの確率です。すごいのかすごくないのかイマイチわからんですね。
• 試行回数が多いと誤差が出る可能性があります。具体的には試行回数100回以上はより高速な計算を使っているのですが、そのため精度1~2%程度ですが落ちている可能性があります。

Q: 期待値モードで「最低でも」とか「ほとんどの人は」とか出るけどあれ具体的には何%なの？

A: 以下のとおりです。

• 最低でも・・・100人中98人がこの数字以上の個数を獲得できます。
• ほとんどの人は・・・100人中85人がこの数字以上の個数を獲得できます。
• 半数の人は・・・100人中50人がこの数字以上の個数を獲得できます。

Q: ガチャの確率ってどこで調べればええの？

A: 以下の様な方法をオススメします。

• ゲーム内に表示されている場合があります。最近のゲームでは特に確率を表示しているものが増えているので、ガチャの画面で注意して探してみてください。
• グーグルとかヤフーで「ゲーム名 ガチャ 確率」と入力して検索する。
• 知ってそうな人に聞く。ただしゲームを作ってる中の人とか関係者にTwitterで聞いても絶対に教えてくれないのでそういう人以外に聞いてください。

サポートとか

もし何かございましたら、以下の私の連絡先にまでご連絡ください。

mail: akisutesamaあっとまーくgmail.com
twitter: @akisutesama

iOS SDK 7.1 / Xcode 5.1にアップグレードした時に踏んだ地雷まとめ

本日iOS SDK 7.1 / Xcode 5.1にアップグレードを行った際にぶつかった所々の問題とTipsをまとめておきたいと思います。

arm64対応とCocoaPods

Xcode 5.1からデフォルトのビルド設定$(ARCHS_STANDARD_32_BIT)がarm64、要するに64bit対応を含むようになり、arm64 armv7 armv7sの３つのアーキテクチャに対してビルドを行うようになりました。ソースコードからビルドを行っている場合は大抵問題ないと思うのですが、以下の様なケースでarm64対応を切りたい場合があります。

• プロジェクト内にarm64アーキテクチャに対応していないstaticライブラリが含まれている場合。
• 64bitになると危険なバグが発生するおそれがあるコードが含まれている場合、例えばCGFloatやNSIntegerのサイズが変化したり、各種ポインタのサイズが4byteから8byteに増えていたりすると面倒な事が起きるような計算をしている場合。

このような場合、一番簡単な対応策はBuild SettingsのArchitectures(ARCH)をarmv7 armv7sに書き換えることなのですが、こうすると実はCocoaPodsを使用しているプロジェクトの場合リンカエラーが発生してビルドができなくなるという問題があります。
https://github.com/CocoaPods/CocoaPods/issues/1787

そこでBuild SettingsのArchitectures(ARCH)を$(ARCHS_STANDARD_32_BIT)という値に設定すると内部的にarmv7 armv7sとして扱ってくれ、かつCocoaPodsが問題を起こさないようです。この方法をオススメします。この件については以下のページが詳しかったです。
http://stackoverflow.com/questions/8323343/archs-standard-32-bit-vs-armv6-armv7-armv7s-vs-i386

JSONKit対応とCocoaPods

Xcode 5.1からisaポインタへの直接アクセスが完全に禁止になりました。これまでは警告を出さないようにする事が可能でしたが、Xcode 5.1からはそのオプションもなくなり問答無用でビルドエラーにされてしまいます。この問題が最も深刻に出るのはJSONKitライブラリです。
https://github.com/johnezang/JSONKit/issues/79#issuecomment-6322919

対策として一番簡単で確実な方法はJSONKitを使うのを今すぐやめてNSJSONSerializationに乗り換えることです。NSJSONSerializationはiOS 5から使用できるので、あなたが余程のパフォーマンス厨か、またはあなたのプロジェクトが数千万人以上のユーザを抱える巨大プロジェクトで、万一iOS 4系のサポートを止めると何故かあなたの会社ではなく携帯電話会社に「使えないんでなんとかしてください」と苦情が寄せられるような社会的インフラとなったアプリでもなければこの方法を取ることを強くオススメします。

それでも何らかの理由か大人の事情で万一JSONKitをサポートしなければならない場合は、もはやソースコードを書き換えるしか手がありません。幸いにしてXcodeがエラー箇所の修正提案を自動的に全て行ってくれるため、それに従ってコードをホイホイ書き換えれば簡単にビルドが通って使えるようになります。また、すでにそのようなパッチやプルリクエストが山ほどgithub上に用意されています。例えば以下の様なプロジェクトをオススメします。
https://github.com/ignazioc/JSONKit-NoWarning (JSONKit 1.5.2pre, 要するに最新版相当)
http://cocoapods.org/?q=jsonkit-nowarning (CocoaPodsでも使用可能です）

まとめ

CocoaPods爆発しろ

アプリのクラッシュ検知・クラッシュレポート系ライブラリを調べてみた

アプリのクラッシュを検知したり、クラッシュレポートを作成したりするライブラリやサービスを試してみたくなったので色々調べてます。まだ実際に検証できていないので主に自分用メモです。

■なぜクラッシュ検知なのか？

以下の様なメリットが考えられます。

• アプリのクラッシュを100%絶対完全に阻止する方法は無い。どんなアプリでもクラッシュする可能性がある。
• 開発者のメリットとして、クラッシュ時に詳細なクラッシュレポートやクラッシュログを数多く収集することができれば、迅速確実な修正が可能になり、結果としてユーザーのメリットに繋がる。
• ユーザーのメリットとして、クラッシュを検知して即座に編集中データが失われないよう退避したり、次の起動時に同じクラッシュが発生しないようセーフモード起動するなどの措置を開発者が取ることができるかもしれないので、利便性向上につながる。
• アプリを通じたサービス提供者のメリットとして、カスタマーサポートに飛んでくる何の付加価値もない「動きません」「落ちます」といった苦情を具体的に解決しやすくなり、カスタマーサポート品質を高めたり要員コストを削減したりすることが可能になるかもしれない。
• ゲームなどでは、例えばクラッシュが発生したら、次の起動時に1つのバージョンに付き1回だけ自動的に詫び石が配られる仕組みなどを作ることができるかもしれない。ゲームのキャラクターにごめんなさい＞＜と謝らせるとなおグッドかもしれない。

逆にデメリットもあって、例えば

• クラッシュ検知の仕組みが入ることで動作がかえって不安定になるおそれがある。SDK自体が問題を起こすなど。
• クラッシュ検知の際に対応して行う処理がかえって致命的な問題を起こすリスクもある。exception handlerやsignal handlerを捕まえて検知する仕組みのため、それらを利用している他のSDKなどと競合するおそれがある。
• 当然それらの機能の分だけ実装とQAと保守のためのコストが上がる。
• 特にプロプライエタリなサービスのものに関しては会社の方針で導入ができないことがある。

メリデメをよく考えて導入する必要がありそうです。

■サービスとして提供されているもの

以下のページのまとめが詳しいです。
http://www.raywenderlich.com/33669/overview-of-ios-crash-reporting-tools-part-1

Crashlytics
http://try.crashlytics.com

Crittercism
https://www.crittercism.com

Bugsense
https://www.bugsense.com

TestFlight (クラッシュ検知以外の方が有名)
https://www.testflightapp.com

HockeyApp (クラッシュ検知以外の仕組みもある)
http://hockeyapp.net

■オープンソースなもの

KSCrash (iOS)
https://github.com/kstenerud/KSCrash

ACRA (Android)
https://github.com/ACRA/acra

実際に使ってみてまたレポートなど書いてみようと思います。

Google Analytics for iOS SDK バージョン3で自動セッションマネージメントをするライブラリを書きました

Google Analytics for iOS SDK バージョン3にちょっとした機能を追加するライブラリを書いてみましたので公開いたします。

https://github.com/akisute/GAI-AutomaticSessionManagement

iOS 5.0以上で動作します。MITライセンスです。

■これは何？

Google Analytics for iOSは皆さんご存知の通りiOSアプリのセッション解析を行ってくれるSDKです。WebのGoogle Analyticsと同様に、ユーザーさんがどれぐらい、どのように自分のアプリを使ってくれているのかを調査することができます。

そんな便利なGoogle Analyticsなのですが、iOS向けのSDKバージョン3から何故か自動セッションマネージメント機能がなくなってしまいました。すなわちアプリがHomeボタンを押されてバックグラウンドに入ったとしてもセッションが自動的に切れないためセッション数およびセッション時間の正しい計測ができません。iOS SDKバージョン2以前、およびAndroid SDKバージョン3では相変わらず自動セッションマネージメント機能が有効になったままのため、何も考えずにSDKを導入するとAndroidとiOSで大幅に数値が異なるという悲しい事態に陥ります。多分大人の事情なんだろうと思います

ということでこのライブラリを作りました。このライブラリを突っ込めばこれまでどおりアプリがバックグラウンドに入ったら自動的にセッションが切れます。他にも同じように困っている人が居るはずだと思って似たようなことをしている人を探してみたのですが、まったく見つからず困ったので自分で作ることにしました。

インストール方法や使い方などはgithubのリポジトリを見ていただければと思います。

ユビレジを支える技術

年末にユビレジさんのところでちょっと仕事のお手伝いをさせていただいたので、その時の内容をご紹介させていただきます。

■ユビレジって何？

iPadをキャッシュレジスタに変えてしまうサービスです。会計からレシートの印刷までやってくれます。最近飲食店などでレジがなくiPadだけが置いてあるお店などを散見するかと思いますが、アレがそうです。一般的なキャッシュレジスタ+店舗システムよりもはるかに安価で導入でき、しかも使いやすいというのがウリです。

開発者的に言うと、Scalaモヒカンの@kmizuさんやiOSモヒカンの@k_katsumiさんなどが在籍されていまして、エンジニアのレベルが高いです。

■開発スタイル

少人数のため、厳密なウォーターフォール管理やアジャイル/スクラムなどは無く、チケット/Issueベースの開発になっています。githubをフル活用します。すべてPull Request(以下PR)ベースで開発され、すべてのPRについてレビュー/CI完備です。forkして修正してPRを投げると自動的にJenkinsがテストを回し、githubのPRページに問題なし/問題ありのコメントを投げるところまで自動化されています。正直半端ないです。

完全に裁量労働になっているため、エンジニア勢は猛烈に朝が遅いです。全員が揃うのが普通に昼過ぎだったりします。朝が弱い人でも安心です。

社内コミュニケーションのためにHipChatを使用しています。使用したのは初めてだったのですが、SkypeやIRCよりも以下の様な点で非常に使いやすく魅力的でした。もし機会があれば私もHipChatを導入したいです。

• IRCと異なり、自分がいない間の過去ログがきちんと残る。
• Skypeと異なり、APIが公開されているためbotが作りやすい。Jenkinsやgithubとの連携もらくらく。
• SkypeやIRCと異なり、モバイルアプリの出来が非常に良い。
• ただし、SkypeやIRCに比べて外部のお客さんを誘うときにちょっと抵抗があるかも。

■サーバサイド

Railsです。私が余りRailsに詳しくないのと殆ど触ってないのでどうすごいのかよくわからなかったのですが、確かRails 3.X系を使用していて、ちょうど4にアップグレードする作業を進めていたかと思います。コードは全PRがレビューされているだけあってものすごい綺麗です。

先述の通りCucumberテスト完備です。
ドキュメントもAPIを外部公開しているので (http://ubiregiinc.github.io/ubiregi-api/) ある程度揃っていますが、完備と言うまでではありません。必要に応じてコードを読めスタイルです。私も結構読みました。というわけでクライアントサイドのエンジニアの方でもある程度以上サーバサイドを理解している必要があります。

フロントエンドまわりの技術については私が係る箇所がなかったためよくわかりませんでした。すみません(´･_･`)

インフラはHerokuを使用してます。デプロイもgithubから一発という仕組みになっています。

■クライアントサイド

ユビレジは現在iPadでのみサービスを展開されているので必然的にクライアントはiOSでiPad向けのみとなっています。ここだけ聞くとiOS/Android両対応だのハンドセット/タブレット両対応だのが必要ないため簡単そうに思えますが、そんなことは全くありません。お客さんがお金を払ってサービスを導入するB2Bアプリで、かつレジという会計を扱うアプリであるため並大抵の無料B2Cアプリとは比較にならないレベルで不具合が許されません。さらに注文を取るハンディ機などの外部アプリ連携、レシートプリンタなどの外部ハードウェア連携、サーバとの会計情報同期、iOS 5&初代iPad対応などが要求され、会計回数も大規模なお店だとそれなりの件数に達するためCore Dataもパフォーマンス最適化が必要になるなど、実はそれなりに難易度が高いです。iOS 7にiPadでのみ発生する問題が多いのも逆風ですね。

まずModel層について、データストアはCore Data+自作の薄いラッパです。MagicalRecordはちょっと複雑で大規模すぎるため導入していないとのことです。通信周りは普通にAFNetworking (1.X系)を使用。2.X系は今後iOS 5を切ってから導入する流れになるのではないかなとのことです。

View層についてはほぼすべてStoryboard/xib化されていますし、Segueもバリバリ使います。シンプルなUIが多いため派手派手なUIライブラリはほとんど使用していませんが、広い画面を有効に使う必要があるiPadアプリならではとして、Container View Controllerの概念をよく使うことになっています。

ちょっと変わっているのが、ビジネス用途で使うためSingle App Modeを有効にしてユーザーがホームボタンを押してもユビレジアプリから外に出られないように設定するのですが、この設定を有効にした時にモーダルなView Controllerを出すと問題が生じる場合があるのでワークアラウンドを導入していたりなどします。こういう問題は普通のB2Cアプリを作っているとほぼ気づかないので大変です。

それからユビレジ特有の問題としてハードウェア連携周りが挙げられます。このへんはは完全に自作です。Raspberry Piを使った自社ハードウェアとWiFi経由でデータをやりとりする仕組みになっています。普通のプロダクトではこういう開発が出来る場所は殆どないので貴重な体験になりました。

サーバサイドにもありますが、クライアントサイドにもfrankを利用した受け入れテストがある程度用意されていて、こちらもPR時に自動的に走るという仕組みになっています。ただしちょうど私が参加したのが次のアプリの大改修に備えていた時期だったため、テストの整備が追いついていない感じでした。

■まとめ

非常に短い期間だったのですが、エンジニアが一度は夢見る理想的な環境みたいなのをある程度実現されているのが素晴らしいと思いました。もちろん完璧というわけではなく今後も維持改善が必要なところがありますが、このような理想環境を一度体験してみたいというエンジニアの方には非常に魅力的な場所だと思います。

現在ユビレジさんはエンジニアの方を募集されているそうなので、興味を持たれた方は一度オフィスまで遊びに行ってみてはいかがでしょうか？

iOS 開発者が Android 開発者になるために用意したものまとめ

これまでiOS 2.0の登場から今日に至るまでiOS開発者として仕事してきたわけですが、今年はいよいよ本格的に仕事でAndroidの開発を行っていきたいと思っています。そこで正月休みを使って準備したAndroidの開発環境や勉強用の資料をまとめてみました。同じく今年からAndroidやってみよう！という方の助けになればと思います。

■前提条件

まず最初に前提条件として筆者のスペックをまとめてみました。

• iOS開発歴4年ぐらい (iOS 2~7)
• Android開発歴半年ぐらい (Android 1.5~2.1の間、仕事では殆ど使ってない）
• Java歴は3年ぐらい (大学時代と最初の会社でSIerをやっていた間、SJC-P所持だがJava 7とか8とかはわからない)

iOSの開発歴が長く、モバイル開発で必要な要素や落とし穴などをひと通り踏んでいること、少しですがAndroid開発歴があること、Javaについてもひと通りの文法がわかるのを前提としています。従いまして完全にモバイル開発もJavaも初めてという方にはおそらく今回の資料は少しハードルが高過ぎると思います。ご了承ください。

特にJavaについてはどの資料も何の説明もなしに匿名クラスや内部クラスをふんだんに利用するので、最低限Javaの事前勉強をしておいたほうが良いかと思います。

■開発環境の用意

今回はMac上にAndroid Studioをインストールする方針でいきます。
http://developer.android.com/sdk/installing/studio.html
Eclipse+ADTな現場もまだまだ多いかと思いますが、今後は間違いなくAndroid Studioが主流になってくると思われるからです。あとは個人的にEclipseが嫌いというのもあります(´･_･`)

インストール時の注意点としては初回起動時に少々時間がかかるのと、アップデートが必要になる程度です。0.3.2から0.4にアップデートする前にプロジェクトを作ってしまうとアップデート後にビルドが通らなくなってしまったので、最初にまずアップデートすることをオススメします。

Android StudioではEclipse+ADTの環境や、旧来のJava開発とは異なりGradleというビルドツールが何をするにも主体となります。そのためGradleについてある程度の知識が必要となります。幸いにしてWeb上に良い記事がありましたのでこちらを参考に勉強しました。

• Android Studio最速入門～効率的にコーディングするための使い方: http://gihyo.jp/dev/serial/01/android_studio

■シミュレータの用意(Genymotion)

ADTには最初からAndroidエミュレータが付属されていますが、これは残念ながらiOSのシミュレータとは異なり、再現度も悪く異常に動作が遅いため使い物になるシロモノではありません。Android SDK 1.6のころから現在4.4に至るまで全く改善の気配が無いため、おそらく未来永劫改善は望まれないと思われます。その代わりと言ってはなんですがGenymotionというサードパーティ製の非常に使い勝手の良いAndroidシミュレータがありますのでこちらをインストールします。
http://www.genymotion.com

アカウントを作成してFree版をダウンロード・インストールします。Free版と有料版の違いは加速度センサーのエミュレーションや、スクリーンキャスト機能の有無程度なので、Free版でまったく問題ありません。Genymotionの起動にはOracle VirtualBoxが必要になるため、https://www.virtualbox.orgからダウンロードしてインストールしておきます。

最後にAndroid StudioのGenymotionプラグインをPreferences -> Plugins -> Brows RepositoryからGenymotionで検索してインストールして完了です。

■開発機の用意

Genymotionだけでもかなりの開発はできますが、やはりモバイル開発では実機上での確認が必須です。特にAndroidはiOSと異なり端末種類が多い上に端末差異が激しいので、出来る限り多くの実機を用意しておくことが望ましいです。またそれだけではなく、実際に日常生活でAndroidを触り多数のアプリに触れておくことで、Android上でのアプリの作法や最近の流行、iOSとの違いなどを肌で学ぶことができます。

開発用の端末は白ロム（中古品）販売店で安く買うのが良いと思います。通販でも購入可能です。
http://masterka.seesaa.net/article/252845343.html

ですが今回は折角なので最新機種Nexus 5をGoogleから直接購入することにしました。

https://play.google.com/store/devices/details?id=nexus_5_black_16gb

こちらから直接SIMロックフリーのNexus 5を通販することができます。私の場合は1/1に16GB Whiteを注文して1/5に届きました。正月でなければもうちょっと早かったかもしれません。

届いたら開封して起動すればそのまますぐに使えます。iPhoneと異なりSIMがアクティベーションに必要だとか、iTunesと接続を要求するとかそういう内容は一切ありませんので、SIMを購入しなくても開発機として使用可能なのがいい感じです。ただし最初の言語選択とWiFi接続時のエラーメッセージが非常に不親切なのでちょっとハマりました。

Nexus 5を使ってみての感想ですが、正直信じられないぐらい良いです。Android 2.x時代のダメダメ端末ばかり触っていたのでギャップが大きいというのも有りますが、電池の消耗がiPhoneと比べると激しい以外は欠点らしい欠点が見当たりませんし、余計なものが一切入っていないのでAndroidの長所を存分に味わう事ができます。iOS開発者の人でAndroid開発に手を出したい人にはまずオススメしたいです。

そのままSIMなしで開発機として使っても良かったのですが、3G回線でのテストも行いたかったので、今回はさらにMVMO業者のSIMパッケージを購入しました。初期費用3000円、月額1000円以下、二年縛り無しでSIMが手に入るため非常に安価で便利です。

• 楽天ブロードバンド: http://broadband.rakuten.co.jp/lte/cpn-entry.html
• 日本通信(b-mobile): http://www.bmobile.ne.jp/zsim/
• u-mobile: http://mobile.unext.co.jp/umobiled/
• OCN モバイル One: http://service.ocn.ne.jp/mobile/one/

などがありますが、今回はOCN モバイル Oneを選択しました。

■Hello World!

さて開発環境も開発機も手に入ったので、あとはコードを書くだけです。最初はまず以下のWebサイトを参考資料に簡単なTwitterクライアントアプリを書いてみました。

• Android Studio最速入門～効率的にコーディングするための使い方: http://gihyo.jp/dev/serial/01/android_studio
• Android再入門 - Twitterクライアントを作ってみよう: http://qiita.com/gabu/items/70689560618f8e67e726

やはりモバイルアプリ開発の手習いはTwitterクライアントアプリからスタートするのが良いと思います。データのリスト表示、非同期通信、画像の非同期読み込みとUIへの反映、一覧と詳細表示など、モバイルアプリに必要な要素がバランスよく学べます。

■購入した書籍

Webの資料も悪くないですが、やはり最初は書籍を読みながら進めるのが情報がまとまっていて近道だと思います。というわけで以下の書籍を購入しました。すべて達人出版会の電子書籍で手に入るため便利です。

• Google Androidプログラミング入門改訂2版: http://tatsu-zine.com/books/androidprogramming2ed
• 入門に必要な内容はひと通り網羅されていると思います。ただし入門書を名乗っていますが、途中からサンプルプログラムが手元にあること前提の説明になったり、コードの一部が説明されていなかったり、Javaがわかること前提のコードが登場したりなど難易度が急激に跳ね上がるので、本当の本当に入門な人には向かないと思います。
• Effective Android: http://tatsu-zine.com/books/effective-android
• Effective系は外れないと思って購入しました。Effective Javaも名著でしたしね。
• Android UI Cookbook for 4.0　ICS（Ice Cream Sandwich）アプリ開発術: http://tatsu-zine.com/books/androiduicookbook40
• 4.0でUI周りは大きく変わっているので、2.3との互換性維持のノウハウも含めて欲しかったので購入しました。iOSの手習いの時もObjective-Cの本とUIKitの本を選びましたが、最初は言語の本とUIフレームワークの本を選ぶのが良いと思います。
• Android Security 安全なアプリケーションを作成するために: http://tatsu-zine.com/books/androidsec
• 仕事でAndroidを使うつもりなのでセキュリティ周りの情報は必須です。セキュリティに関してはiOSよりも更に環境がシビアですので、念には念を入れておきたいです。

LLDB のカスタムコマンドを Python で書いてみようとして大失敗した話

なんかうまくいかないんです(´･_･`)

Xcode 5のデバッガとして用意されているLLDBですが、実は設定ファイルを書くことで自由にカスタマイズすることが可能になっています。またPythonを使ってより深いLLDB自体の挙動をカスタマイズすることも出来るらしいと最近教えてもらいました。

参考: http://qiita.com/dealforest/items/e3a5284badd17733ccc1

さてこちらの参考記事に、

例えば動的に生成した UIImage をファイルに出力するコマンドとかは便利そうですね。

というなかなか夢のある発言があるのですが、残念ながらこちらの記事の中では実際のコードがありません。ということでLLDBの設定の練習がてら、私の方で早速デバッガからUIImageをファイルに書き出すコマンドの作成にチャレンジしてみました。

■実装方針

LLDBを操作するために使用できるPythonモジュールについては、LLDBの公式ページに詳しいドキュメントが揃っています。
http://lldb.llvm.org/python-reference.html （簡単な解説とチュートリアル）
http://lldb.llvm.org/python_reference/ （APIドキュメント）

また既に何人かの方が似たようなことをされた形跡があります。
http://stackoverflow.com/questions/12668815/lldb-python-access-of-ios-variables
http://stackoverflow.com/questions/18468126/pointer-arithmetic-in-lldb-python-scripts
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2011-January/000321.html

これを元にして、以下の様な戦略でいってみます。

1. 引数のUIImageをUIImagePNGRepresentation関数を通してNSDataにする。
• ただのUIImageをそのままファイルに書き出しても使えませんので、まず一旦JPEGなりPNGなりに変換する必要があります。ここではObjective-C側に変換してもらうことにします。
2. NSData bytesを取得する。
• expr (const void *)[(NSData *)UIImagePNGRepresentation(image) bytes]とか叩けば一発なはずなので、その方針で行きます。
3. ファイルに書き出す。
• exprの結果をraw dataで取り出せれば、あとは普通にファイルに書き出しておしまいです。簡単そうですね。

ということで出来たコードはこちら。

■しかし

やはりというか落とし穴がorz
冒頭の画像にもあるのですが、Python経由でexprした実行結果を取得する手段がどうにも見つかりません。SBFrame.EvaluateExpression(expr)の結果がSBValueなんだからそっからデータが引けるだろうと思っていたのですが、何を実行しても壊れたSBValueしか返却されないためどうにもうまくいきません。SBDebuggerやSBCommandInterpreter経由でHandleCommand(expr, result)する手も考えたのですが、今度はresultから値を取る手段がない（resultをコンソールではなくファイルにリダイレクトする手段しか無い）ためやはり断念です・・・

うーん。もう少し頑張ったらうまくいきそうな気もするのですが。残念です＞＜

Spark Inspectorを一ヶ月ほど使ってみた感想

ちょっと仕事で複雑なiOSの画面を作りたいということになり、デバッグに難儀していた所、Spark InspectorというiOS向けのランタイムインスペクタツールが発売されていましたので、やや乗り遅れた感がありますが私も早速試してみました。

Spark Inspectorを使うと、

• リアルタイムにViewの構造を視覚的に確認し、直接プロパティの値を編集してアプリに反映させることができる
• Webエンジニアの人にわかりやすくたとえるならば、ChromeやFirefoxなどに付いているインスペクタをiOS上で使えるようなものです
• その他、アプリ内を飛び交っているNSNotificationの状態を監視することができる（らしい）

既に試された方のブログ記事で導入方法など詳しく公開されていますので、まずはそちらを見ていただくのが良いかと思います。

Spark Inspectorを導入してみた
http://inon29.hateblo.jp/entry/2013/12/06/002948
[Xcode][tool] ランタイムデバッガーSpark Inspectorが便利！
http://blog.natsuapps.com/2013/05/spark-inspector.html

ということで、私は一ヶ月ほど実際に仕事で使ってみて良かった点と悪かった点をまとめてみようかと思います。興味ある方の参考になればと思います。

■良かった点

導入が非常に楽です。ブログ記事で既に紹介されている方法は自分のプロジェクトに必要なフレームワークを組み込んで設定する方法ですが、最近のSpark Inspectorはこの方法を用いなくてもXcodeから一発で必要なフレームワークを動的に読み込んでインスペクタを起動してくれます。

Viewの階層構造をリアルタイムに監視できるのはやはり非常に有効です。これまではUIViewの- (void)recursiveDescriptionプライベートメソッドを呼び出したりして状態を確認したりしていたのですが、実行中の画面に対して動的に状態を見て、動的にプロパティの値を書き換えて見た目を調整することができるのは劇的に作業効率を改善してくれます。これってWebプログラミングだと実に当たり前のことなんですが、iOSプログラミングだと余りまだ普及してない考えだなと思います。

動作はやや重いですが、2012年モデルのMacBook Airでも問題なく動作させることが出来ました。もちろんiPadのアプリでもちゃんと動作します。

■イマイチだった点

楽に導入できる、自分のプロジェクトに必要なフレームワークを組み込まないやり方では、いくつか制限があります。

• 自分のプロジェクトに必要なフレームワークを組み込まないと、実機でSpark Inspectorを動作させることが出来ない。
• 動作が非常に安定しない。プロジェクトによってはかなりの確率で起動に失敗したりする。今回私が仕事で使っていたプロジェクトでは8割ぐらいの確率で起動に失敗していた。

それから地味に痛いのが、表示と編集が可能なのが現状CALayerとUIViewのプロパティのみに制限されているところです。Auto Layoutには対応していませんし、例えばUIScrollViewのcontentInsetを動的に調整してみたりですとかUIButtonの横幅とタイトルを動的に調整してみたりですとかそういう小技が出来ないため、なんというかかなり中途半端感を受けます。結局私の場合は表示されているはずなのに表示されていないViewの構造を調べる程度の用途にとどまりました。