Глава 12. Создание приложения контактов с помощью Hyperview

---

В предыдущих главах этой книги объяснялись преимущества создания приложений с использованием архитектуры гипермедиа. Эти преимущества были продемонстрированы при создании надежного веб-приложения «Контакты». Затем в главе 11 утверждалось, что концепции гипермедиа могут и должны применяться к платформам, отличным от Интернета. Мы представили Hyperview как пример гипермедийного формата и клиента, специально предназначенного для создания мобильных приложений. Но вам все еще может быть интересно: каково это — создать полнофункциональное, готовое к работе мобильное приложение с помощью Hyperview? Должны ли мы изучать совершенно новый язык и структуру? В этой главе мы покажем Hyperview в действии, перенеся веб-приложение «Контакты» в собственное мобильное приложение. Вы увидите, что многие методы веб-разработки (и большая часть кода) полностью идентичны при разработке с помощью Hyperview. Как это возможно?

1. Наше веб-приложение «Контакты» было построено по принципу HATEOAS (Гипермедиа как двигатель состояния приложения). Все функции приложения (получение, поиск, редактирование и создание контактов) реализованы в бэкэнде (классе ContactsPython). Наше мобильное приложение, созданное с помощью Hyperview, также использует HATEOAS и использует серверную часть для всей логики приложения. Это означает, что Contactsкласс Python может обеспечивать работу нашего мобильного приложения так же, как и веб-приложение, без каких-либо изменений.

2. Взаимодействие клиент-сервер в веб-приложении происходит с использованием HTTP. HTTP-сервер для нашего веб-приложения написан с использованием инфраструктуры Flask. Hyperview также использует HTTP для связи клиент-сервер. Таким образом, мы можем повторно использовать маршруты и представления Flask из веб-приложения и для мобильного приложения.

3. Веб-приложение использует HTML в качестве формата гипермедиа, а Hyperview использует HXML. HTML и HXML — это разные форматы, но базовый синтаксис схож (вложенные теги с атрибутами). Это означает, что мы можем использовать одну и ту же библиотеку шаблонов (Jinja) для HTML и HXML. Кроме того, многие концепции htmx встроены в HXML. Мы можем напрямую переносить функции веб-приложений, реализованные с помощью htmx (поиск, бесконечная загрузка), в HXML.

По сути, мы можем повторно использовать практически все из серверной части веб-приложения, но нам нужно будет заменить шаблоны HTML шаблонами HXML. В большинстве разделов этой главы предполагается, что приложение веб-контактов работает локально и прослушивает порт 5000. Готовы? Давайте создадим новые шаблоны HXML для пользовательского интерфейса нашего мобильного приложения.

Создание мобильного приложения

Чтобы начать работу с HXML, есть одно неприятное требование: клиент Hyperview. При разработке веб-приложений вам нужно беспокоиться только о сервере, поскольку клиент (веб-браузер) доступен повсеместно. На каждом мобильном устройстве не установлен эквивалентный клиент Hyperview. Вместо этого мы создадим собственный клиент Hyperview, настроенный только для взаимодействия с нашим сервером. Этот клиент можно упаковать в мобильное приложение для Android или iOS и распространить через соответствующие магазины приложений.

К счастью, нам не нужно начинать с нуля, чтобы реализовать клиент Hyperview. Репозиторий кода Hyperview поставляется с демонстрационным сервером и демонстрационным клиентом, созданным с использованием Expo. Мы будем использовать этот демонстрационный клиент, но в качестве отправной точки укажем его на серверную часть нашего приложения контактов.

> git clone [e-mail]:Instawork/hyperview.git
> cd hyperview/demo
> yarn (1)
> yarn start (2)

1. Установите зависимости для демонстрационного приложения

2. Запустите сервер Expo, чтобы запустить мобильное приложение в симуляторе iOS.

После запуска yarn startвам будет предложено открыть мобильное приложение с помощью эмулятора Android или симулятора iOS. Выберите вариант в зависимости от того, какой SDK разработчика у вас установлен. (Снимки экрана в этой главе взяты из симулятора iOS.) Если повезет, вы увидите мобильное приложение Expo, установленное в симуляторе. Мобильное приложение автоматически запустится и отобразит экран с надписью «Ошибка сетевого запроса». Это связано с тем, что по умолчанию это приложение настроено на отправку запроса на http://0.0.0.0:8085/index.xml, но наш сервер прослушивает порт 5000. Чтобы исправить это, мы можем внести простое изменение конфигурации в demo/src/constants.jsфайл:

//export const ENTRY_POINT_URL = 'http://0.0.0.0:8085/index.xml'; (1)
export const ENTRY_POINT_URL = 'http://0.0.0.0:5000/'; (2)

1. URL-адрес точки входа по умолчанию в демонстрационном приложении.

2. Настройка URL-адреса, указывающего на наше приложение контактов

Мы еще не в деле. Теперь, когда наш клиент Hyperview указывает на правильную конечную точку, мы видим другую ошибку — «ParseError». Это связано с тем, что серверная часть отвечает на запросы содержимым HTML, а клиент Hyperview ожидает ответа в формате XML (в частности, HXML). Итак, пришло время обратить внимание на наш сервер Flask. Мы рассмотрим представления Flask и заменим шаблоны HTML шаблонами HXML. В частности, давайте поддержим следующие функции в нашем мобильном приложении:

• Список контактов с возможностью поиска

• Просмотр сведений о контакте

• Редактирование контакта

• Удаление контакта

• Добавление нового контакта

Нулевая конфигурация клиента в приложениях Hypermedia

Для многих мобильных приложений, использующих клиент Hyperview, настройка этого URL-адреса точки входа — единственный код на устройстве, который необходимо написать для доставки полнофункционального приложения. Рассматривайте URL-адрес точки входа как адрес, который вы вводите в веб-браузер, чтобы открыть веб-приложение. За исключением Hyperview, здесь нет адресной строки, а браузер жестко запрограммирован на открытие только одного URL-адреса. Этот URL-адрес будет загружать первый экран, когда пользователь запускает приложение. Любое другое действие, которое может предпринять пользователь, будет объявлено в HXML этого первого экрана. Эта минимальная конфигурация является одним из преимуществ архитектуры на основе Hypermedia.

Конечно, вам может потребоваться написать больше кода на устройстве, чтобы поддерживать больше функций в вашем мобильном приложении. Мы продемонстрируем, как это сделать, позже в этой главе, в разделе «Расширение клиента».

Список контактов с возможностью поиска

Мы начнем создавать наше приложение Hyperview с экрана точки входа и списка контактов. Для начальной версии этого экрана давайте поддержим следующие функции веб-приложения:

• отображать прокручиваемый список контактов

• Поле «поиск по мере ввода» над списком

• «бесконечная прокрутка» для загрузки большего количества контактов по мере прокрутки пользователем

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

Если вы помните, все страницы веб-приложения «Контакты» имеют общий базовый шаблон layout.html. Нам нужен аналогичный базовый шаблон для экранов мобильного приложения. Этот базовый шаблон будет содержать правила стиля нашего пользовательского интерфейса и базовую структуру, общую для всех экранов. Давайте назовем это layout.xml.

<doc xmlns="https://hyperview.org/hyperview">
  <screen>
    <styles><!-- omitted for brevity --></styles>
    <body style="body" safe-area="true">
      <header style="header">
        {% block header %} (1)
          <text style="header-title">Contact.app</text>
        {% endblock %}
      </header>

      <view style="main">
        {% block content %}{% endblock %} (2)
      </view>
    </body>
  </screen>
</doc>

1. Раздел заголовка шаблона с заголовком по умолчанию.

2. Раздел содержимого шаблона, предоставляемый другими шаблонами.

Мы используем теги и атрибуты HXML, описанные в предыдущей главе. Этот шаблон устанавливает базовый макет экрана с использованием тегов <doc>, <screen>, <body>, <header>и <view>. Обратите внимание, что синтаксис HXML хорошо сочетается с библиотекой шаблонов Jinja. Здесь мы используем блоки Jinja для определения двух разделов ( headerи content), которые будут содержать уникальное содержимое экрана. Закончив наш базовый шаблон, мы можем создать шаблон специально для экрана списка контактов.

{% extends 'hv/layout.xml' %} (1)

{% block content %} (2)
  <form> (3)
    <text-field name="q" value="" placeholder="Search..." style="search-field" />
    <list id="contacts-list"> (4)
      {% include 'hv/rows.xml' %}
    </list>
  </form>
{% endblock %}

1. Расширение базового шаблона макета

2. Переопределить contentблок шаблона макета

3. Создайте форму поиска, которая будет выдавать HTTP-запрос GETна/contacts

4. Список контактов с использованием includeтега Jinja.

Этот шаблон расширяет базу layout.xmlи переопределяет contentблок с помощью <form>. На первый взгляд может показаться странным, что форма охватывает как элементы, <text-field>так и <list>элементы. Но помните: в Hyperview данные формы включаются в любой запрос, исходящий от дочернего элемента. Вскоре мы добавим в список взаимодействия (потяните, чтобы обновить), для которых потребуются данные формы. Обратите внимание на использование includeтега Jinja для отображения HXML для строк контактов в списке ( hv/rows.xml). Как и в шаблонах HTML, мы можем использовать, includeчтобы разбить наш HXML на более мелкие части. Это также позволяет серверу отвечать только шаблоном rows.xmlдля таких взаимодействий, как поиск, бесконечная прокрутка и обновление по запросу.

<items xmlns="https://hyperview.org/hyperview"> (1)
  {% for contact in contacts %} (2)
    <item key="{{ contact.id }}" style="contact-item"> (3)
      <text style="contact-item-label">
        {% if contact.first %}
          {{ contact.first }} {{ contact.last }}
        {% elif contact.phone %}
          {{ contact.phone }}
        {% elif contact.email %}
          {{ contact.email }}
        {% endif %}
      </text>
    </item>
  {% endfor %}
</items>

1. Элемент HXML, группирующий набор <item>элементов в одном родительском элементе.

2. Переберите контакты, которые были переданы в шаблон.

3. Отобразите значок <item>для каждого контакта, указав имя, номер телефона или адрес электронной почты.

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

Теперь у нас есть шаблоны для базового макета, экрана контактов и строк контактов. Но нам все равно придется обновить представления Flask, чтобы использовать эти шаблоны. Давайте посмотрим на contacts()представление в его текущей форме, написанное для веб-приложения:

@app.route("/contacts")
def contacts():
    search = request.args.get("q")
    page = int(request.args.get("page", 1))
    if search:
        contacts_set = Contact.search(search)
        if request.headers.get('HX-Trigger') == 'search':
            return render_template("rows.html", contacts=contacts_set, page=page)
    else:
        contacts_set = Contact.all(page)
    return render_template("index.html", contacts=contacts_set, page=page)

Это представление поддерживает выборку набора контактов на основе двух параметров запроса q: page. Он также решает, следует ли отображать всю страницу ( index.html) или только строки контактов ( rows.html) на основе HX-Triggerзаголовка. Это представляет собой небольшую проблему. Заголовок HX-Triggerустанавливается библиотекой htmx; в Hyperview нет эквивалентной функции. Более того, в Hyperview существует несколько сценариев, которые требуют от нас ответа только строками контактов:

• идет поиск

• потянуть, чтобы обновить

• загрузка следующей страницы контактов

Поскольку мы не можем зависеть от заголовка типа HX-Trigger, нам нужен другой способ определить, нужен ли клиенту полноэкранный режим или только строки в ответе. Мы можем сделать это, введя новый параметр запроса rows_only. Если этот параметр имеет значение true, представление ответит на запрос, отобразив rows.xmlшаблон. В противном случае он ответит шаблоном index.xml:

@app.route("/contacts")
def contacts():
    search = request.args.get("q")
    page = int(request.args.get("page", 1))
    rows_only = request.args.get("rows_only") == "true" (1)
    if search:
        contacts_set = Contact.search(search)
    else:
        contacts_set = Contact.all(page)

    template_name = "hv/rows.xml" if rows_only else "hv/index.xml" (2)
    return render_template(template_name, contacts=contacts_set, page=page)

1. Проверьте наличие нового rows_onlyпараметра запроса.

2. Отобразите соответствующий шаблон HXML на основе rows_only.

Нам нужно внести еще одно изменение. Flask предполагает, что большинство представлений будут отвечать HTML. Поэтому Flask по умолчанию присваивает Content-Typeзаголовку ответа значение text/html. Но клиент Hyperview ожидает получить контент HXML, указанный в Content-Typeзаголовке ответа со значением application/vnd.hyperview+xml. Клиент будет отклонять ответы с другим типом контента. Чтобы это исправить, нам нужно явно установить Content-Typeзаголовок ответа в наших представлениях Flask. Мы сделаем это, представив новую вспомогательную функцию render_to_response():

def render_to_response(template_name, *args, **kwargs):
    content = render_template(template_name, *args, **kwargs) (1)
    response = make_response(content) (2)
    response.headers['Content-Type'] = 'application/vnd.hyperview+xml' (3)
    return response

1. Отображает заданный шаблон с предоставленными аргументами и аргументами ключевого слова.

2. Создайте явный объект ответа с помощью визуализированного шаблона.

3. Устанавливает заголовок ответа Content-Typeв формате XML.

Как видите, эта вспомогательная функция работает render_template()скрытно. render_template()возвращает строку. Эта вспомогательная функция использует эту строку для создания явного Responseобъекта. У объекта ответа есть headersатрибут, позволяющий нам устанавливать и изменять заголовки ответа. В частности, render_to_response()устанавливается Content-Typeзначение application/vnd.hyperview+xml, позволяющее клиенту Hyperview распознавать содержимое. Этот помощник является заменой для render_templatein наших представлений. Итак, все, что нам нужно сделать, это обновить последнюю строку функции contacts().

return render_to_response(template_name, contacts=contacts_set, page=page) (1)

1. Преобразуйте шаблон HXML в ответ XML.

Благодаря этим изменениям в contacts()представлении мы наконец сможем увидеть плоды нашего труда. После перезапуска серверной части и обновления экрана в нашем мобильном приложении мы видим экран контактов!

Рисунок 1. Экран контактов

Поиск контактов

На данный момент у нас есть мобильное приложение, которое отображает экран со списком контактов. Но наш пользовательский интерфейс не поддерживает никаких взаимодействий. Ввод запроса в поле поиска не фильтрует список контактов. Давайте добавим поведение в поле поиска, чтобы реализовать взаимодействие поиска по мере ввода. Это требует расширения <text-field>, чтобы добавить <behavior>элемент.

<text-field name="q" value="" placeholder="Search..." style="search-field">
  <behavior
    trigger="change" (1)
    action="replace-inner" (2)
    target="contacts-list" (3)
    href="/contacts?rows_only=true" (4)
    verb="get" (5)
  />
</text-field>

1. Это поведение сработает при изменении значения текстового поля.

2. Когда поведение сработает, действие заменит содержимое внутри целевого элемента.

3. Целью действия является элемент с идентификатором contacts-list.

4. Содержимое для замены будет получено по этому URL-пути.

5. Содержимое замены будет получено методом GETHTTP.

Первое, что вы заметите, это то, что мы изменили текстовое поле с использования самозакрывающегося тега ( <text-field />) на использование открывающего и закрывающего тегов ( <text-field>…​</text-field>). Это позволяет нам добавить дочерний <behavior>элемент для определения взаимодействия.

Атрибут trigger="change"сообщает Hyperview, что изменение значения текстового поля вызовет действие. Каждый раз, когда пользователь редактирует содержимое текстового поля, добавляя или удаляя символы, срабатывает действие.

Остальные атрибуты элемента <behavior>определяют действие. action="replace-inner"означает, что действие обновит содержимое на экране, заменив содержимое HXML элемента новым содержимым. Чтобы replace-innerвыполнить свою задачу, нам нужно знать две вещи: текущий элемент на экране, на который будет нацелено действие, и контент, который будет использоваться для замены. target="contacts-list"сообщает нам идентификатор текущего элемента. Обратите внимание, что мы устанавливаем id="contacts-list"элемент <list>в index.xml. Поэтому, когда пользователь вводит поисковый запрос в текстовое поле, Hyperview заменит содержимое <list>(группу <item>элементов) новым содержимым (<item>элементы, соответствующие поисковому запросу), полученные в соответствующем ответе href. Домен здесь выводится из домена, используемого для получения экрана. Обратите внимание, что это hrefвключает в себя наш rows_onlyпараметр запроса; мы хотим, чтобы ответ включал только строки, а не весь экран.

Рисунок 2. Поиск контактов

Это все, что нужно, чтобы добавить в наше мобильное приложение функцию поиска по мере ввода! Когда пользователь вводит поисковый запрос, клиент будет отправлять запросы к серверной части и заменять список результатами поиска. Вам может быть интересно, откуда серверная часть узнает, какой запрос использовать? Атрибут hrefв поведении не включает параметр, qожидаемый нашим сервером. Но помните, что в index.xml, мы обернули элементы <text-field>и <list>родительским <form>элементом. Элемент <form>определяет группу входных данных, которые будут сериализованы и включены в любые HTTP-запросы, инициированные его дочерними элементами. В этом случае <form>элемент окружает поведение поиска и текстовое поле. Таким образом, ценность<text-field>будет включен в наш HTTP-запрос для результатов поиска. Поскольку мы делаем GETзапрос, имя и значение текстового поля будут сериализованы как параметр запроса. Любые существующие параметры запроса hrefбудут сохранены. Это означает, что фактический HTTP-запрос к нашему серверу выглядит так GET /contacts?rows_only=true&q=Car: Наша серверная часть уже поддерживает qпараметр для поиска, поэтому ответ будет включать строки, соответствующие строке «Автомобиль».

Бесконечная прокрутка

Если у пользователя сотни или тысячи контактов, загрузка их всех одновременно может привести к снижению производительности приложения. Вот почему большинство мобильных приложений с длинными списками реализуют взаимодействие, известное как «бесконечная прокрутка». Приложение загружает в список фиксированное количество начальных элементов, скажем, 100 элементов. Если пользователь прокручивает список до конца, он видит счетчик, указывающий, что загружается больше контента. Как только контент станет доступен, счетчик заменяется следующей страницей из 100 элементов. Эти элементы добавляются в список, а не заменяют первый набор элементов. Итак, список теперь содержит 200 пунктов. Если пользователь снова прокрутит список до конца, он увидит еще один счетчик, и приложение загрузит следующий набор контента. Бесконечная прокрутка повышает производительность приложения двумя способами:

• Первоначальный запрос на 100 элементов будет обработан быстро с предсказуемой задержкой.

• Последующие запросы также могут быть быстрыми и предсказуемыми.

• Если пользователь не прокрутит список до конца, приложению не придется выполнять последующие запросы.

Наш бэкэнд Flask уже поддерживает нумерацию страниц на /contactsконечной точке через pageпараметр запроса. Нам просто нужно изменить наши шаблоны HXML, чтобы использовать этот параметр. Для этого давайте отредактируем rows.xmlи добавим новый <item>ниже цикла for Jinja:

<items xmlns="https://hyperview.org/hyperview">
  {% for contact in contacts %}
    <item key="{{ contact.id }}" style="contact-item">
      <!-- omitted for brevity -->
    </item>
  {% endfor %}
  {% if contacts|length > 0 %}
    <item key="load-more" id="load-more" style="load-more-item"> (1)
      <behavior
        trigger="visible" (2)
        action="replace" (3)
        target="load-more" (4)
        href="/contacts?rows_only=true&page={{ page + 1 }}" (5)
        verb="get"
      />
      <spinner /> (6)
    </item>
  {% endif %}
</items>

1. Включите в список дополнительный элемент <item>, чтобы отобразить счетчик.

2. Поведение элемента срабатывает, когда он виден в области просмотра.

3. При срабатывании поведение заменит элемент на экране.

4. Заменяемым элементом является сам элемент (ID load-more).

5. Замените элемент следующей страницей содержимого.

6. Спиннерный элемент.

Если текущий список контактов, переданный в шаблон, пуст, мы можем предположить, что больше нет контактов, которые можно было бы получить из серверной части. Поэтому мы используем условие Jinja, чтобы включать это новое только <item>в том случае, если список контактов не пуст. Этот новый <item>элемент получает идентификатор и поведение. Поведение определяет взаимодействие бесконечной прокрутки.

До сих пор мы видели triggerзначения changeи refresh. Но для реализации бесконечной прокрутки нам нужен способ запускать действие, когда пользователь прокручивает список до конца. Триггер visibleможно использовать именно для этой цели. Это вызовет действие, когда элемент с таким поведением будет виден в окне просмотра устройства. В этом случае новый <item>элемент является последним элементом в списке, поэтому действие сработает, когда пользователь прокрутит вниз достаточно далеко, чтобы элемент попал в область просмотра. Как только элемент станет видимым, действие выполнит HTTP-запрос GET и заменит <item>элемент загрузки содержимым ответа.

Обратите внимание, что наш href должен включать rows_only=trueпараметр запроса, чтобы наш ответ включал HXML только для элементов контакта, а не для всего экрана. Кроме того, мы передаем pageпараметр запроса, увеличивая номер текущей страницы, чтобы гарантировать загрузку следующей страницы.

Что происходит, когда элементов имеется более одной страницы? Начальный экран будет включать первые 100 элементов, а также элемент «Загрузить еще» внизу. Когда пользователь прокручивает экран до нижней части, Hyperview запросит вторую страницу элементов ( &page=2) и заменит элемент «Загрузить больше» новыми элементами. Но на этой второй странице элементов будет новый элемент «Загрузить больше». Поэтому, как только пользователь прокрутит все элементы на второй странице, Hyperview снова запросит дополнительные элементы ( &page=3). И снова пункт «загрузить еще» будет заменен на новые элементы. Это будет продолжаться до тех пор, пока все элементы не будут загружены на экран. В этот момент больше не будет контактов для возврата, ответ не будет включать еще один элемент «загрузить больше», и наша нумерация страниц будет завершена.

Обновление по запросу

Обновление по запросу — обычное взаимодействие в мобильных приложениях, особенно на экранах с динамическим контентом. Это работает следующим образом: в верхней части прокручиваемого представления пользователь тянет прокручиваемый контент вниз жестом прокрутки вниз. Это покажет счетчик «под» содержимым. Если переместить контент вниз на достаточное расстояние, произойдет обновление. Пока содержимое обновляется, счетчик остается видимым на экране, указывая пользователю, что действие все еще происходит. После обновления содержимого оно возвращается в положение по умолчанию, скрывая счетчик и давая пользователю знать, что взаимодействие завершено.

Рисунок 3. Обновление по запросу

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

<list id="contacts-list"
  trigger="refresh" (1)
  action="replace-inner" (2)
  target="contacts-list" (3)
  href="/contacts?rows_only=true" (4)
  verb="get" (5)
>
  {% include 'hv/rows.xml' %}
</list>

1. Это поведение сработает, когда пользователь выполнит жест «потянуть, чтобы обновить».

2. Когда поведение сработает, это действие заменит содержимое внутри целевого элемента.

3. Целью действия является <list>сам элемент.

4. Содержимое для замены будет получено по этому URL-пути.

5. Содержимое замены будет получено методом GETHTTP.

В приведенном выше фрагменте вы заметите кое-что необычное: вместо добавления элемента <behavior>в <list>, мы добавили атрибуты поведения непосредственно к <list>элементу. Это сокращенное обозначение, которое иногда полезно для указания отдельного поведения элемента. Это эквивалентно добавлению <behavior>элемента <list>с теми же атрибутами.

Так почему же мы использовали здесь сокращенный синтаксис? Это связано с действием replace-inner. Помните, что это действие заменяет все дочерние элементы цели новым содержимым. Это включает в себя <behavior>и элементы! Допустим, наш <list>файл содержал файл <behavior>. Если бы пользователь выполнил поиск или обновил по запросу, мы бы заменили содержимое <list>содержимым из rows.xml. Больше <behavior>не будет определяться в <list>, и последующие попытки обновления не сработают. Если поведение определить как атрибуты <list>, оно будет сохраняться даже при замене элементов в списке. Обычно мы предпочитаем использовать явные<behavior>элементы в HXML. Это упрощает определение нескольких вариантов поведения и их перемещение во время рефакторинга. Но сокращенный синтаксис удобен для применения в подобных ситуациях.

Просмотр сведений о контакте

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

<items xmlns="https://hyperview.org/hyperview">
  {% for contact in contacts %}
    <item key="{{ contact.id }}" style="contact-item">
      <behavior trigger="press" action="push" href="/contacts/{{ contact.id }}" /> (1)
      <text style="contact-item-label">
        <!-- omitted for brevity -->
      </text>
    </item>
  {% endfor %}
</items>

1. Поведение, позволяющее помещать экран сведений о контакте в стек при нажатии.

В нашем бэкэнде Flask уже есть маршрут для предоставления контактных данных по адресу /contacts/<contact_id>. В нашем шаблоне мы используем переменную Jinja для динамического создания URL-пути для текущего контакта в цикле for. Мы также использовали действие «push», чтобы показать детали, помещая новый экран в стек. Если вы перезагрузите приложение, вы сможете коснуться любого контакта в списке, и Hyperview откроет новый экран. Однако на новом экране появится сообщение об ошибке. Это потому, что наш сервер по-прежнему возвращает в ответ HTML, а клиент Hyperview ожидает HXML. Давайте обновим серверную часть, чтобы она отвечала HXML и соответствующими заголовками.

@app.route("/contacts/<contact_id>")
def contacts_view(contact_id=0):
    contact = Contact.find(contact_id)
    return render_to_response("hv/show.xml", contact=contact) (1)

1. Создайте ответ XML из нового файла шаблона.

Как и contacts()представление, contacts_view()используется render_to_response()для установки Content-Typeзаголовка ответа. Мы также генерируем ответ из нового шаблона HXML, который мы можем создать сейчас:

{% extends 'hv/layout.xml' %} (1)

{% block header %} (2)
  <text style="header-button">
    <behavior trigger="press" action="back" /> (3)
    Back
  </text>
{% endblock %}

{% block content %} (4)
<view style="details">
  <text style="contact-name">{{ contact.first }} {{ contact.last }}</text>

  <view style="contact-section">
    <text style="contact-section-label">Phone</text>
    <text style="contact-section-info">{{contact.phone}}</text>
  </view>

  <view style="contact-section">
    <text style="contact-section-label">Email</text>
    <text style="contact-section-info">{{contact.email}}</text>
  </view>
</view>
{% endblock %}

1. Расширьте базовый шаблон макета.

2. Переопределите headerблок шаблона макета, включив в него кнопку «Назад».

3. Поведение для перехода к предыдущему экрану при нажатии.

4. Переопределите contentблок, чтобы отобразить полную информацию о выбранном контакте.

Экран сведений о контактах расширяет базовый layout.xmlшаблон, как мы это делали в index.xml. На этот раз мы переопределяем контент как в headerблоке, так и contentв блоке. Переопределение блока заголовка позволяет нам добавить кнопку «Назад» с поведением. При нажатии клиент Hyperview раскрутит стек навигации и вернет пользователя в список контактов.

Обратите внимание, что запуск этого поведения — не единственный способ вернуться назад. Клиент Hyperview соблюдает соглашения о навигации на разных платформах. В iOS пользователи также могут перейти к предыдущему экрану, проведя пальцем вправо от левого края устройства. На Android пользователи также могут перейти к предыдущему экрану, нажав аппаратную кнопку «Назад». Нам не нужно указывать что-либо дополнительно в HXML, чтобы получить эти взаимодействия.

Рисунок 4. Экран сведений о контакте

С помощью всего лишь нескольких простых изменений мы перешли от одноэкранного приложения к многоэкранному. Обратите внимание: нам не нужно было ничего менять в коде мобильного приложения для поддержки нашего нового экрана. Это большое дело. При разработке традиционных мобильных приложений добавление экранов может оказаться серьезной задачей. Разработчикам необходимо создать новый экран, вставить его в соответствующее место иерархии навигации и написать код для открытия нового экрана из существующих экранов. В Hyperview мы только что добавили поведение с action="push".

Редактирование контакта

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

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

{% block header %}
  <text style="header-button">
    <behavior trigger="press" action="back" />
    Back
  </text>

  <text style="header-button"> (1)
    <behavior trigger="press" action="reload" href="/contacts/{{contact.id}}/edit" /> (2)
    Edit
  </text>
{% endblock %}

1. Новая кнопка «Редактировать».

2. Поведение для перезагрузки текущего экрана с экраном редактирования при нажатии.

Мы снова используем существующий маршрут Flask ( /contacts/<contact_id>/edit) для пользовательского интерфейса редактирования и заполняем идентификатор контакта, используя данные, переданные в шаблон Jinja. Нам также необходимо обновить contacts_edit_get()представление, чтобы оно возвращало ответ XML на основе шаблона HXML ( hv/edit.xml). Мы пропустим пример кода, поскольку необходимые изменения идентичны тем, которые мы применили contacts_view()в предыдущем разделе. Вместо этого давайте сосредоточимся на шаблоне экрана редактирования.

{% extends 'hv/layout.xml' %}

{% block header %}
  <text style="header-button">
    <behavior trigger="press" action="back" href="#" />
    Back
  </text>
{% endblock %}

{% block content %}
<form> (1)
  <view id="form-fields"> (2)
    {% include 'hv/form_fields.xml' %} (3)
  </view>

  <view style="button"> (4)
    <behavior
      trigger="press"
      action="replace-inner"
      target="form-fields"
      href="/contacts/{{contact.id}}/edit"
      verb="post"
    />
    <text style="button-label">Save</text>
  </view>
</form>
{% endblock %}

1. Форма, обертывающая поля ввода и кнопки.

2. Контейнер с идентификатором, содержащий поля ввода.

3. Шаблон включает в себя визуализацию полей ввода.

4. Кнопка для отправки данных формы и обновления контейнера полей ввода.

Поскольку экрану редактирования необходимо отправлять данные на серверную часть, мы заключаем весь раздел содержимого в <form>элемент. Это гарантирует, что данные полей формы будут включены в HTTP-запросы к нашему серверу. Внутри <form>элемента наш пользовательский интерфейс разделен на две части: поля формы и кнопку «Сохранить». Фактические поля формы определяются в отдельном шаблоне ( form_fields.xml) и добавляются на экран редактирования с помощью тега включения Jinja.

<view style="edit-group">
  <view style="edit-field">
    <text-field name="first_name" placeholder="First name" value="{{ contact.first }}" /> (1)
    <text style="edit-field-error">{{ contact.errors.first }}</text> (2)
  </view>

  <view style="edit-field"> (3)
    <text-field name="last_name" placeholder="Last name" value="{{ contact.last }}" />
    <text style="edit-field-error">{{ contact.errors.last }}</text>
  </view>

  <!-- same markup for contact.email and contact.phone -->
</view>

1. Ввод текста, содержащий текущее значение имени контакта.

2. Текстовый элемент, который может отображать ошибки из модели контакта.

3. Еще одно текстовое поле, на этот раз для фамилии контакта.

Мы опустили код номера телефона и адреса электронной почты контакта, поскольку они соответствуют тому же шаблону, что и имя и фамилия. Каждое поле контакта имеет свой собственный элемент <text-field>, а также <text>элемент под ним для отображения возможных ошибок. Имеет <text-field>два важных атрибута:

• nameопределяет имя, которое будет использоваться при сериализации значения текстового поля в данные формы для HTTP-запросов. Мы используем те же имена, что и веб-приложение из предыдущих глав ( first_name, last_name, phone, email). Таким образом, нам не нужно вносить изменения в наш сервер для анализа данных формы.

• valueопределяет предварительно заполненные данные в текстовом поле. Поскольку мы редактируем существующий контакт, имеет смысл предварительно заполнить текстовое поле текущим именем, телефоном или электронной почтой.

Вам может быть интересно, почему мы решили определить поля формы в отдельном шаблоне ( form_fields.xml)? Чтобы понять это решение, нам нужно сначала обсудить кнопку «Сохранить». При нажатии клиент Hyperview отправит HTTP- POSTзапрос к contacts/<contact_id>/edit, с сериализацией данных формы из <text-field>входных данных. Ответ HXML заменит содержимое контейнера поля формы (ID form-fields). Но каким должен быть этот ответ? Это зависит от достоверности данных формы:

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

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

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

@app.route("/contacts/<contact_id>/edit", methods=["POST"])
def contacts_edit_post(contact_id=0):
    c = Contact.find(contact_id)
    c.update(request.form['first_name'], request.form['last_name'], request.form['phone'], request.form['email']) (1)
    if c.save(): (2)
        flash("Updated Contact!")
        return render_to_response("hv/form_fields.xml", contact=c, saved=True) (3)
    else:
        return render_to_response("hv/form_fields.xml", contact=c) (4)

1. Обновите объект контакта из данных формы запроса.

2. Попытайтесь сохранить обновления. Это возвращает Falseневерные данные.

3. В случае успеха отобразите шаблон полей формы и передайте флаг savedшаблону.

4. В случае неудачи отобразить шаблон полей формы. На объекте контакта присутствуют сообщения об ошибках.

Это представление уже содержит условную логику, основанную на успешности модели контакта save(). Если save()не получается, мы визуализируем form_fields.xmlшаблон. contact.errorsбудет содержать сообщения об ошибках для недопустимых полей, которые будут отображаться в <text style="edit-field-error">элементах. Если save()получится, мы также отрендерим form_fields.xmlшаблон. Но на этот раз шаблон получит savedфлаг, указывающий на успех. Мы обновим шаблон, чтобы использовать этот флаг для реализации желаемого пользовательского интерфейса: переключение пользовательского интерфейса обратно в режим отображения.

<view style="edit-group">
  {% if saved %} (1)
    <behavior
      trigger="load" (2)
      action="reload" (3)
      href="/contacts/{{contact.id}}" (4)
    />
  {% endif %}

  <view style="edit-field">
    <text-field name="first_name" placeholder="First name" value="{{ contact.first }}" />
    <text style="edit-field-error">{{ contact.errors.first }}</text>
  </view>

  <!-- same markup for the other fields -->
</view>

1. Включайте это поведение только после успешного сохранения контакта.

2. Немедленно запустите поведение.

3. Поведение перезагрузит весь экран.

4. Экран будет перезагружен с экраном контактной информации.

Условие шаблона Jinja гарантирует, что наше поведение отображается только при успешном сохранении, а не при первом открытии экрана (или при отправке пользователем неверных данных). В случае успеха шаблон включает поведение, которое срабатывает немедленно благодаря trigger="load". Действие перезагружает текущий экран с экраном «Сведения о контакте» (из маршрута /contacts/<contact_id>).

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

Почему бы не перенаправить?

Возможно, вы помните, что версия этого кода для веб-приложения вела себя немного иначе. При успешном сохранении представление вернулось redirect("/contacts/" + str(contact_id)). Это перенаправление HTTP сообщит веб-браузеру перейти на страницу контактных данных.

Этот подход не поддерживается в Hyperview. Почему? Стек навигации веб-приложения прост: линейная последовательность страниц, активная только одна. Навигация в мобильном приложении значительно сложнее. Мобильные приложения используют вложенную иерархию стеков навигации, модальных окон и вкладок. Все экраны в этой иерархии активны и могут отображаться мгновенно в ответ на действия пользователя. Как в этом мире клиент Hyperview интерпретирует перенаправление HTTP? Должен ли он перезагрузить текущий экран, отправить новый или перейти к экрану в стеке с тем же URL-адресом?

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

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

Давайте добавим еще одно улучшение в интерфейс редактирования. Было бы неплохо позволить пользователю выходить из режима редактирования без необходимости сохранять контакт. Обычно это делается с помощью действия «Отмена». Мы можем добавить это как новую кнопку под кнопкой «Сохранить».

<view style="button">
  <behavior trigger="press" action="replace-inner" target="form-fields" href="/contacts/{{contact.id}}/edit" verb="post" />
  <text style="button-label">Save</text>
</view>
<view style="button"> (1)
  <behavior
    trigger="press"
    action="reload" (2)
    href="/contacts/{{contact.id}}" (3)
  />
  <text style="button-label">Cancel</text>
</view>

1. Новая кнопка «Отмена» на экране редактирования.

2. При нажатии перезагрузка всего экрана.

3. Экран будет перезагружен с экраном контактной информации.

Это тот же метод, который мы использовали для переключения с пользовательского интерфейса редактирования на пользовательский интерфейс сведений после успешного редактирования контакта. Но нажатие «Отменить» обновит пользовательский интерфейс быстрее, чем нажатие «Сохранить». При сохранении приложение сначала сделает POSTзапрос на сохранение данных, а затем GETзапросит экран с подробностями. Отмена пропускает POSTи немедленно выполняет GETзапрос.

Рисунок 5. Экран редактирования контакта

Обновление списка контактов

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

1. Запустите приложение в списке контактов.

2. Нажмите на контакт «Джо Блоу», чтобы загрузить его контактную информацию.

3. Нажмите «Изменить», чтобы переключиться в режим редактирования, и измените имя контакта на «Джозеф».

4. Нажмите «Сохранить», чтобы вернуться в режим просмотра. Имя контакта теперь «Джозеф Блоу».

5. Нажмите кнопку «Назад», чтобы вернуться в список контактов.

Вы уловили проблему? В нашем списке контактов по-прежнему отображается тот же список имен, что и при запуске приложения. Контакт, который мы только что переименовали в «Джозеф», по-прежнему отображается в списке как «Джо». Это общая проблема в гипермедийных приложениях. Клиент не имеет понятия об общих данных в разных частях пользовательского интерфейса. Обновления в одной части приложения не будут автоматически обновлять другие части приложения.

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

Поведение событий

События — это клиентская функция Hyperview. В разделе «Клиентские сценарии» мы обсуждали события при работе с HTML, _hyperscript и DOM. Элементы DOM будут отправлять события в результате взаимодействия с пользователем. Скрипты могут прослушивать эти события и реагировать на них, запуская произвольный код JavaScript.

События в Hyperview намного проще, но они не требуют каких-либо сценариев и могут быть определены декларативно в HXML. Это делается через систему поведения. События требуют добавления нового атрибута поведения, типа действия и типа триггера:

• event-name: Этот атрибут <behavior>определяет имя события, которое будет либо отправлено, либо прослушиваться.

• action="dispatch-event": при срабатывании это поведение отправляет событие с именем, определенным атрибутом event-name. Это событие отправляется глобально по всему приложению Hyperview.

• trigger="on-event": это поведение сработает, если другое поведение в приложении отправит событие, соответствующее event-nameатрибуту.

Если <behavior>элемент использует action="dispatch-event"или trigger="on-event", он также должен определить event-name. Обратите внимание, что несколько вариантов поведения могут отправлять событие с одним и тем же именем. Аналогично, одно и то же событие может активировать несколько вариантов поведения.

Давайте посмотрим на это простое поведение:

<behavior trigger="press" action="toggle" target="container" />.

Нажатие на элемент, содержащий это поведение, переключит видимость элемента с идентификатором «контейнер». Но что, если элемент, который мы хотим переключить, находится на другом экране? Действие «переключение» и поиск идентификатора цели работают только на текущем экране, поэтому это решение не будет работать. Решение состоит в том, чтобы создать два поведения, по одному на каждом экране, взаимодействующие через события:

• Экран А:<behavior trigger="press" action="dispatch-event" event-name="button-pressed" />

• Экран Б:<behavior trigger="on-event" event-name="button-pressed" action="toggle" target="container" />

Нажатие на элемент, содержащий первое поведение (на экране A), отправит событие с именем «нажатие кнопки». Второе поведение (на экране B) сработает при событии с этим именем и переключит видимость элемента с идентификатором «контейнер».

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

Теперь мы знаем достаточно о системе событий Hyperview, чтобы устранить ошибку в нашем приложении. Когда пользователь сохраняет изменение контакта, нам нужно отправить событие с экрана «Сведения». И экран «Контакты» должен прослушивать это событие и перезагружаться, чтобы отразить изменения. Поскольку form_fields.xmlшаблон уже получает savedфлаг, когда серверная часть успешно сохраняет контакт, это хорошее место для отправки события:

{% if saved %}
  <behavior
    trigger="load" (1)
    action="dispatch-event" (2)
    event-name="contact-updated" (3)
  />
  <behavior (4)
    trigger="load"
    action="reload"
    href="/contacts/{{contact.id}}"
  />
{% endif %}

1. Немедленно запустите поведение.

2. Поведение отправит событие.

3. Название события — «обновление контактов».

4. Существующее поведение для отображения пользовательского интерфейса Details.

Теперь нам просто нужен список контактов, чтобы прослушать событие contact-updatedи перезагрузиться:

<form>
  <behavior
    trigger="on-event" (1)
    event-name="contact-updated" (2)
    action="replace-inner" (3)
    target="contacts-list"
    href="/contacts?rows_only=true"
    verb="get"
  />
  <!-- text-field omitted -->
  <list id="contacts-list">
    {% include 'hv/rows.xml' %}
  </list>
</form>

1. Запускайте поведение при отправке события.

2. Запускайте поведение для отправленных событий с именем «contact-updated».

3. При срабатывании замените содержимое элемента <list>строками из серверной части.

Каждый раз, когда пользователь редактирует контакт, экран списка контактов обновляется, отражая изменения. Добавление этих двух <behavior>элементов исправляет ошибку: на экране «Список контактов» в списке будет правильно отображаться «Джозеф Блоу». Обратите внимание: мы намеренно добавили новое поведение внутри <form>элемента. Это гарантирует, что инициируемый запрос сохранит любой поисковый запрос.

Чтобы показать, что мы имеем в виду, давайте вернемся к набору шагов, демонстрирующих ошибочное поведение. Предположим, что прежде чем нажать «Джо Блоу», пользователь выполнил поиск контактов, введя «Джо» в поле поиска. Когда позже пользователь обновляет контакт на «Джозеф Блоу», наш шаблон отправляет событие «contact-updated», которое запускает поведение replace-innerна экране списка контактов. Благодаря родительскому <form>элементу поисковый запрос «Джо» будет сериализован с запросом: GET /contacts?rows_only=true&q=Joe. Поскольку имя «Джозеф» не соответствует запросу «Джо», отредактированный нами контакт не появится в списке (пока пользователь не очистит запрос). Состояние нашего приложения остается неизменным на всей серверной части и на всех активных экранах.

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

Экрану все равно, что вызывает contact-updatedотправку события. Он просто знает, что ему нужно делать, когда это происходит.

Удаление контакта

Говоря об удалении контакта, это хорошая следующая функция, которую стоит реализовать. Мы разрешим пользователям удалять контакт из пользовательского интерфейса редактирования. Итак, давайте добавим новую кнопку в edit.xml.

<view style="button">
  <behavior trigger="press" action="replace-inner" target="form-fields" href="/contacts/{{contact.id}}/edit" verb="post" />
  <text style="button-label">Save</text>
</view>
<view style="button">
  <behavior trigger="press" action="reload" href="/contacts/{{contact.id}}" />
  <text style="button-label">Cancel</text>
</view>
<view style="button"> (1)
  <behavior
    trigger="press"
    action="append" (2)
    target="form-fields"
    href="/contacts/{{contact.id}}/delete" (3)
    verb="post"
  />
  <text style="button-label button-label-delete">Delete Contact</text>
</view>

1. Новая кнопка «Удалить контакт» на экране редактирования.

2. При нажатии добавьте HXML в контейнер на экране.

3. HXML будет получен по запросу POST /contacts/<contact_id>/delete.

HXML для кнопки «Удалить» очень похож на кнопку «Сохранить», но есть несколько тонких отличий. Помните, что нажатие кнопки «Сохранить» приводит к одному из двух ожидаемых результатов: сбой и отображение ошибок проверки в форме или успех и переключение на экран контактных данных. Для поддержки первого результата (сбой и отображение ошибок проверки) поведение сохранения заменяет содержимое контейнера <view id="form-fields">повторно обработанной версией form_fields.xml. Поэтому использование replace-innerдействия имеет смысл.

Удаление не требует этапа проверки, поэтому ожидаемый результат только один: успешное удаление контакта. После успешного удаления контакт больше не существует. Нет смысла показывать интерфейс редактирования или контактные данные для несуществующего контакта. Вместо этого наше приложение вернется к предыдущему экрану (списку контактов). Наш ответ будет включать только действия, которые срабатывают немедленно, пользовательский интерфейс менять не нужно. Таким образом, использование appendдействия сохранит текущий пользовательский интерфейс, пока Hyperview выполняет действия.

<view>
  <behavior trigger="load" action="dispatch-event" event-name="contact-updated" /> (1)
  <behavior trigger="load" action="back" /> (2)
</view>

1. При загрузке отправьте contact-updatedсобытие для обновления экрана списков контактов.

2. Вернитесь к экрану списка контактов.

Обратите внимание: помимо поведения для перехода назад, этот шаблон также включает поведение для отправки события contact-updated. В разделе предыдущей главы мы добавили поведение, позволяющее index.xmlобновлять список при отправке этого события. Отправляя событие после удаления, мы гарантируем, что удаленный контакт будет удален из списка.

Еще раз пропустим изменения в бэкэнде Flask. Достаточно сказать, что нам нужно будет обновить contacts_delete()представление, чтобы оно отвечало шаблоном hv/deleted.xml. И нам нужно обновить маршрут для поддержки POSTпомимо DELETE, так как клиент Hyperview понимает только GETи POST.

Теперь у нас есть полнофункциональная функция удаления! Но он не самый удобный: для окончательного удаления контакта достаточно одного случайного нажатия. Для деструктивных действий, таких как удаление контакта, всегда полезно запросить у пользователя подтверждение.

Мы можем добавить подтверждение к поведению удаления, используя alertсистемное действие, описанное в предыдущей главе. Как вы помните, это alertдействие покажет системное диалоговое окно с кнопками, которые могут запускать другие действия. Все, что нам нужно сделать, это обернуть удаление <behavior>в поведение, использующее action="alert".

<view style="button">
  <behavior (1)
    xmlns:alert="https://hyperview.org/hyperview-alert"
    trigger="press"
    action="alert"
    alert:title="Confirm delete"
    alert:message="Are you sure you want to delete {{ contact.first }}?"
  >
    <alert:option alert:label="Confirm"> (2)
      <behavior (3)
        trigger="press"
        action="append"
        target="form-fields"
        href="/contacts/{{contact.id}}/delete"
        verb="post"
      />
    </alert:option>
    <alert:option alert:label="Cancel" /> (4)
  </behavior>
  <text style="button-label button-label-delete">Delete Contact</text>
</view>

1. Нажатие «Удалить» запускает действие по отображению системного диалога с заданным заголовком и сообщением.

2. Первая нажимаемая опция в системном диалоге.

3. Нажатие первой опции приведет к удалению контакта.

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

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

Рисунок 6. Подтверждение удаления контакта

Добавление нового контакта

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

• Показать форму для сбора информации о контакте.

• Иметь способ сохранить введенную информацию.

• Покажите ошибки проверки в форме.

• Сохраните контакт, если нет ошибок проверки.

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

1. Обновление index.xml.

   • Переопределите headerблок, чтобы добавить новую кнопку «Добавить».

   • Включите поведение в кнопку. При нажатии нажмите новый экран как модальное с помощью action="new"и запросите содержимое экрана из /contacts/new.

2. Создайте шаблон hv/new.xml.

   • Переопределите блок заголовка, включив в него кнопку, закрывающую модальное окно, используя action="close".

   • Включите hv/form_fields.xmlшаблон для отображения пустых полей формы.

   • Добавьте кнопку «Добавить контакт» под полями формы.

   • Включите поведение в кнопку. При нажатии сделайте POSTзапрос /contacts/newи используйте action="replace-inner"для обновления полей формы.

3. Обновите представление Flask.

   • Измените contacts_new_get()для использования render_to_response()с hv/new.xmlшаблоном.

   • Измените contacts_new()для использования render_to_response()с hv/form_fields.xmlшаблоном. Пройти saved=Trueпри отрисовке шаблона после успешного сохранения нового контакта.

Повторно используя form_fields.xmlкак для редактирования, так и для добавления контакта, мы можем повторно использовать некоторый код и гарантировать, что обе функции имеют согласованный пользовательский интерфейс. Кроме того, наш экран «Добавить контакт» выиграет от «сохраненной» логики, которая уже является частью form_fields.xml. После успешного добавления нового контакта на экране будет отправлено событие contact-updated, которое обновит список контактов и отобразит вновь добавленный контакт. Экран перезагрузится и отобразит контактную информацию.

Рисунок 7. Модальное окно «Добавить контакт»

Развертывание приложения

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

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

1. Загрузите приложение Expo Go на устройство Android или iOS.

2. Перезапустите приложение Flask, привязавшись к интерфейсу, доступному в вашей сети. Это может выглядеть примерно так flask run --host 192.168.7.229: где хост — это IP-адрес вашего компьютера в сети.

3. Обновите код клиента Hyperview, чтобы ENTRY_POINT_URL(in demo/src/constants.js) указывал на IP-адрес и порт, к которым привязан сервер Flask.

4. После запуска yarn startдемо-приложения Hyperview вы увидите напечатанный в консоли QR-код с инструкциями по его сканированию на Android и iOS.

После сканирования QR-кода на устройстве запустится полная версия приложения. При взаимодействии с приложением вы увидите HTTP-запросы, отправленные на сервер Flask. Вы даже можете использовать физическое устройство во время разработки. Каждый раз, когда вы вносите изменения в HXML, просто перезагрузите экран, чтобы увидеть обновления пользовательского интерфейса.

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

1. Разверните наш бэкэнд в производстве. Нам нужно использовать веб-сервер производственного уровня, такой как Gunicorn, вместо сервера разработки Flask. И нам следует запустить наше приложение на машине, доступной через Интернет, скорее всего, с использованием облачного провайдера, такого как AWS или Heroku.

2. Создавайте автономные бинарные приложения. Следуя инструкциям проекта Expo, мы можем создать файл .ipaили .apkдля платформ iOS и Android. Не забудьте обновить ENTRY_POINT_URLклиент Hyperview, чтобы он указывал на производственный сервер.

3. Отправьте наши двоичные файлы в iOS App Store или Google Play Store и дождитесь одобрения приложения.

Как только приложение будет одобрено, поздравляем! Наше мобильное приложение могут скачать пользователи Android и iOS. И вот что самое приятное: поскольку наше приложение использует архитектуру гипермедиа, мы можем добавлять в него функции, просто обновляя серверную часть. Пользовательский интерфейс и взаимодействие полностью определяются с помощью HXML, созданного на основе серверных шаблонов. Хотите добавить новый раздел на экран? Просто обновите существующий шаблон HXML. Хотите добавить в приложение новый тип экрана? Создайте новый маршрут, представление и шаблон HXML. Затем добавьте к существующему экрану поведение, которое будет открывать новый экран. Чтобы донести эти изменения до своих пользователей, вам просто нужно повторно развернуть серверную часть. Наше приложение умеет интерпретировать HXML, и этого достаточно, чтобы понять, как обращаться с новыми функциями.

Один бэкэнд, несколько форматов гипермедиа

Чтобы создать мобильное приложение с использованием архитектуры гипермедиа, мы начали с веб-приложения контактов и внесли несколько изменений, в первую очередь заменив шаблоны HTML шаблонами HXML. Но в процессе портирования бэкенда для обслуживания нашего мобильного приложения мы потеряли функциональность веб-приложения. Действительно, если бы вы попытались зайти http://0.0.0.0:5000в веб-браузер, вы бы увидели беспорядочный текст и разметку XML. Это связано с тем, что веб-браузеры не знают, как отображать простой XML, и они, конечно, не знают, как интерпретировать теги и атрибуты HXML для отображения приложения. Это досадно, потому что код Flask для веб-приложения и мобильного приложения практически идентичен. Логика базы данных и модели является общей, и большинство представлений также не изменилось.

На этом этапе вы наверняка задаетесь вопросом: можно ли использовать один и тот же бэкэнд для обслуживания как веб-приложения, так и мобильного приложения? Ответ – да! Фактически, это одно из преимуществ использования архитектуры гипермедиа на нескольких платформах. Нам не нужно переносить какую-либо клиентскую логику с одной платформы на другую, нам просто нужно отвечать на запросы в соответствующем формате Hypermedia. Для этого мы будем использовать согласование контента, встроенное в HTTP.

Что такое согласование контента?

Представьте себе, что говорящий по-немецки и по-японски заходят на сайт https://google.comв своем веб-браузере. Они увидят домашнюю страницу Google, локализованную на немецкий и японский языки соответственно. Как Google узнает, что нужно вернуть другую версию главной страницы в зависимости от предпочитаемого языка пользователя? Ответ кроется в архитектуре REST и в том, как она разделяет концепции ресурсов и представлений.

В архитектуре REST домашняя страница Google считается единым «ресурсом», представленным уникальным URL-адресом. Однако этот единственный ресурс может иметь несколько «представлений». Представления — это варианты того, как содержимое ресурса представляется клиенту. Немецкая и японская версии главной страницы Google представляют собой два представления одного и того же ресурса. Чтобы определить наилучшее представление возвращаемого ресурса, HTTP-клиенты и серверы участвуют в процессе, называемом «согласованием контента». Это работает следующим образом:

• Клиенты указывают предпочтительное представление через Accept-*заголовки запросов.

• Сервер пытается максимально соответствовать предпочтительному представлению и возвращает выбранное представление, используя Content-*.

В примере с домашней страницей Google говорящий по-немецки использует браузер, в котором настроено предпочтение контента, локализованного на немецкий язык. Каждый HTTP-запрос, сделанный веб-браузером, будет включать заголовок Accept-Language: de-DE. Сервер видит заголовок запроса и вернет ответ, локализованный для немецкого языка (если сможет). Ответ HTTP будет включать Content-Language: de-DEзаголовок, информирующий клиента о языке содержимого ответа.

Язык — это лишь один из факторов представления ресурсов. Что еще более важно для нас, ресурсы могут быть представлены с использованием различных типов контента, таких как HTML или HXML. Согласование контента по типу контента выполняется с использованием Acceptзаголовка запроса и Content-Typeзаголовка ответа. Веб-браузеры установлены text/htmlв качестве предпочтительного типа контента в Acceptзаголовке. Клиент Hyperview устанавливает application/vnd.hyperview+xmlпредпочтительный тип контента. Это дает нашему серверу возможность различать запросы, поступающие от веб-браузера или клиента Hyperview, и предоставлять каждому соответствующий контент.

Существует два основных подхода к согласованию содержания: детальный и глобальный.

Подход 1: переключение шаблонов

Когда мы портировали приложение «Контакты» из Интернета на мобильные устройства, мы сохранили все представления Flask, но внесли некоторые незначительные изменения. В частности, мы представили новую функцию render_to_response()и вызвали ее в операторе возврата каждого представления. Вот еще раз функция, чтобы освежить вашу память:

def render_to_response(template_name, *args, **kwargs):
    content = render_template(template_name, *args, **kwargs)
    response = make_response(content)
    response.headers['Content-Type'] = 'application/vnd.hyperview+xml'
    return response

render_to_response()отображает шаблон с заданным контекстом и превращает его в объект ответа Flask с соответствующим Content-Typeзаголовком Hyperview. Очевидно, что реализация очень специфична для обслуживания нашего мобильного приложения Hyperview. Но мы можем изменить функцию для согласования содержимого на основе Acceptзаголовка запроса:

HTML_MIME = 'text/html'
HXML_MIME = 'application/vnd.hyperview+xml'

def render_to_response(html_template_name, hxml_template_name, *args, **kwargs): (1)
    response_type = request.accept_mimetypes.best_match([HTML_MIME, HXML_MIME], default=HTML_MIME) (2)
    template_name = hxml_template_name if response_type == HXML_MIME else html_template_name (3)
    content = render_template(template_name, *args, **kwargs)
    response = make_response(content)
    response.headers['Content-Type'] = response_type (4)
    return response

1. Сигнатура функции принимает два шаблона: один для HTML и один для HXML.

2. Определите, хочет ли клиент HTML или HXML.

3. Выберите шаблон, наиболее подходящий для клиента.

4. Установите Content-Typeзаголовок на основе наилучшего соответствия клиенту.

Объект запроса Flask предоставляет accept_mimetypesсвойство, помогающее при согласовании содержимого. Мы передаем два наших MIME-типа контента request.accept_mimetypes.best_match()и получаем обратно тот MIME-тип, который работает для нашего клиента. В зависимости от наиболее соответствующего типа MIME мы выбираем отображение шаблона HTML или шаблона HXML. Мы также обязательно устанавливаем Content-Typeдля заголовка соответствующий тип MIME. Единственная разница в наших представлениях Flask заключается в том, что нам нужно предоставить шаблон как HTML, так и HXML:

@app.route("/contacts/<contact_id>")
def contacts_view(contact_id=0):
    contact = Contact.find(contact_id)
    return render_to_response("show.html", "hv/show.xml", contact=contact) (1)

1. Переключение шаблонов между шаблонами HTML и HXML в зависимости от клиента.

После обновления всех представлений Flask для поддержки обоих шаблонов наш бэкэнд будет поддерживать как веб-браузеры, так и наше мобильное приложение! Этот метод хорошо работает для приложения «Контакты», поскольку экраны мобильного приложения напрямую связаны со страницами веб-приложения. Каждое приложение имеет специальную страницу (или экран) для перечисления контактов, отображения и редактирования сведений, а также создания нового контакта. Это означало, что представления Flask можно было оставить без каких-либо серьезных изменений.

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

Подход 2: Вилка перенаправления

Если вы помните, веб-приложение «Контакты» имеет indexпредставление, маршрутизируемое из корневого пути /:

@app.route("/")
def index():
    return redirect("/contacts") (1)

1. Перенаправить запросы с «/» на «/contacts»

Когда кто-то запрашивает корневой путь веб-приложения, Flask перенаправляет его на этот /contactsпуть. Это перенаправление также работает в нашем мобильном приложении Hyperview. Клиент Hyperview ENTRY_POINT_URLуказывает на http://0.0.0.0:5000/, а сервер перенаправляет его на http://0.0.0.0:5000/contacts. Но не существует закона, который бы предписывал нам перенаправляться на один и тот же путь в нашем веб-приложении и мобильном приложении. Что, если мы используем Acceptзаголовок перенаправления, чтобы выбрать путь перенаправления?

HTML_MIME = 'text/html'
HXML_MIME = 'application/vnd.hyperview+xml'

@app.route("/")
def index():
    response_type = request.accept_mimetypes.best_match([HTML_MIME, HXML_MIME], default=HTML_MIME) (1)
    if response_type == HXML_MIME:
      return redirect("/mobile/contacts") (2)
    else:
      return redirect("/web/contacts") (3)

1. Определите, хочет ли клиент HTML или HXML.

2. Если клиенту нужен HXML, перенаправьте его на /mobile/contacts.

3. Если клиенту нужен HTML, перенаправьте его на /web/contacts.

Точка входа — это развилка: если клиенту нужен HTML, мы перенаправляем его по одному пути. Если клиенту нужен HXML, мы перенаправляем его по другому пути. Эти перенаправления будут обрабатываться различными представлениями Flask:

@app.route("/mobile/contacts")
def mobile_contacts():
  # Render an HXML response

@app.route("/web/contacts")
def web_contacts():
  # Render an HTML response

Представление mobile_contacts()будет отображать шаблон HXML со списком контактов. Прикосновение к элементу контакта откроет запрошенный экран /mobile/contacts/1, обрабатываемый представлением mobile_contacts_view. После первоначального разветвления все последующие запросы от нашего мобильного приложения передаются по путям с префиксом /mobile/и обрабатываются представлениями Flask, специфичными для мобильных устройств. Аналогичным образом, все последующие запросы из веб-приложения передаются по путям с префиксом /web/и обрабатываются веб-представлениями Flask. (Обратите внимание, что на практике нам бы хотелось разделить веб-представление и представление для мобильных устройств на отдельные части нашей кодовой базы: web_app.pyи mobile_app.py. Мы также можем отказаться от префикса веб-путей с префиксом /web/, если хотим, чтобы в адресной строке браузера отображались более элегантные URL-адреса. )

Вы можете подумать, что вилка Redirect приводит к большому дублированию кода. Ведь нам нужно прописать двойное количество просмотров: один набор для веб-приложения и один набор для мобильного приложения. Это правда, поэтому Redirect Fork предпочтителен только в том случае, если двум платформам требуется несвязанный набор логики представления. Если приложения на обеих платформах одинаковы, переключение шаблонов сэкономит много времени и обеспечит единообразие приложений. Даже если нам понадобится использовать Redirect Fork, основная часть логики в наших моделях может использоваться обоими наборами представлений.

На практике вы можете начать использовать переключение шаблонов, но затем осознаете, что вам нужно реализовать форк для функций, специфичных для платформы. Фактически, мы уже делаем это в приложении «Контакты». При переносе приложения с веб-версии на мобильное устройство мы не задействовали некоторые функции, такие как функция архивирования. Пользовательский интерфейс динамического архива — это мощная функция, которая не имеет смысла на мобильном устройстве. Поскольку наши шаблоны HXML не предоставляют никаких точек входа в функцию архива, мы можем рассматривать ее как «только для Интернета» и не беспокоиться о ее поддержке в Hyperview.

Contact.app в Hyperview

В этой главе мы рассмотрели очень многое. Переведите дух и подведите итоги того, как далеко мы продвинулись: мы перенесли основные функции веб-приложения Contact.app на мобильные устройства. И мы сделали это, повторно используя большую часть нашей серверной части Flask и придерживаясь шаблонов Jinja. Мы снова увидели полезность событий для связи различных аспектов приложения.

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

Примечания к Hypermedia: конечные точки API

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

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

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

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

---