Диссертация. "Технология создания кроссплатформенных приложений с динамическим формированием структуры и контента"
 Скачать 1.73 Mb.
|
|
Action. Описание реакции элементов интерфейса на взаимодействие пользователя. Например, нажатие кнопки, либо успешный ввод данных. Является составной частью связки view с моделью, направленной на !30 генерацию событий и реакцию на них. В настоящем проекте предусмотрены три типа реакций на событие: 1. открытие внутренней URL - открывает заданный URL во внутреннем (не покидая приложения) веб-браузере; 2. открытие внешней URL - открывает заданный URL в стандартном браузере мобильной операционной системы; 3. переход на другой экран - производит переход на заданный Page с указанием payload - прикрепленных данных, которые будут расширять контекст открываемой страницы; с точки зрения структуры данных, payload - это набор пар ключ-значение, где значение может являться ссылкой на какое-либо поле текущего контекста данных. Procedure. Составная часть связки ViewModel с Model. Является одним из источников контекста данных (Data Context), используемого при создании связок у объектов Page. В настоящем проекте Procedure (процедура) - создаваемые разработчиком динамические скрипты, которые при интерпретации с указанными аргументами генерируют объекты для их последующего представления. Созданные процедуры могут быть использованы в рамках приложения при определении контекста данных. При описании новой процедуры разработчику предлагается указать набор параметров (имя, тип, значение по умолчанию), которые также могут быть опциональными, и разместить написанный на языке Python исполнимый код, который будет интерпретирован при обращении клиентским мобильным приложением. Описанные параметры могут быть получены из мобильной операционной системы пользователя (в настоящее время доступно местоположение устройства, как один из вариантов параметра), либо будут заданы на основе контекста страницы, которая использует данную процедуру в качестве поставщика данных, или принимать произвольные значения. Загруженный программный код должен иметь основную функцию с именем !31 func и набором параметров, заданным при описании процедуры. Возвращаемое значение должно быть списком объектов ( list из dict), чьи атрибуты могут быть использованы в указателях связках (data-binding) в частях шаблона отображения. При написании исполняемого скрипта разработчики могут пользоваться разработанным в рамках настоящей работы API, описание которого приводится в разделе 3.2. Данные, поставляемые процедурами принимаются как динамические и не могут быть доступны без активного интернет-соединения на клиентском мобильном приложении. EntityDescription. Аналогичная по назначению Procedure составляющая модели. Основное отличие состоит в том, что контент статический и создается модератором/администратором приложения в рамках серверного веб-приложения, а затем синхронизируется с клиентскими приложениями с помощью локального хранения и кеширования на удаленной стороне. Особенностью этой модели является runtime-генерация классов (согласно созданному описанию), а также создание их экземпляров, которые хранятся в локальном хранилище посредством стандартных для конкретной платформы методов хранения объектов (в основном - ORM решения). Подробное описание runtime-генерации классов, а также особенностей описания модели и создания объектов на ее основе, приведено в разделе 3.6. Binding. Основная сущность-связка, которая обеспечивает соединение свойств View и атрибутов модели, полученной через EntityDescription или Procedure, а также используется для установки связей между объектами Page и шаблонами отображения и между объектами Procedure и их аргументами (при их наличии). Текущая архитектура абстракции предусматривает полное переиспользование компонентов связки. В настоящем проекте используются связи следующих типов: 1. TypeValue - связь между значением атрибута элемента модели (data context) и параметром свойства, доступным для связывания у !32 элемента отображения (view). Параметрами данного типа связи являются: • view - объект шаблона отображения, на свойство которого будет установлена связь; • property - свойство элемента отображения, к которому проводится связь (например, text у TextView); • value - значение, которое будет принимать указанное свойство; при установке значения может быть использован любой элемент текущего контекста данных (payload для объекта Page или атрибут модели данных); полное описание вариантов установки значений для Binding находится в разделе 3.1.1. 2. TypeTemplate - связь между значением атрибута объекта Page, доступным для связывания с шаблоном, и объектом шаблона отображения (например, item у объекта Page с типом List). Параметрами данного типа связи являются: • property - имя атрибута объекта Page, для которого осуществляется связь; • view - объект шаблона отображения, созданный с помощью конструктора описания в рамках разработанного веб- приложения. 3. TypeProcedure - связь между объектом Procedure, как элементом контекста данных, и атрибутом объекта Page, доступным для указания контекста данных (например, свойство items объекта Page с типом List). Параметрами данного типа связи являются: • procedure - процедура, используемая для генерации объектов контекста данных; !33 • property - имя атрибута объекта Page, для которого осуществляется связь. 4. TypeArgument - используется в комбинации с TypeProcedure типом связи. Содержит информацию о значениях аргументов процедуры, передаваемых при ее вызове в контексте отдельного объекта Page. Параметрами данного типа связи являются: • procedure - процедура, для которой предназначен данный аргумент; • argument - аргумент, значение которого будет указано в связи; • value - значение аргумента, указанное произвольно или с использованием элементов текущего контекста (заданного payload объекта Page); полное описание вариантов установки значений приводится в разделе 3.1.1. 5. TypeAction - связь между элементом шаблона отображения, и вариантом реакции на событие, которое он генерирует при пользовательском взаимодействии (например, нажатие на кнопку - элемент отображения Button). Параметрами данного типа связи являются: • action - объект Action, содержащий в себе информацию о варианте реакции на событие и значение, которое будет использовано для этого перехода (либо payload для открытия страницы); полное описание вариантов установки значений приводится в разделе 3.1.1.; • view - элемент отображения, который генерирует событие в результате пользовательского взаимодействия. 6. TypeEntity - связь между описанием модели данных EntityDescription !34 и атрибутом объекта Page, для которого доступна установка связи контекста данных (например, items у объекта Page с типом List). При установке связи в последствии значением атрибута объекта Page будет являться список объектов, соответствующих описанию модели EntityDescription и созданных в рамках модуля разработанного веб- приложения. Параметрами данного типа связи являются: • entityDescription - описание модели данных, в соответствии с которым будут передаваться объекты; • query - опциональный запрос на языке SQL (фильтр - WHERE), который будет выполнен при получении данных из локального хранилища; полное описание вариантов установки значения запроса приводится в разделе 3.1.1. Пример схемы связей объекта Page с типом List изображен на рис. 12. Все изображенные связи (кроме связи App(1)—(*)Page) являются объектами типа Binding с разными типами и набором параметров, описанными выше. Сериализованная схема будет являться входными данными для клиентского мобильного приложения, которое будет строить свою структуру и !35 Рисунок 12. Схема связей для объекта Page типа List содержание контента в соответствии с описанием схемы. 3.2.1. Варианты установки значений для объектов связей В рамках разработанной технологической платформы создания мобильных приложений основополагающим объектом связей является Binding - сущность, отвечающая за присвоение значений между частями контекста данных и элементами отображения с опциональной фильтрацией получаемых объектов (при указании условий для запроса к локальной базе данных приложения или при указании параметров исполняемой процедуры), процедурами и значениями их аргументов, а также дополнительных данных (payload) при открытии страницы (page) в результате пользовательского взаимодействия. Контекст данных можно разделить на два типа: 1. Контекст данных самой страницы (page) отображения: пары ключ- значения, переданные при выполнении инструкций объекта Action при реакции на событие. 2. Контекст данных, определенный после выполнения процедуры или при получении значений объектов модели в соответствии с каким- либо описанием EntityDescription. При использовании значений из первого контекста ключевым символом является символ “ #”, второго - символ “$”. В общем случае устанавливаемое значение принимает следующий вид: Some text [$some_property], [#payload_key], format [$date|time] где интерес представляют значения, заключенные в [], которые учитываются при обработке значения. При преобразовании значений поиск в строке осуществляется регулярными выражениями вида: \[\$[A-Za-z]+(?:\| [A-Za-z]+)?\] и \[#[A-Za-z]+(?:\|[A-Za-z]+)?\], з а т е м определяется источник необходимого значения (объект модели или payload !36 текущей страницы) и происходит подстановка с возможным преобразованием, если оно указано после символа “ |”, который используется как разделитель между именем атрибута и функцией форматирования значения. Доступные функции форматирования значений указаны в таблице 4. Таким образом, преобразованные с заданными функциями значения замещаются в исходной строке, формируя результирующее значение, которое становится значением свойства, указанного в целевом объекте отдельного Binding: атрибуты элементов отображения (например, text у TextView или title у Button), значения пар в составе payload, передаваемого в объект Page при реакции на Action, части значения URL (или полное значение), указанные при реакции на Action, запрос к локальной базе данных при формировании контекста из модели EntityDescription, аргументы, необходимые для вызова процедуры с целью формирования контекста данных. Таблица 4. Доступные функции форматирования значений для преобразования в рамках установленных связей Название функции Тип входного значения Описание функции date datetime Вывод только даты time datetime Вывод только времени fXX double Округление нецелого значения до XX знаков после запятой ceil double Округление до целого в верхнюю сторону floor double Округление до целого в меньшую сторону round double Округление по правилам округления len string Длина строки !37 3.3. Описание работы исполняемых процедур, как инструмента динамической генерации контекста данных Один из источников формирования контекста данных в рамках данной технологической платформы являются объекты типа Procedure (процедура), которые описываются набором параметров и программным кодом на языке Python. Заданные процедуры могут быть использованы в связях при установке data-context элементам Page, например, при задании items для объекта Page с типом List. Параметры (аргументы), используемые при описании процедур характеризуются следующими свойствами: 1. Имя параметра - при передаче параметров в функцию, написанную на языке программирования Python используется механизм передачи keyword-args ( **kwargs), при котором аргументы передаются в виде пар ключ-значение. Такое решение обеспечивает необходимый для создания универсальных процедур уровень абстракции. 2. Тип - может быть custom, то есть передаваемое извне произвольное значение (в соответствии с преобразованием), либо device-specific, то есть зависит от устройства и настроек пользователя. На данный момент доступен из второго типа доступно только “местоположение пользователя”. 3. Значение по умолчанию - нужно в случае, если значение извне не было передано. 4. Флаг опциональности - значение параметра может быть опциональным, в таком случае будет использоваться значение по умолчанию. Программный код в конечном счете должен объявлять глобальную !38 функцию func с параметрами, указанными при создании описания процедуры (порядок в данном случае не важен), и возвращаемым значением в виде массива объектов модели, чьи свойства могут быть использованы как составные части объектов Binding. При разработке исполнимого скрипта допускается использование всех стандартных функций и модулей Python 2.7 плюс разработанного в рамках настоящей технологической платформы программного API-обёртки для доступа к внешним ресурсам, кэшированию и хранению объектов на серверной базе данных. Описание API приводится в Приложении 2. Примеры программных скриптов на языке Python с использованием описанного API приводится в Приложениях 3, 4. Указанные примеры демонстрируют полный цикл получения и преобразования контента, готового к отображению (с использованием запросов удаленных ресурсов, а также соединения с удаленной MySQL базой данных). Также в рамках настоящей работы были разработаны процедуры, доступные для общего использования, получающие данные из различных социальных сетей: 1. get_twitter_feed - получение ленты сообщений пользователя из социальной сети Twitter (http://twitter.com). Имя пользователя передается в качестве аргумента. 2. get_instagram_feed - получение ленты фотографий пользователя из социальной сети Instagram (http://intagram.com/). Имя пользователя передается в качестве аргумента. 3. get_vk_feed - получение новостей со стены группы из социальной сети ВКонтакте (http://vk.com/). Идентификатор группы передается в качестве аргумента. !39 3.4. Суммирующее описание предлагаемого архитектурного решения Предлагаемое архитектурное решение было полностью реализовано в виде веб-приложения для настройки структуры и содержания контента. Уникальность описываемой архитектуры заключается в возможности переиспользования ее компонентов, а также, при наличии клиентского мобильного приложения, в полной мере реализующего всю логику серверной части, решение позволяет модифицировать структуру и содержание контента без необходимости повторной сборки и компиляции программы. При использовании технологии практически полностью исключается написание программного кода при разработке мобильного приложения: настройка структуры и непосредственная генерация контента осуществляется с помощью разработанного веб-приложения, использование которого не требует специальной квалификации пользователя. Применение навыков программирования потребуется только для написания собственных скриптов- генераторов динамического контента (Procedure), однако их создание не обязательно должно быть связано непосредственно с разработкой приложения на основе данной технологии: в рамках технологической платформы разработчики могу размещать свои исполняемые скрипты доступные создателям приложений. В рамках данной работы было реализовано несколько общих скриптов, направленных на получение данных пользователей из социальных сетей, и доступных для использования в любом разрабатываемом приложении. Таким образом, для создания мобильного приложения с использованием разработанной технологии, необходимо, взаимодействуя с веб-приложением, выполнить следующие шаги: 1. описать предметную область, создав соответствующие описания модели EntityDescription - необходимо определить набор классов- сущностей, свойства объектов которых будут использованы при !40 отображении данных; 2. при необходимости добавить свои скрипты генерации динамического контента (либо выбрать из каталога имеющихся процедур); 3. создать шаблоны отображения view, настроив свойства каждого элемента; 4. создать набор объектов Page (экранов приложения) с использованием доступных типов, указав контекст данных (объекты модели в соответствии с описанием какой-либо EntityDescription, получаемые с использованием заданного запроса фильтрации, или процедура генерации динамического контента с заданными параметрами) и шаблон их отображения; 5. расставить связи (data-bindings) между свойствами объектов модели и атрибутами элементов отображения; 6. определить возможности перехода между экранами, используя связь Action у элемента Button, передавая необходимые части контекста данных следующему объекту Page; 7. создать объекты модели в соответствии с созданным описанием EntityDescription; 8. после этого полученные структура и содержание контента могут быть синхронизированы демонстрационным приложением, которое зафиксирует все данные локально в момент исполнения и сможет продолжить свою работу без активного интернет-соединения. В рамках настоящей работы было также разработано демонстрационное мобильное клиентское приложение, которое способно синхронизировать произвольные структуру и содержание контента, конфигурируя на их основе локальное хранилище данных, что в итоге позволяет использовать полностью !41 нативное приложение без необходимости в соединении с сетью Интернет (кроме вызова процедур для динамической генерации контента). Описание разработанного демонстрационного приложения приводится в разделе 3.7. !42 3.5. Описание специфики runtime-генерации классов Для описанной в данной работе архитектуры, в силу своей динамичности, невозможно заранее определить структуру и модель данных. Архитектура данного проекта предусматривает создание описания модели данных (под моделью понимается набор классов, как название плюс описание всех полей: название и тип), хранение ее описания и объектов, созданных на основе этой модели, в базе данных, а так же передача модели на клиентское приложение, которое должно сконфигурировать на ее основе локальное хранилище и представление объектов в форме каких-либо структур, доступных на платформе конкретного мобильного приложения. Таким образом, речь идет о формировании модели данных в момент выполнения (at runtime), что накладывает определенные ограничения, так как не все языки программирования позволяют runtime генерацию и описание классов. В рамках данной работы рассматривались возможности формирования модели данных в момент исполнения. Основные исследовательские данные были получены на основе платформы iOS и возможностей языка Objective-C, а также дополнительно был проведен анализ возможностей разработки подобных решений на таких мобильных платформах, как Windows Phone (язык программирования C#) и Android (язык программирования Java). Выбор структуры сильно зависит от скорости работы, ведь именно скорость работы является основным преимуществом native-приложений перед html5- и hybrid-приложениями. В рамках настоящей работы был проведен сравнительный анализ потребления процессорного времени (CPU time) при обращении к полям объектов разными способами для разных структур данных. Замер производился посредством стандартной функции языка C - clock_t clock(void), которая возвращает количество потребленного процессорного времени приложением на момент вызова метода [4]. Было выбрано несколько вариантов возможного представления !43 объектов модели, а также способов обращения к их полям. Далее приводятся рассмотренные варианты и результаты проведенного сравнительно анализа. 1. Самым "наивным" подходом является представление объектов в виде такой структуры данных, как словарь (dictionary, map), где поля представлялись бы в виде пар ключ-значение. В рамках Objective-C за эту структуру данных отвечает класс NSDictionary, объекты которого могут являться представлением частей модели данных, описанной в приложении. 2. Обращение к полю объекта класса посредством стандартного метода всех объектов Objective-C -(id)valueForKey: (NSString *)key, который производит поиск значения поля по его строковому названию. 3. Обращение к значению поля объекта с помощью средств, доступных через библиотеку C. В таблице 5приведены результаты анализа, который заключался в замере затраченного процессорного времени на получение значения поля объекта тем или иным способом. Результаты рассчитывались 10 раз для 10000000 обращений (для получения достоверных средних значений) для получения строкового (NSString) значения поля объекта полноценного сформированного runtime Objective-C класса, либо через структуру NSDictionary. Диаграмма (рис. 13) показывает затраченное процессорное время на каждом из испытаний для каждого способа. !44 Таблица 5 Результаты анализа затраченного процессорного времени на получение значения поля объекта ! Рисунок 13. Затраченное на получение значения поля объекта процессорное время Согласно полученным результатам сравнительного анализа, был выбран способ получения значений полей объекта напрямую через runtime- reflection посредством Objective-C метода аксессора (второй по производительности подход). Метод аксессор в данном случае был использован для удобства. Сигнатура метода имеет следующий вид: — |