Автоматическая генерация UI-настроек
Меня зовут Илья, я мобильный разработчик в Naumen. Моя основная специализация — iOS‑разработка. Я занимаюсь развитием мобильного клиента платформы Naumen Service Management Platform, а также Chat SDK в рамках Naumen Contact Center.
В работе мобильной команды регулярно появляются задачи, в процессе решения которых команда так или иначе сталкивается с трудностями. У меня это произошло, когда я занимался задачей на сжатие изображений перед отправкой на сервер.
В статье расскажу, как из этой задачи вырос подход к автоматической генерации экранов настроек: без ручного добавления каждого нового поля в интерфейс, с опорой на интроспекцию типов и метаданные у самих свойств.
Как из обычной задачи выросла проблема с настройками
Когда в работе появилась задача на сжатие изображений перед отправкой на сервер, основной проблемой казалась сама реализация: как сжимать, как настроить параметры, как подобрать нужное поведение.Но довольно быстро возникла другая проблема: как проверять изменения в реальном времени, не пересобирая приложение после каждой правки.
Для разработчика это не так критично — пересобрать проект через Xcode можно за несколько минут. Однако в работе участвуют и другие роли:
-
аналитики на приемке
-
тестировщики при тестировании
Каждое изменение параметров означало необходимость пересборки приложения. В итоге тестирование любой мелкой настройки превращалось в цепочку действий с участием разработчика.
Стало очевидно, что нужен отдельный экран с настройками, где параметры можно менять прямо во время работы приложения.
С какой еще проблемой мы столкнулись
Сначала мы решили сделать экран настроек с переключателями, полями ввода и другими UI‑элементами, однако столкнулись со следующей ситуацией.
Каждый раз, когда появляется новая настройка или меняется существующая, разработчику нужно:
- добавить свойство в модель настроек
- добавить UI‑компонент на экран
- прописать обработку
- связать все с системой хранения
-
Растет объем дублирующего кода
-
Тратится дополнительное время
-
Любое расширение экрана требует новых изменений в кодовой базе
Такую систему можно собрать через фабрики: описывать структуру данных отдельно, а компоненты строить на ее основе, но это решает лишь часть задачи. Однако даже в этом случае остается ручная работа — при появлении новой настройки нужно идти в отдельную часть кода, добавлять ее описание и отдельно выводить на экран.
Мне хотелось прийти к модели, где разработчик просто описывает новую настройку, а все остальное система делает сама.
К какому решению в итоге мы пришли
В поиске решения я вспомнил о механизме Reflection, в других языках этот механизм может называться Introspection. Он позволяет анализировать структуру объектов во время выполнения программы.
В Swift возможности рефлексии ограничены, поэтому корректнее говорить об интроспекции, а не о полной рефлексии, потому что язык не позволяет изменять код в реальном времени. Но для нашей задачи этого оказалось достаточно.
На основе интроспекции данных удалось выстроить подход к созданию экранов настроек, который заметно сокращает трудозатраты и убирает значительную часть ручной работы при добавлении новых параметров.
Что меняется в подходе
Если коротко, идея такая: разработчик больше не описывает каждый UI‑элемент экрана отдельно вручную. Вместо этого он задает свойства объекта настроек и добавляет к ним нужные метаданные. Дальше система сама анализирует эти данные и генерирует соответствующие компоненты интерфейса.
Из чего состоит такая система
1. Метаданные настроек
Каждая настройка описывается как свойство объекта. Дополнительно используются аннотации, которые содержат метаданные:
-
читаемое название свойств настроек
-
зависимости между настройками
-
дополнительные параметры отображения
2. Механизм анализа типов данных (интроспекция)
Центральный механизм системы — анализ типов данных, который с помощью интроспекции анализирует структуру объекта настроек во время выполнения программы.
Он проходит по всем свойствам объекта настроек и извлекает:
-
тип данных конкретной настройки
-
метаданные из аннотаций
Полученная информация используется для построения интерфейса.
3. Система соответствия типов данных и UI-компонентов
Дальше система определяет, какой UI‑компонент нужен для конкретного типа.
Например:
-
для Bool — переключатель
-
для текстового значения — поле ввода
-
для числового значения — тоже поле ввода, но уже с ограничением на числовой ввод
За счет этого интерфейс строится не вручную, а на основе правил сопоставления.
4. Система обработки событий взаимодействия и UI-компонентов
После генерации интерфейса пользователь должен иметь возможность менять значения, а система — корректно эти изменения обрабатывать.
Для этого нужен обработчик событий, который принимает пользовательские действия, передает изменения в систему хранения данных и уведомляет о том, что данные изменились.
5. Система хранения и восстановления настроек
Чтобы настройки могли сохраняться между запусками приложения, можно использовать систему хранения. Она должна уметь сохранять данные при их изменении и восстанавливать при перезапуске системы.
Как выглядит процесс сборки экрана
Для автоматического создания экрана настроек сначала нужно объявить объект настроек и описать в нем необходимые свойства, добавив аннотации для дополнительных метаданных. После этого модель объекта настроек передается на сборку.
Сама сборка делится на четыре этапа: анализ объекта настроек, генерация UI‑модели, создание интерактивного интерфейса и обработка изменений.
Этап 1. Анализ объекта настроек
-
Получение метаинформации об объекте настроек с использованием интроспекции
-
Обход всех свойств объекта
-
Извлечение типов данных и метаданных из аннотаций
Этап 2. Генерация UI-модели
-
Создание секций настроек на основе группировки по объектам настроек
-
Генерация UI-моделей компонентов для каждого типа данных
-
Настройка связей между компонентами — зависимости
-
Применение метаданных — названия
Этап 3. Создание интерактивного интерфейса
-
Создание UI-элементов на основе сгенерированной модели
-
Настройка обработчиков событий для каждого компонента
-
Связывание с системой хранения для сохранения изменений
-
Реализация зависимостей между настройками
Этап 4. Обработка изменений ё
- Перехват пользовательского ввода через обработчик событий
- Валидация данных в соответствии с типом
- Сохранение в хранилище с сериализацией
- Обновление зависимых настроек при необходимости
Как это реализовано в Swift
Метаданные через Property Wrappers
Для добавления метаданных мы используем механизм Property Wrappers. Он позволяет обернуть свойства в дополнительную логику и сохранить прозрачный доступ к значению. Property Wrappers идеально подходит для нашего случая, так как он может добавлять метаданные прямо в объявление свойства, а не где‑то в отдельной части кода.
Анализ типов через Mirror
А еще с помощью механизма можно:
- автоматически обнаружить все свойства объекта настроек
- извлечь их типы и метаданные
- построить на основе этой информации UI‑модель
Генерация UI-компонентов
- UIKit
- SwiftUI
Ключевая часть здесь — создание фабрики компонентов. Она принимает уже сгенерированную UI-модель и создает нужный UI-компонент для конкретного типа настройки.
Обработка событий
В Swift мы используем стандартный подход с назначением действия на UI‑компоненты — это классический подход iOS‑разработки. Каждый UI‑компонент может иметь целевой объект и действие, которое выполняется при взаимодействии. В других языках программирования эта задача чаще всего решается с помощью callback'ов.
Каждый UI‑компонент получает свое действие на изменение значения. Дальше система должна правильно интерпретировать пользовательский ввод и привести его к нужному типу.
Это особенно важно для текстовых полей. В одном случае текстовое значение должно сохраниться как строка, в другом — быть преобразовано в число, если настройка ожидает именно числовое представление. Поэтому здесь критична типобезопасность: система должна не просто получать ввод, а проверять, что его можно корректно сохранить.
Хранилище и восстановление данных
- UserDefaults — для простых типов данных
- NSKeyedArchiver — для преобразования сложных объектов в данные
Кроме того, система должна учитывать, что структура настроек со временем может меняться. Значит, сериализация и десериализация должны работать так, чтобы не терять уже сохраненные данные при изменении модели.
Ключевая особенность системы хранения — это автоматическая сериализация и десериализация различных типов данных. Нужно корректно обрабатывать как примитивные типы, так и сложные объекты, обеспечивая при этом обратную совместимость при изменении структуры настроек.
Пример добавления настройки: изначальное описание объекта настроек и то, что пользователь увидит в приложении
Важное ограничение Swift, которое пришлось обойти
Поэтому для этой части был реализован отдельный интерфейс PropertyAccess, который закрывает этот пробел и позволяет работать со значениями так, как это нужно системе.
Пример добавления новой настройки для отображения вкладки с чатом — она связана с отображением таббара. Включение и отключение настройки отображения таббара влияет на настройку открытия вкладки с чатом в таббаре
Что дает такой подход на практике
Поддержка разных языков
Расширяемость системы
- Добавить новый тип данных в анализатор
- Создать соответствующий UI‑компонент
- Настроить обработку взаимодействия с данным компонентом
- После все свойства этого типа автоматически появятся на экране настроек.
Сокращение трудозатрат
Уменьшение объема дублирующего кода
Типобезопасность
Консистентный интерфейс
Подход с автоматической генерацией UI-настроек через интроспекцию типов позволяет сократить объем ручной работы и дает разработчику возможность уделять больше времени бизнес-логике, а не ручному созданию интерфейсов.
В нашем случае он вырос из обыденной задачи — необходимости быстро проверять изменения без постоянной пересборки приложения. Но в итоге этот подход можно использовать не только для одной конкретной задачи, а для построения экранов настроек в целом.
