Со временем размер приложения начал увеличиваться, стали появляться новые функции и, в конечном итоге, увеличилось количество контроллеров представления.
Моя раскадровка увеличилась в размерах, и это напрямую повлияло на производительность загрузки раскадровок. Это было очевидно, поскольку раскадровка - это не что иное, как скрытый за сценой xml-код. Чем больше строк кода, тем больше времени потребуется для загрузки. Кроме того, теперь стало головной болью прокручивать такую огромную раскадровку, чтобы найти и исправить мелочь. То, что мне нравилось, теперь стало болевой точкой. На этом этапе я начал проектировать ячейки представлений и другие представления в отдельных файлах пера. Это немного снизило нагрузку на раскадровки и позволило контролировать ее размер. Тем не менее, это не было хорошим решением.
Спаситель.
Я наткнулся на статью Чистый код для нескольких раскадровок.
Наши приложения обычно имеют разные модули или разные пользовательские потоки. Мы можем сгруппировать эти контроллеры представлений либо по «потокам пользователей», либо по «модулям» и создать отдельные раскадровки для каждого потока / модуля пользователя. Теперь перемещаться по раскадровке стало намного проще. Кроме того, он контролировал размеры файлов раскадровки, что сокращало время загрузки.
Спаситель? Не долго.
Вскоре несколько разработчиков присоединились ко мне над приложением, и те, кто работал над GIT с раскадровками, знают это… Это просто не работает! Конфликты слияния здесь просто не могут быть разрешены. То, как Xcode отображает конфликты слияния для раскадровок, - это отдельная история. Пройдя через множество конфликтов слияния, мои коллеги теперь боялись услышать слово «слияние».
Планируйте свое развитие
К счастью, мне удалось решить эту проблему, спланировав разработку таким образом, чтобы у каждого разработчика был свой собственный модуль для работы. Следовательно, скажем, Разработчик-1 работал над Модулем-1, у которого была собственная Раскадровка-1. Я работал над другим модулем, у которого была собственная раскадровка. Это в значительной степени уменьшило конфликты слияния в раскадровках, поскольку два разработчика не работали над одной и той же раскадровкой одновременно.
Уф, жизнь здесь решилась.
Пока не…
У iOS были на меня другие планы. Теперь наступил момент, когда нам было поручено разработать функции, которые были бы доступны в одних выпусках и отсутствовали в других. Очевидно, мы не могли продолжать копировать эти функции, когда это необходимо, и удалять, когда они не нужны. Для решения этой проблемы на помощь пришли Feature-ветки. Мы начали разрабатывать эти дополнительные функции или запросы на изменение в собственных ветках. Теоретически все было хорошо, пока ... нам не пришлось объединить наши функциональные ветки в нашу ветку разработки. Конфликты слияния вернулись со словами: «Скучал по мне?»
Наконец-то пришло время ...
Это было время, когда я должен был спросить себя…. Раскадровки или нет раскадровок? При всем уважении к преимуществам, которые дает раскадровка, она просто не может идти рука об руку с Git. Это был самый большой недостаток для нашей команды, которая в настоящее время работала над большим продуктом с множеством функций и множеством разработчиков. Поэтому мы начали разрабатывать новые пользовательские интерфейсы, особенно в функциональных ветках, программно, без использования раскадровок.
Поверьте мне, это будет сложно вначале, особенно если вы никогда не разрабатывали пользовательский интерфейс программно, но это становится намного проще. И с долгосрочными преимуществами, которые он дает, это определенно лучший вариант. Подводя итог, вот плюсы и минусы использования раскадровок:
Плюсы: упрощает создание прототипов, более быструю разработку пользовательского интерфейса, оперативную обратную связь в Interface Builder, доступные атрибуты.
Минусы: нет надлежащей возможности повторного использования, отсутствие совместной работы, конфликты слияния с Git, время загрузки раскадровки прямо пропорционально размеру раскадровки.
Заключение - Prior SwiftUI
Когда можно использовать раскадровки?
- Продолжительность жизни - недолго
- Размер приложения - маленький или средний
- Количество разработчиков - 1!
Несколько советов по этому поводу -
- С самого начала придерживайтесь подхода использования нескольких раскадровок.
- Создайте архитектуру своего приложения на логические модули и соответствующим образом разделите раскадровки.
- Кроме того, чтобы контролировать размеры раскадровок, используйте отдельные файлы пера для разработки ячеек TableView и CollectionView, а также других многоразовых представлений, где это возможно.
Когда следует избегать раскадровки?
- Продолжительность жизни - Недолго!
- Размер приложения - большой
- Количество разработчиков - 2 и более
Несколько советов по этому поводу -
- Используйте гибридный подход с несколькими раскадровками, настраиваемыми представлениями и ячейками представления в NIB и программным созданием представлений.
- Чтобы работать с контролем версий и избежать головной боли, связанной с конфликтами слияния, спланируйте разработку таким образом, чтобы два разработчика не работали над одной раскадровкой одновременно.
Заключение - Post SwiftUI
Я серьезно? Есть ли необходимость использовать раскадровки, а не SwiftUI? При всей мощности, простоте, реактивности и т. Д. И т. Д., Которые он предлагает?
Получается ДА !!! Если вы хотите, чтобы ваши приложения поддерживали iOS13, вы не можете использовать SwiftUI.
Так что, я думаю, «когда» и «когда не нужно» теперь сводятся к одному пункту. Вы хотите, чтобы ваше приложение поддерживало версию ОС ниже iOS 13? При этом мы также можем сказать, что будущее раскадровок будет зависеть от - «До тех пор, пока приложения не будут поддерживать iOS 12 и ниже».
Если вам понравилась эта статья, спамьте кнопку хлопка 👏 и поделитесь ею с другими разработчиками iOS. Если у вас есть собственная Story-Board-Story, поделитесь ею в комментариях. Если вам есть что обсудить относительно раскадровки или любой другой темы, связанной с разработкой, дизайном, проектированием мобильных приложений… Оставьте комментарий ниже или напишите мне в Twitter :)
Если вам это интересно, скорее всего, вы тоже найдете мою ленту в Твиттере! Я продолжаю ежедневно делиться статьями и прочим, связанным с разработкой, дизайном и производительностью. Так что подпишитесь на меня в Twitter и наслаждайтесь познавательной поездкой!
До следующей статьи…
