Что такое Angstrom Style System?

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

Даже если дизайн рисуется до разработки, в процессе создания первой версии всё-равно появляется огромное количество изменений. Тут кнопочку перекрасить, тут подвинуть, там шрифт увеличить/уменьшить, потому что не поместилось и так далее. Каждое из этих изменений требует доработки. Часто таких доработок бывает несколько сотен или даже тысяч, если не получается сразу подобрать правильные параметры.

В такой ситуации очень выгодным получается отделить настройки дизайна от самого интерфейса и настраивать независимо. Эту задачу должна решать система стилей, идеологически — как CSS для HTML.

В статье я покажу, как именно я стараюсь организовать стили в приложении, и какими средствами я для этого пользуюсь.

Структура стилевой системы в приложении

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

• цвета приложения,
• шрифты приложения,
• базовые стили текстов приложения,
• базовые параметры. Например, общий радиус скругления углов, или какие-то шаги отступов для сетки.

Это те параметры, которыми пронизано всё приложение. Если вдруг дизайнер решил, что он выбрал неудачный шрифт и его требуется поменять, то поменять нужно сразу везде. Этот слой обычно достаточно небольшой и понятный всем. Можно отдать поредактировать/понастраивать его дизайнерам или даже, в особо доверенных случаях, заказчику.

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

• лейбл-раз: шрифт номер два, цвет красный-три, выравнивание влево,
• кнопка-два: шрифт пять, цвет синий-активный, выравнивание по центру.

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

Достоинства стилей в приложении

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

В случае, если научиться загружать стили из удаленного источника (из файла в ДропБоксе), то в сотни раз ускоряется настройка дизайна при удалённой разработке. Одно дело, когда дизайнер может сесть вместе с разработчиком и попытаться быстро поднастроить какой-то параметр, а когда это невозможно? Каждая итерация может занимать часы и дни. В данном же случае обновил файл, перезапустил приложение (или сделал хитрый секретный жест), посмотрел результат.

В некоторых ситуациях удобно использовать скины. Для читалок книжек это, например, необходимость, читать днём удобно со светлым фоном, ночью — с тёмным. Иногда этого хочет заказчик, иногда по дизайну требуется для «вау-эффекта». Если сделать два варианта первого слоя стилей, то можно их переключать, оставляя второй слой одним и тем же. В результате скины получатся почти бесплатно.

Когда появилась необходимость в системе стилей?

Необходимость в системе стилей появилась сразу с двух сторон:

• в аутсорсинговой компании разрабатывается множество приложений. Приятно иметь общую схему их работы, чтобы один разработчик мог поправить код другого. И заказчики постоянно меняющие требования — тоже встречаются чаще, чем хотелось бы.
• в разработке своих приложений хочется всегда сделать «идеально». Когда мы разрабатывали Ангстрем с Ильёй Бирманом, требовался механизм настройки дизайна, который бы позволил Илье играться с настройками сложных компонентов, таких, как кастомный курсор.

Я предпочитаю тестировать новые идеи на своих собственных проектах, а не на проектах заказчика, поэтому Ангстрему повезло, и я создал для него систему стилей. В ней для описания стилей использовался файл на JSON, в который я добавил возможностей включения других файлов (в том числе «из Дропбокса»). Во фреймворке также были реализованы колбеки, которые сообщали, что стиль изменился. Я подключил обновление стилей на тряску Айфона, получилось занятно. Поправил файл в Саблайме, сохранил, трясанул Айфон, стили подгрузились и применились ко всему приложению.

Недостатки существующей системы, что «не взлетело»?

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

Но несколько моментов мне не понравились.

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

Тот же JSON заставил меня кодировать типы данных прямо в названиях. Цвета у меня заканчивались на color, точки — на center или point, и так далее. В результате названия полей получались сильно длинее, чем требуется.

После первых попыток использования стилевой системы, выяснилось, что самый удобный вариант — когда по JSON'у создаётся иерархия классов, полностью повторяющая иерархию объектов в JSON'е. В приложении тогда появляется строго-типизированная структура, к которой можно удобно обращаться как к обычному коду. В принципе, можно было привязать к обновлению стилей UI-компоненты, чтобы стиль знал, что он применяется вот к этой кнопке, и если вдруг обновился (скачался новый стиль из Дропбокса), то сам бы кнопку и обновил. Но на деле оказалось, что такая магия только мешает жить, лучше прописывать правила обновления явно.

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

Также немного мешал Objective-C и необходимость поддержки старых версий iOS. Код сгенерированного класса получался большой и неприятный, очень хотелось бы его оптимизировать.

S2 — более простая и эффективная система стилей

Поняв недостатки, я попробовал улучшить систему с тем, чтобы она лучше подходила для решаемых задач, по всем параметрам:

• Теперь формат файла — KTV. Он поддерживает и ссылки, и миксины, и типы, включая базовый тип color. KTV умеет без изменений читать и JSON-файлы, поэтому мои старые стили перекочевали в новую структуру без изменений.
• Файл стиля создается из ktv-файла на Swift. При этом, если не использовать поддержку Objective-C (которая тоже возможна), то получается компактный, удобный как для просмотра так и для использования класс (иерархия вложенных классов), не засоряющих глобальное пространство имён приложения.
• Благодаря поддержке типов в KTV, стало возможным отказаться от суффиксов в названиях, что упростило имена пропертей и классов.
• Появилась консольная утилита, которая может по ktv-файлу (или нескольким файлам) создать классы стиля.

Для примера приведу (очень небольшой) фрагмент исходного KTV:

{
    maxWidthForIPad: 600

    darkTheme: false

    defaultFontName: HelveticaNeue-Light
    bolderFontName: HelveticaNeue
    boldFontName: HelveticaNeue-Medium

    defaultSymbolFontName: AngstromSymbols-Light
    bolderSymbolFontName: AngstromSymbols

    basicColors: {
        plateBackground: #edf5f4
        separators: #00407020
    }

    ilya: {
        aboutBackground: @basicColors.plateBackground
        listSeparator: @basicColors.separators
    }

    colors: {
        about: {
            background: @ilya.aboutBackgroundColor
            separator: @ilya.listSeparatorColor
        }
    }    

    about: {
        margins: [0, 0, 0, 0]
        separatorSpacing: 10
        background: @colors.about.backgroundColor
        separator: @colors.about.separatorColor
    }
}

И соответствующий ему фрагмент стилевого файла, который получается:

let S2 = CONStyle()

public struct CONStyle: S2Object {
    private static let _rootStyle = S2

    public struct BasicColors: S2Object {
        let separators = UIColor(colorLiteralRed:Float(1.0), green:Float(1.0), blue:Float(1.0), alpha:Float(0.0))
        let plateBackground = UIColor(colorLiteralRed:Float(0.929411764705882), green:Float(0.929411764705882), blue:Float(0.929411764705882), alpha:Float(1.0))
    }
    let basicColors = BasicColors()

    public struct Ilya: S2Object {
        let aboutBackground = _rootStyle.basicColors.plateBackground
        let listSeparator = _rootStyle.basicColors.separators
    }
    let ilya = Ilya()

    public struct Colors: S2Object {
        public struct About: S2Object {
            let background = _rootStyle.ilya.aboutBackgroundColor
            let separator = _rootStyle.ilya.listSeparatorColor
        }
        let about = About()
    }

    public struct About: S2Object {
        let margins = UIEdgeInsets(top:0.0, left:0.0, bottom:0.0, right:0.0)
        let separatorSpacing = Int(10)
        let background = _rootStyle.colors.about.backgroundColor
        let separator = _rootStyle.colors.about.separatorColor
    }
}

Конечно же, использование Swift будет неудобно для полностью Objective-C проектов. Это потащит за собой в проект Swift-рантайм, который может существенно увеличить размер приложения. Но, во-первых, не сильно сложно написать генератор чисто Objective-C кода, а во-вторых, всё сейчас идёт к массовому использованию Swift в приложениях, так что и генерируемый S2 код будет «в тему».