Storyboardは要らない子

Storyboard
Storyboardが登場したのはXcode4…いや、4.1だったか…
まあいい。
Storyboardには72通りの機能があるから、僕が使いこなせてると言っていいのか…。
確か最初にプロジェクトで使ったときは、コーディング要らずで、デザイン、画面遷移が作れると歓喜したものだが、まあ、要らないのはコーディングじゃなくてStoryboardだったよ。

当初はコードを書かずに、デザインから画面遷移まで書ける!と感動したものですが、実際は…。
というわけでタイトル通りStoryboardがダメな理由を挙げます。

遷移先にオブジェクトを渡せない

MyDetailController* controller = [MyDetailController new];
controller.selectedObj = selectedObj; // 選択されたオブジェクトを渡す
[self.navigationController pushViewController:controller animated:YES];

例えば、リストに項目が並んでいて、それをタップするとその詳細な情報が表示される。
よくある流れだと思います。
コードで書くなら上のような感じでしょうね。
しかし、Storyboardではこの処理はできないため、結局コードを書く必要があります。

一部分をコードで、一部分をStoryboardで作ることになる

さて、1年後、項目をタップしたときの動作を変える必要がでてきました。
Storyboardから該当の処理を探すと…ない。別の箇所は逆にコードがない。
画面遷移の処理がコードにあるのかStoryboardにあるのか捜す必要がでてきます。

CellやViewの使い回しがやりづらい、メンテし辛い

他の画面で作ったCellやViewを使いまわしたいことがあります。
(Viewはやったことがないけど)CellはIDで引っ張って使い回すことができます、確か。
使い回したCellを修正する必要があるとき、Storyboardから探す必要あります。画面数が多いとシンドイ。

重い

画面数が多くなってくると、めちゃくちゃ重いです…!
マネージャ、メモリ買ってください!

スパゲッティ遷移
共通で使われる画面なんかはとってもラーメン美味しいです!

チームで開発しづらい

storyboardXML
StoryBoardは1ファイルのXMLです。チームで開発するとしばしば衝突します。
機械が出力した巨大なXMLなので、衝突した場合、マージするのは困難なので、しぶしぶ、自分の変更を対比させて、手でマージします。
結局、「オレがいじるから、おまえ今いじるなよ」になり、効率的に作業ができ、ゆっくり残業していってね!

理解しづらい

Storyboardを使うと画面遷移が簡単にかけるけど、理解しづらい。
UITabBarControllerがいて、UINavigationControllerがいて、その子どもが連なって、modalの親はこいつで…、というようなのがモヤモヤっとしたままできてしまう。
でも込み入ったことをしようとすると、途端に難易度があがる。

まとめ:僕達が欲しかったものはこれなの?

結局、僕達が欲しかったのは、GUIでUIデザインをしたかっただけ、ではないでしょうか?
MVCでいうとVじゃないんでしょうか?
画面遷移はCの仕事だから、中途半端に手を出すからかえってややこしくなる。
そこで、Interface Builderですよ。
Interface Builderなら上記で挙げた問題はありません(一部はコード、はあるけど)。

Storyboardの使いどころは…

  • モックには最適です。コード無しでそれなりに動きはわかります!小さい工数で「動かないとわからない厨」を黙らせるには最適です。
  • 画面数が少ない。
  • 一人で作る。メンテは多分しない。もしくは1年後も作りを思い出せる。

…と言いたいこと言いたい放題書きましたが、これらの問題を解決する方法があれば教えていただけると嬉しいです。

この投稿へのコメント

コメントはありません。

コメントを残す

メールアドレスが公開されることはありません。

この投稿へのトラックバック

トラックバックはありません。

トラックバック URL