Typhoon без Info.plist

Интеграция с Info.plist — одна из приятных мелочей, которая делает Typhoon более дружелюбным к конечному пользователю. Что может быть проще — написал новую TyphoonAssembly, добавил в plist-файл — и все, остальное сработает за тебя самостоятельно. До тех пор, пока сам не заинтересуешься деталями реализации, под капот лезть не придется. Такой подход хорош для небольших приложений, в которых используется пара-тройка assembly — одна для контроллеров, другая — для сервисных объектов, третья — для всяких полезных мелочей. Но когда приложение начинает расти, либо в чью-то светлую голову приходит желание внедрять VIPER — начинаются проблемы.

В чем, собственно, состоит проблема VIPER в данном случае? Каждому модулю соответствует своя Assembly, задача которой — инициализировать и связать друг с другом все компоненты текущего модуля. Получаем минимум по одной assembly на экран. Захотели декомпозировать модули еще сильнее — смело увеличиваем это число. В итоге plist разрастается до неимоверных величин:
TRL6f1c47eyb6pSomhm-grNprK2Xlz9dQ2ZTkTqXPG4

Простой способ обойти эту проблему — отказаться от использования Info.plist и реализовать в AppDelegate метод:

Он дергается автоматически при первичной инициализации стека Typhoon, и ожидается, что он вернет массив классов assembly, которые нужно активировать.

Вторая часть решения — вместо того, чтобы указывать все классы вручную, проще собирать их в рантайме. Завязываться можно либо на нейминг (AuthorizationModuleStartupAssembly, где Startup — ключевое слово), либо на реализацию определенного протокола. Второй способ выглядит чище и защищен от последствий опечаток.

В первую очередь получаем список всех классов проекта:

Затем проходимся по ним циклом и сохраняем те, которые удовлетворяют поставленному нами условию:

В этом случае все, что нужно, чтобы добавить новую Assembly, это реализовать соответствующий протокол:

В последнее время мы в Rambler&Co стали очень активно выкладывать в open-source многие из наших наработок, в том числе и под RamblerTyphoonUtils, в составе которого есть реализующий описанную выше логику класс RamblerInitialAssemblyCollector.

И, как водится, будем рады новым Issues и Pull Request’ам, как в Typhoon, так и в наши велосипеды.

  • Max Kurpa

    Добрый день. Но если мы используем VIPER, и у нас куча разных Assembly у каждого модуля, то почему бы не активировать их в момент перехода в новый модуль. Как раз ваши ребята предложили грамотный способ передачи данных между модулями (https://www.youtube.com/watch?v=XvAHqDvGqzE). Почем бы, предварительно, непосредственно перед переходом в новый модуль не инжектить зависимости по поддерживаемому протоколу, например, как вы предложили?

    И немного не понятно зачем сразу инжектить все зависимости (или я не так понял?). Можно же для каждого модуля написать протокол и на основании этого инжектить все нужное непосредственно в момент перехода?

    Спасибо

  • http://etolstoy.ru etolstoy

    @maxkurpa:disqus Добрый!

    Активация всех Assembly в момент старта приложения — это логика работы Typhoon — такой подход позволяет правильно менеджерить жизненные циклы всех объектов (к примеру, Typhoon ищет все зависимости со scope Singleton, создает их и кладет в отдельный пул).

    Использование Typhoon позволяет отделить процесс передачи данных в модуль от процедуры его создания и проставления всех зависимостей — об этом говорит Сергей Крапивенский в другом докладе с нашей встречи (под номером 2).

  • Pingback: Best Writing Service()

  • Pingback: apush american revolution essay questions()

  • Pingback: Best Writing Service()