自分流 View Controllerの作り方 その2

その1はこちら

ぼくのかんがえたさいきょうのせっけいです
主に以下の書籍に影響受けまくりであります

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler)) Martin Fowler Addison-Wesley Professional 2002-11-05 by G-Tools

レガシーコード改善ガイド (Object Oriented SELECTION) マイケル・C・フェザーズ ウルシステムズ株式会社 翔泳社 2009-07-14 by G-Tools

---

図を適当に補足
ViewWrapperは既存のすでにあるどうしようもない設計のViewを何とか救いたいときに非常に便利、Wraper / Decoratorパターンを適用してボタンのタップを奪い取ってViewHelperに流すみたいな役目をする
ViewHelperは簡単に言うならUITableViewControllerのdelegate, datasourceだけを担うオブジェクトみたいな感じ。要するにView専用のドメインロジックを書くオブジェクト
Viewの表示を制御するドメインロジックが途方もなく大きくてViewControllerに納めるのが不可能になってしまったときに超便利

Serviceは準ドメインロジックだと思っている、たいていの場合セミシングルトンみたいにする（通信が絡むので複数画面をまたいで使うことがほとんど）
Androidの場合はここ、普通にServiceクラスでいいんじゃないでしょうかね

Managerはドメインロジックというよりもプロセス外へのリソースアクセスを行うためのクラスというイメージ、個人的にはゲートウェイみたいな感じ

• NSFileManager
• NSUserDefaults
• KeychainAccessManager
• InAppPurchaseManager
• APIConnectionManager

Modelはドメインモデルです、ほとんどの場合はCoreDataのNSManagedObject。用がないときでもCoreData使っておけ（超便利）
と思ってましたがCoreDataのモデルは特にN:N関係を正しく扱わないと簡単に問題が発生してしまいますので、安易に採用すると危険かも。

Task, Operationってのは非同期で実行されていく特別なドメインロジックのイメージ。要するにAPI通信みたいなもんです
API通信を複数束ねて使ったりとか並列実行したりとかの制御が絶対必要になるのでそういうときに使う via @monjudoh

// MyTaskが終わったらMySuperTaskを実行して、それが終わったらさらにMySuperDuperTaskを連続して実行したい
// 終わったらselfに通知させたい
Task *root = [[[MyTask alloc] init] autorelease];
root.nextTask = [[[MySuperTask alloc] init] autorelease];
root.nextTask.nextTask = [[[MySuperDuperTask alloc] initWithId:100] autorelease];
root.delegate = self;
[root start];

自分流 View Controllerの作り方 その1

その2はこちら

以前勉強会の際に発表した View Controller の作り方のメモをまとめてみました。あくまでメモなので中身はうまくまとまっていませんが、何かのご参考になればと思います。

---

通信が絡んでくると、たいていの人がやりがちな問題（実例）

• API通信のレスポンスを処理するコードがViewControllerの中に入っている
• API通信が3種類必要で、Aを実行したあとにBとCを実行しなければならないとか
• ABCのレスポンスJSONのパースまでViewControllerでやっている
• というかAPIの呼び出しの組み立てだとかURLの指定だとか自体がIBActionの中に入っていたりする

API通信だけじゃなくてIn App Purchaseなどでも同様の事例が見られる

それに対する対応策。そもそもなぜこのような問題が発生するのか？

1. Outletの生成・更新・レイアウトが分離されていない
   • そのため複数回画面が更新されるタイミングが発生するととたんに破綻する
   • 大変よく見かける初心者コードが"drawXXX"という名前のOutletを生成してデータをセットしてframeまでセットして画面に配置するコード
   • Outletを描画コードと勘違いしている。Outletはペンやブラシに相当するものであって、実際に線を書くコードではない
   • この初心者コードでも動く唯一の理由は画面が一回（viewWillAppear時）しか更新されないから
2. 通信という（比較的大きくなりがちな）ドメインロジックがViewControllerに混入している

そこで問題1.に対応するためにViewControllerの中でやる作業を以下のように分割する

• Outletを生成する
  • preload（一度に生成する方法）
  • lazy load（必要になったら生成し、必要でなくなったら捨てる方法）
• Outletのプロパティを更新する
• Outletをレイアウトする

これらはそれぞれ（基本的に）以下のようなUIViewControllerのメソッドが対応する

• loadView
  • Outletをpreloadする場合はコレで全く問題ない。このとき、self.viewとここで作られたOutletの生存期間は等しくなる
  • Outletをlazy loadする場合はOutletを生成するコードと削除するコードを用意しておいて、必要なタイミングで呼び出すとかする
• なし
  • プロパティを更新するために、たとえばupdateOutletsみたいなメソッドを自分で用意してやる
• 各種willRotate...系メソッド
  • willRotateほげほげの中にレイアウトコードを入れておくと自動的に画面の回転にも対応できて超便利
  • 自動的に必要なタイミングで適切に呼び出ししてくれて超便利
  • そういうのが嫌いな人はlayoutOutletsForInterfaceOrientation:みたいなメソッドでも作ればいいんじゃないでしょうか

次に問題2.に対応するためにAPIの呼び出しやファイルアクセスなどはService, Managerなどの層を作ってそちらに任せる
決してViewControllerの中にドメインロジックを混入させないのが大事
→混入するとドメインロジックとビューナビゲーションロジックが混ざって大爆発する
→さらにドメインロジック自身も複雑な通信が必要になると大爆発する

それとは別にイベントを受け取ってViewの状態を制御する大事なお仕事をする必要がある

• ボタンタップしたり
• 画面をタップしたりパンしたり
• スクロールが発生したり
• APIコールが完了したり
• In App Purchaseが完了したり

ここまでがView Controllerのお仕事。決してドメインロジックを混ぜないのがポイント

Objective-C で文字列リテラルに \0 を含めたいときの作戦

Xcode 4.0 から LLVM が標準のコンパイラとなり、各種警告が非常に厳しくなっています。その中でも特に今回は文字列リテラルに \0 が含まれているときの警告について回避策を発見したのでご紹介したいと思います。

Objective-C では文字列リテラルは @"abesi" のように @"" で囲んで表現します。このリテラルは（あくまで推測で確定ではないのですが）コンパイラによってコンパイル時に CFSTR("abesi") に置換され、 CFStringRef 型としてプログラム中に定義されているようです。さて問題はここからで、 Xcode 4.0 が内部的に構文解析のために使っている LLVM がこのリテラル中に \0 、要するにNULL文字が含まれていると以下のような警告を出すようになってしまったのです

CFString literal contains NUL character

普通はNULL文字をリテラル中に含めたいということはまず無いのですが、SMTPの通信部分を書いたりしていると通信プロトコル自体が命令を \0 で区切れみたいな要件を求めてくるため、どうしてもリテラルの中に \0 を含めたいときが出てきます。 まぁ、具体的には以下のライブラリなんですけどね。

http://code.google.com/p/skpsmtpmessage/source/browse/trunk/SMTPSender/Classes/SKPSMTPMessage.m

sendState = kSKPSMTPWaitingAuthSuccess;
NSString *loginString = [NSString stringWithFormat:@"\000%@\000%@", login, pass];
NSString *authString = [NSString stringWithFormat:@"AUTH PLAIN %@\r\n", [[loginString dataUsingEncoding:NSUTF8StringEncoding] encodeBase64ForData]];
NSLog(@"C: %@", authString);
if (CFWriteStreamWriteFully((CFWriteStreamRef)outputStream, (const uint8_t *)[authString UTF8String], [authString lengthOfBytesUsingEncoding:NSUTF8StringEncoding]) < 0)
{
    error =  [outputStream streamError];
    encounteredError = YES;
}
else
{
    [self startShortWatchdog];
}

そして私と同じライブラリの同じ箇所でぶつかった人を発見。

http://stackoverflow.com/questions/5814520/how-do-i-create-a-login-string-that-contains-2-embedded-nulls-and-the-login-an

さて回避方法はないものかと探してみたところ、ちょうど良い回避策が発見できました。

http://stackoverflow.com/questions/6211908/nsstring-with-0

NSStringのstringWithFormat:に %C を埋め込んで、そこに 0 を渡せばうまくいくみたいです！

int main() {
    NSString *string = [NSString stringWithFormat: @"Hello%CWorld!", 0];
    NSData *bytes = [string dataUsingEncoding: NSUTF8StringEncoding];
    NSLog(@"string: %@", string);
    NSLog(@"bytes: %@", bytes);
    return 0;
}

さっきの例だと、

sendState = kSKPSMTPWaitingAuthSuccess;
NSString *loginString = [NSString stringWithFormat:@"%C%@%C%@", 0, login, 0, pass];
NSString *authString = [NSString stringWithFormat:@"AUTH PLAIN %@\r\n", [[loginString dataUsingEncoding:NSUTF8StringEncoding] encodeBase64ForData]];
NSLog(@"C: %@", authString);
if (CFWriteStreamWriteFully((CFWriteStreamRef)outputStream, (const uint8_t *)[authString UTF8String], [authString lengthOfBytesUsingEncoding:NSUTF8StringEncoding]) < 0)
{
    error =  [outputStream streamError];
    encounteredError = YES;
}
else
{
    [self startShortWatchdog];
}

このようにすればばっちり上手く回避できました！