Диссертация. "Технология создания кроссплатформенных приложений с динамическим формированием структуры и контента"
 Скачать 1.73 Mb.
|
|
Bizness Apps Kitapps Attendify My-apps.com Мобильные платформы ■ iPhone ■ Android Phone ■ HTML5 ■ iPhone ■ iPhone ■ Android ■ HTML5 ■ WPhone Тип создаваемого приложения wrapped web native native Настройка внешнего вида цветовая схема, готовые шаблоны экранов цветовая схема, готовые шаблоны экранов цветовая схема, два варианта расположения элементов, готовые шаблоны экранов Цена $60 /месяц $400-600 /приложение /год $33 /месяц !17 3. используемые языки программирования. Ниже приведен краткий обзор каждого из приложений. Таблица 2 показывает результаты проведенного анализа в соответствии с выбранными критериями. Adobe PhoneGap Web-сайт: https://build.phonegap.com/ Технологическая платформа для создания мобильных приложений с использованием HTML, JavaScript и CSS. На выходе получается "обёрнутое" приложение с возможностью полноправно взаимодействовать с системными функциями (обычные браузерные обёртки не имеют доступа к системе в целом). Пользователю предлагается написать мобильное веб-приложение самостоятельно, после чего платформа поможет подготовить сборки для популярных мобильных платформ. Технологическая составляющая основана на открытой платформе Apache Cordova. IBM Worklight Web-сайт: http://www-03.ibm.com/software/products/en/worklight Полноценный инструмент для разработки кросс-платформенных приложений. Позволяет создавать HTML5 и гибридные приложения для четырех популярных платформ. Основной упор делается на безопасность и стабильность работы. Основными потребителями продукта являются бизнесы Enterprise уровня, о чем говорит очень высокая цена использования. Предоставляется инструмент для разработки (IDE), а так же высокоуровневый API для кроссплатформенного доступа приложения к мобильной операционной системе. По факту использует Adobe PhoneGap, как технологическую платформу, и собственные плагины для IDE Eclipse. !18 Apache Cordova Веб-сайт: https://cordova.apache.org/ Технологическая платформа, позволяющая создавать мобильные приложения, используя HTML, JavaScript и CSS. Предоставляет API для работы с системными функциями устройства, что вкупе с UI библиотеками в итоге позволяет создать почти полностью navite-приложение. Является платформой с открытым исходным кодом. Основное отличие от Adobe PhoneGap состоит в том, что Apache Cordova не предоставляет упрощенной возможности публикации приложений. Всю разработку нужно вести самостоятельно. Appcelerator Web-сайт: http://www.appcelerator.com/ Технологическая платформа, позволяющая создавать полноценные приложения. Предоставляет свои инструменты разработки, SDK и полноценный API для доступа к системе. Самое комплексное решение с точки зрения мульти-платформенной разработки из существующих на рынке. Требует усилий, связанных с разработкой приложения и изучением внутреннего языка разметки и стилей (подмножество XML и аналог CSS). !19 Таблица 2 Сравнение существующих платформ разработки приложений IBM Worklight Adobe PhoneGap Apache Cordova Appcelerator Мобильные платформы ■ iPhone ■ Android ■ WindowsPhone ■ Blackberry OS ■ iPhone ■ Android ■ webOS ■ WindowsPhone ■ Bada ■ Blackberry OS ■ Amazon Fire OS ■ Android ■ Bada ■ Blackberry OS ■ Firefox OS ■ iOS, Mac OS X ■ QT ■ Tizen ■ Ubuntu ■ Web OS ■ Windows ■ Windows Phone ■ iPhone ■ Android ■ HTML5 ■ WPhone ■ Blackberry OS Тип создаваемого приложения wrapped web + native wrapped web + native native + wrapped web native + wrapped web !20 Все представленные решения предусматривают самостоятельное проектирование и разработку приложения. Суть всех продуктов заключается в экспорте написанной программы в упакованные под разные платформы мобильные приложения. Особенность же настоящего проекта заключается в отсутствии части написания программного кода: все взаимодействие между элементами интерфейса, структура и содержание контента конфигурируются на серверной стороне без необходимости непосредственной разработки. Программная составляющая предусмотрена только в рамках интерфейса программной платформы, основываясь на котором сторонние разработчики смогут создавать свои модули для интеграции с системой контента. В течение настоящей работы одной из задач является разработка набора модулей для демонстрационного приложения, которые также будут использоваться как пример использования API технологической платформы. Используемые языки программирован ия HTML, JavaScript, CSS HTML, JavaScript, CSS HTML, JavaScript, CSS JavaScript, CSS- like + XML definitions of layouts Цена $39600 / год 1 приложение бесплатно $9.99 / мес Беплатно Платно, цены по запросу индивидуально для каждой компании !21 3. ОПИСАНИЕ АРХИТЕКТУРЫ 3.1. Выбор основополагающего паттерна проектирования Для реализации данной технологической платформы необходимо было определиться с ключевым архитектурным решением - выбор паттерна проектирования, который бы предусматривал высокий уровень абстракции, так как это диктуется главной особенностью настоящего проекта - кросс- платформенным решением для управления структурой и контентом мобильных клиентских приложений без необходимости повторной сборки. Основные паттерны проектирования мобильных приложений обычно диктуются отдельными технологическими платформами. Компании- производители мобильных операционных систем создают собственные API для сторонних разработчиков согласно определенным паттернам, ожидая, что разрабатываемые приложения будут создаваться с учетом особенностей целевой платформы. Одним из самых популярных на данный момент паттернов является Model-View-Controller [3] (MVC) (рис. 8). В рамках этого паттерна, все объекты в приложении принадлежат одной из трех ролей: модель (model), отображение (view), контроллер (controller). MVC определяет не только роли каждого из объектов, но также описывает способы их взаимодействия между !22 Рисунок 8. Model-View-Controller собой. Объекты каждого из типов строго разделены между собой и могут общаться только по описанным интерфейсным каналам. Основные роли объектов в рамках паттерна Model-View-Controller: 1. Model - объекты модели инкапсулируют в себе представление данных какой-либо предметной области, а также определяют бизнес-логику и операции взаимодействия с данными (загрузку с удаленных ресурсов, из локальной базы, вычисления). Если модель спроектирована верно, то есть все данные и базовая логика заложены внутри объектов данной роли, главным преимуществом будет являться возможность простого переиспользования компонентов. Объекты модели могут также иметь связи между собой (например, один-к-одному, одним-ко-многим). В идеальном сценарии объекты модели должны быть полностью абстрагированы от объектов представления (view). При необходимости обновления представления, модель сообщает контроллеру о том, какие именно данные были обновлены, а уже контроллер определяет, какие именно представления и каким именно образом необходимо актуализировать. 2. View - объект представления, то есть того, что пользователь может непосредственно видеть на экране устройства. Объекты представления знают, каким образом они должны быть отрисованы на экране, а также определяют действия и события, на которые будут они могут реагировать при взаимодействии пользователя с приложением. Основное назначение view - отображение данных модели на экране и предоставление пользователю возможности для их создания и редактирования. При правильном проектировании, объекты представления являются переиспользуемыми и могут быть интегрированы в другие приложения. При обновлении данных модели контроллер соответственно обновляет представление, которое самостоятельно определяет, каким образом данные будут выглядеть на экране. При возникновении заданного события !23 взаимодействия с пользователем объект view посылает уведомление контроллеру, который в свою очередь может, например, обновить модель. 3. Controller - объект контроллера - главное связующее звено между моделью и ее представлением. Обычно, контроллер отвечает за актуализацию представления в соответствии с последними изменениями в модели, а также обрабатывает все события, генерируемые объектами view, преобразуя модель: внося изменения или создавая новые объекты. Таким образом, объекты представления являются полностью абстрагированы от конкретной предметной области и модели данных, которая, в свою очередь, независима от представления. Основным преимуществом данного паттерна является независимость представления от модели, что в итоге дает высокую степень модульности и переиспользуемости компонентов. При проектировании архитектуры настоящей технологической платформы необходимо было, наоборот, связать модель и представление, минимизировав влияние контроллера. Такое требование объясняется универсальностью решения, которая невозможна при использовании контроллера в его классической роли, так как вся логика должна быть максимально описана на серверной стороне - что бы позволило сделать клиентские приложения независимыми и легко изменяемыми. Таким образом, использование MVC в чистом виде не представляется возможным в силу особенностей реализуемой системы. Вторым рассматриваемым паттерном является Model-View-ViewModel (MVVM)[19] (иногда также называют Model-View-Binder). В литературе сюда относят и Presentation (Application) Model [16], который является популярным паттерном проектирования среди разработки мобильных приложений для популярных платформ (например, Windows Phone). Основной особенностью паттерна MVVM является совмещение в себе функциональных преимуществ ставшего уже классическим для мобильных !24 (и веб-) приложений подхода MVC (Model-View-Controller) с преимуществами связывания данных (data-binding), то есть завязки атрибутов View на отдельные свойства модели через создания так называемых Binding, которые часто также предусматривают внутренние (в основном примитивные) конвертеры (например, для преобразования объекта типа date в строку даты, или для форматирования строк и чисел). Такой подход позволяет минимизировать код, связанный с частью контроллера из MVC. Паттерн MVVM широко применяется в программных продуктах компании Microsoft (WPF, Silverlight), однако, стоит заметить, что сам по себе подход независим от платформы. В рамках настоящей работы сделана попытка воспроизведения данного паттерна проектирования в совмещении с описанным ранее паттерном MVC с использованием собственных инструментов связывания данных. В упрощенном виде паттерн представлен на рис. 9. Основные компоненты: 1. View - непосредственное графическое представление в виде UI элементов на экране устройства. По своей роли совпадает с ролью из MVC. 2. Model - модель представления какой-либо предметной области, бизнес- логика, данные. По своей роли совпадает с ролью из MVC. 3. ViewModel - абстрактное представление View, открывающее атрибуты для связки, а также описывающее возможные события, которые будут генерироваться при взаимодействии пользователя с приложением. В какой-то степени отчасти повторяет функциональное назначение роли контроллера из паттерна Model-View-Controller. 4. DataBinding (Binder) - указатель-связка между данными и непосредственным их представлением на графическом интерфейсе. Связки возможны благодаря описанным в ViewModel свойствам, к !25 которым Model может иметь доступ напрямую, минуя посредников. Рисунок 9. Паттерн Model-View-ViewModel (Binder) Преимуществом данного подхода является наличие тесной связи между моделью и представлением посредством data-binding связки, что позволяет отображению динамически меняться при изменениях модели, минуя посредников. ViewModel здесь выступает, скорее, как контекст, который может обрабатывать события, а также указывает, какие именно данные должны быть связаны с отображением. Недостатком паттерна MVVM в рамках настоящей работы является необходимость для представления самостоятельно отслеживать изменения модели. Это ограничение удалось обойти при комбинации MVC и MVVM, таким образом применив при разработке технологической платформы основополагающего паттерна в виде модифицированного паттерна MVVM. Модификация заключается в присвоении ViewModel “обязанностей” роли контроллера из MVC, а именно - отслеживание изменений в модели и предоставление подходящей связки (data-binding) для представления. То есть комбинированный ViewModel и Controller выступает в роли менеджера указателей-связок, являясь посредником между моделью и представлением только по части преобразования значений в соответствии с указанным форматом, поиском ассоциированной связки, а также обработкой событий (например, нажатие кнопки) в соответствии с заданной конфигурацией реакции на них (рис. 10). !26 3.2. Реализация собственного паттерна проектирования В рамках настоящего проекта был реализован модифицированный паттерн MVVM как в серверном, так и в клиентском решениях. Основными сущностями (см. Приложение 1) являются View, Page, Action, Procedure, EntityDescription, Binding. View. Шаблон представления графического интерфейса пользователя в рамках клиентского приложения. Текущая реализация содержит следующие подклассы: TextView, ImageView, Button, PdfView, WebView. Архитектурное решение позволяет добавлять новые подклассы в модель, что в итоге автоматически масштабируется в веб-приложении - проектировщике интерфейса. Основные свойства класса описывают расположение на экране, размеры, цвет фона. Свойства каждого из подклассов описывают возможные параметры настройки отображения, а также предоставляют информацию об атрибутах, которые доступны для установления связей (data-binding) с моделью. Таблица 3 описывает доступные для настройки параметры отображения и атрибуты, для которых можно указывать связи. !27 Рисунок 10. Комбинированный вариант MVC и MVVM Таблица 3 Доступные для настройки параметры отображения и атрибуты, предназначенные для связывания Концептуально данный класс и его подклассы представляют собой часть View паттерна MVVM, так как являются лишь шаблоном отображения Класс Параметры отображения Атрибуты для связывания View - прямоугольная область Frame - расположение на экране, включает в себя: 1) origin - x, y 2) size - width, height Background color - цвет фона PdfView - компонент отображения PDF файлов Наследуются из View file - pdf-файл, который будет отображаться ImageView - компонент отображения изображений Наследуются из View ContentMode - варианты отображения изображения: • scale - растягивание на всю площадь view • fit - растягивание с сохранением отношения сторон image_url - URL картинки для отображения image - статическое изображение (placeholder) TextView - компонент отображения текстовых данных Наследуются из View TextAlign - расположение (выравнивание) текста: • center - по центру • left - по левому краю • right - по правому краю TextStyle - стиль (начертание) текста: • regular - обычный • bold - полужирный • light - тонкий • italic - с наклоном TextSize - размер (кегль) шрифта TextColor - цвет текста text - текст для отображения Button - компонент “кнопка”, доступная для нажатия пользователем Наследуются из TextView title - текст для отображения на кнопке action - реакция на нажатие кнопки !28 и хранят информацию о свойствах, доступных для связки. Список доступных View расширяется по мере внесения доработок в настоящий проект. В данной реализации он лишь подтверждает возможность существования данной части архитектуры. Параметры отображения настраиваются при создании шаблонов отображения. Под “шаблоном” понимается созданное в рамках разработанного модуля веб-приложения для создания шаблонов (рис. 11) описание родительского view и, соответственно, его дочерних view с использованием вариантов параметров отображения. Созданный шаблон может быть использован при настройки отображения отдельных страниц приложения как шаблон для всей страницы, так и как шаблон для отображения строки при использовании списков (как отдельного типа объекта Page). Page. Представляет собой отображение отдельного экрана (страницы) в рамках клиентского мобильного приложения. Является представлением части ViewModel в рамках паттерна MVVM. Архитектура разработанной технологической платформы предусматривает добавление новых типов !29 Рисунок 11. Модуль веб-приложения для создания описаний шаблонов view экранов без значительных затрат. На данный момент момент реализованы следующие типы экранов: • Custom - произвольный экран с отображением шаблона. Предусматривает связку на свойство view, где необходимо указать созданный ранее шаблон отображения, а также связку на свойство item - контекст данных для отображения. • List - экран для отображения списка элементов. Предусматривает связку на свойство item - шаблон отображения строки элемента и связку на свойство items - контекст (массив) данных для отображения в списке. • Pdf - экран для отображения файла формата PDF. Предусматривается связку на свойство file, необходимый для отображения на экране. Итого, в рамках объекта Page предусматривается два типа указателей связок: контекст (data-context) и отображение (view). Первый тип связи определяется одним из двух вариантов поставщиков данных: выполнение заданной процедуры (объекта Procedure) или получение заданных данных согласно описанию объекта EntityDescription. Специфика работы каждого из вариантов описана ниже. Второй тип - view - ссылка на шаблон отображения, созданного с помощью модуля описания в рамках созданного веб- приложения. При открытии страницы в результате сгенерированного события объектом Action в контексте данных также доступна информация из payload, переданного вместе с информацией о событии, указанной в объекте Action. |