Android-разработка: принципы, паттерны, архитектура

Мобильная разработка — одна из самых динамично развивающихся областей IT. В интервью с аndroid-разработчиком Григорием Паравяном мы погружаемся в детали современных подходов к построению архитектуры мобильных приложений. Григорий делится своим видением популярных архитектурных паттернов, подходов к управлению состоянием, а также принципами, которые помогают создавать масштабируемые и устойчивые решения.

На мой взгляд, наиболее подходящий подход для разработки сейчас — это сочетание MVVM и State. Этот вариант представляет собой MVVM с элементами MVI, где мы используем два выхода на UI: единый state для отображения текущего состояния и effect для событий. Это отличается от классического MVVM, где для каждого поля выделяется своя LiveData.

Такой паттерн проще, чем MVI, который нагружает на реализацию классов Action. При этом он более гибкий, чем MVP, где приходится напрямую вызывать UI функции из Presenter.

Да, использую. Но выбор зависит от подхода и используемого фреймворка. Например, для Jetpack Compose можно рассмотреть Modo, где уже реализован базовый родительский класс для ViewModel. Кроме того, я заметил тенденцию постепенного отказа от использования LiveData, в сторону Flow, т.к он более гибкий и функциональный. Эти компоненты помогают при создании архитектуры, упрощают разработку и избавляют от необходимости вручную реализовывать базовые вещи и решения.

На основе моего опыта работы с различными проектами, не всегда есть необходимость делить архитектуру на доменный слой. В некоторых случаях разделение бывает излишним и только усложняет разработку. Однако, если приложение изначально планируется крупным или постепенно разрастается, разделение на слои становится важным.

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

Рекомендуется отделить UI и состояние в ViewModel, используя единый data class с Flow для удержания состояния. Для повышения модульности и тестируемости нужно создать интерфейс-обертку для состояния/эффекта (Flow или LiveData). Это упростит замену реализации и облегчит тестирование, обеспечит гибкость архитектуры.

У меня был опыт переписывания UI-архитектуры в крупном приложении для поддержки как Compose, так и View. Исходя из этого опыта и работы над собственными проектами с полноценной архитектурой, я придерживаюсь подхода Clean + SOLID. Эти принципы помогают написать чистый и читаемый код, но могут немного усложнить его понимание из-за наличия абстракций.

Есть принципы, несоблюдение которых не критично, но это всегда сказывается на читаемости кода. Поэтому лучше стараться следовать всем принципам, насколько это возможно. Это позволяет поддерживать высокое качество и понятность кода, что важно для работы в команде и долгосрочной поддержки проекта.