Swiftで複数画面遷移するViewControllerを使い回す時の設計

Question

お世話になります。

現在、複数の画面遷移を伴うViewControllerの設計を行っております。
以下画面遷移のイメージです

このようにパスワード忘れた場合などユーザーに確認コードを送信して認証を行い新しいパスワードを登録させるといった処理を作成してますが、この確認コード周りの処理はほかの処理でも使う可能性があるので使いましできるように設計したいと考えています。

現在考えているのは確認コード部分の2つのViewControllerを別Storyboardに分けて、ログイン処理側から呼び出すようにする。確認完了後に実行されるデリゲートもログイン処理側で登録できるようにして、認証完了後これを呼び出すようにする想定です。

上記の設計を行ったときの問題点として以下を考えています。

• storyboardを分けることによって、一連の画面遷移流れがわかりにくくなる（これはもう仕方ないことだと思いますが）

• ログイン側で登録したデリゲートが実際に実行されるのは2つ先の「認証」画面なので実際に呼び出す「確認コード送信」画面からさらに渡してあげないといけない。

などです。

画面遷移については別storuboardにするよりもxibファイル化して、viewControllerは認証が必要な箇所だけ用意して、viewを使い回せるようにする。なども考えましたが、それだと必要な箇所に毎回viewControllerを用意する必要があり無駄になるかなとも思ってしまします。

xibファイルを使用してUIを使い回せるようにするという記事はよく見るのですが、
一連の処理をまとめて使い回せるような設計についてはなかなか出てこなくて悩んでいます。

このような設計について皆様のご意見いただきたいです。
よろしくお願いいたします。

Answer 1

ある画面での処理結果を離れた画面で補足したいというニーズはよくあります。

古典的方法だと、NotificationCenterを使うという方法があります。

この方法ではまず、確認コードを処理するビューコントローラはNotificationCenterに処理の結果を通知します。
で、認証コード画面の処理の完了（もしくは失敗・キャンセルなど）を知りたいViewControllerが、NotificationCenter経由で通知を受けとるという方法です。

ただ、この方法は、複雑なアプリでは情報の流れや状態管理がスパゲッティ化するので多用しない方が良いと思います。

長年iOSアプリを開発していますが、iOSアプリは結局アプリ全体の状態変化を多くの画面で知りたくなるものだというのが僕の結論です。

なので、個人的にはReduxのSwift実装であるReswiftをおすすめしたいです。ただし、アプリの規模によってはオーバースペック（導入コストに対して、得られるメリットが少ない）かも知れません。

この記事などを参考にされてはいかがでしょうか。

アプリ開発と状態遷移の管理

Comments

[annderber]

ご回答ありがとうございます。
参考にさせていただきます。