Как перестать вручную поддерживать экран настроек
Новая настройка появилась в модели — значит, нужно добавить соответствующий UI‑компонент, настроить обработчики, связать все с системой хранения и не забыть ничего по пути.
Пока настроек немного, это не вызывает проблем. Но со временем поддержка такого экрана начинает занимать все больше времени.
Илья, iOS‑разработчик в Naumen, рассказывает, как пришел к подходу, при котором разработчику достаточно описать новое свойство, а интерфейс собирается автоматически.
Почему задача оказалась сложнее?
Все началось с настройки сжатия изображений перед отправкой на сервер. На первый взгляд задача выглядела вполне стандартной: подобрать параметры, проверить результат и убедиться, что все работает как нужно.
Но довольно быстро возник другой вопрос: как проверять изменения без постоянной пересборки приложения?
Для разработчика это не так критично, а вот для аналитиков на приемке и тестировщиков каждая новая проверка требовала участия разработчика. Тогда появилась идея вынести параметры в отдельный экран настроек.
Почему обычный экран настроек не решил проблему?
Сначала мы решили добавить переключатели, поля ввода и другие элементы интерфейса. Но появилась новая сложность: поддерживать такой экран вручную неудобно.
Чтобы добавить новую настройку, нужно было каждый раз:
добавлять свойство;
добавлять соответствующий UI‑компонент;
настраивать обработку;
связывать с хранилищем данных.
Я начал искать подход, при котором разработчику не нужно отдельно поддерживать интерфейс настроек. Хотелось, чтобы достаточно было просто описать новую настройку, а все остальное система делала сама.
В этот момент я вспомнил про Reflection. В Swift этот механизм ограничен и фактически работает как интроспекция, но даже этих возможностей оказалось достаточно для решения задачи.
Как сделать так, чтобы экран собирался автоматически?
В основе подхода лежит декларативный принцип: разработчик описывает свойства объекта настроек и добавляет к ним метаданные, например, название настройки или связи с другими параметрами.
Дальше система анализирует структуру объекта, определяет типы данных и автоматически подбирает нужные UI‑компоненты:
для булевых значений — переключатели;
для текста — поля ввода;
для чисел — поля с ограничением на числовой ввод.
Что изменилось после внедрения такого подхода?
Теперь для добавления новой настройки достаточно описать новое свойство и добавить необходимые метаданные. После этого настройка автоматически появляется в интерфейсе.
По моей оценке, трудозатраты на работу с настройками сократились примерно на 80–90%. Кроме того, уменьшилось количество дублирующего кода, а интерфейс стал более единообразным и предсказуемым для пользователей.
→ Подробнее своим опытом Илья поделился в статье.
