Jetpack Compose, навигация, многомодульная архитектура, модули API и Impl, внедрение зависимостей - в этом сообщении блога мы увидим, как эти компоненты можно объединить в масштабируемую многомодульную архитектуру, используя лучшие практики разработки Android. Мы также увидим, как использовать Compose Navigation API для эффективной навигации по функциям в многомодульных приложениях.
Pavlo StavytskyiКаждая функция приложения может быть представлена на диаграмме ниже и состоит из модулей API и реализации. Часть API содержит открытый интерфейс функции, включая абстрактную @Composableточку входа в нее и поставщика зависимостей DI. Все детали реализации функции хранятся в модуле Impl.
В этом сообщении блога мы рассмотрим каждый компонент этой схемы, включая реализации кода, чтобы вы имели четкое представление о том, как это работает.
Мы попробуем все концепции на практике на примере Android-приложения, исходный код которого можно найти на GitHub.
MorflyЭтот проект также можно собрать с помощью системы сборки Bazel. Используйте //app:binцель для создания и запуска приложения с помощью Bazel.Многомодульная архитектура
Хорошо. Вы видели название. Речь идет не о любом приложении Jetpack Compose, а о многомодульном . Но что отличает многомодульные проекты? Что ж, они определенно более сложные с точки зрения архитектуры. И, что наиболее важно, их очень легко испортить, поэтому у вас больше нет преимуществ, которые они приносят, но все же вам придется иметь дело с повышенной сложностью.
Однако одна из основных целей многомодульных архитектур - разделение. Разделение многих аспектов. Логическое разделение на функциональные модули для упрощения разработки и сопровождения кодовой базы. И разделение ради эффективных сборок.
Последнее становится все более важным по мере роста проекта. Таким образом, вместо того, чтобы каждый раз строить весь монолит, система сборки будет постепенно перестраивать только те модули, которые были изменены. И, конечно, те, кто от них зависит.
Итак, чтобы сделать многомодульную архитектуру эффективной и масштабируемой, важно правильно определить правила, по которым модули будут зависеть друг от друга.
Как мы делаем это? Прежде всего, мы можем логически разделить все модули в нашем проекте на 3 категории, такие как функциональные модули, библиотечные модули, модули инжектора .
Начнем с самого интересного. Функциональные модули. Они представляют собой некоторые конкретные компоненты приложения, которые можно рассматривать как отдельные функции. При работе с функциями мы должны убедиться в следующем:
- Каждый функциональный модуль в проекте должен напрямую зависеть от как можно меньшего количества модулей.
- Каждый модуль, от которого зависит наша функция, должен быть как можно меньше.
Для этого мы разделим каждую функцию на 2 модуля: API и реализацию (Impl) . Модуль API представляет собой публичный интерфейс / фасад функции. Он содержит только набор интерфейсов Java / Kotlin, которые определяют точку входа в функцию. Он также включает сущности, которые предоставляет своим потребителям посредством внедрения зависимостей. Этот модуль должен быть как можно меньше.
Модуль Impl, с другой стороны, содержит все детали реализации функции. Более того, если какой-либо другой модуль хочет использовать эту функцию, он может зависеть только от своего модуля API, но не от реализации.
Другой тип модулей - это библиотечные модули. Это простые модули, которые содержат некоторую общую логику, которая используется другими функциями. Здесь ничего особенного.
Наконец, у нас есть инжекторный модуль. Это корневой модуль, который служит точкой входа в приложение. Его основная цель - настроить граф зависимостей для всего приложения. Поэтому его называют «инжектором». Когда приложение запускается, такие модули выполняют свою работу, а затем делегируют выполнение определенным функциональным модулям. Модуль инжектора зависит от всех других модулей проекта.
Например, это может быть обычный модуль приложения , который есть в вашем Android-проекте.
Объединение всех 3-х типов модулей в проекте позволяет нам увидеть многомодульную структуру проекта на диаграмме ниже.
Конкретный пример проекта
Чтобы немного упростить демонстрацию, мы будем использовать конкретный пример проекта, основанного на концепциях, обсуждаемых в сообщении в блоге.
В нашем примере проекта будет отображаться список изображений, загруженных разными пользователями. Таким образом, он состоит из 3 основных функций. Функция изображений реализует функцию подачи для отображения содержимого пользователю. Функция профиля показывает подробную информацию о конкретных пользователях и загруженных ими изображениях. Наконец, функция данных представляет уровень данных приложения в соответствии с чистой архитектурой и отвечает за предоставление контента для других функций.
Все функции зависят от общего библиотечного модуля, который содержит общий код проекта. Мы увидим это более подробно позже в этом сообщении в блоге.
