「iOSアプリ:テスト自動化入門」が届いた

すごく読みたかった本がようやく届いた。

バックエンド系のシステムだと自動テストがあるのは当たり前になってきたけど、まだまだネイティブアプリでは自動テストが書かれていないというのが実情だと思ってる(私もあまり出来ていない)。 テストができていないと、つまらないミスでアプリがクラッシュしてしまい、AppStoreのレビューが荒れて悲惨なことになる。。 かといって、リリース前に毎回手動テストするのもそれはそれでコストなので、そこでテストの自動化でしょという話になってくる。

既存のアプリのすべてのコンポーネントに自動テストを一気に用意するのは、大変だと思うけど、テストを書きやすいところから書いていければいいと思う。UIに依存しない部分、APIにリクエストして結果を取得する部分など。 現実問題、UIのテストってやるべきなのかって話もあるからね。

とりあえず目次を貼って終わりにします。

iOSアプリ テスト自動化入門|書籍情報|秀和システム

ヘッダのカスタマイズや独自処理をしたいときの AFNetworking 2.0 の使い方

ヘッダのカスタマイズや独自処理をしたいときの AFNetworking 2.0 の使い方

普通の使い方

AFHTTPRequestOperationManager というクラスを主に利用します。 GETで通信したい場合は、以下のように GET:parameters:success:failure: メソッドを呼び出すことで、リクエストを開始することができます。 parameters: に NSDictionary 型のデータを渡せば、それをよしなにURIパラメータやBODYに付与してくれます。

サーバとの通信に成功しレスポンスが返って来た場合には、success: で指定したブロックが呼び出されます。また、ネットワークに繋がっていなかったり、指定したURLのサーバホストの名前解決がでいないなどサーバとの通信に失敗した場合は、failure: で指定したブロックが呼び出されます。 ちなみに、AFHTTPRequestOperation からステータスコードやレスポンスヘッダといった情報を取り出すことができます。

GET 以外には、POST, DELETE, PUT 用のメソッドも用意されています。

ヘッダのカスタマイズ

さて、ここからカスタマイズ編です。リクエスト時のヘッダをカスタマイズしたい場合は、以下のように AFHTTPRequestOperationManagerrequestSelializer というプロパティに対して、setValue:forHTTPHeaderField: を呼び出します。 NSMutableURLRequest にヘッダを設定する場合と似てますね。

ちなみに、BASIC認証したい場合は、以下のメソッドが使えます。

NSURLRequest のカスタマイズ

リクエストを開始する前にNSURLRequestにある処理を実行したいという場合があると思います。 例えば、Parse を使っていてリクエストヘッダにアクセストークンを付与したい場合、以下のように行うことができます。

最初に紹介したやり方よりは記述量が多くなってしまいますが、必ず毎回実行したい処理ならAFHTTPRequestOperationManagerのカテゴリ拡張もしくはサブクラスを作っても良いかもしれません。

Reference

  • http://qiita.com/asakahara/items/9cb68bef56ca70b505c6
  • http://qiita.com/jtemplej/items/c3c25a5301c7250305fe
    • Request Serialization, Response Serialization の説明がわかりやすい

NSSetの内部実装

NSSet の内部実装

ふと気になったので調べてみたところ、以下のリンクを見つけた。

どうやら実装としてはハッシュテーブルらしい。だから、要素の挿入、削除、検索が一定時間でできる。

なんでそんなことがわかるかというと、NSSet のC言語実装である CFSet が CFHashTable というハッシュテーブルを使って書かれているから。

実は CoreFoundation のソースコードは公開されていて、その一部である CFSet のソースコードも見ることができる。

CFSet のメソッドを見ていると、NSSet のどのメソッドと対応しているか、それとなくわかる。気になる実装を軽く眺めてみるだけでも楽しいかも。もしかしたら、CoreFoundation のクラスの内部でクラッシュした時に、参考になるかも(笑)

iosのクリップボードの変化を検知するOSS「GLPasteboardMonitor」を公開しました

https://github.com/gologo13/GLPasteboardMonitor

iOS のクリップボード(UIPasteboard の generalPasteboard)の変化を検知し、通知が受け取れるようにするOSS「GLPasteboardMonitor」を公開しました。

使い方は github に書いてあるので、よかったら使ってみてください。 あまり大したことはしていないのですが、ポイントを上げるとすると、

  1. バックグラウンドでも変化を検知できるように、 Task Competion を使っている点
  2. 画像データの比較で、単純なバイト列の比較ではなく、ハッシュ値を元に比較し、比較を高速にしている点

です。

サンプルのプロジェクトでは、クリップボードの変化を検知すると、Local Notification を飛ばすようになってます。

dispatch_create_queueを使うときの勘違い

久々エントリ。

queue を作るとき、dispatch_create_queue の第1引数に名前を指定する。 ところが、すでに同じ名前の queue があるからといって、その queue が再利用されるわけではない

例えば、以下のコードはqueueの生成コストがすごく無駄

ドキュメントに書いてあるけど、このラベルは本質的に意味はなくて、デバッグ時の queue の識別子として使われるだけであった。

label

A string label to attach to the queue to uniquely identify it in debugging tools such as Instruments, sample, stackshots, and crash reports. Because applications, libraries, and frameworks can all create their own dispatch queues, a reverse-DNS naming style (com.example.myqueue) is recommended. This parameter is optional and can be NULL.

だから、上のソースコードは「1個のキューに対して、100個のタスクが直列に実行」されるわけではなく、「100個のキューに対して、1個のタスクが直列に実行」される。よって実質的には並列キューみたいにタスクが実行される。

参考

iOS Developer Progamで複数チームに所属することは可能か?

iOS Developer Progamで複数チームに所属することは可能か?

結論としては、可能です。

添付したスクリーンショットのように、iOS dev center にログインするたびに、どのチームで操作を行うかを選択することができる。

すでにあるチームの Developer Program に所属している状態で、新規で Developer Program に参加しようとした時、

  • 古いチームの情報が上書きされてしまい、無効になる
  • 既にチームに参加しているから、新規で参加できない

と、懸念があったが、全くそんなことはなかった。

個人的に安心できたので、シェアします。


以下、実機インストールまでの簡単な導入手順

  1. Safari で iOS Dev Center を開く(Chrome だとうまく行かないことがあった)
  2. デバイス登録:実機インストールするデバイス名, UDID(Xcode Identifier で調べられる)を登録
  3. AppID 登録:アプリのユニークなIDの作成
  4. 証明書登録:KeyChain Access で作成できる
  5. プロビジョニングプロファイル作成:実機インストールするための準備ファイル

詳しくは、ここ が参考になりそう。