iOS開発者として、最初は少し退屈だったと認めますが、一般に、展示会での報告（会議）のほかに、非常に多くの興味深い点がありました。 特に注目に値するのは、再指導からの素敵な姉妹の言及です（素敵な写真に感謝します！）そして、この技術的なIT会議に美の寛大な部分を追加した人類の美しい半分のすべての魅力的な代表者。
そして今、レポート自体について。 繰り返しになりますが、iOS開発者として、主にRambler＆CoのYegor TolstoyのVIPERと、PostforpostのAlexander Orlovの「スムーズなTableViews」に関するレポートに興味がありました。 みんなは失望しなかった-それはとてもクールだった！ 私は長い間VIPERを研究してきました。会議のスピーカーと参加者が答えを見つけるのに役立ったいくつかの質問がありました。
たとえば、「あるInteractorのコードの一部を別のInteractorで使用する必要がある場合はどうすればよいですか？」という質問に興味がありました。 答えは非常に簡単です-特別なサービスレイヤーを選択します（すべての再利用可能なコードがあります）。
ただし、コールバックには非常に不快な欠点があるため、サービスにはコールバック関数を使用する必要があるという事実に同意できません：コールバックでコールバックを使用して別の関数を呼び出す必要がある場合、このヌードルが表示されます：
[self someFunctionWithCallbackOnSucces:^{ [weakSelf anotherFunctionWithCallbackOnSucess:^{ // some code 1 } andFail:^{ // some code 1 }]; } andFail:^{ [weakSelf andTheOtherFunctionWithCallbackOnSucess:^{ // some code 2 } andFail:^{ // some code 2 }]; }];
私の主観的な意見では、これはコードの可読性を大幅に低下させます。 この点では、同じデリゲートがより望ましいように見えます（ただし、デリゲートは、多くに接続されている場合、あまり良く見えません）。
説明します。 前述のとおり、Yegorはレポート「VIPER Secrets」-「ルーターはルーティングする必要があります。」 しかし、問題は、たとえば、Jeff GilbertとConrad StollによるVIPERの「参照」実装（objc.ioの記事）で、特定のワイヤフレームが言及されていることです。
1.すべてのコンポーネントを作成します
2.依存関係を構成します（dependecyインジェクション）
3.ルート
これは、単一責任の原則とあまり一致していません。 私が理解しているように、ランブラーでは、これに次のスキームが使用されます。
1.ストーリーボードで、どこから行くかを設定します
2.ルーターでprepareForSegueをインターセプトし、初期化を実行します
3.台風はDependecy Injectionを行います
私の主観的な見方では、これは「正しさ」を生み出しますが、これらすべてのタスクを明示的なクラスに入れることはより「正しい」でしょう。 それは：
@interface ModuleA_Router () <ModuleA_Router_Protocol> @property id<ModuleA_DependencyInjector> di; @property id<ModueA_ViewFactory> viewFactory; @property id<ModuleA_InteractorFactory> interactorFactory; @property id<ModuleA_PresenterFactory> presenterFactory; @end @implementation ModuleA_Router - (void)showViewForModuleA { // create id view = [self.viewFactory createViewForModuleAWithParams:...]; id presenter = [self.presenterFactory createPresenterForModuleAWithParams:...]; id interactor = [self.interactorFactory createInteractorForModuleAWithParams:...]; // inject dependencies [self.di configureModuleAWithView:view presenter:presenter interactor:interactor]; [self.navigationController pushViewController:view]; } @end
このアプローチでは、どのツールがDIに使用されるかは関係ありません。オブジェクトの作成は、実際にテストするファクトリクラスに完全に転送されます。 これは、「「表示」、「プレゼンター」、「インタラクター」という用語はそれぞれ特定のエンティティではなく、レイヤー（一般的な場合、複数のクラスで構成できる）であるというステートメントと矛盾しません。
別のスピーカー、つまりKule Fullerは、理想的なルーターがどうあるべきかという質問を私に明らかにしました。 彼のレポートでは、彼の移行全体がステートマシンであると述べました。 一種の啓発になったのは私です。
実際、ルータコードをより正確に表現することが可能になりました。たとえば、次のように、画面から画面への論理的な遷移を有限状態マシンとして描きましょう。
+ -------------------- + + --------------------- +
| 状態：| ----- {正しいログインパスワード} ----> | 状態：|
| 認証| | ホームページ|
| | | |
+ -------------------- + + --------------------- +
|
{間違ったログインパスワード}
|
|
+ --------------------- +
| 状態：|
| 登録|
| |
+ --------------------- +
この場合、もちろん、有限状態マシンとは、部分遷移関数（および、最適化のための状態でのカウンターの使用）を持つオートマトンを意味します。 4人のギャングの状態パターンも参照してください。
さらに、EgorとRamblerは、VIPERに関連する多くの開発を世界に紹介しました。 どうもありがとう！
私の意見では、言及に値する別のレポートは、TableViewの最適化に関するレポートです。 残念ながら、レポート自体は短く、質問する時間がありませんでしたが、個人的な会話の中で、Alexander OrlovからComponents KitとAsyncDisplayKitの違いを見つけることができました。 また、アレクサンダーは、最適化するために、自動レイアウトを放棄してレイアウトを自分で行うのが理にかなっていると言いました。 当然、これはあなたがしなければならないことではなく、あなたの頭で考えることによって行われなければなりません （ ハードコードはありません！ ）。 この原則の有能な実装はgithub.com/plasmLC/PPlayerで見つけることができます。 アレクサンダーは、切実なニーズなしにCollectionViewを使用しないことも推奨しました。
公平には、Sally Shpeardの「Developing for Apple TV」、Brigit Lyonsの「サウンドクラウドの本物のテスト」、Chris Eidhofの「SwiftのようなAPI」からのレポートも非常に有益で有用であると言う必要があると思います。
会議の価値ある「文脈」を提供してくれた主催者と、有益な一日を過ごした講演者に感謝します！