Пользовательский интерфейс, управляемый сервером (SDUI) — это новая технология, используемая такими компаниями, как Airbnb и Lyft, которые используют сервер для создания пользовательских интерфейсов своих мобильных приложений. Это открывает новые возможности и решает некоторые фундаментальные проблемы, связанные с разработкой собственных мобильных приложений. Прежде чем мы рассмотрим, как работает пользовательский интерфейс, управляемый сервером, давайте посмотрим, как сегодня разрабатываются мобильные приложения.
Содержание статьи
Как это начиналось
В традиционном мобильном приложении макет и представление пользовательского интерфейса создается разработчиком и упаковывается в приложение. Пакет приложения отправляется в App / Play Store, где он проверяется Apple или Google и затем становится доступным для установки пользователями.
Пользовательские интерфейсы в этих приложениях сделаны динамическими за счет отделения пользовательского интерфейса от данных, которые он отображает. Хотя пользовательский интерфейс является частью двоичного кода приложения, данные обычно берутся с сервера и встраиваются в пользовательский интерфейс.
Рассмотрим пример типичного экрана со списком товаров. Разработчик создаст представление списка с одним шаблоном строки, используемым для отображения каждого продукта. В этом случае мы будем отображать миниатюру, название и цену каждого продукта.
Когда пользователю отображается экран со списком, приложение получает список продуктов для отображения с сервера.
[
{
"thumbnail": "https://images.example.com/instinct.jpg",
"title": "Rocky Mountain Instinct",
"description": "Stable and aggressive, the Instinct is..."
"price": 6999.99,
"rating": 4.8,
"sale": false,
"featured": false
},
{
"thumbnail": "https://images.example.com/stumpjumper.jpg",
"title": "Specialized Stumpjumper",
"description": "The Stumpjumper brings all-new..."
"price": 3178.99,
"rating": 4.3,
"sale": true,
"featured": false
},
//...
]
Список продуктов, данные объединяются с пользовательским интерфейсом, созданным разработчиком, и преобразуются в представление списка.
Цикл выпуска
А теперь представим, что после запуска экрана со списком мы решили добавить оценку продукта в каждой строке и уделить особое внимание товарам со скидкой.
Логика, которая определяет, как данные представлены для каждой строки, встроена в приложение, поэтому для того, чтобы внести эти изменения в пользовательский интерфейс, нам необходимо выполнить полный цикл выпуска. Процесс выглядит примерно так:
- Разработчики пишут код для внесения желаемых изменений пользовательского интерфейса.
- Изменения пользовательского интерфейса проверяются тестировщиками.
- В App / Play Store размещена новая версия приложения.
- Apple / Google рассматривают и одобряют его.
- Пользователи обновили до новой версии.
Для типичного приложения, поддерживающего iOS и Android, цикл выпуска должен выполняться дважды, по одному разу для каждой платформы, и, как правило, для каждой из них требуются разные разработчики.
К тому времени, как эти изменения коснулись устройств наших пользователей, мы уже собираемся внести дополнительные изменения. В этом случае мы теперь хотим отображать избранные продукты вверху списка в контейнере с горизонтальной прокруткой.
И снова мы должны пройти полный цикл выпуска, чтобы внести эти изменения.
Между разработкой, тестированием и ожиданием утверждения — на обеих платформах — каждое из этих простых изменений занимает недели или даже месяцы, прежде чем они появятся в App / Play Store. И даже после того, как они попали в магазин, нам все равно приходится ждать, пока наши пользователи обновятся до новой версии приложения, прежде чем они их увидят.
Проблема
Необходимость пройти полный цикл выпуска даже для простых изменений пользовательского интерфейса сопряжена с некоторыми проблемами.
Во-первых, это замедляет экспериментирование и итерацию. Накладные расходы на цикл выпуска означают, что мы ждем долгое время, прежде чем понять, как пользователи реагируют на каждое изменение, которое мы вносим в пользовательский интерфейс. Из-за этого многие компании прибегают к тестированию прототипов вместо того, чтобы учиться у реальных пользователей. В идеальном мире мы могли бы провести A / B-тестирование наших пользовательских интерфейсов, но цикл выпуска делает это трудным.
Во-вторых, как сказал Райан Брукс из Airbnb, это создает проблему с версией. Каждый раз, когда мы выпускаем новую версию нашего приложения, нам приходится ждать, пока наши пользователи обновят ее. Некоторые из них обновятся сразу, некоторые займут свое время, а некоторые вообще не обновятся. Это создает фрагментированный пользовательский опыт.
Наконец, поскольку мы должны разрабатывать наши изменения независимо для iOS и Android, может быть сложно сохранить согласованный пользовательский интерфейс. Обе платформы имеют разные парадигмы пользовательского интерфейса, которые необходимо учитывать, и часто результаты отличаются друг от друга. Кроме того, пользователи iOS обычно обновляют свои приложения чаще, чем пользователи Android, что приводит к еще большей фрагментации.
Как дела
При традиционном процессе разработки пользовательский интерфейс встроен в приложение, что делает его негибким и трудным для обновления. Но данные берутся с удаленного сервера. Данные, отображаемые в приложении, всегда актуальны и могут быть изменены в любое время через серверную систему. Что, если бы мы могли применить тот же метод, который мы используем для данных, к самому пользовательскому интерфейсу?
Что, если бы мы могли применить тот же метод, который мы используем для данных, к самому пользовательскому интерфейсу?
Войдите в управляемый сервером пользовательский интерфейс. В реализации SDUI пользовательский интерфейс в приложении представляет собой чистый лист. Приложение знает, что будет отображать экран со списком, но не делает никаких предположений о том, как этот экран будет выглядеть. Приложение отправляет запрос на сервер, который возвращает и пользовательский интерфейс, и данные вместе.
Ответ сервера представляет собой некую форму проприетарной разметки, которую понимает приложение. Вместо получения списка продуктов приложение выбирает представление списка, которое содержит набор представлений строк, каждое из которых содержит представления текста и изображения с информацией о интервале, выравнивании, цвете и типографии.
{
"список": {
"rowHeight": 44,
"dividerColor": "# 979797",
"строки": [
{
"padding": [7, 14, 7, 14],
"изображение": {
"источник": "https://images.example.com/instinct.jpg",
"расклад": "ведущий",
«ширина»: 30,
«высота»: 30
},
"метка": {
"text": "Инстинкт Скалистых гор",
"выравнивание": "верх",
"fontSize": 11,
"fontWeight": "полужирный",
"цвет": "# 000000"
},
// ...
},
// ...
]
}
}
Приложение отображает ответ сервера, и результат идентичен версии, использующей традиционные методы разработки.
Звучит знакомо? Именно так веб-браузеры работают с HTML и CSS. Помните, все старое снова новое.
Преимущества серверного пользовательского интерфейса
Получившийся экран списка с использованием как традиционного подхода к разработке, так и подхода пользовательского интерфейса, управляемого сервером, идентичен. Так что же нам на самом деле дала SDUI?
Преимущества SDUI проявляются, когда мы хотим внести изменения. В нашем предыдущем примере мы прошли две итерации пользовательского интерфейса, которые потребовали недель или месяцев, чтобы добраться до наших пользователей из-за цикла выпуска. Давайте вернемся к циклу выпуска и посмотрим, как SDUI может его оптимизировать.
- Разработчики пишут код для внесения желаемых изменений пользовательского интерфейса.
- Изменения пользовательского интерфейса проверяются тестировщиками.
- В App / Play Store размещена новая версия приложения.
- Apple / Google рассматривают и одобряют его.
- Пользователи обновили до новой версии.
В пользовательском интерфейсе, управляемом сервером, первый шаг заменяется серверным обновлением разметки экрана листинга. Вот и все. Остальные четыре шага не нужны. Мы не пишем новый код, поэтому нам не нужно его тестировать. Мы не вносим никаких изменений в приложение, поэтому нам не нужно отправлять новую версию и, следовательно, нам не нужно ждать одобрения Apple или Google. Поскольку мы не представили новое приложение, а наши обновления были сделаны на стороне сервера, все пользователи сразу видят изменения.
Обновления, которые раньше занимали недели или месяцы, теперь можно выполнять за дни или часы. Изменения вносятся в приложение для iOS и Android последовательно, и все пользователи видят одну и ту же версию одновременно.
Двухфазная визуализация
В примере SDUI мы видели, что сервер включает данные и пользовательский интерфейс как один ответ. Обратной стороной этого подхода является то, что пользовательский интерфейс необходимо загружать каждый раз, когда просматривается экран со списком. В ожидании пользовательского интерфейса и данных с сервера пользователю предоставляется пустой экран и индикатор загрузки. Это шаг назад по сравнению с традиционным подходом, когда пользовательский интерфейс встроен в приложение, и пользователям не нужно ждать его загрузки.
Альтернативный способ реализации SDUI, который использует дзюдо, состоит в разделении выборки пользовательского интерфейса и выборки данных на две фазы. Это резко снижает размер ответа сервера для представлений списков, поскольку нет необходимости повторять разметку презентации для каждого элемента. Что еще более важно, это позволяет нам предварительно загружать пользовательский интерфейс.
С помощью этого метода пользовательский интерфейс может быть извлечен заранее и сохранен на диске, чтобы он был доступен до того, как пользователю потребуется его увидеть. Пользовательский интерфейс можно даже вызвать в фоновом режиме, когда телефон пользователя находится в его кармане, что позволяет постоянно поддерживать его в актуальном состоянии. Когда пользователь открывает приложение и просматривает экран со списком, пользовательский интерфейс отображается немедленно. Затем данные извлекаются с сервера, объединяются с предварительно выбранным пользовательским интерфейсом и преобразуются в представление списка.
Такой подход позволяет нам не только съесть свой торт, но и съесть его. Результат незаметен для традиционно разработанного приложения, но у нас гораздо больший контроль над тем, как и когда обновляется наш пользовательский интерфейс.
Разрешено ли это?
Apple и Google не разрешают изменять код в приложении после того, как оно было проверено и выпущено. На первый взгляд кажется, что реализация пользовательского интерфейса на основе сервера нарушает это правило, но это не так. SDUI настраивает пользовательский интерфейс вашего приложения на основе ответа сервера, но не изменяет код . Большинство современных приложений уже сегодня используют некоторую базовую форму SDUI.
Представьте себе страницу со списком продуктов, созданную с использованием традиционных методов разработки. Каждая строка в списке имеет белый фон, но наше приложение содержит логику для отображения строк для избранных продуктов с оранжевым фоном. Это очень простой пример пользовательского интерфейса, управляемого сервером. В зависимости от статуса продукта мы выделяем для каждой строки белый или оранжевый цвет фона. Мы модифицируем пользовательский интерфейс нашего приложения на основе ответа сервера. Обновляя статус нашего продукта на сервере, мы изменяем пользовательский интерфейс удаленно без обновления App / Play Store.
Дзюдо и другие реализации пользовательского интерфейса, управляемые сервером, расширяют эту технику, чтобы обеспечить гораздо большую степень настройки. В случае с дзюдо наш SDK содержит логику для рендеринга пользовательского интерфейса на основе ответа сервера. Весь код содержится в SDK и включает в себя конечный набор возможных вариантов. Этот код проходит стандартный процесс проверки Apple при первой интеграции SDK в свое приложение. После этого первоначального обзора вы можете использовать SDUI для обновления частей вашего пользовательского интерфейса без повторного прохождения процесса проверки.
Заключение
Пользовательский интерфейс, управляемый сервером, является новым и требует значительных предварительных вложений для реализации. Такие компании, как Airbnb и Lyft, являются первопроходцами в этой сфере, но не у всех есть возможность разработать собственную реализацию SDUI. В Judo мы создаем платформу, чтобы сделать управляемый сервером пользовательский интерфейс доступным для продуктовых команд любого размера. Если вы хотите попробовать SDUI для себя, загрузите наше бесплатное приложение для Mac, посетите центр обучения и присоединитесь к нашему сообществу растущих энтузиастов SDUI. Увидимся там.
Загрузка...
