Мобильная версия

Во фреймворке Webasyst есть набор инструментов для создания версии приложений для мобильных устройств с сенсорными экранами: смартфонов и планшетов. В текущую версию фреймворка включён минимальный набор этих инструментов, который пока не позволяет создавать полноценные приложения для работы в операционных системах мобильных устройств. Реализована только возможность создания веб-интерфейсов, ориентированных на такие устройства.

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

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

В рамках приложения тип клиента (мобильный/стандартный) определяется с помощью вызова метода системного класса waRequest::isMobile()

//определяет тип устройства, с которого поступил HTTP-запрос
//возвращает идентификатор мобильной операционной системы, если устройство является мобильным смартфоном,
//в противном случае возвращает false

$is_mobile = waRequest::isMobile();

Способы организации мобильной версии приложения

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

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

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

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

Единственной точкой пересечения двух версий приложений остается лицевая страница приложения, которая также поддается разделению — для мобильной версии создается свой лицевой интерфейс, доступный по отдельному URL, а в логику стандартной (настольной) версии добавляется условие перенаправления мобильных клиентов на URL мобильной версии приложения:

if (waRequest::isMobile()) {
    $this->redirect('mobile/');
    return;
}

Вариант 2. Доработка логики определения соответствия шаблона и экшена

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

Архитектура фреймворка позволяет переопределить логику соответствия файла шаблона экшену и включить в нее условие проверки значения waRequest::isMobile(). Для этого в классе экшена — наследнике класса waViewAction или waViewActions — подробнее см. «Экшены и контроллеры» — нужно переопределить метод getTemplate(), реализующий логику, согласно которой система определяет имя файла шаблона для рендеринга при выполнении экшена. Ниже показан пример из приложения «Стикеры», иллюстрирующий такой подход:

<?php

class stickiesBackendAction extends waViewAction
{
    ...

    public function getTemplate()
    {
        $template = parent::getTemplate();

        if (waRequest::isMobile()) {
            $template = str_replace('templates/actions/', 'templates/actions-mobile/', $template);
        }
        
        return $template;
    }
}