LoginSignup
46
46

More than 5 years have passed since last update.

アプリ内の画面にURLを与えるといろいろ捗る

Last updated at Posted at 2014-02-24

segueの不満点

Storyboardのsegueはちょっとした遷移を書くのには便利なのですが、viewの状態遷移が複雑な場合にはあっという間にスパゲッティ状態になります。また、状態遷移にパラメタをつけたい場合、prepareForSegueを用いるのは結構面倒です。

実例

うちの会社で作っている「Poin」というアプリケーションの場合、「User」「Book」「Page」を表示するViewControllerに、様々な経路で状態遷移します。ざっと挙げても下記の通りで、実際にはこの倍近い経路があります。

  • Top -> Book
  • Top -> User
  • User -> Book
  • User -> User
  • Book -> User
  • Book -> Page
  • Page -> User
  • Page -> Book
  • Notification -> User
  • Notification -> Book
  • Notification -> Page

「User」「Book」「Page」にはそれぞれIDを与える必要があるため、segueで書くと泣ける状態になります。
このようなブラウザ的なアプリケーションには、今回紹介するURLを用いる方法は絶大な効果があります。

対応策

すべてをsegueで制御せずに、要所となるviewにはURLを定義します。URLには引数をつけることができるので、IDも問題なくURLに含めることができます。上記の例の場合には、下記三つだけを考えれば良くなります。

  • -> User
  • -> Book
  • -> Page

あとは、目的に応じてUIApplicationか、Application DelegateのどちらかのopenURLに状態遷移を記述します。たったそれだけで、アプリ内のどこからでもURLで指定したviewに遷移できるようになります。

さらに、一つのStoryboard内はsegue、異なるStoryboard間はURLで結合させると見通しが良くなります。

余談

Poinではアプリ外からのURL起動を先に実装していたので、「アプリ内でもこのURL使える!!」と気付いた後は、あっという間にリファクタできました。さくさくsegueを消して行くのは壮快でしたよ。

補足

Twitterで、「そこまでやるならaddSubviewでよくない?」というコメントを頂いたので追記。
Poinの場合、画面遷移は基本的にStoryboardで記述しており、各画面には固有のIDを持たせてState Restoreを行っています。個人的には、これがStoryboardの最大のメリットだと思っています。
そのため、画面遷移はUIViewController単位とし、Restoreの必要ないviewのみsubviewとして使っています。

46
46
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
46
46