Привет, если поделитесь подробностями, постараюсь ответить на первый вопрос :) интересны платформа, модель устройства и хотя бы примерный сценарий использования где тормозит. А если в ЛС скинете видео - сразу тикет заведу
gorbikvv я немного промазал с кнопкой Ответа, так что в отдельном треде получилось :)
Для нас такая ситуация невозможна, внутренние модули не имеют версий, т.к. весь исходный код находится в одном репозитории.
В master действительно лежит самый актуальный код всех модулей. Deps не занимается вытягиванием, исходники тащатся вместе с git pull origin master.
В целом такая проблема есть, но она не очень заметна даже на 100+ модулях. Т.е. при разработке новой функциональности бывает, что нужно менять публичный интерфейс модуля, тогда это действительно может затронуть другие модули и приложения, но случается это не очень часто, и в целом такой подход форсирует разработку более устойчивых архитектур, с интерфейсами, которые скорее придётся расширить, чем изменить.
Привет! На так лишь кажется. Deps не такой уж сложный инструмент, т.к. он оперирует только Build Phases c помощью библиотеки Xcodeproj. Все настройки сборки унифицированы в xcconfig, а deps лишь по «интересным» нам правилам добавляет / удаляет модули в фазах link binaries и embed frameworks.
А вот взять какой-нибудь Swift Package Manager — там нельзя, например, на Package xcconfig постоянный навесить (можно делать override при генерации отдельного проекта, но нам не подходит). Управлять настройками SPM в таком — случае — опять же придется писать какие-то скрипты чтобы обходить все модули, генерить для них проекты с кастомными параметрами сборки и т.д.
В общем, мы руководствовались идеей максимально нативной интеграции в Xcode при максимальной гибкости, и получилось, что создать свой инструмент — довольно быстро и недорого.
Привет, к моменту когда мы решили делить приложение на модули, SPM еще не поддерживал iOS проекты без костылей, поэтому сейчас мы рассматриваем его как потенциальный менеджер зависимостей. Однако, скорее всего, только для внешних зависимостей, т.к. deps (о нем будет чуть подробнее во 2 статье, в течение недели должна опубликоваться) отлично справляется с нашим сложным графом и очень гибок в настройках (по сравнению с SPM, где пока мало параметров Build Settings можно кастомизировать)
Спасибо! Мы его тоже используем, но сейчас только для генерации новых модулей. В целом можно рассматривать переезд на XcodeGen и для большого «взрослого» проекта, но это может быть достаточно трудоемкой задачей.
Привет, спасибо за обратную связь! Извиняюсь за задержку с ответами, идем по порядку:
1-2. UIGallery как раз является таргетом, агрегирующим все UI подмодули. Есть модель, в которой зарегистрированы все интересующие билдеры вьюшек. Когда UIGallery запускается как приложение — из этой модели строится табличка, где по каждому пункту можно провалиться и посмотреть как это выглядит. Когда запускается тест-схема, из добавленных туда примеров автоматически формируется итоговый набор тест кейсов (через XCTestSuite). Генерацию снепшотов и сравнение сейчас делаем с помощью FBSnapshotTestCase, но планируем в ближайшее время переехать на что-то более легковесное и свифтовое. Техникой, как автоматически добавить множество различных конфигураций UIView с разными стилями и вью моделями пока не овладели, поэтому разработчик делает это сам.
3. Всю верстку сейчас пишем кодом, активно отрабатываем переход на SwiftUI, но пока что не можем отказаться от iOS 12 из-за неутешительной статистики ее использования.
4. Об этом будет в следующей статье, в целом стоит лишь выключить галочку Find Implicit Dependencies и посмотреть где что не прилинковано после Clean Build. А так — да, дальше расскажу поподробнее как мы работаем с этим при большом количестве модулей.
NoFearJoe, как думаешь, можно ли считать проблемой в таком подходе, что в протокол открывается внутренняя реализация? Т.е. наружу от роутера начинает торчать не только close(), но и transitionHandler, а от интерактора service?
И, как понимаю, сделать их private тоже нельзя, т.к. тогда нельзя будет инжектить снаружи.
В первой статье показаны другие способы, которые в принципе не затронуты в моей статье, а вторая и третья вместе — раскрывают второй пункт — оптимизацию через рефакторинг кода, поэтому я не могу с Вами согласиться по поводу того, что это статьи про то же самое.
Но спасибо за дополнение, было интересно почитать.
Иногда дефолтные параметры не привязаны напрямую к классу, а зависят от места использования класса. То есть в рамках, например, двух разных таблиц плейсхолдеры для лейблов одной и той же ячейки могут быть разными, но в рамках одного адаптера — одни и те же.
Jenkins не решает проблемы сборки приложения на компьютере разработчика (если вы про CI говорите). Прежде чем послать pull-request у нас считается хорошей практикой потестировать написанный код собственными руками в наиболее типичных кейсах реализованной функциональности, для чего и необходимо собрать приложение «у себя».
Привет, если поделитесь подробностями, постараюсь ответить на первый вопрос :) интересны платформа, модель устройства и хотя бы примерный сценарий использования где тормозит. А если в ЛС скинете видео - сразу тикет заведу
gorbikvv я немного промазал с кнопкой Ответа, так что в отдельном треде получилось :)
А вот взять какой-нибудь Swift Package Manager — там нельзя, например, на Package xcconfig постоянный навесить (можно делать override при генерации отдельного проекта, но нам не подходит). Управлять настройками SPM в таком — случае — опять же придется писать какие-то скрипты чтобы обходить все модули, генерить для них проекты с кастомными параметрами сборки и т.д.
В общем, мы руководствовались идеей максимально нативной интеграции в Xcode при максимальной гибкости, и получилось, что создать свой инструмент — довольно быстро и недорого.
1-2. UIGallery как раз является таргетом, агрегирующим все UI подмодули. Есть модель, в которой зарегистрированы все интересующие билдеры вьюшек. Когда UIGallery запускается как приложение — из этой модели строится табличка, где по каждому пункту можно провалиться и посмотреть как это выглядит. Когда запускается тест-схема, из добавленных туда примеров автоматически формируется итоговый набор тест кейсов (через XCTestSuite). Генерацию снепшотов и сравнение сейчас делаем с помощью FBSnapshotTestCase, но планируем в ближайшее время переехать на что-то более легковесное и свифтовое. Техникой, как автоматически добавить множество различных конфигураций UIView с разными стилями и вью моделями пока не овладели, поэтому разработчик делает это сам.
3. Всю верстку сейчас пишем кодом, активно отрабатываем переход на SwiftUI, но пока что не можем отказаться от iOS 12 из-за неутешительной статистики ее использования.
4. Об этом будет в следующей статье, в целом стоит лишь выключить галочку Find Implicit Dependencies и посмотреть где что не прилинковано после Clean Build. А так — да, дальше расскажу поподробнее как мы работаем с этим при большом количестве модулей.
И, как понимаю, сделать их private тоже нельзя, т.к. тогда нельзя будет инжектить снаружи.
Но спасибо за дополнение, было интересно почитать.