Добрый день! Так точно, все правильно поняли, пока только во время активной разработки используется. Но, в целом, ничего не мешает попробовать внедрить решение на этап тестирования, только тут надо будет обдумать и посоветоваться с QA-командой. Опыт написания автотестов у нас имеется, но пишутся они все же на реальное приложение - помимо проверки логики модуля можно попутно проверить и его интеграцию. Если говорить о ручном тестировании и проведении смоука - тут опять же важно понять, не отвалилась ли интеграция той или иной проверяемой фичи.
Возможное применение, которое я вижу - проведение тестов большой фичи со сложной логикой, которая, к тому же, располагается в труднодоступном месте, в таком вспомогательном приложении во время ручных/автотестов (чтоб время на перемещение между экранами не терять) + отдельное проведение интеграционных тестов на реальном приложении.
Помимо тестов такая система неплохо помогает, если есть весьма похожие внешне экраны с практически или совершенно разной логикой: ViewInput/Output протоколы позволяют легко и непринужденно подсунуть к готовой View другой Presenter с новой логикой.
В качестве примера, из последнего, когда такой прием применял — экран карты неких объектов. В одном кейсе экран представлял собой просто View с минимум логики, где даже запрос не выполнялся, в другом — самостоятельный полноценный экран -> View одна и она переиспользуется, просто к ней подсовывается в каждом случае свой Presenter
Отлично, спасибо за информацию! Тогда точно пора обратить свой взор на настройку окружение через .xcconfig.
Но отдельно замечу, что хотя подход с таким скриптом сам по себе решает одну определенную проблему, которую и можно было бы избежать в принципе, но сам опыт оказался полезным. Приятно было отвлечься и попробовать себя в несколько иной роли, кроме iOS-разработчика, плюс найти подход и выявить проблемы с запуском самописных скриптов)
Чувствую, пора еще раз посмотреть в сторону .xcconfig)
Только один вопрос есть. Где-то полгода назад на онбординге один разработчик как-то пытался реализовать такой подход, но завяз с тем, что разные бандлы => разные проекты в firebase => разные .plist файлы для конфигурации аналитики. И реализовать корректное их подтягивание в зависимости от конфигурации у него с ходу не получилось. Может быть у вас есть какие-то рецепты для таких случаев?
Значит, я вас все же правильно понял) Да, это уход в сторону дробления приложения на модули, и в данный момент новые проекты у нас уже создаются с многомодульной архитектурой. И это, конечно, правильно) Но, как сказал выше, тратить время на проект в стадии неспешной поддержки, с вероятностью скорого её прекращения, да к тому же с большими шансами получить гору импакта, показалось нецелесообразным.
А не могли бы вы более детально раскрыть суть вопроса? Вся кодовая база у нас естественно лежит в общем репозитории, с которым работает вся команда. Если же вы имели в виду, что можно весь проект разбить на отдельные модули, в рамках которых описанных проблем бы не возникло, — то данный подход не рассматривался, ибо второй таргет был добавлен «на коленке» в свободное от работы время, а времени на внедрение многомодульной архитектуры не было) Да и нецелесообразно это было, в силу большого количества легаси-кода на проекте, и как следствие большой сложности и огромного количества импакта
В свое время в студии мы проводили исследование, где выясняли, что нам лучше подходит для разделения сборок под разное окружение, в котором в том числе рассматривался подход и с .xcconfig, и со схемами, и с разными таргетами. Выбор тогда пал на использование таргетов, так как описанный подход позволяет более явно разделять файлы (вроде GoogleService-Info.plist) между таргетами, плюс на тот момент в разработке были проекты, где нужны были реально разные инстансы приложений (случай брендирования одного приложения с дополнением различной логики в зависимости от конкретного таргета). Но соглашусь с вами, это добавляет головной боли, и в конкретно данном случае вполне мог подойти подход с использованием указанной вами связки)
Добрый день! Так точно, все правильно поняли, пока только во время активной разработки используется. Но, в целом, ничего не мешает попробовать внедрить решение на этап тестирования, только тут надо будет обдумать и посоветоваться с QA-командой. Опыт написания автотестов у нас имеется, но пишутся они все же на реальное приложение - помимо проверки логики модуля можно попутно проверить и его интеграцию. Если говорить о ручном тестировании и проведении смоука - тут опять же важно понять, не отвалилась ли интеграция той или иной проверяемой фичи.
Возможное применение, которое я вижу - проведение тестов большой фичи со сложной логикой, которая, к тому же, располагается в труднодоступном месте, в таком вспомогательном приложении во время ручных/автотестов (чтоб время на перемещение между экранами не терять) + отдельное проведение интеграционных тестов на реальном приложении.
В качестве примера, из последнего, когда такой прием применял — экран карты неких объектов. В одном кейсе экран представлял собой просто View с минимум логики, где даже запрос не выполнялся, в другом — самостоятельный полноценный экран -> View одна и она переиспользуется, просто к ней подсовывается в каждом случае свой Presenter
Но отдельно замечу, что хотя подход с таким скриптом сам по себе решает одну определенную проблему, которую и можно было бы избежать в принципе, но сам опыт оказался полезным. Приятно было отвлечься и попробовать себя в несколько иной роли, кроме iOS-разработчика, плюс найти подход и выявить проблемы с запуском самописных скриптов)
Только один вопрос есть. Где-то полгода назад на онбординге один разработчик как-то пытался реализовать такой подход, но завяз с тем, что разные бандлы => разные проекты в firebase => разные .plist файлы для конфигурации аналитики. И реализовать корректное их подтягивание в зависимости от конфигурации у него с ходу не получилось. Может быть у вас есть какие-то рецепты для таких случаев?