2014年6月9日月曜日

既存の Objective-C のメソッド引数の Swift 上での扱われ方を調べてみた

前置き

こちらの記事には2014/06/09現在、公式にはリリースされていないiOS8プレリリースドキュメントへのリンクが含まれます。iOS8にて新しく追加された内容には一切触れておらずAppleとのNDA規約にも違反するものではないという認識ですが、場合により予告なく削除する可能性があります。予めご了承ください。

本題

iOS8プレリリースドキュメントを眺めていて気になったのですが、ほとんどのCocoaのメソッドの引数に!がついています。例えばNSKeyValueObservingプロトコルのaddObserver:forKeyPath:options:context:メソッドのシグネチャは以下のようになっています。

func addObserver(_ anObserverNSObject!,
      forKeyPath keyPathString!,
         options optionsNSKeyValueObservingOptions,
         context contextCMutableVoidPointer)

第1引数と第2引数に!がついているのがわかると思います。
更にもうひとつ気になったのが、このメソッドの第3・第4引数です。これらは元々0やNULLポインタを渡すことができる引数だったのですが、見ての通り引数が?で宣言されておらず、そのままnilを渡してしまうとエラーになってしまうように見えます。

直感的に考えると、

  • !がついている引数は呼び出し時に強制的にunwrapされるので、nilを渡してはいけない、必須引数なのではないか?
  • !がついていない第3第4引数はnilが渡せないのではないか?

という風に思うのですが、実際には

  • !がついている引数にnilを渡すことができる。さらにnilを渡してもランタイムでクラッシュしない。
    • 今回の例のaddObserver:forKeyPath:の場合はクラッシュしますが、これは元々のAPIがそうだったからで、例えば他のCocoaのAPIで!がついているものでnilを渡しても問題ないものが多数存在します。
  • !がついていないNSKeyValueObservingOptions, CMutableVoidPointerにnilを渡してもコンパイルエラーにすらならず、何の問題もなくそのまま動作する。

このような私の理解とは正反対の挙動をします。大変気になったので調べてみることにしました。

!がついている引数の謎

これについてはそもそも私のSwiftに対する理解が完全に間違っていました。正しい理解は以下のとおりです。

  • 無印型 - nilを渡すことができない。nilになる瞬間が一瞬もない。これこそがnilを渡せない必須引数である。
  • ?型 - Optional型であり、nilを扱うことができる。これについては問題ない。
  • !型 - ImplicitlyUnwrappedOptionalという特殊なOptional型であり、Optional型なのでnilを扱うことができる。すなわち!が付いている引数については任意引数でありnilを渡すことができる。
    • !も?も演算子でも命令でもなく型であり、!や?をつけることで対象を型に包んでいる、と考えれば良いと思います。
    • !と?の違いはメンバにアクセスした際に暗黙的かつ強制的に元の型にアンラップされるか、そのままOptionalとして扱われるかの違いだけです。

ではなぜCocoaのAPIは引数で?ではなく!を使ってnilを受け取れるようにしているのでしょうか?これは引数を受け取った後に、その引数にアクセスした場合の挙動がおそらく影響しているのではないかと思われます。以下の例を見てください。

こちらのコードですが、safeSwim()メソッドが旧Objective-Cと完全に同じ挙動を示します。これは以下の様な理由によるものです。

  • self.name(!型)が?型によってラップされる。
  • self.name?の.descriptionにアクセスする。このとき?型によってラップされているので、self.nameがnilであれば何も起こらず、self.nameがnilでなければまず?型からアンラップされ、次に強制的に!型からアンラップされ、その結果通常通りdescriptionが呼び出される。
  • 通常だと?型の返り値は?型にラップされてしまうが、self.nameが!型なので強制的にアンラップされ?型ではなく素のString型を返すことができる
    • ここだけよく理解できてないです・・・

間違っていたらすみません(´・_・`)

とにかくこれこそが旧Objective-CのAPIについて!で型が表現されている理由ではないかと考えています。

!がついていないのにnilが渡せる引数の謎

こちらの謎はカラクリがわかってしまえば簡単です。前回の記事をご覧になった方はお気づきになったかもしれませんが、これらの型はAppleが__convertion()メソッドをNilTypeに対して追加しているため、nilを問題なく扱うことができます。

まとめ


  • !が付いている引数は?と同様にnilを渡しても良い引数である。nilを渡せない必須型は何もついていない引数のみである。
  • !はImplicitlyUnwrappedOptionalという特殊なOptional型であり、アクセス時にOptionalではなく強制的に元の型を返す点がOptionalと異なる、と考えれば理解しやすい。
  • 変数をすべて!で定義し、メンバアクセス時に常に?をつけるようにすると、どの変数にもnilを渡すことができ、実行時にnilがあればそこで実行がスキップされ、さらに返り値もOptionalではない通常の型にできるため、旧Objective-Cとほぼ同じ挙動になる。
    • ただしSwiftで新しく用意されているAPIを見る限りnilを扱う必要がある箇所については可能な限り!ではなく?を引数や返り値に使っているように見えるため、新しくSwiftで書く箇所については!を乱用するべきではないと思われる。
  • Cocoaの用意している型のうち、元々nilやNULLや0を渡すことができた型については、NilTypeに__conversion()メソッドが追加されているので、そのままnilを渡すことができる。

Swift で __conversion メソッドを使ってカスタムの型変換を定義する方法

2014/10/21追記:
Xcode 6.0 beta 6以降、__conversion()を使った暗黙的なas演算子を用いた型変換はサポートされていません。Xcode 6.1(Swift 1.1)現在、暗黙的な型変換を行う手段はないため、型変換を行いたい場合はイニシャライザを定義する方法を取るのが通例として良いと思います。

class 変換対象の型 {
  init(_ obj: 変換元の型:) -> 変換対象の型 {
    return 適当に変換対象の型を返す
  }
}



Swiftではas演算子を使ったり、型の定義されている変数・定数へ代入したり、メソッド呼び出しの引数にオブジェクトを渡す際に型変換が行われますが、デフォルトでは対応していない型変換があったりします。例えばStringはasを使ってもIntに変換することはできません。

また、SwiftではnilはNilTypeという型のシングルトンとして実装されており、nilを渡すとNilTypeから当該型への型変換が行われるようです。?(Optional)型や!(ImplicitlyUnwrappedOptional)型はNilTypeからの型変換に対応しているからnilが代入でき、それ以外の型は対応していないためコンパイルエラーになるというのがカラクリのようです。

この型変換ですが、__conversion()というメソッドを変換元の型に実装することで、任意の型変換を自分で実装する事ができます。以下のようになります。
class 変換元の型 {
  //@conversion属性は付けても付けなくても大丈夫みたいですが、一応つけます
  @conversion func __conversion() -> 変換対象の型 {
    return 適当に変換対象の型を返す
  }
}
以下にNilTypeを使ったnilからカスタムクラスへの型変換サンプルを示します。こうすればnilを引数にとってもエラーになりません。

ご覧のとおり、extensionとの組み合わせで既存のクラスも含むどのような型からどのような型への型変換にも対応可能になりますので色々はかどります。ぜひご活用ください。

2014年6月6日金曜日

Swift の enum型を for-in でイテレーションする方法

例えばJavaのEnum型などはそのまま以下のようにイテレーションすることが可能なのですが、

なぜかSwiftのenum型はそのままではイテレーションすることができません。対策としてGeneratorという仕組みが標準ライブラリに用意されてますので、それを使ってenumをイテレーションできるようにします。

具体的には、Generatorを継承したクラスを作成して next() -> Element? を実装してください。ElementはAnyObjectのtypealiasなので実際には好きな型を返していただければOKです。あとはSequenceOf<T>型でGeneratorをラップしてあげればOKです。next()メソッドがnilを返すまでSequenceOf<T>はイテレーションを続けてくれます。

以下にサンプルコードを示します。

Generator内部でyieldが使えれば便利なんですが、おそらくyield構文は無さそうです。Enum型を一覧したい場合以外にもGeneratorは便利に使えますのでぜひお試しください。

Swift を使ってみてがっかりした点まとめ



数日間iOS8/Xcode6/Swiftな環境で色々試してみて、Swiftを使っていて思ったよりがっかりした点が多かったのでちょっとまとめてみようと思います。

動的な処理がSwiftだけでは一切できない

[NSObject performSelector:]の類と、NSInvocationがSwiftからは一切呼び出せません。使おうとすると怒られます。objc/runtime.hは試していませんが、同様に直接Swift経由では呼び出せず間にObjective-Cをかます必要があるのではないかと思われます。

@optionalなprotocolが限定的にしか使用できない

具体的には@objc属性を付けないと使えません。しかしながらこのような後方互換性のためだけに存在する属性をいつまでもAppleがサポートするかは疑問が残るというのと、もう一つ以下の様な問題があります。

@objc属性のついたSwiftの型はただのObjective-Cクラスになる


こういう問題があるのであまり使いたいとは思えません。ちなみになのですがCocoaのクラスはほぼすべて@objc属性が付いているため、それを継承して使うことになるアプリでは事実上Swiftの本来の能力を出せないのではないかと思っていますが、実際のところはわかっていません・・・

メモリ管理が相変わらず必要

Swiftのメモリ管理はGCではなくARCでありただの参照カウント方式にすぎないため、Swiftでも循環参照が発生しないようにプログラマが明示的に参照の種類を指定しなければなりません。その上Objective-Cでも存在したstrong, weakに加えunownedという新しい種類のメモリ管理が追加されています。これはweakは参照が消滅するとnilにするという挙動であるためOptional型を使わなければならないのに対し、unownedは参照が消滅してもnilにならない代わりに通常の型がそのまま使えるというもののようです。

closureでselfをキャプチャするときの循環参照対策が相変わらず必要

いちばんがっかりしたのがこれです。Swiftはdelegateよりもclosureを使ったcallbackのほうが言語構造上向いているためclosureを大量に使うことになると思うのですが、このときselfがclosureを強参照し、closureがselfをキャプチャするようなコードを書いてしまうと、循環参照になるためメモリが開放されなくなるという問題がObjective-Cから引き続き発生します。対策としてclosure capture listと呼ばれる新たな構文が追加されています。closureの先頭、引数宣言の前に[unowned self]のような構文を追加することで、selfをunownedとしてキャプチャすることができます。

以下に使用前・使用後の例を示します。

Objective-CのweakSelfよりはマシに思えますが、とはいえこの辺りはコンパイラが自動的に対応してほしいところです(´・_・`)

2014年5月26日月曜日

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

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

最初にまとめ

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

今回の発端

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なんですけど。もっとうまいやり方で出来そうな気がするんですが・・・


2014年4月30日水曜日

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を上書きすることもできる。

2014年4月20日日曜日

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

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

まずググってみると出るわ出るわ同じ問題。やはりみんな同じ場所で躓いているようです。
しかしながらいまいち具体的な原因がググっても見つかりません。そこでtraceviewを取ってみました。


すると原因が一発でわかりました。android.graphics.Paint.getTextRunAdvances()です。
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にして一度に表示するテキスト量を減らすのが良いと思います。


2014年4月1日火曜日

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でのみご覧になれる文字(具体的には🍣)を多数含んでおりますことをお詫び申し上げます(´・_・`)

2014年3月20日木曜日

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)

機能

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

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


使い方

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



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

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


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

2014年3月12日水曜日

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の3つのアーキテクチャに対してビルドを行うようになりました。ソースコードからビルドを行っている場合は大抵問題ないと思うのですが、以下の様なケースで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爆発しろ

2014年2月25日火曜日

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

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

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

以下の様なメリットが考えられます。
  • アプリのクラッシュを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

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

2014年2月24日月曜日

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のリポジトリを見ていただければと思います。

2014年1月18日土曜日

ユビレジを支える技術


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

■ユビレジって何?

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時に自動的に走るという仕組みになっています。ただしちょうど私が参加したのが次のアプリの大改修に備えていた時期だったため、テストの整備が追いついていない感じでした。

■まとめ

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

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

2014年1月12日日曜日

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上に良い記事がありましたのでこちらを参考に勉強しました。

■シミュレータの用意(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から直接購入することにしました。
こちらから直接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が手に入るため非常に安価で便利です。
などがありますが、今回はOCN モバイル Oneを選択しました。

■Hello World!

さて開発環境も開発機も手に入ったので、あとはコードを書くだけです。最初はまず以下のWebサイトを参考資料に簡単なTwitterクライアントアプリを書いてみました。
やはりモバイルアプリ開発の手習いは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よりも更に環境がシビアですので、念には念を入れておきたいです。


2014年1月7日火曜日

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をコンソールではなくファイルにリダイレクトする手段しか無い)ためやはり断念です・・・

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


2014年1月6日月曜日

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の構造を調べる程度の用途にとどまりました。

2013年12月14日土曜日

Webページのサムネイル画像を生成して表示する AKWebRenderer を公開してみました


Social.frameworkSLComposeViewControllerに貼り付けたURLのWebページのサムネイル画像を表示する機能があるのですが、それを真似する感じのライブラリです。TwitterのTLをダラダラ見ていて画像とURLをダラダラ流すだけのTwitterクライアントを作ってみたら面白くないかなと思ってやってみました。

リポジトリはこちらになります。
https://github.com/akisute/AKWebRenderer

使い方やライセンスなど全てREADMEに記載しておきましたのでそちらをご覧ください。

注意点として、遅い・重い・不安定の三重苦です>< 実用で似たようなことをしたいのであればサーバを自前で用意して事前に画像をレンダリングさせるほうが良いと思いますが、SLComposeViewControllerと同じような動作がさせたいだけならばそこそこ使えるんじゃないのかと思っています。一応キャッシュとかもついてます。

2013年12月9日月曜日

Xcode 5 で、発生した NSException の詳細が表示されない時の対処法

原因がよくわからないのですが、iOSアプリをデバッグ中にNSExceptionが発生してアプリがクラッシュしてしまった時、その詳細がXcodeのコンソール上に表示されなくなってしまいました。普通はデフォルトのexception handlerがうまい具合にやってくれるのですが、何らかの理由でそれがうまくいかない場合があるようです。自分でスレッド立ててるとかでしょうか・・・


上図のように、例外が発生している箇所にブレークポイントをおいてどこで発生したのかを知ることはできるのですが、実際には発生箇所がわかっても発生原因がさっぱりわからないというケースもあります。例えばiOSのシステムが例外を発生させたときや、コードが公開されていないライブラリが例外を発生させたときなどです。

さて、このようなときは発生しているNSExceptionのdescriptionを直接読めれば便利そうです。というわけで調べてみました。

http://stackoverflow.com/questions/384775/how-do-i-find-out-what-exception-was-thrown-in-the-xcode-debugger-for-iphone
After you stop in the debugger, you can enter po $eax (simulator) or po $r0 (device) to see the exception. This is because the exception object is passed as the first argument to objc_exception_throw, which is kept in register r0 or EAX.
こちらの投稿のコメントにちょっとだけ書かれている方法がどうやら一番良さそうです。というわけで試してみました。
  1. まずはプロジェクトのAll Exception Breakpointを有効にします。
  2. アプリをデバッグして、例外が発生する箇所を実行します。
  3. 例外発生箇所でブレークポイントが発動したら、左のスタックトレースナビゲーションから、スタックトレースの一番上(objc_exception_throw)を選択します。
  4. コンソール上で以下のコマンドを実行します。
    • シミュレータなら、po $eax
    • 実機上なら、po $r0
うまくいきました!これで万一発生した例外の原因がよくわからない場合でも安心です。

余談ですが、eaxレジスタ/r0レジスタは関数の引数だかなんだかに相当するレジスタみたいなので、よくわからないコードで詰まっている場合はここを見れば他のケースでも解決できるかもしれません。

2013年11月27日水曜日

Mac の Skype のデータベースを最適化してパフォーマンスを向上させる小技



もりよしさんにSkypeで教えてもらったのですが、Mac版のSkypeクライアントってデータベースにsqlite3を使用しているんですね。少なくとも3年前には既に知られているネタみたいなのですが、ぜんぜん知りませんでした。
http://d.hatena.ne.jp/shishimaruby/20101214/1292288183

というわけで、Mac版のSkypeをお使いの方は
~/Library/Application Support/Skype/(自分のアカウント名)/
以下にsqlite3のデータベースファイルがあるので、Skypeを一度終了した状態で
sqlite3 main.db VACUUM
sqlite3 main.db REINDEX
という感じでVACUUMREINDEXを実行すると劇的にパフォーマンスが改善します。特に仕事とかで大量のログを見ている方におすすめです。私の場合、370MBもあったログが270MBまで減って、Skypeの起動も高速化しました。

※注意: このコマンドはSkypeのログデータベースを直接操作します。最悪全てのログが失われる危険があります。何を言っているのか分からない、ターミナルの操作なんて知らないという人は実行しないことを強くおすすめします。

Unity の PostprocessBuildPlayer を Ruby で書いてみる(第二版)

UnityでiOSのアプリを作っていて困ることの一つに、iOSが提供するシステムフレームワークへのリンクをプロジェクトに追加するのが超面倒くさいという問題が挙げられます。UnityがiOSアプリを書きだした後、手動でXcode上からシステムフレームワークを追加してもいいのですが、これはとんでもなく面倒です。というわけで、以前こちらの記事でRubyのxcodeprojモジュールを利用して自動的にシステムフレームワークを追加する方法をご紹介しました。
http://akisute.com/2012/09/unity-postprocessbuildplayer-weak.html

今回はそのPostprocessBuildPlayerをさらに機能拡充しましたのでご紹介いたします。主な機能として、
  • システムフレームワークへのリンクをプロジェクトに追加する
    • dylib, framework両方に対応
    • required, optional両方に対応
  • 空のinfo.plistをプロジェクトに追加する
    • ja, enに対応
    • Unity 3時代に空のinfo.plistを追加しないとiOSが提供するUIが英語で表示される問題が合ったため追加
    • Unity 4以上であれば修正されているかも
  • ヘッダサーチパスをライブラリサーチパスからコピーして自動設定する
    • Unity 3時代にビルドにこける事があったので追加
    • Unity 4以上であれば修正されているかも
  • ローンチイメージを自動設定する
    • 容量の関係で極限まで圧縮したjpgをpngの代わりに使いたいということで追加
    • 現在のXcode 5/iOS7向けの環境ではjpgを利用したDefault.pngは全く考慮されていない用に見えるので、使わないほうが無難だと思います
  • main.mmの書き換え
    • ここではSystem.Net.Socket.SocketがSIGPIPEを飛ばしてアプリ全体をクラッシュさせてしまうことがある問題を回避するためにsignalを捕まえたりしています
    • 変更規模が大きいならわざわざここでやるよりUnity側の/Assets/Plugins/iOSにmain.mmを置くほうが良いかと思いますが、ちょっと書き換えるだけなら有用です
  • AppController.mmの書き換え
    • 変更規模が大きいならわざわざここでやるよりUnity側の/Assets/Plugins/iOSにAppController.mmを置くほうが良いかと思いますが、ちょっと書き換えるだけなら有用です
インストール方法は、
  • まずソースコードを取ってきてPostprocessBuildPlayerという名前でUnityプロジェクトの/Assets/Editor/以下に配置します。
  • 実行にはRubyとバージョン0.4.xのxcodeprojモジュールが必要になりますので、インストールします。より大きいバージョンのxcodeprojでは動作未確認ですので、0.4.x系を指定することをおすすめします。
    • sudo gem install xcodeproj --version '~>0.4.0'

ソースコードはこちらになります。MITライセンスです。

余談になりますが、最近ではRubyのxcodeprojを使うのではなく、Pythonのmod-pbxprojを使う方法もあるみたいです。@Seasons氏はこちらの方法を使われているそうです。Pythonのがいい!という方はいかがでしょうか。



2013年11月3日日曜日

Objective-Cでパターンマッチしたい

また誰得な妄想ネタですみません><

突然ですが、Objective-Cでパターンマッチがやりたいんです。MLだとかOCamlだとかScalaだとかみたいに。
MLの例: http://kktoppa.web.fc2.com/smlnj4.html
OCamlの例: http://www.geocities.jp/m_hiroi/func/ocaml04.html

パターンマッチがないせいで、StoryboardでSegueを使ったとき、こんな何かの冗談みたいなコードを書かなくちゃいけないんです。

見ての通り、大学時代に恩師が「アホのn段重ね」と読んでいたif~elseの重ね技です。これ以外に方法がないんです。

だからこういうコードが書きたいんです。厳密には関数型言語のパターンマッチと違う気がしますしなんか色々とメチャクチャな文法になってますが、だいたいなんかこんな感じのコードが。

しかし残念ながらObjective-C (CでもC++でもいいですけど) の文法を捻じ曲げるのは極めて難しいです。

Rubyならこんな感じでパターンマッチを実現するライブラリがあるみたいです。素敵ですね。
http://www.callcc.net/diary/20120303.html
https://github.com/k-tsj/pattern-match

というわけで今日もアホのn段重ねでSegueを使おうと思います\(^o^)/

2013年10月30日水曜日

【誰得】ncursesをiOS 7向けにビルドしてみた



久々のブログ投稿がこんな内容でほんとすみません。

ややタイトル出落ち感がありますが、ncursesをiOS向けにビルドしてみました。環境は以下のとおりです。

  • OS X 10.8.5 (Mountain Lion)
  • Xcode 5.0 & iOS SDK 7.0
  • ncurses-5.9
  • TerminalにはOS X付属のTerminal.appを使用

※注意: 本当に使えるかどうかまでは試してません。ちょっと根性が足りませんでした。あくまでiOS向けにC/C++で書かれたライブラリをビルドして使えるようにするときの参考になったりならなかったり程度でお考えください。

というわけで、まずはncursesのソースコードをhttp://ftp.gnu.org/gnu/ncurses/あたりからサクッと拾ってきます。今回はncurses-5.9を使用しましたがどのバージョンでも大して変わらないと思います。

あとはconfigureしてmakeすればOKですが、configureが少々厄介です。そのままだとerror: Cross-build requires two compilers.とか言われてしまいますので、./configureの当該箇所をコメントアウトしてからオプションを付けて実行してください。それから./configureを実行した端末エミュレータ向けにビルドされてしまうようで、その挙動を変更するオプションが見つからなかったのでこちらも注意してください。私は今回xterm向けにビルドしてしまいましたがxtermエミュレータが用意できない場合はVT100などに変更した上でビルドしたほうが良いかと思います。



うまくいけば無事ビルドが通ってタイトルの画像のようになります。
CFLAGSでarchとisysrootを指定してビルドする手法は他のautoconfを使っているオープンソースのライブラリでも応用できそうですね。

さてlibncurses.aはビルドできたのですが、このままでは端末エミュレータがなくてどうにもならないので、iOS用の端末エミュレータを用意しなければなりません。幸いにしてオープンソースのmobileterminalというプロジェクトを見つけましたので、こちらをお借りしましょう。ライセンスがGPLですがどうせこんな酔狂なものを人様の前に晒すことは決してないはずなので問題ありません。

あとはhttp://www.kis-lab.com/serikashiki/man/ncurses.htmlでも参考にncursesでのCUIプログラミングをお楽しみください。多分、きっと、運が良ければ、動くと思います。


参考文献:
http://d.hatena.ne.jp/maminus/20100129/1264781242 - configureのbuild、host、targetの違い
https://twitter.com/moriyoshit - @moriyoshi

2013年5月15日水曜日

「モバイルアプリのバックエンド(Web API)に特化したサービスのまとめ」のその後(2013年版)

1年ほど前にモバイルアプリのバックエンド(Web API)に特化したサービスのまとめというBaaSサービスについて非常に丁寧にまとめた記事が公開されていたのをつい最近知ったのですが、公開から1年が経ちBaaSサービス周りも統合再編が起きているようなので誠に勝手ながら2013年版を引き継いて書いてみようかと思います。

まずBaaSについて基本的なところはlaisoさんの元記事が素晴らしく良くまとめてくださっていますのでそちらを参照してください。

2013/05/16追記: こちらのSlideshareにも2013年現在のBaaSサービスを取り巻く状況が非常に丁寧にまとめられていますので、オススメです。

2013年のトレンド

まずは元記事で上がっていたBaaSサービスの名前を片っ端からGoogleトレンドに突っ込んでみて人気度を評価してみました。その他、2013年になって登場してきたサービスがないか調べてみました。

その結果、はっきりと人気がある勢と人気がない勢が分かれました。

人気がある勢

StackMob
https://www.stackmob.com
実際に使ってみたわけではないのですが、多機能さが目につきます。元記事で言われていたサンプルが動作しないなども直っているようです。しかしながらクラウド側コードをJava/Scalaという結構ガッツリ系言語で書く必要があったりして、お手軽さがParse.comなどと比べて今ひとつ、売りの機能面では最近赤丸急上昇のKinveyに遅れを取っている印象があります。
機能一覧はこちらから。

Parse.com
http://www.parse.com
最近Facebookに買収された、BaaS分野では一番の知名度を誇ると思われるサービスです。以前に実際に使ってみた時の感想など書いてみましたが、ドキュメントとクライアントSDKが極めて充実しており、導入が非常に簡単なのが良いところだと思います。まず困ったら比較基準元としてとりあえず使っておけるサービスとしてオススメできます。
反面、お手軽なぶん機能面では外のサービスに及ばない箇所が見受けられます。特に既存データとの接続が直接的にはサポートされていなかったりするため、エンタープライズ系のサービスには向かないと思います。
機能一覧はこちらこちらが参考になるかと思います。

Kinvey
http://www.kinvey.com
最近トレンドサーチで赤丸急上昇なサービスです。路線としてはStackMobのような多機能でエンタープライズ系も狙えるような路線になっていますが、見た感じクラウド側コードもJSで比較的お手軽に書けるのがいいですね。iOSのSDKだけを見れば、Core Dataのサポートがあったり、NSNotificationで状態通知を飛ばしていたりするなど何かと多機能で嬉しいです。課金がAPI呼び出し数ではなくアクティブユーザー数単位だったりするのもユニークなところです。
機能一覧はこちらこちら、またはこちら

Appcelerator Cloud (元Cloudfish)
http://www.appcelerator.com/cloud/
CloudfishがTitaniumの開発元であるAppceleratorに買収・統合されました。Titaniumを使っている人は事実上全員がターゲット層になりますし、根強い人気が今後も期待できそうです。

人気がない勢

CloudMine
https://cloudmine.me/
ちょっとドキュメントを見てみただけでダメそう感が伝わってくるのがなんとも。

Buddy
http://buddy.com/
どうもクラウド側コードを走らせる機能が無さそうです。イマイチ。ゲームAPIなどが最初から用意されているのですが、内容を見ても(少なくとも日本では)余り使える内容に見えません。

QuickBlox
http://quickblox.com/
LocationやVideo Chat、Content RankingなどのB2Cアプリ向けのサービスが標準提供されており、そういう用途だと良いかもしれません。

yorAPI
http://www.yorapi.com/
サイト自体が潰れてます。

新しく登場した勢

BaasBox
http://www.baasbox.com/
完全にオープンソースなのが売りみたいです。ScalaのPlay!フレームワーク上に実装されており、自分でJVMの動作するサーバを用意すれば環境を構築することができます。弱点は機能がまだほぼ皆無でクライアントSDKもまったくないことです。要するにまだ全然使えません。一応クライアントSDKはリリース予定があるみたいです。

appiaries
http://www.appiaries.com/jp/index.html
ついに登場した日本のBaaSサービスです。が、残念ながら現地点では機能が大きく人気のある勢に対して劣っており、クライアントSDKもクラウド側コードもどうやらまだ存在しないようです。現段階ではオススメしづらいですが、今後どうなるか次第ですね。

Kii
2013/05/16追加
http://www.kii.com/
もう一つの日本のBaaSサービスです。appiariesよりも完成度が高くParseにサービス内容と料金体系が似ています。iOS/Android向けのクライアントSDKもきちんと用意されていますが、クラウド側コードはまだ準備中になっており使用出来ませんでした。特徴的な点としてアドネットワークとの連携が標準で用意されていたり、ファイルストレージにゴミ箱機能や共有機能があったりします。実際には試せていないのですが、サーバが日本にあるため応答性が良いかもしれません。
機能一覧はこちらこちらこちらのスライドも非常によくまとめられていてわかりやすいです。

Windows Azure Mobile Services
2013/05/16追加
https://www.windowsazure.com/en-us/develop/mobile/
Microsoftが提供しているWindows AzureクラウドのMobile向けサービスです。クライアントSDKもWindows/Android/iOSに対応済み、クラウド側コードをJSで記述可能、さらにはcronに相当するクラウド側コードの定期実行も可能と、こういったところはさすがのMicrosoftという印象を受けます。ただしクライアントSDKはWindows向けのもの以外開発途中でドキュメントも貧弱、サービス内容もそれほど充実していません。Windows Azure自体との連携もあると思われますが、詳細がよくわかりませんでした。

2013年5月2日木曜日

Parse.com の Cloud Code ハマりどころ

Parse.comのCloud Codeを触っていてハマった点や気づきにくい仕様を列挙させて頂きます。

■Parse.Cloud.useMasterKeyを呼び出すことで特権ユーザー権限になれる

Cloud Code上でACLによるアクセス制限を無視して現在のrequest.userとは関係なしにデータを操作したいということが多々あるかと思います。そのような場合は以下のようにリクエスト処理の先頭でParse.Cloud.useMasterKeyメソッドを呼び出してください。

useMasterKeyの効果は呼び出された瞬間からリクエストが終了するまで有効です。

■Parse.Cloud.beforeSaveやParse.Cloud.afterSaveはData Browserから直接Rowを追加した場合にも呼び出される

これは意外とハマりどころです。例えばData BrowserからUserを追加した時などにUserに対してつけておいたParse.Cloud.beforeSaveが発動するなどしてよく発生します。Data Browserから直接Rowを追加した場合、request.userはnullになりますので注意してください。また追加元がData Browserなのか普通のクライアントなのかを判定する手段が用意されていないため、処理を分岐させたくなるととたんに話が面倒なことになります。

Parse.com使ってみた

いまさらですがBaaS (Backend as a Service) が来てるらしいですので、とりあえずParse.comに手を出してみました。

■良かった所

  • クライアント側の実装が楽で安定しています。デバッグログも充実しており、Parseが原因でクラッシュするということもなく、特に悩まされるところはありませんでした。
  • 料金がとにかく安いです。個人で使うぶんには全く問題ないかなと思います。

■イマイチだった所

  • サーバーがUSなせいもあってそれほどレスポンスはよくありません。
  • セキュリティモデルをまじめに構築しようとするとかなり面倒くさいです。
  • Cloud Codeに山ほどハマりどころがあります。詳しくは別記事で。
  • バッチ(定期実行)に相当するものがありません。自宅のPCをから毎晩のタスクを定期実行するとかそういう悲しい方法で回避するしかありません。
  • Dev版と製品版で同じバックエンドを使うことになるので、公開したアプリの継続開発が面倒そうです。これは違う名前で開発版アプリを作ることで回避することができます。
  • 料金。エンタープライズで使うときの料金体系が不明瞭で、「連絡してね」の一言で済まされているため不安が残ります。
  • データの可搬性。一応Exportオプションは用意されていますが形式が独自形式のJSONなので自前で手元のDBなどへのImportツールを作る必要があり結構面倒だと思います。手軽にExcelやCSVでExportするオプションがほしいです。

■まとめ

プロトタイピングや小規模なアプリには良いと思います。ただしデータ可搬性をまじめに考えるのであればRESTful APIを使う必要があり、そうなってくるとせっかくよくできているクライアント側実装のほとんどが無駄になるため微妙に感じられます。Cloud Codeはハマリどころが多いのがまず問題ですが、わかってしまえば問題ないと思います。

2013年3月24日日曜日

Unity でソースコードに書いたリテラル文字列の文字コードを調べてみた

Unity3.5.6においてソースコード上にリテラル文字列として日本語を置いた時、時々ログ出力が上手くいかないことがあるということがわかり、ちょっと調べてみました。するとリテラル文字列を置いたソースコードの種類に応じて文字コードが違うということがわかりました。
  • C# (.cs) はUTF-16
  • JS (.js) はUTF-8
  • Boo (.boo) は不明
  • ネイティブのiOSはUTF-8
また出力する側、要するにDebug.Logメソッドは基本的にUTF-8のみを受け付けられるようになっているということがわかりました。まとめると以下の図のようになります。



最終的にJSファイルに全ての日本語リテラルをまとめて回避しましたが、そもそも日本語リテラルは使わず国際化文言ファイルみたいなものを別途用意しておいたほうが筋が良いと思います。iOSならLocalizable.stringsがありますしね。

2013年1月20日日曜日

SLComposeViewControllerでFacebook投稿する際に投稿が失敗してしまう問題

iOS 6.0より追加されたSocial.frameworkは大変お手軽に使用できて、ユーザーさんも毎回毎回素性の知れないアプリに対してTwitter/Facebookログインをし直すという手間と危険性から開放される便利な代物ですが、ちょっとした落とし穴を見つけたのでご紹介します。

SLComposeViewControllerを使っている時に、同じ文面でもTwitterには正常に投稿できるがFacebookには投稿に失敗してしまうというケースが発生することがあります。画面にはただ「Facebookに投稿できません」とアラートが表示されるだけですし、SLComposeViewControllerは投稿失敗時のerrorに対してコールバックblockもdelegateも存在しないので原因を調べることもできません。

実機のコンソールログを見てみると以下の様なエラーになっています。
Jan  8 11:01:25 akisute-no-iPhone sociald[6444] : 2013-01-08 11:01:25.665|sociald|0x1fd65e70: Request status was 400
Jan  8 11:01:25 akisute-no-iPhone sociald[6444] : 2013-01-08 11:01:25.668|sociald|0x1fd65e70: SLDFacebookPostUpload: The response indicates an error
 Parameters:{type = immutable dict, count = 1,
 entries =>
  2 : {contents = "error"} = {type = immutable dict, count = 3,
 entries =>
  0 : {contents = "message"} = {contents = "(#100) The parameter link is required"}
  1 : {contents = "type"} = {contents = "OAuthException"}
  2 : {contents = "code"} = {value = +100, type = kCFNumberSInt64Type}
 }
 
 }
 . 
 
 HTTP status 0
SLComposeViewControllerが裏で使用しているsocialdのSLDFacebookPostUploadクラスがエラーを吐いています。一見しただけだとOAuthExceptionとか書いてあって認証系のエラーかと勘違いしてしまいそうですが、実はこれSLComposeViewControllerのaddURL:メソッドに「空の」NSURLインスタンスを渡した時に発生するエラーです。以下のコードで簡単に実験することができます。

対策としてaddURL:しようとしているURLのschemeがnilまたは空文字列だったらaddURL:しないとすればOKです。しかしTwitterでは通るのにFacebookだけ通らないのはなんだか納得いかない・・・><

エンジニアサポートCROSS 2013で発表してきました

先日ニフティさんが主催されたエンジニアサポートCROSS 2013におじゃまさせていただきました。このエンジニアサポートCROSSは年に1回、去年から開催されているらしいのですが、なんといっても大手企業さんが主催ということで
  • 参加者がとにかく豪華
  • プレモル飲み放題ケンタッキー食べ放題という夢の様な環境
  • それでいてきちんとWeb系/Make系コミュニティのギークっぽい雰囲気のカンファレンスになっている、スーツではない
という独自の魅力があるカンファレンスになっていました。

で、このエンジニアサポートCROSSにはアンカンファレンス枠があって、参加者が自由気軽にその場でプレゼンを行う事ができる場がありましたので、せっかくだからということで私も発表させて頂きました。


内容については先日リリースしましたダンゴルのサーバサイド側の裏話です。といってもスライド見れば分かる程度のものです。

来年は正規のスピーカー枠で参加したいです><