Декларативный подход как тенденция в разработке интерфейсов мобильных приложений

За каждым приложением стоит отдельный набор средств и библиотек для создания пользовательского интерфейса. Эти библиотеки и фреймворки играют огромную роль в том, как создаются приложения, а также насколько они производительны. Каждое средство имеет свой подход описания экранных форм в виде кода, но данные подходы можно обобщить до 2 групп: декларативной и императивной.

Исторически сложилось, что иерархия элементов интерфейса Android была представлена в виде дерева виджетов. По мере изменения состояния приложения, иерархию пользовательского интерфейса необходимо обновлять для отображения актуальных данных. Наиболее распространенным способом обновления интерфейса является обход дерева с помощью функций, а изменение отображения происходит путем вызова методов этих узлов, то есть изменения внутреннего состояния виджета.

Манипулирование представлениями вручную увеличивает вероятность ошибок. Если фрагмент данных отображается в нескольких местах, легко забыть обновить одно из отображающих его представлений. Также легко создавать ошибочные состояния, когда два обновления конфликтуют неожиданным образом. Например, обновление может попытаться установить значение узла, который только что был удален из пользовательского интерфейса. В целом сложность обслуживания программного обеспечения возрастает с увеличением числа представлений, требующих обновления.

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

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

Декларативный пользовательский интерфейс требует переосмысления разработки приложения, принятия того, что можно перестраивать части пользовательского интерфейса с нуля, а не изменять их. Современные процессоры достаточно быстры для этого и даже могут обрабатывать анимацию при перестройке всего экрана. В декларативной структуре изменения состояния данных запускают перестройку пользовательского интерфейса, которая удаляет целую категорию ошибок, связанных с состоянием, и упрощает рассуждения об обновлениях. Необходимо описать, как должен выглядеть пользовательский интерфейс для данного состояния, а платформа определяет, как это сделать, используя значения по умолчанию и контекст. Это значительно сокращает объем кода, который нужно написать, и облегчает возможность использовать код повторно.

Основным представителем декларативного подхода является Jetpack Compose, разрабатываемый компанией Google в рамках Jetpack — набора библиотек и инструментов для упрощения разработки под Android. Стоит рассмотреть ключевые причины перехода на данный фреймворк.

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

Инструментарий пользовательского интерфейса умеет в разы больше кода, по сравнению с новым. В Compose, в отличие от оригинального подхода, не нужно создавать файлы разметки. Меньший код помогает избежать множества ошибок. Это также делает код простым и легким в обслуживании.

При разработке с использованием фреймворка Compose используются два термина: «компоновка» (“composition”) и «перекомпоновка» (“recomposition”). Компоновка — процесс, в котором выполняются составные функции и создается пользовательский интерфейс для пользователя. Перекомпоновка — процесс обновления пользовательского интерфейса в результате изменения состояния или данных, которые составной объект использует для своего отображения. Во время перекомпоновки Compose может понять, какие данные использует каждая композиция, и обновляет только те компоненты пользовательского интерфейса, которые были изменены. Остальные составные элементы будут пропущены.

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

Поток данных в Compose устроен таким образом, что событие перемещается вверх по направлению к родительскому элементу, а данные передаются вниз от родительского элемента к его дочернему виджету. Важно то, что родитель всегда контролирует данные, передаваемые потомку.

События, происходящие с уровня интерфейса, такие как нажатия кнопок, передаются обработчику событий, например, модели представления. Модель представления предоставит пользовательскому интерфейсу состояние через LiveData/Flow. По мере изменения состояния обновления передаются в составные файлы, которые затем проводят перекомпоновку с использованием последнего состояния.

Стоит отметить основные преимущества и недостатки. Первым преимуществом является низкий порог входа. В первую очередь это вызвано тем, что разработка интерфейса и логики приложения происходят на одном языке. Команда Jetpack Compose также следует лучшим практикам разработки, уменьшая шаблонный код, при этом создавая качественную документацию, расположенную на официальном сайте документации Android.

Совместимость — одно из важнейших преимуществ, которое позволяет не переписывать проект, а использовать там, где это нужно. API работает в обоих направлениях – составные функции могут использоваться внутри XML, а сами функции могут содержать XML элементы.

Важно заметить, что Jetpack Compose может использоваться не только для разработки Android интерфейсов. Compose Multiplatform получил стабильную версию 1.0 в декабре 2021 года. Он позволяет производить разработку для Android, Windows, Linux, а также информационных систем в сети Интернет.

При разработке под Android используется один язык — Kotlin. Отсутствие XML и императивного программирования означает низкую связь и высокую согласованность, что приводит к меньшему количеству возможных проблем. Одним небольшим плюсом также является меньшее время сборки и размер приложения.

Теперь стоит отметить основные недостатки Compose. В первую очередь это то, что данный фреймворк все еще не является отраслевым стандартом. Все больше разработчиков обращают внимание на данную библиотеку, выражая свое одобрение, некоторые готовы заняться этим в будущем, говоря о его высоком потенциале. Но подавляющее большинство существующих систем используют стандартные инструменты Android и перестроить их моментально невозможно.

Следующей проблемой являются побочные эффекты совместимости. При использовании Compose совместно с XML разметкой увеличивается размер приложения и время сборки. Но как только приложение будет полностью перенесено на Compose, данные параметры будут лучше, чем до переноса.

При использовании данной библиотеки также возможен предварительный просмотр с введенными тестовыми данными. Недостатком этого решения является повторный запуск сборки предварительного просмотра при каждом изменении кода.

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

Новый способ описания пользовательского интерфейса означает изучение нового синтаксиса тестирования, что означает дополнительные затраты на исследования и обучение.

Важным замечанием является и то, что необходимо продолжать читать о новых инструментах, библиотеках и архитектурах. Кроме того, придется менять версии по мере обновления системы, что приведет к постоянному рефакторингу кода. После выпуска версии 1.0 обновления стали менее частыми и радикальными с точки зрения изменений, но это не отменяет факта обновления системы при каждом обновлении библиотеки. Постоянная работа над фреймворком означает множество улучшений, которые вселяют оптимизм в отношении Jetpack Compose.

Исходя из всего вышесказанного, можно сделать вывод, что Compose предоставляет современный, новый подход к определению пользовательского интерфейса. Поскольку составные функции очень похожи на обычные функции Kotlin, инструменты, с помощью которых пишется и производится переработка кода экранных форм, будут аккуратно вписываться в набор навыков мобильного разработчика. Compose – это мощный скачок относительно создания UI, это изменение, которое значительно упростит многие проблемы, возникающие в устаревшей нагроможденной системе.