Когда вы начинаете создавать приложение, в котором хотя бы несколько экранов, всегда встает вопрос - как лучше реализовать навигацию. Вопрос становится интереснее и сложнее, когда вы собираетесь делать многомодульное приложение. Примерно полтора года назад я рассказывал как можно реализовать навигацию c помощью Jetpack в многомодульном проекте. И вот спустя время, я наткнулся на свою реализацию и понял, что можно на том же Jetpack летать по модулям проще: без магии и DI.

Сегодня почти в каждом проекте существует хотя бы базовая инфраструктура, включающая в себя систему хостинга кода проекта (Github, Bitbucket и др.) и систему его сборки (Teamcity, Jenkins и др.). Мы в ЦФТ активно используем Bitbucket server и Teamcity в наших пайплайнах. Подкатом я расскажу, как мы настроили взаимодействие этих сервисов, с какими трудностями столкнулись и как с ними справились.

Сегодня почти у каждого проекта мобильного приложения есть базовая инфраструктура: ваш код хранится на git хостинге и весь новый код регулярно проверяется на CI, чтобы не сломать старый. Если ваша команда в несколько человек производит не очень много кода, то скорее всего вы настроили весь пайплайн один раз и радуетесь его работе. Но что если ваша мобильная команда это пара десятков или даже сотен разработчиков? Много разработчиков производят много кода, что создает нагрузку на инфраструктуру, увеличивает вероятность сломать важные флоу приложения и просто навсего унести время сборки проекта в небеса. Единожды кем-то настроенный пайплайн обречен на изменения, если он не справляется с нагрузкой.

Вы уже наверное поняли о чем пойдет речь под катом? В виде интересной истории я расскажу вам про типичные проблемы мобильных команд (да-да, вы можете узнать в них свои), а также что такое Mobile DevOps, как он поможет решить проблемы и, наконец, как получить этот самый Mobile DevOps к вам в команду.

Почти каждый растущий проект рано или поздно начинает смотреть в сторону многомодульной архитектуры. Разработчики не хотят ждать пока пересобирается полностью весь проект, когда была изменена только одна фича. Многомодульность помогает изолировать фичи приложения друг от друга, тем самым сокращая время сборки. Но такое изолирование накладывает некоторые ограничения на область видимости компонентов. Когда мы используем навигацию из Jetpack в проекте с одним модулем, граф навигации доступен из любого пакета приложения, мы всегда можем явно указать какой action NavController должен выполнить, а также есть доступ к глобальному хосту, если в проекте есть вложенные фрагменты. Но когда модулей становится много, то возникают вопросы: где строить граф навигации, как получать к нему доступ и как не запутаться в зависимостях модулей. Обо всем этом поговорим под катом.

Из проекта в проект мы замечаем, что наш код, выполняет одни и те же функции и выглядит почти одинаково. Это заставляет задуматься — а не выполняем ли мы лишнюю работу, переписывая одно и то же? Мы начинаем копировать классы из предыдущих проектов и все равно понимаем, что делаем что-то не то и оказываемся правы — просто копируя классы из проекта в проект, мы запросто можем что-то потерять/заменить/затереть, а если еще наша команда ведет несколько проектов одновременно, то обнаружение ошибок в заимствованных классах потребует изменений вручную во всех проектах. Устав наступать на эти грабли, мы решаем, что нужен общий код, который будет расшариваться на все наши проекты и любые изменения в нем будут легко подтягиваться. Да, мы создаем свою библиотеку переиспользуемых компонентов! О разных способах организовать свою библиотеку, о всех плюсах и минусах подходов вы узнаете под катом :)

Наверняка каждый Android разработчик работал со списками, используя RecyclerView. А также многие успели посмотреть как организовать пагинацию в списке, используя Paging Library из Android Architecture Components.

Все просто: устанавливаем PositionalDataSource, задаем конфиги, создаем PagedList и скармливаем все это вместе с адаптером и DiffUtilCallback нашему RecyclerView.

Но что если у нас несколько источников данных? Например, мы хотим иметь кэш в Room и получать данные из сети.

Кейс получается довольно кастомный и в интернете не так уж много информации на эту тему. Я постараюсь это исправить и показать как можно решить такой кейс.