コーディネーターパターンの問題とRouteComposerがそれとどう関係するか

私が使用するRouteComposerライブラリーに関する一連の記事を続けていますが、今日はCoordinatorパターンについてお話したいと思います。 パターンに関する記事の1つを議論することで、この記事を書くよう促されました。

少し前に導入されたCoordinatorパターンは、iOS開発者の間でますます人気を得ており、一般的に、その理由は明らかです。 UIKitが提供するすぐに使えるツールは、普遍的な混乱ではないからです。

私はすでに、スタック上のコントローラーのビューを構成する方法の断片化の問題を提起しています 。繰り返しを避けるために、 ここでそれについて読むことができます 。

正直に言ってください。 ある時点で、Epoleはコントローラーをアプリケーション開発センターに配置することで、コントローラー間でデータを作成または転送するための賢明な方法を提供しなかったことに気付きました。ある時点で、ストーリーボードとセグエを紹介してくれました。 その後、Epolusは自分が2つの画面だけで構成されるアプリケーションを書いていることに気づき、次の反復では、ストーリーボードが特定のサイズに達するとXcodeがクラッシュし始めたため、ストーリーボードをいくつかのコンポーネントに分割する可能性を提案しました。 セグエは、この概念に沿って、互いにあまり互換性のないいくつかの反復で変更されました。 それらのサポートは、大規模なUIViewController



クラスにしっかりと縫い付けられており、最終的には得たものを手に入れました。 ここにあります：

 override func prepare(for segue: UIStoryboardSegue, sender: Any?) { if segue.identifier == "showDetail" { if let indexPath = tableView.indexPathForSelectedRow { let object = objects[indexPath.row] as! NSDate let controller = (segue.destination as! UINavigationController).topViewController as! DetailViewController controller.detailItem = object controller.navigationItem.leftBarButtonItem = splitViewController?.displayModeButtonItem controller.navigationItem.leftItemsSupplementBackButton = true } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードブロックのフォースタイキャストキャストの数は驚くべきものです。ストーリーボード自体の文字列定数も、Xcodeがまったく手段を提供していないことを追跡するためのものです。 そして、ナビゲーションプロセスで何かを変更したいというわずかな欲求により、何の努力もせずにプロジェクトをコンパイルすることができ、Xcodeからのわずかな警告なしで実行時に突然クラッシュします。 これが最終的に判明したそのようなWYSIWYGです。 あなたが見るものはあなたが得るものです。

ストーリーボードのこれらの灰色の矢印の魅力については、画面間の接続を誰かに示していると長い間議論できますが、私の実践が示しているように、プロジェクトが5〜6画面を超えてすぐに、さまざまな会社のいくつかのよく知られている開発者に意図的にインタビューしましたより信頼性の高いソリューションを見つけて、ようやくView Controllerのスタックの構造を頭の中に保持し始めました。 また、iPadやその他のナビゲーションモデルのサポートやプッシュのサポートが追加された場合、すべてが悲しくなりました。

それ以来、この問題を解決するためにいくつかの試みが行われましたが、その中にはView Controller内にView Controllerを作成するとこの巨大で不器用なコードがさらに作成されたため、いくつかは別々のフレームワーク、別々のアーキテクチャパターンになりました。

コーディネーターパターンに戻りましょう。 明らかな理由で、Wikipediaには標準のプログラミング/デザインパターンではないため、その説明はありません。 むしろ、これは一種の抽象化であり、スタックに新しいコントローラーツイストを作成して挿入し、コントローラーコンテナーへの参照を保存し、コントローラー間でデータをプッシュするためのこの「ugい」コードをすべて隠します。 このプロセスを説明する最も適切な記事は、 raywenderlich.comの記事を呼び出します。 2015年のNSSpain会議の後、一般大衆にそのことが伝えられた後、人気が出始めました。 詳細については、 こことここに記載されています 。

次に進む前に、その構成を簡単に説明します。

すべての解釈におけるコーディネーターパターンは、この図にほぼ適合しています。

つまり、コーディネーターはプロトコルです

 protocol Coordinator { func start() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、すべてのcodeいコードはstart



関数に隠されているはずです。 さらに、コーディネーターは子コーディネーターへのリンクを持つことができます。つまり、構成する能力があり、たとえば、ある実装を別の実装に置き換えることができます。 つまり、かなりエレガントに聞こえます。

しかし、不幸はすぐに始まります：

1. いくつかの実装では、特定の生成パターンからコーディネーターをより合理的なものに変え、コントローラーのスタックをモニターし、コンテナーのデリゲート （ UINavigationController
   
   
   
   など）にして、戻るボタンのクリックを処理するか、子コーディネーターをスワイプして削除することをUINavigationController
   
   
   
   しています。 自然な理由により、1つのオブジェクトのみがデリゲートになります。これにより、コンテナー自体の制御が制限され、このロジックがコーディネーターにあるか、このロジックをリストの下の方にさらに委任する必要が生じます。
2. 多くの場合、次のコントローラーを作成するためのロジックはビジネスロジックに依存します。 たとえば、次の画面に進むには、ユーザーがシステムにログインする必要があります。 明らかに、これは非同期プロセスであり、ログインフォームを使用した中間画面の生成が含まれます。ログインプロセス自体は正常に終了するかどうかが異なります。 CoordinatorがMassive Coordinatorに変わるのを避けるために（Massive View Controllerとの類推により）、分解が必要です。 つまり、実際には、コーディネーターのコーディネーターを作成する必要があります。
3. コーディネーターが直面する別の問題は、 UINavigationController
   
   
   
   やUITabBarController
   
   
   
   などのコンテナービューコントローラーのラッパーであることです。 そして、誰かがこれらのコントローラーへのリンクを提供する必要があります 。 子コーディネーターを使用してもすべてが多少明確でない場合、チェーンの最初のコーディネーターを使用すると、すべてがそれほど単純ではありません。 さらに、A / Bテストなどのナビゲーションを変更する場合、そのようなコーディネーターのリファクタリングと適応により、別の頭痛が生じます。 特に、コンテナのタイプが変更された場合。
4. これらすべては、アプリケーションがView Controllerを生成する外部イベントのサポートを開始するとさらに複雑になります。 プッシュ通知やユニバーサルリンクなど（ユーザーがレター内のリンクをクリックし、対応するアプリケーション画面で続行します）。 ここで、コーディネーターパターンに正確な答えがない他の不確実性が生じます。 外部イベントによって要求された次の画面をユーザーに表示するには、ユーザーが現在どの画面にいるのかを正確に知る必要があります。
   
   最も簡単な例は、3つの画面（チャットリスト、チャットリストコントローラーのナビゲーションにプッシュされるチャット自体、およびモーダルで表示される設定画面）で構成されるチャットアプリケーションです。 ユーザーは、プッシュ通知を受信して​​タップすると、これらの画面のいずれかにアクセスできます。 そして、ここで不確実性が始まります、彼がチャットリストにいる場合、この特定のユーザーとチャットを開始する必要があります、彼が既にチャットにいる場合、それを切り替える必要があり、彼が既にこのユーザーとチャットしている場合、何もせずに更新します、ユーザーがオンの場合設定画面-それ、明らかにあなたは閉じて、前の手順に従う必要があります。 または、閉じずに設定でモーダルでチャットを表示することもできますか？ そして、設定がモーダルではなく別のタブにある場合はどうなりますか？ これらは、コーディネーターによって広げられるか、スパゲッティの形で別のメガコーディネーターに行きます。 さらに、コントローラースタックに対するアクティブな反復と、ユーザーが現在どこにいるかを判断する試み、またはその状態を監視する何らかの種類のアプリケーションを構築する試みのいずれかですが、これはコントローラースタック自体の性質に基づいた簡単なタスクではありません。
5. そして、UIKitの不具合はケーキのチェリーです。 簡単な例：2番目のタブにUINavigationController
   
   
   
   があり、他のUIViewController
   
   
   
   。 最初のタブのユーザーは、タブを切り替えUINavigationController
   
   
   
   別のView ControllerをUINavigationController
   
   
   
   する必要がある特定のイベントを発生させUINavigationController
   
   
   
   。 これはすべて、まさにそのような順序で実行する必要があります。 これより前にユーザーが2番目のタブを開いたことUINavigationController
   
   
   
   なく、 viewDidLoad



UINavigationController
   
   
   
   呼び出されなかったviewDidLoad
   
   
   
   、 push
   
   
   
   メソッドは機能せず、コンソールに不明瞭なメッセージのみが残ります。 つまり、この例では、コーディネーターを単にイベントのリスナーにすることはできず、特定の順序で動作する必要があります。 そのため、お互いの知識が必要です。 そしてこれは、コーディネーターは生成コーディネーターについて何も知らず、子コーディネーターのみと接続しているというコーディネーターパターンの最初のステートメントとはすでに矛盾しています。 また、互換性も制限されます。

このリストは継続できますが、一般的に、コーディネーターパターンがかなり制限された拡張性の低いソリューションであることは明らかです。 ピンク色のメガネなしで見ると、通常、大規模なUIViewController



内に記述されているロジックの一部を別のクラスに分解する方法です。 単なる生成的なファクトリー以上のものを作り、そこに別のロジックを持ち込もうとする試みはすべてうまくいきません。

このパターンに基づいたライブラリが存在することは注目に値します。これらのライブラリは、ある程度はこれらの欠点を部分的に緩和することができます。 XCoordinatorとRxFlowに 言及します 。

私たちは何をしましたか？

サポートと開発のために別のチームから得たプロジェクトに参加し、コーディネーターと彼らの簡略化された「great祖母」 ルーターをVIPERアーキテクチャアプローチで使用して、当社の以前の大規模プロジェクトでうまく機能したアプローチにロールバックしました。 このアプローチには名前がありません。 それは表面にあります。 空き時間があるとき、それは別のRouteComposerライブラリにコンパイルされ、コーディネーターを完全に置き換え、より柔軟であることが証明されました。

このアプローチは何ですか？ その中で、スタック（ツリー）に依存するために、コントローラーをそのままひねります。 従う必要がある不必要なエンティティを作成しないため。 条件を保存または追跡しないでください。

UIKitエンティティをより詳しく見て、 最終的に何があるのか​​、何を操作できるのかを考えてみましょう。

1. コントローラスタックはツリーです。 子View Controllerを持つルートView Controllerがあります。 モーダルで提示されるView Controllerは、生成されたView Controllerへのバインディングも持つため、子View Controllerの特殊なケースです。 すぐに使用できます。
2. コントローラーの本質を作成する必要があります。 それらはすべて異なるコンストラクターを持ち、Xibファイルまたはストーリーボードを使用して作成できます。 これらには異なる入力パラメーターがあります。 しかし、それらは作成される必要があるという点で団結しています。 これで、目的のView Controllerを作成する方法を知っているFactoryパターンができました。 各工場は包括的な単体テストで簡単にカバーでき、他の工場からは独立しています。
3. View Controllerを2つのクラスに分割します：1. Controllerを表示するだけです。2. Container View Controller（Container View Controller） 。 コンテナView Controllerは、子View Controllerを含めることができるという点で通常のものと異なります-コンテナまたはシンプルなものも含まれます。 このようなView Controllerは、 UITabBarController
   
   
   
   、 UITabBarController
   
   
   
   などのボックスから使用できますが、ユーザーが作成することもできます。 無視すると、すべてのコンテナで次のプロパティを見つけることができます。1.含まれているすべてのコントローラのリストがあります。 2. 1つ以上のコントローラーが現在表示されています。 3.これらのコントローラーのいずれかを表示するように求められる場合があります。 UIKitコントローラーでできることはこれだけです 。 彼らはこのために異なる方法を持っています。 ただし、タスクは3つしかありません。
4. 工場で作成されたView Controllerを埋め込むために、Controllerの親ViewメソッドはUINavigationController.pushViewController(...)
   
   
   
   、 UITabBarController.selectedViewController = ...
   
   
   
   、 UIViewController.present(...)
   
   
   
   です。 2つのView Controllerが常に必要であり、1つは既にスタック上にあり、もう1つはスタックに埋め込む必要があることに気付くかもしれません。 これをラッパーでラップし、 Action（Action）と呼びます。 各アクションは包括的な単体テストで簡単にカバーでき、それぞれは他のアクションから独立しています。
5. 上記から、準備されたエンティティを使用して、構成チェーンを構築できることがわかりましたFactory- > Action-> Factory-> Action-> Factoryそして、完了後、任意の複雑なコントローラーのビューツリーを構築できます。 エントリポイントを指定するだけです。 通常、これらの入力ポイントは、 UIWindowが所有するrootViewControllerか、ツリーの最も極端なブランチである現在のView Controllerです。 つまり、このような構成は、 ViewController-> Action-> Factory-> ...-> Factoryのように正しく記述されます。
6. 構成に加えて、提供された構成を開始および構築する方法を知っているエンティティが必要になります。 これをRouterと呼びます。 状態がなく、リンクを保持していません。 構成が渡される1つのメソッドがあり、構成手順を順番に実行します。
7. インターセプタークラスを構成チェーンに追加して、ルーターに責任を追加します。 インターセプターには次の3種類があります。1.ナビゲーションを開始する前に起動します。 システム内のユーザー認証タスクと、その他の非同期タスクを削除します。 2. View Controllerの作成時に実行して、値を設定します。 3.ナビゲーションおよびさまざまな分析タスクの実行後に実行されます。 各エンティティは単体テストで簡単にカバーされ、構成でどのように使用されるかわかりません。 彼女には1つの責任しかなく、それを果たします。 つまり、複雑なナビゲーションの構成は、 [事前ナビゲーションタスク...]-> ViewControllerの開始->アクション->（ファクトリー+ [ContextTask ...]）-> ...->（ファクトリー+ [ContextTask ...]）-> [ポストNavigationTask ...] 。 つまり、すべてのタスクはルーターによって順番に実行され、順番に小さくて読みやすいアトミックエンティティを実行します。
8. 構成で解決できない最後のタスクは残ります-これは現時点でのアプリケーションの状態です。 ユーザーが部分的に渡したため、構成チェーン全体ではなく、その一部のみを構築する必要がある場合はどうなりますか？ この質問は、ビューコントローラーのツリーによって常に明確に回答できます。 チェーンの一部がすでに構築されている場合、それはすでにツリー内にあるためです。 これは、チェーン内の各工場が建設されているかどうかの質問に回答できる場合、ルーターはチェーンのどの部分を完了する必要があるかを理解できることを意味します。 もちろん、これはファクトリーのタスクではないため、別のアトミックエンティティが導入されます- 検索エンジン（Finder）および構成は次のようになります： [Pre-navigation Task ...]-> ViewControllerの開始-> Action->（Finder / Factory + [ContextTask ...]） -> ...->（Finder / Factory + [ContextTask ...]）-> [Post NavigationTask ...] 。 ルーターが最後から読み取りを開始すると、ファインダーの1つが既に構築されていることを通知し、この時点からルーターはチェーンの構築を開始します。 それらのいずれかがツリーで自分自身を見つけられない場合、最初のコントローラーからチェーン全体を構築する必要があります。
   
   
9. 構成は厳密に入力する必要があります。 したがって、各エンティティは1種類のコントローラービューでのみ動作します; 1種類のデータと設定は、swiftがrelatedtypesを使用できるかどうかに完全に依存しています。 ランタイムではなく、コンパイラに依存したいのです。 開発者は意図的にタイピングを弱めることができますが、その逆はできません。

そのような構成の例：

 let productScreen = StepAssembly(finder: ProductViewControllerFinder(), factory: ProductViewControllerFactory()) .add(LoginInterceptor<UUID>()) // Have to specify the context type till https://bugs.swift.org/browse/SR-8719 is fixed .add(ProductViewControllerContextTask()) .add(ProductViewControllerPostTask(analyticsManager: AnalyticsManager.sharedInstance)) .using(UINavigationController.push()) .from(NavigationControllerStep()) .using(GeneralActions.presentModally()) .from(GeneralStep.current()) .assemble()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記の項目はライブラリ全体を網羅し、アプローチを説明しています。 残っているのは、ユーザーがボタンをクリックしたとき、または外部イベントが発生したときにルーターが実行するチェーン構成を提供することだけです。 これらがiPhoneやiPadなどの異なるタイプのデバイスである場合、ポリモーフィズムを使用して異なるトランジション構成を提供します。 A / Bテストがある場合、同じことです。 ナビゲーションを開始する時点でアプリケーションの状態を考慮する必要はありません。最初に設定が正しく記述されていることを確認する必要があり、ルーターが何らかの方法でそれを構築することを確認します。

説明したアプローチは、特定の抽象化やパターンよりも複雑ですが、まだ十分ではないという問題に直面していません。 もちろん、 RouteComposerには、それがどのように機能するかについてある程度の調査と理解が必要です。 ただし、これはAutoLayoutまたはRunLoopの基本を学ぶよりもはるかに簡単です。 高等数学はありません。

ライブラリ、およびそれに提供されるルーターの実装は、客観的なランタイムでトリックを使用せず、Cocoa Touchのすべての概念に完全に準拠し、構成プロセスをステップに分割し、指定された順序で実行するのに役立ちます。 ライブラリは、iOSバージョン9〜12でテストされています。

詳細については、以前の記事をご覧ください。

UIViewControllersの構成とそれらの間のナビゲーション（だけでなく）/オタク誌

RouteComposer / geek magazineを使用したUIViewControllersの構成例

ご清聴ありがとうございました。 コメントで質問にお答えします。