79989

Портирование пользовательского интерфейса на мобильные платформы на примере приложения для электронной валютной торговли

Дипломная

Информатика, кибернетика и программирование

Проведено портирование элементов пользовательского интерфейса приложения для платформы Adobe Flash в приложения для платформ iOS и Android. Проведен анализ предоставляемых создателями платформ SDK, выявлены соответствия компонентов пользовательского интерфейса. Проведен анализ платформ и сформулированы перечень особенностей каждой платформы и рекомендации для начинающих разработчиков.

Русский

2015-02-15

2.02 MB

9 чел.

МИНОБРНАУКИ РОССИИ

Томский государственный университет

Факультет информатики

Кафедра программной инженерии

УДК 004.514

ДОПУСТИТЬ К ЗАЩИТЕ В ГАК

Зав. кафедрой, профессор, д.ф.-м.н.

________________ О.А.Змеев

«___» ___________ 2013 г.

Симахина Лидия Сергеевна

Портирование пользовательского интерфейса на мобильные платформы на примере приложения для электронной валютной торговли

МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ

на соискание степени магистра

по направлению подготовки

230700 «Прикладная информатика»

Руководитель ВКР, заведующий кафедрой программной инженерии

профессор, д.ф.-м.н.

____________ О.А.Змеев

                                                                                                                                       подпись

«_____»___________ 2013 г.

                                                                                               

                                                

Автор работы

                                                                                             студент группы № 1418

                                                                             _____________ Л.С.Симахина

                                                                                                      подпись

 

Электронная версия магистерской диссертации   Администратор электронной

помещена в электронную библиотеку.        библиотеки факультета

                                                                             _____________ Е.Н.Якунина

                                                                                                      подпись

Томск 2013

Реферат

Выпускная квалификационная работа магистра 50 с., 20 рис., 3 табл., 16 источников.

портирование, МОБИЛЬНОЕ ПРИЛОЖЕНИЕ, Android, ios, adobe flash, пользовательский интерфейс, НАТИВНАЯ РАЗработка, электронная валютная торговля.

Объект исследования - процесс портирования пользовательского интерфейса на мобильные платформы Android и iOS.

Цель работы: провести анализ SDK, предоставляемых разработчиками платформ Android и iOS, провести процесс портирования элементов пользовательского интерфейса из RIA-приложения на платформе Adobe Flash  в мобильные приложения на платформах Android и iOS.

Метод проведения работы: теоретический и экспериментальный.

Проведено портирование элементов пользовательского интерфейса приложения для платформы Adobe Flash в приложения для платформ iOS и Android. Проведен анализ предоставляемых создателями платформ SDK, выявлены соответствия компонентов пользовательского интерфейса. Проведен анализ платформ и сформулированы перечень особенностей каждой платформы и рекомендации для начинающих разработчиков.

Результаты работы внедрены в ООО «Е-Трейд Софт».

Содержание

Перечень терминов и условных обозначений

API – (англ. application programming interface) набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах.

SDK – (англ. software development kit) — комплект средств разработки, который позволяет создавать приложения для определённой операционной системы.

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

Кастомизация – дополнительная настройка внешнего вида компонента (изменение цвета, размера, шрифтов и др.).

Котировка – текущая цена валютной пары.

Нативная разработка – разработка приложений с применением средств, предоставляемых производителем целевой платформы.

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

Ордер – распоряжение на продажу/покупку определенной валютной пары по определенной цене.

Платформа – программный комплекс, служащий основой для запуска приложений.

Трейдер – торговец на валютном рынке.


Введение

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

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

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

Создание мобильной версии клиентского flash-приложения очень актуально не только как расширение перечня поддерживаемых платформ, а значит и целевой аудитории. В связи с прекращением компанией Adobe поддержки технологии Flash для мобильных платформ в сети Интернет всё чаще появляются обсуждения и заметки  о бесперспективности данной технологии. Поэтому необходимо переносить существующие flash-приложения на другие платформы, хотя бы с целью сохранения существующей пользовательской аудитории. В случае с мобильными платформами, такая «миграция» способствует расширению рынка и повышению популярности приложения.

Анализ различных источников в сети Интернет показал, что проблема переноса приложения с платформы Adobe Flash на мобильные платформы очень актуальна, но совершенно не исследована. Единственное предлагаемое решение – использование технологии Adobe AIR. Такой подход практически не требует времени и средств, поэтому прекрасно подходит для небольших не требовательных к ресурсам приложений. Однако для тех приложений, для которых быстродействие выходит на первый план, данная технология не подходит.

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

Выделяют несколько методов создания приложений для мобильных платформ Android и iOS. Для разработки клиентского приложения для электронной валютной торговли выбран нативный метод. Детали и причины выбора данного метода описаны в первом разделе данной работы.

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

Анализ SDK, предоставляемых создателями мобильных платформ для разработки приложений, позволит выявить особенности составных компонентов SDK для разных платформ, определить перечень предоставляемых компонентов для разработки интерфейсов. Это позволит найти соответствия между элементами интерфейса и разработать методику портирования пользовательского интерфейса приложений для платформы Adobe Flash на мобильные устройства.

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

Целью данной выпускной квалификационной работы магистра является анализ SDK, предоставляемых разработчиками мобильных платформ Android и iOS и портирование элементов пользовательского интерфейса приложения для платформы Adobe Flash на данные мобильные платформы.

1 Разработка приложений для мобильных платформ

1.1 Клиент для электронной валютной торговли

Описание проблемы и формулировку цели и задач данной работы необходимо начать с описания предметной области. Согласно определению, данному в экономическом словаре [1]:

«Валютный рынок - сфера, где совершается купля-продажа иностранной валюты на основе спроса и предложения. Делится на биржевой и внебиржевой (межбанковский).»

В качестве целевого валютного рынка был выбран внебиржевой валютный рынок Форекс. Пользователи сети Интернет могут осуществлять валютные операции на данном рынке через брокеров и другие институты валютного рынка. Пользователь с помощью приложения для торговли, предоставляемого брокером (торгового представителя, совершающего операции по поручению клиента), управляет ордерами на продажу и покупку различных валют. Разница в цене валюты при открытии и закрытии ордера является прибылью или убытком пользователя.

Приложение для электронной валютной торговли должно удовлетворять следующим требованиям:

а) высокая производительность;

б)  расширяемость;

в)  малая потребность в ресурсах;

г)  высокая скорость передачи данных.

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

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

В рамках первого жизненного цикла автором данной работы было создано RIA (Rich Internet Application)-приложение для электронной валютной торговли. В качестве платформы для разработки использовалась Adobe Flash. Средой разработки послужил программный продукт от компании Adobe для создания кроссплатформенных интернет-приложений -  Adobe Flash Builder 4.5. Проблемы выбора данной платформы для разработки в данной работе не рассматриваются.

Flash-приложение имеет две версии: веб-приложение, исполняемое плагином Adobe Flash Player, встроенным в браузер и настольное приложение, запускаемое в рамках среды Adobe AIR, установленной на ПК.

Диаграмма вариантов использования для Flash-приложения представлена на рисунке 1.

Рисунок 1 - Диаграмма вариантов использования для приложения Flash-приложения.

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

Целевой аудиторией разрабатываемого приложения являются начинающие и опытные трейдеры. Исследований популярности мобильных платформ среди трейдеров найдено не было, однако, анализ Интернет-форумов, таких как MT5 Forum [2] показал, что наиболее популярными среди представителей целевой аудитории являются смартфоны и планшеты со встроенными операционными системами iOS и Android.

Различными компаниями ежегодно проводятся многочисленные исследования по вопросу распространения мобильных платформ на рынке, однако полученные ими данные различаются. Согласно исследованиям компании NetApplications [3], наиболее распространенными операционными системами для мобильных устройств (смартфонов и планшетов) по итогам 2012 года являются iOS (61%) и Android (22%). По данным исследований корпорации IDC [4], доля устройств с операционной системой Android составляет 75%, iOS – 14,9%. Общим в большинстве исследований является тот факт, что Android и iOS - наиболее распространенные. Другие операционные системы, такие как Symbian и Windows Phone 7 существенно отстают от своих более успешных конкурентов.

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

Авторы статьи [5], посвященной методам разработки мобильных приложений, выделяют следующие методы:

а) нативная разработка,

б) веб-разработка,

г) гибридная разработка.

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

Рассмотрим каждый метод подробнее.

1.2 Нативная разработка приложений

Нативной называют разработку приложений с использованием средств, предоставляемых производителем целевой платформы. Для Android нативными являются приложения, написанные на языке Java с использованием Android SDK, для iOS – приложения, написанные на Objective C.

Для каждой из целевых платформ выпущено множество книг и статей по разработке нативных приложений. В качестве примера для платформы Android можно назвать книгу «Программирование под Android» [6], для платформы iOS – «Профессиональное программирование приложений для iPhone и iPad» [7]. Кроме того, производители предоставляют исчерпывающую онлайн-документацию с описанием всех классов и пакетов соответствующих SDK.

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

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

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

Распространение готовых нативных приложений осуществляется с помощью специальных магазинов приложений. Для iOS таковым является App Store, для AndroidGoogle Play. Для публикации приложений необходимо наличие платной лицензии. Однако, помимо лицензии, магазин App Store так же проводит проверку приложений на наличие вредоносного кода, нарушений требований к интерфейсу, функциональности, нарушений чьих-либо авторских прав и т.п. Данный подход компании Apple можно назвать как недостатком, так и достоинством нативных приложений. Предшествующая появлению приложения в магазине проверка позволяет избавиться от опасного «мусора», однако накладывает дополнительные ограничения на дизайн приложения. Магазин Google Play тоже проводит проверку приложений, но предъявляемые к приложениям требования не такие жесткие.

1.3 Кроссплатформенная разработка приложений

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

Результатом веб-разработки является веб-приложение, запускаемое внутри браузера, установленного на мобильном устройстве. Для разработки такого приложения используются Java Script, HTML 5, каскадные стили CSS 3 и другие языки, технологии и инструменты веб-разработчиков.

Авторы статьи [5] выделяют два вида веб-приложений: сайты, адаптированные для просмотра на мобильных устройствах и полноценные веб-приложения, каждое из которых «выглядит как нативное приложение и может быть запущено из ярлыка, который не отличается от используемого для запуска нативных приложений» [5].

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

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

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

Гибридный подход является комбинацией двух предыдущих. Гибридное приложение, по сути, представляет из себя приложение, созданное с помощью современных веб-технологий, которое покрыто нативной «оболочкой», позволяющей запускать веб-часть вне браузера. В качестве «оболочки» может выступать как собственный код, так и одно из многочисленных готовых решений, таких как PhoneGap, Titanium и другие.

Данные метод позволяет получить доступ к API устройства. Кроме того, популярные фреймворки содержат в себе богатые библиотеки элементов интерфейса и позволяют генерировать свой пользовательский интерфейс для каждой целевой платформы с учетом её особенностей.

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

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

1.4 Использование возможностей Adobe Air

Исходное приложение для электронной валютной торговли реализовано на платформе Adobe Flash. Возможности данной платформы не ограничены созданием RIA для настольных ПК. Компанией Adobe разработана кроссплатформенная среда исполнения Adobe AIR. Согласно заявлению на сайте компании «среда исполнения Adobe AIR позволяет разработчикам запаковывать один и тот же код в нативные приложения для iPhone, iPad, Kindle Fire, Nook Tablet и других Android устройств, делая доступными магазины мобильных приложений для более чем 500 миллионов устройств»[8]. Таким образом, разработка приложений с помощью Adobe AIR по сути является гибридной разработкой.

У данного метода есть свои минусы. Каких-либо исследований на тему производительности приложений, созданных с помощью Adobe AIR, найдено не было, однако многие разработчики в своих блогах ([9],[10]) утверждают, что такие приложения существенно уступают по производительности нативным с аналогичным функционалом. Кроме того, размер итогового приложения возрастает в несколько раз.

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

1.5 Выбор метода разработки для нескольких платформ

Каждый из вышеперечисленных подходов обладает своими достоинствами и недостатками, написан ряд статей, содержащих сравнения данных подходов и рекомендации по выбору наиболее подходящего. Авторы статьи [5] считают, что выбор наиболее подходящего метода «зависит от специфических нужд организации и может управляться многими параметрами, такими как бюджет, сроки, внутренние ресурсы, целевой рынок, требуемый функционал приложения, IT-инфраструктура и многие другие».

Веб и гибридная методика позволяют создать одно приложение для целого ряда платформ, не требуя много времени и средств. Использование Adobe AIR позволяет сгенерировать приложение под нужную платформу из исходного одним щелчком мыши. Однако, исходное приложение разработано с использованием SDK Adobe Flex. Не все классы, входящие во Flex-фреймворк поддерживаются на мобильных устройствах, следовательно, необходимо переработать исходное приложение.

Кроме того, в списке требований к целевому приложению одним из важнейших является графический дизайн пользовательского интерфейса. Следовательно, для каждой платформы необходимо разработать собственный дизайн с учетом особенностей и требований Apple Store и Google Play. Так как исходное приложение разработано для настольных компьютеров, его дизайн не адаптирован под мобильные устройства и нуждается в полной переработке.

Архитектор пользовательских интерфейсов Джозеф Дикерсон в своей статье [11] утверждает, что «нативные приложения предлагают ряд преимуществ. Основным из них является производительность такого приложения… нативное приложение быстрее и более доступно, что критично важно для финансовых услуг». Однако для разработки нативных приложений потребуется больше времени и ресурсов.

Таким образом, главное требование – высокая производительность – удовлетворяют только нативные приложения. Кроме того, веб-методика и ряд фреймворков для кросс-платформенной мобильной разработки не являются подходящими для разработки целевого приложения из-за особенностей протокола шифрования на торговом сервере. Использование технологии Adobe AIR потребует полной переработки исходного приложения, но не даст необходимого уровня производительности.

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

При разработке нативных приложений следует опираться на опыт, полученный при создании исходного приложения. Так как функционал исходного и мобильных приложений идентичен, всю бизнес логику можно перенести из исходного приложения. Сходство языков Action Script 3.0 и Java позволяет копировать все классы бизнес-логики в приложение для Android, для iOS необходима незначительная переработка синтаксиса. Однако перенос элементов пользовательского интерфейса в приложения для мобильных платформ не является тривиальной задачей.

Исследование различных источников показало, что вопрос портирования приложений на мобильные платформы актуален, но мало изучен. Единственным вариантом, предлагаемым для портирования приложений с Adobe Flash на мобильные платформы, является использование технологии Adobe AIR. Так же на различных форумах можно найти целую серию рекомендаций по портированию приложений с Android и iOS и наоборот, но большая часть из них касается только изменений в интерфейсе. Сотрудники института Мэриленд опубликовали статью, посвященную портированию веб-приложения на платформу iOS [12]. В своей работе они  также создавали нативное приложение. Однако их предметная область достаточно специфична, основным элементом интерфейса приложения является географическая карта. Других научных статей на данную тему найдено не было. Из вышеперечисленных фактов можно заключить, что проблема портирования интерфейса приложений на мобильные платформы актуальна и мало изучена.

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

Из всего вышеизложенного следует цель данной выпускной квалификационной работы: провести анализ SDK, предоставляемых разработчиками платформ Android и iOS; портировать элементы пользовательского интерфейса приложения, разработанного на платформе Adobe Flash, на данные платформы. Для достижения поставленных целей необходимо решить следующие задачи:

  1.  Провести анализ пользовательского интерфейса исходного приложения для платформы Adobe Flash.

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

  1.  Исследовать Android SDK, сравнить предоставляемые во фреймворке элементы интерфейса с элементами интерфейса из фреймворка Flex.

Для проведения портирования элементов интерфейса необходимо выявить различия в перечне элементов, предоставляемых фреймворками Flex и Android.

  1.  Провести портирование элементов интерфейса в приложение на платформе Android.
  2.  Исследовать iOS SDK, сравнить предоставляемые во фреймворке элементы интерфейса с элементами интерфейса из фреймворка Flex.

Для проведения портирования элементов интерфейса необходимо выявить различия в перечне элементов, предоставляемых фреймворками Flex и iOS.

  1.  Провести портирование элементов интерфейса в приложение на платформе iOS.

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

2 Особенности интерфейса на платформе Adobe Flash

2.1 Adobe Flex

При создании исходного клиента использовался комплект средств разработки Adobe Flex. Данный SDK позволяет создавать приложения, использующие в качестве среды исполнения Adobe Flash Player. Помимо интегрированной среды разработки Adobe Flash Builder в комплект входит Flex-фреймворк, содержащий различные элементы управления, медиакомпоненты для отображения изображений, видео и аудио, контейнеры, валидаторы, эффекты и многие другие компоненты для создания RIA.

Использование фреймворка Flex для разработки RIA дает ряд преимуществ:

1. Возможности языка ActionScript 3.0. «ActionScript 3.0 представляет собой объектно-ориентированный язык программирования, применяемый для создания приложений и управляемого с помощью сценариев мультимедийного содержимого для воспроизведения в клиентских средах выполнения Flash»[13].

2. Широкие возможности для использования видео, аудио, анимации. Фреймворк позволяет внедрять в приложения анимацию, созданную в приложении Adobe Flash. При этом доступ к swf-файлу с анимацией осуществляется так же, как к любому другому объекту класса MovieClip.

2. Отсутствие каких-либо ограничений в дизайне пользовательского интерфейса. Можно изменить внешний вид любого компонента, предоставляемого фреймворком. Кроме того, использование каскадных таблиц стилей (CSS 3.0) и встроенного языка MXML позволяет упростить процесс разработки элементов пользовательского интерфейса.

3. Возможность сохранения настроек пользователя в памяти. Класс SharedObject позволяет сохранять небольшие объемы данных в формате «ключ – значение» в локальном дисковом пространстве.

4. Поддержка нескольких платформ. Приложения запускаются на любом устройстве, где установлена среда исполнения Adobe Flash Player.

5. Большое количество доступных компонентов пользовательского интерфейса. Фреймворк Flex предлагает множество различных компонентов, так же в сети Интернет доступно большое количество компонентов от сторонних разработчиков.

Но помимо преимуществ у данной технологии имеется ряд недостатков:

  1.  Главный недостаток технологии Adobe Flash – однопоточность. Все операции выполняются в одном потоке; если приложение выполняет какие-то сложные вычисления, пользовательский интерфейс не будет отвечать на действия пользователя. В Flash Player 11.4 и AIR 3.4 появилась технология ActionScript Workers. «Объекты Background Workers запускаются параллельно, чтобы высвободить больше машинных ресурсов и избежать замирания элементов интерфейса»[14]. Однако технология появилась недавно (в конце 2012 года), поэтому не использовалась при разработке исходного приложения для электронной валютной торговли.
  2.  Приложения требуют наличия Adobe Flash Player. Если среда исполнения не установлена на компьютере – приложение не запустится. Многие пользователи сети Интернет блокируют мультимедиа-контент, чтобы избавиться от навязчивой рекламы. Веб-приложения, разработанные с помощью Flex так же блокируются, что существенно мешает их распространению.
  3.  Большой размер приложения. RIA-приложения нагружены картинками, видео и аудио, что отрицательно влияет на размер приложения.

Исходное приложение для электронной валютной торговли так же обладает перечисленными достоинствами и недостатками. Однопоточность платформы существенно снижает производительность приложения, размер готового приложения составил 3,6 Мб, что делает приложение недоступным для пользователей с очень низкой пропускной способностью сети.

Приложение богато графическими и анимационными элементами, что выделяет его среди конкурентов.

2.2 Клиент для электронной валютной торговли

При разработке исходного клиента были использованы компоненты пользовательского интерфейса, предоставляемые Flex-фреймворком. Их внешний вид был кастомизирован с помощью каскадных таблиц стилей.

Рисунок 2 - Окно авторизации.

На рисунке 2 представлено окно авторизации исходного клиента. Для отображения  однострочной текстовой информации использовался компонент Label из пакета spark.components, многострочного текста – компонент TextArea. Для ввода данных использован TextInput, для выбора альтернативы посредством выпадающего списка – ComboBox, для выбора «истина/ложь» - CheckBox. Для отображения кнопок служит компонент Button.

Для валидации введенных значений и отображения её результатов был использован класс Validator из пакета mx.validators.

Рисунок 3 - Панель открытия ордера.

Для ввода численных значений как с помощью клавиатуры, так и с помощью кнопок, был использован компонент NumericStepper из пакета spark.componens.

Рисунок 4 - Панель отображения ордеров.

Табличная информация отображается с помощью компонента mx.controls.DataGrid. Группировку нескольких таблиц в виде вкладок реализует экземпляр класса mx.containers.TabNavigator.

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

Рисунок 5 - Диаграмма классов компонента для отображения графиков.

Компонент для отображения графиков представляет экономические данные в виде японских свечей, столбцового графика, линейных и тиковых графиков. Скроллинг и масштабирование содержимого графика осуществляется с помощью специального мини-графика. Так же доступен расчет и отображение ряда индикаторов, таких как полосы Боллинджера, скользящая средняя, RSI и др. Окно с графиком можно произвольно перемещать и изменять размер, размер содержимого окна так же будет изменяться.

Рисунок 6 - Компонент для отображения графиков.

Для отображения многочисленных окон в приложении используется класс spark.components.Group. Добавление изображений на экран осуществляется с помощью экземпляров класса mx.controls.Image, swf-анимации – класса mx.controls.SWFLoader.

Каркас пользовательского интерфейса приложения составляет набор классов, унаследованных от spark.components.Group для отображения конкретных окон и других элементов. Управление окнами осуществляет собственный класс WindowManager, который создает, вызывает отображение и удаляет экземпляры окон. Отображение модальных окон осуществляется с помощью mx.managers.PopUpManager.

3 Портирование интерфейса на платформу Android

3.1 Специфика разработки приложений для платформы Android

Операционная система Android разработана компанией Google на основе ядра Linux. Данная ОС предназначена для смартфонов, планшетных компьютеров, электронных книг и других портативных устройств.

Для разработки приложений на сайте компании Google доступен Android SDK, в который помимо библиотек входит Eclipse IDE со встроенным плагином Android Developer Tools. Так же туда входит эмулятор устройств с ОС Android, однако он не очень удобен в использовании из-за низкой скорости работы. Так же SDK содержит различные инструменты для тестирования, профайлер Android-приложений и другие полезные приложения. Плагин ADT содержит целый ряд компонентов, таких как визуальный редактор макетов, позволяющий быстро создавать несложные интерфейсы, xml-редактор, инструменты для отладки и другие.

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

Приступая к разработке приложений для платформы Android впервые, необходимо ознакомиться и учитывать следующие особенности:

  1.  Жизненный цикл компонентов. С целью повысить эффективность использования памяти в операционной системе Android введен особый жизненный цикл компонентов. Самым сложным и наиболее важным для понимания жизненным циклом обладает активность (Activity). Подробное описание жизненного цикла активности можно найти в официальной документации на сайте компании Google.
  2.  Поддержка большого числа различных разрешений экрана. В отличие от ОС iOS, Android поддерживается множеством устройств с различными разрешениями экрана. Данную особенность необходимо учитывать при разработке дизайна пользовательского интерфейса.
  3.  Многопоточность. Основным языком для написания приложений является Java, который поддерживает параллельные потоки выполнения задач. В приложениях для Android все обращения к элементам интерфейса должны осуществляться из главного потока приложения (ui-потока).
  4.  Модель-вид-контроллер. Фреймворк пользовательского интерфейса Android организован на базе данного паттерна, причем компоновка элементов вида может быть определена как в рамках кода, так и с помощью XML-определения.
  5.  Файл описания AndroidManifest.xml. Данный файл содержит параметры инициализации приложения, такие как версия приложения, перечень активностей, права доступа и другие.

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

Компания Google предоставляет статистические данные по количеству скачиваний приложений в Google Play с различных версий операционной системы. Так как целевое приложение предназначено для электронной валютной торговли, наиболее интересной является статистика по категории «Финансы». Данные с сайта Google Play[15] представлены в таблице 1.

Таблица 1. Статистика скачивания приложений категории «Финансы» с различных  версий ОС Android.

Android 4.1

34,13%

Android 2.3.3-2.3.7

29,71%

Android 4.0.3 – 4.0.4

24,07%

Android 2.2

5,13%

Android 4.2

4,61%

Android 2.1

1,08%

Android 3.2

0,82%

Android 3.1

0,25%

Android 1.6

0,08%

Android 2.3

0,04%

Прочие

0,08%

Хотя первое место в статистике занимает одна из самых «свежих» версий 4.1, второе место за версиями 2.3.3-2.3.7 Gingerbread, выпущенными в феврале 2011 года [16]. Возможно это связано с тем, что в 2011 году популярность устройств с ОС Android резко возросла, однако выпущенные тогда устройства не поддерживают более новые версии ОС, а их владельцы не спешат покупать новые.

На основе приведенных данных в качестве старейшей поддерживаемой версии ОС выбрана 2.2 Froyo (Api Level 8). Таким образом, мобильное приложение для платформы Android будет доступно для как минимум 98,76% клиентов.

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

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

  1.  Изменение структуры пользовательского интерфейса приложения.
  2.  Портирование основных элементов интерфейса.
  3.  Реализация компонента для отображения плашек.
  4.  Реализация компонента для ввода числовых данных.
  5.  Портирование компонента для отображения графиков.
  6.  Реализация шаблона Наблюдатель для получения уведомлений от контроллера.

Рассмотрим каждую задачу подробнее.

3.2 Изменение структуры пользовательского интерфейса приложения

Для отображения окон был использован основной компонент любого приложения для ОС Android  – android.app.Activity. Для перемещения между окнами с помощью жеста swipe использовался компонент android.support.v4.view.ViewPager. Для группировки элементов интерфейса был использован контейнер android.widget.RelativeLayout, так как он позволяет располагать элементы относительно друг друга и родительского контейнера без привязки к конкретным координатам, что очень удобно при разработке пользовательского интерфейса для нескольких разрешений экранов. Многие разработчики советуют использовать для отображения окон компонент android.app.Fragment, который дает ряд преимуществ при разработке приложений для планшетов и других устройств с большими экранами. Данное приложение разрабатывалось для смартфонов, поэтому компонент Fragment не использовался, однако в будущем, при разработке планшетной версии Fragment будут добавлены.

Рисунок 7 - Диаграмма классов главного окна.

На рисунке 7 изображена диаграмма классов главного окна приложения MainSlidingActivity, внутри которого отображается информация о пользователе, таблица котировок и таблица ордеров. Информация сгруппирована в виде трех окон, перемещение между которыми осуществляется с помощью жеста swipe.

Рисунок 8 - Диаграмма классов окна открытия ордера.

Рисунок 9 - Диаграмма классов окна с детальной информацией об ордерах.

На рисунках 8 и 9 представлены диаграммы классов окна открытия ордеров и окна с детальной информацией об ордерах. Их структура аналогична главному окну. Однако, если в MainSlidingActivity всегда содержатся 3 окна с информацией, в окнах OpenOrderSlidingActivity и OrdersSlidingActivity количество вложенных окон зависит от количества доступных для торговли валютных пар и открытых ордеров, т.е. может изменяться в процессе работы приложения. Созданием и удалением окон занимается объект класса MainPagerAdapter, унаследованного от абстрактного класса android.support.v4.view.PagerAdapter. Переопределение метода instantiateItem(ViewGroup, int) позволяет адаптеру создавать отдельное окно для каждого ордера или валютной пары, передавать ему ряд параметров для отображения. Таким образом, с помощью одного адаптера создается изменяемый набор окон с различным содержимым.

3.3 Портирование основных элементов интерфейса

В процессе изучения библиотеки элементов пользовательского интерфейса Android были определены компоненты, соответствующие элементам интерфейса из библиотеки Flex. Соответствие использованных при портировании компонентов представлено в таблице 2.

Таблица 2 - Соответствие компонентов интерфейса во фреймворках Flex и Android.

Платформа

Adobe Flash

Android

Базовый компонент-контейнер

Group

ViewGroup

Компонент для ввода текста

TextInput

EditText

Компонент для отображения изображений

Image

ImageView

Компонент для отображения однострочного текста

Label

TextView

Компонент для отображения многострочного текста

TextArea

TextView

Полоса прокрутки

Slider

SeekBar

Выбор «истина/ложь»

CheckBox

CheckBox

Кнопка

Button

Button

Ввод численных данных

NumericStepper

-

Для компонента NumericStepper не было найдено соответствия, поэтому был реализован собственный компонент для ввода числовых данных (см. подраздел 3.5).

Для отображения сообщений от сервера использовался компонент, специфичный для ОС Android – android.widget.Toast. Внешний вид компонента был изменен с помощью метода setView(View view). Положение компонента на экране было изменено с помощью метода setGravity(int gravity, int xOffset, int yOffset). Результат работы представлен на рисунке 10.

Рисунок 10 - Внешний вид оригинального компонента android.widget.Toast (слева) и компонента после кастомизации (справа).

Для отображения диалоговых окон использовался компонент android.app.AlertDialog. Его внешний вид был изменен с помощью экземпляра класса ContextThemeWrapper. Компонент до и после кастомизации изображен на рисунке 11.

Рисунок 11 -  Компонент AlertDialog до (слева) и после (справа) кастомизации.

3.4 Реализация компонента для отображения плашек

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

Рисунок 12 - Таблица котировок.

Для реализации плашки был реализован класс QuoteRectangle, унаследованный от контейнера RelativeLayout. Структура содержимого плашки описана в xml-файле. При возникновении события «получение котировок» происходит перерисовка графика и изменение значения котировки. Для отображения графика котировок использован собственный компонент.

Плашка для отображения ордеров выполнена аналогичным образом, но с другим содержимым.

Для отображения плашек в виде таблицы использован компонент android.widget.GridView. Создание экземпляров плашек для котировок производится экземпляром класса QuotesListAdapter, реализующего интерфейс ListAdapter. Диаграмма последовательности вызовов при создании новой плашки для отображения котировок представлена на рисунке 13.

Рисунок 13 - Диаграмма последовательности вызовов при создании новой плашки.

Экземпляр класса AppData является хранилищем данных и предоставляет информацию о валютной паре, соответствующей данной плашке.

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

3.5 Реализация компонента для ввода числовых данных

В библиотеке android представлен компонент NumberPicker, схожий по функциональности с NumericStepper из библиотеки Flex, однако он добавлен в API level 11 и не поддерживается версиями Android ниже 3.0. Был реализован собственный компонент, схожий по функционалу и дизайну с NumericStepper. Кроме того, была добавлена возможность изменения значения длительным нажатием на кнопки, причем, чем дольше время нажатия, тем больше величина изменения значения.

Класс NumericStepper унаследован от контейнера RelativeLayout, содержит в себе две кнопки Button и поле для ввода EditText. Для обработки нажатия на кнопки был добавлен слушатель, код представлен в листинге 1.

Листинг 1. Обработка нажатия на кнопку увеличения значения.

//получение ссылки на экземпляр кнопки, описанный в xml-файле

Button btnPlus = (Button)findViewById(R.id.btnPlus);

//реализация интерфейса android.view.View.OnTouchListener с помощью //анонимного класса

btnPlus.setOnTouchListener(new OnTouchListener(){

private Timer _timer;

     public boolean onTouch(View v, MotionEvent event) {

      if (event.getAction() == MotionEvent.ACTION_DOWN){

                   

//включение таймера при нажатии на кнопку  

                 _timer = new Timer("buttonPlusTimer");

                 _timer.schedule(new TimerTask(){

                  private double step = 1;

                       

   //метод, запускаемый при срабатывании таймера

                       @Override

                       public void run(){

                           double value = getValue();

                           

//если результат увеличения превышает максимально //допустимое значение – возврат к минимальному //значению    

                           if (value+step <= _maxValue)

                            setValue(value+step);

                           else

                            setValue(_minValue);

                           

   //увеличение шага

                           step =step*2;

                       }

                 //0 – задержка перед первым срабатыванием, 100 – количество

//миллисекунд между срабатываниями      

                 }, 0, 100);

           }

           else if (event.getAction() == MotionEvent.ACTION_UP){

    //кнопка отпущена – работа таймера завершена

                   if (_timer!= null)

                       _timer.cancel();

           }

               return true;

           }        

    });

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

3.6 Портирование компонента для отображения графиков

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

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

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

Компонент для отображения графиков создан на основе класса View – базового для всех элементов пользовательского интерфейса. Для прорисовки графика переопределен метод onDraw(Canvas canvas). Экземпляр класса Canvas, по сути, является «холстом», на котором рисуются точки и линии будущего графика. Так как метод onDraw(Canvas canvas) вызывается гораздо чаще, чем происходит обновление данных на графике (экспериментально выяснено, что 80% вызовов происходят «в холостую»), добавлено кэширование графика. Прорисовка происходит на хранящемся в памяти объекте класса Canvas при изменении данных на графике. При вызове onDraw(Canvas canvas) осуществляется вывод заранее нарисованного графика. При изменении данных на графике происходит вызов других методов прорисовки в зависимости от значения параметров графика. Метод прорисовки графика с учетом цветовой дифференциации положительных и отрицательных значений приведен в листинге 2.

Листинг 2. Метод прорисовки графика прибыли с цветовой дифференциацией.

private void drawWithColors(Canvas canvas){

int x1, x2, x3, y1, y2, y3;

     double zeroX = 0; //значение x, при котором график пересекает ось OX

//координаты первой точки

     x1 = toLocalCoordinateX(_dataProvider.get(0).getX().getTime());

     y1 = toLocalCoordinateY(_dataProvider.get(0).getY());

 //цвета положительной и отрицательной частей

     Paint positivePaint = new Paint();

     positivePaint.setColor(_positiveColor);

     Paint negativePaint = new Paint();

     negativePaint.setColor(_negativeColor);

     for (int i = 1; i < _dataProvider.size(); i++){

 //ищем отрезки, концы которых не равны нулю и разные по знаку

 //сравнение с 0.001 является достаточным, так как при вычислении

//прибыли значение округляется до сотых

      if (Math.abs(_dataProvider.get(i - 1).getY()) > 0.001

                   && Math.abs(_dataProvider.get(i).getY()) > 0.001

                   && _dataProvider.get(i - 1).getY()

                           * _dataProvider.get(i).getY() < 0){

               // рисуем часть ДО пересечения с осью OX

               if (_dataProvider.get(i - 1).getY() > 0){

//значение функции уменьшается

zeroX = (_dataProvider.get(i).getX().getTime() –

_dataProvider.get(i - 1).getX().getTime())

* _dataProvider.get(i - 1).getY()

/ (Math.abs(_dataProvider.get(i - 1).getY())

+ Math.abs(_dataProvider.get(i).getY()));

               } else {

//значение функции растет

                   zeroX = (_dataProvider.get(i).getX().getTime() –

_dataProvider.get(i - 1).getX().getTime())

                       * _dataProvider.get(i).getY()

                       / (Math.abs(_dataProvider.get(i - 1).getY())

+ Math.abs(_dataProvider.get(i).getY()));

                     zeroX = _dataProvider.get(i).getX().getTime()

                        - _dataProvider.get(i - 1).getX().getTime() - zeroX;

               }

   //координаты точки пересечения с осью OX на графике

               x2 = toLocalCoordinateX(

 _dataProvider.get(i - 1).getX().getTime() + zeroX);

               y2 = toLocalCoordinateY(0);

               if (_dataProvider.get(i - 1).getY() > 0)

                   canvas.drawLine(x1, y1, x2, y2, positivePaint);

               else

                   canvas.drawLine(x1, y1, x2, y2, negativePaint);

               

               // рисуем часть ПОСЛЕ пересечения

               x3 = toLocalCoordinateX(

  _dataProvider.get(i).getX().getTime());

               y3 = toLocalCoordinateY(_dataProvider.get(i).getY());

               if (_dataProvider.get(i - 1).getY() > 0)

                   canvas.drawLine(x2, y2, x3, y3, negativePaint);

               else

                   canvas.drawLine(x2, y2, x3, y3, positivePaint);

     //подготовка к следующему шагу цикла

               x1 = x3;

               y1 = y3;

           } else {

  //рисуем отрезок одним цветом

           }

       }

   }

Цветовая дифференциация является новым функционалом и отсутствует в исходном клиенте. Результат работы данного метода представлен на рисунке 14.

Рисунок 14 - График прибыли по открытому ордеру.

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

3.7 Шаблон Наблюдатель для получения уведомлений от контроллера

В исходном flex-клиенте для уведомления элементов пользовательского интерфейса об изменении данных использовалась событийная модель языка Action Script 3.0, основанная на спецификации W3C Document Object Model Level 3 [13]. Так как в языке Java обрабатывается только ограниченный список событий, например, события мыши, для обработки собственных событий бизнес-логики был реализован шаблон Наблюдатель. Диаграмма классов шаблона изображена на рисунке 15.

Рисунок 15 - Диаграмма классов шаблона Наблюдатель.

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

4 Портирование интерфейса на платформу iOS

4.1 Специфика разработки приложений для платформы iOS

Операционная система iOS разработана компанией Apple для своих мобильных устройств. В отличие от ОС Android, данная система не устанавливается на устройства других фирм, что облегчает труд разработчиков приложений, так как список устройств, которые необходимо поддерживать, очень сильно ограничен.

При переходе от разработки приложений на платформе Adobe Flash к разработке мобильных приложений для iOS необходимо учитывать следующие особенности:

  1.  Специфика языка Objective-C. Разработчики платформы советуют использовать для разработки язык Objective-C. Однако синтаксис и некоторые семантические конструкции данного языка могут поставить в тупик разработчиков, привыкших к Java или Action Script. Кроме того, код на Objective-C богат различными директивами компилятора, которые призваны облегчить разработку, но усложняют изучение языка.
  2.  Многопоточность. Язык Objective-C поддерживает многопоточность, причем в каждом iOS-приложении есть главный поток, отвечающий за обработку событий от пользователя и обновление пользовательского интерфейса.
  3.  Модель-вид-контроллер. Подобно приложениям для Android, приложения для iOS проектируются на базе шаблона Модель-Вид-Контроллер, причем компоновка элементов вида может быть определена как в рамках кода, так и с помощью инструмента Interface Builder.
  4.  Отсутствие сборщика мусора. В iOS отсутствует сборщик мусора, поэтому при разработке необходимо следить за выделяемой памятью. Для этих целей реализован механизм автоматического подсчета ссылок Automatic Reference Counting.

Для разработки приложений компания Apple предоставляет разработчикам пакет программ Xcode. Помимо среды разработки в пакет входят набор компиляторов, инструмент для разработки интерфейсов Interface Builder и другие полезные приложения. Для отладки можно использовать как устройства от компании Apple, так и встроенный эмулятор. Следует заметить, что, в отличие от эмулятора, встроенного в Android SDK, iOS эмулятор обладает высокой производительностью и удобен для отладки.

Перед добавлением приложения в AppleStore оно должно пройти специальную проверку. Компания Apple предъявляет ряд требований как к безопасности и функционалу приложений, так и к пользовательскому интерфейсу. При разработке дизайна окон необходимо учитывать данные требования и придерживаться рекомендаций компании.

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

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

Перед началом разработки приложений для операционной системы iOS необходимо определить перечень целевых версий системы. На момент начала разработки мобильного клиента (начало 2012 года) последней версией iOS была версия 5.0. Наиболее распространенной среди мобильных устройств была версия 4.3, поэтому данная версия была выбрана в качестве начальной. Таким образом, клиент для iOS поддерживает версии операционной системы 4.3 и выше.

К сожалению, компания Apple не предоставляет статистику по скачиванию приложений из Apple Store с различных версий операционной системы, как это делает Google. Некоторые компании и разработчики пытаются составить собственную статистику на основе данных полученных от своих приложений из Apple Store, однако, очевидно, что такая информация характеризует только их приложения, а не весь рынок в целом.

В процессе портирования пользовательского интерфейса из flex-приложения в iОS-приложение были решены следующие задачи:

  1.  Изменение структуры пользовательского интерфейса приложения.
  2.  Реализация компонента для обработки жеста swipe.
  3.  Портирование основных элементов интерфейса.
  4.  Реализация компонента для отображения сетки.
  5.  Реализация компонента для отображения плашек.
  6.  Реализация компонента для ввода числовых данных.
  7.  Портирование компонента для отображения графиков.
  8.  Получение уведомлений от контроллера.

Рассмотрим каждую задачу подробнее.

4.2 Изменение структуры пользовательского интерфейса приложения

Структура приложения для iOS схожа со структурой приложения для Android, различия возникли из-за того, что ОС Android самостоятельно управляет памятью, а iOS всё управление перекладывает на плечи разработчика. Соответственно, необходимо самостоятельно создавать все окна, выделять для них память и следить за её очисткой. В Android-приложениях отдельные activity не знают о существовании друг друга, в iOS-приложении окно-родитель содержит ссылку на создаваемое окно.

Для реализации жеста swipe фреймворк UIKit предоставляет компонент UIPageViewController, однако данный жест поддерживается только начиная с версии iOS 6.0. Собственный компонент для реализации данного жеста описан в следующем подразделе.

Классы-контроллеры для окон унаследованы от класса UIViewController, класс для отображения набора окон SwipeContainer был унаследован от UIView.

Диаграмма классов окон приложения изображена на рисунке 16.

Рисунок 16 - Диаграмма классов окон iOS-приложения.

4.3 Реализация компонента для обработки жеста swipe

Так как приложение должно поддерживаться версиями операционной системы, начиная с iOS 4.3, был реализован собственный компонент для навигации между окнами с помощью жеста swipe. Экземпляр класса SwipeContainer содержит внутри себя экземпляр UIScrollView, который, в свою очередь, наполнен необходимым содержимым. UIScrollView позволяет прокручивать содержимое с помощью жеста swipe. При завершении прокрутки (палец отпускает экран) происходит проверка текущей координаты, при необходимости происходит «докрутка» до следующего окна, либо возвращение к предыдущему. При возникновении события экземпляр UIScrollView посылает своему делегату сообщение scrollViewDidScroll. Для обработки сообщения класс SwipeContainer является делегатом класса UIScrollView, то есть реализует протокол UIScrollViewDelegate. Код проверки приведен в листинге 3.

Листинг 3. Проверка текущего положения при завершении прокрутки.

  •  (void)scrollViewDidScroll:(UIScrollView *)sender {

//ширина одного окна

CGFloat pageWidth = _scrollView.frame.size.width;

//высчитываем номер окна, которое нужно отобразить

int page = floor((_scrollView.contentOffset.x - pageWidth / 2) / pageWidth) + 1;

//докручиваем до нужного окна

   if (_visibleView != page)

       [self showViewAtIndex:page];

}

Очевидно, что Objective-C существенно отличается от Action Script, поэтому перед началом разработки необходимо тщательно изучить особенности языка, такие как делегаты, категории, протоколы.

4.4 Портирование основных элементов интерфейса

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

Таблица 3 - Соответствие компонентов интерфейса во фреймворках Flex и UIKit.

Платформа

Adobe Flash

iOS

Базовый компонент-контейнер

Group

UIView

Компонент для ввода текста

TextInput

UIEditText

Компонент для отображения изображений

Image

UIImageView

Компонент для отображения однострочного текста

Label

UILabel

Компонент для отображения многострочного текста

TextArea

UILabel

Полоса прокрутки

Slider

UISlider

Выбор «истина/ложь»

CheckBox

UISwitch

Кнопка

Button

UIButton

Ввод численных данных

NumericStepper

-

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

Для отображения сообщений от сервера и диалоговых окон был использован компонент UIAlertView. Данный компонент не подлежит кастомизации и одинаково выглядит во всех приложениях для операционной системы iOS. Внешний вид компонента изображен на рисунке 17.

Рисунок 17 - Компонент UIAlertView.

4.5 Реализация компонента для отображения сетки

Для отображения набора элементов в виде сетки фреймворк UIKit предоставляет компонент UICollectionView, однако данный компонент доступен начиная с версии iOS 6.0. В сети Интернет можно найти множество реализаций от сторонних разработчиков, но при отображении набора плашек с постоянно меняющимися графиками такие компоненты работали крайне медленно, что недопустимо для торговли.

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

Так как UIScrollView не отвечает за расстановку элементов внутри себя, был реализован метод для расчета координат каждой плашки внутри контейнера. Исходный код метода приведен в листинге 4. Внешний вид компонента аналогичен компоненту из приложения для Android.

Листинг 4. Определение координаты плашки внутри контейнера.

//определяем число столбцов   

Int columnCount = self.frame.size.width/(cell.frame.size.width+self.space);

//определяем отступы от границ контейнера. self.space – расстояние между //плашками

    self.border = (self.frame.size.width – columnCount * (cell.frame.size.width+self.space)) / 2;            

float x=self.border;

float y=self.border;

GridCellView *cell;

for (int i=0; i<_cellsCount; i++)

{

     cell = [_delegate cellForIndex:i forGridView:self];      

//устанавливаем размер плашки          

     cell.frame = CGRectMake(x, y, cell.frame.size.width, cell.frame.size.height);

      //добавляем только видимые плашки

if (CGRectIntersectsRect(_scrollView.bounds, cell.frame))

        [_scrollView addSubview:cell];              

      if((i+1) % cellCount == 0)

      {

  //распологаем плашку в первом столбце

            x = self.border;

            y += cell.frame.size.height + self.space;

       }

       else

            x += cell.frame.size.width + self.space;

 }

4.6 Реализация компонента для отображения плашек

Для отображения плашки с графиком и текстовыми данными был создан компонент UIGridCell, унаследованный от UIView. Наполнение компонента содержимым реализовано программно.

Каждая плашка реагирует на одинарное и длительное нажатие. Для обработки одинарного нажатия используется экземпляр класса UITapGestureRecognizer. Подписка на событие осуществляется с помощью следующих команд:

_tapRec=[[UITapGestureRecognizer alloc] initWithTarget:self action:@selector(onTapedEvent)];

     self addGestureRecognizer:_tapRec];

onTapedEvent – название метода, запуск которого осуществляется при возникновении события.

Обработка длительного нажатия осуществляется аналогично, но задействован экземпляр класса UILongPressGestureRecognizer.

Внешний вид компонента для отображения плашек приведен на рисунке 18.

Рисунок 18 - Плашки для отображения котировки (слева) и ордера (справа).

4.7 Реализация компонента для ввода числовых данных

Для ввода числовых данных с помощью кнопок «+», «-» и текстового поля был наследован класс UIView. В качестве кнопок использовался компонент UIButton, в качестве поля для ввода данных с помощью клавиатуры – UITextField.

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

Проверка корректности значения вызывается при возникновении события «нажатие на кнопку». Для проверки значения, введенного с помощью клавиатуры, реализован протокол UITextFieldDelegate, в частности, переопределены методы textFieldDidBeginEditing, textFieldDidEndEditing. Внешний вид компонента приведен на рисунке 19.

Рисунок 19 - Компонент для ввода числовых данных.

4.8 Портирование компонента для отображения графиков

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

Портирование компонента для отображения графиков на платформу iOS происходило аналогично Android. Был создан класс-наследник от UIView, в котором переопределен метод drawRect(CGRect). Так как данный метод вызывается гораздо чаще, чем меняется содержимое графика, был реализован механизм кэширования графических данных. Прорисовка графика производится в хранящийся в памяти экземпляр класса CGContextRef (аналог класса flash.display.Graphics из библиотеки Flex, содержащего методы для векторного рисования), который затем выводится при каждом вызове метода drawRect(CGRect). Такой подход позволил убрать временные задержки при отображении большого числа графиков.

Метод drawRect(CGRect) и примеры вызова различных методов класса CGContextRef, использующихся при прорисовке графиков, приведены в листинге 5.

Листинг 5. Рисование с помощью CGContextRef.

- (void) drawRect: (CGRect) rect {

 CGContextRef currentContext = UIGraphicsGetCurrentContext();

    CGContextClearRect(currentContext, rect);

   //_context - экземпляр класса CGContextRef, содержащий заранее

//нарисованный график

    CGImageRef image = CGBitmapContextCreateImage(_context);

    CGContextDrawImage(currentContext, rect, image);

    CGImageRelease(image);    

}

//вывод текста                    

CGContextSetRGBFillColor(_context, 0.6, 0.6, 0.6, 1.0);

CGContextSetLineWidth(_context, 2.0);

CGContextSetCharacterSpacing(_context, 2.0);

//определение размера текста

CGSize maxSize=[maxString sizeWithFont:[UIFont fontWithName:@"Helvetica-Bold" size:10]];

CGContextShowTextAtPoint(_context, width-maxSize.width, self.frame.size.height-maxSize.height+3, [maxString UTF8String], maxString.length);               

//рисование линий

CGContextBeginPath(_context);

CGContextSetLineWidth(_context, _lineWidth);

CGContextSetStrokeColorWithColor(_context, _lineColor.CGColor);

CGContextMoveToPoint(_context, x1,y1);

CGContextAddLineToPoint(_context, x2,y2);

4.9 Получение уведомлений от контроллера

Для получения событий от контроллера при разработке iOS-клиента не понадобилась собственная реализация шаблона Наблюдатель. Для получения уведомлений от контроллера используется экземпляр класса NSNotificationCenter – центр уведомлений. Объекты регистрируются для получения уведомлений от центра с помощью метода addObserver(), в параметрах которого указывается название события, уведомление о котором необходимо получить, и метод, который необходимо вызвать при получении уведомления. По сути, данный механизм аналогичен механизму подписки и получения уведомлений в ActionScript 3.0, отличие состоит лишь в том, что объект NSNotificationCenter является единственным для процесса, то есть механизм получения уведомлений централизован.

5 Сравнение приложений для различных платформ

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

Основная причина возникновения проблем для операционной системы iOS – отсутствие тех или иных компонентов для версий ниже 5.0. Для разработчиков, пишущих приложения для версии 6.0 и выше, большинство возникших проблем не актуальны.

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

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

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

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

На рисунке 20 представлено окно открытия ордера из приложений для двух платформ. Если разница в цветовых решениях является отражением предпочтений дизайнера, отличия в наборе элементов возникли из-за особенностей каждой платформы. На корпусе устройств с операционной системой Android есть кнопка «Назад» для возврата к предыдущему окну, тогда как на устройствах от компании Apple такая кнопка отсутствует. Поэтому была добавлена кнопка в верхней части окна.

Остальные окна приложения практически не отличаются, за исключением цветовых решений.

Рисунок 20 - Окно открытия ордера в приложениях для Android и iOS.

При портировании пользовательского интерфейса приложения для платформы Adobe Flash в приложение для платформы Android необходимо обратить внимание на следующие факторы:

  1.  Ресурсы мобильных устройств сильно ограничены. Не смотря на бурное развитие современных технологий, смартфоны и планшеты всё еще сильно отстают от персональных компьютеров. Те решения, которые во flex-приложении работали прекрасно, на мобильных устройствах могут работать очень медленно.
  2.  Необходимо помнить о жизненном цикле Activity. В приложениях для Android нельзя хранить ссылки на окна, так как их жизненным циклом управляет операционная система, и нет гарантии, что в нужный момент окно не удалится из памяти.
  3.  При определении размеров элементов интерфейса не следует указывать размер в пикселях. Разнообразие устройств для ОС Android очень велико, поэтому необходимо настраивать приложение для различных размеров и разрешений экрана. При определении размеров лучше использовать единицу измерения dp - Density-independent Pixels.
  4.  Следует избегать большого количества вложенных View. Наличие на экране «капусты» из View очень сильно замедляет работу приложения.
  5.  Главный поток должен заниматься исключительно интерфейсом. Все операции, не требующие обращения к интерфейсу следует выполнять в другом потоке, тогда приложение будет быстрее откликаться на действия пользователя.

Данные рекомендации пригодятся не только при портировании flex-приложения, но и любого другого, а так же при разработке абсолютно нового приложения.

Для платформы iOS следует обратить внимание на следующие факторы:

  1.  Острая проблема нехватки ресурсов. В процессе портирования несколько раз возникали ситуации, когда одно и то же решение для интерфейса в iOS-приложении работало крайне медленно, а в Android-приложении вполне приемлемо. При реализации бизнес-логики складывалась противоположная ситуация.  При этом устройства для тестирования практически не отличались по характеристикам. Возможно, это связано с тем, что механизм определения приоритетов потоков на iOS устроен иначе.
  2.  Необходимо следить за объектами. Так как на данной платформе сборщик мусора отсутствует, необходимо следить за удалением из памяти ненужных объектов.
  3.  Главный поток должен заниматься исключительно интерфейсом. Данный фактор актуален и для операционной системы iOS.
  4.  Не все компоненты интерфейса позволяют настраивать их внешний вид. Некоторые компоненты не поддаются изменениям внешнего вида, что следует учитывать при разработке дизайна.

В заключении, можно сказать, что разработка пользовательского интерфейса для платформы iOS проще, чем для Android. Во-первых, из-за ограниченности перечня поддерживаемых устройств, во-вторых, многие настройки компонентов пользовательского интерфейса делаются с помощью одной-двух строк кода, когда для платформы Android аналогичные настройки требуют нескольких десятков строк. Однако данное сравнение субъективно и зависит от предпочтений и навыков конкретного разработчика.

Заключение

В процессе работы было проведено портирование элементов пользовательского интерфейса приложения для платформы Adobe Flash в нативные приложения для платформ iOS и Android. Проведен анализ предоставляемых создателями платформ SDK, выявлены соответствия компонентов пользовательского интерфейса. Проведен анализ платформ и сформулированы перечень особенностей каждой платформы и рекомендации для начинающих разработчиков.

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

Данная работа была представлена на конференции «Научное творчество молодежи»  в г. Анжеро-Судженске в 2013 году. Мобильные приложения внедрены в ООО «Е-Трейд Софт».

Список использованных источников

  1.  Райзберг Б.А., Лозовский Л.Ш., Стародубцева Е.Б.. Современный экономический словарь. — 2-е изд., испр. М.: ИНФРА-М, 1999.
  2.  MT5 Forum [Электронный ресурс]: Сообщество Forex трейдеров. – Электрон. дан. -  URL: http://ruforum.mt5.com (дата обращения: 06.02.2013).
  3.  Mobile/Tablet Operating System Market Share [Electronic resource] // Netmarketshare – Electronic data. – 2012. - URL: http://netmarketshare.com/operating-system-market-share.aspx?qprid=8&qpcustomd=1&qpct=3&qptimeframe=Y&qpsp=2012#  (access date: 16.02.2013).
  4.  Android Marks Fourth Anniversary Since Launch with 75.0% Market Share in Third Quarter, According to IDC  [Electronic resource] // IDC - Press Release / IDC Corporate USA. – Electronic data. – 2012. - URL: https://www.idc.com/getdoc.jsp?containerId=prUS23771812#.UTsZtlf76VE   (access date: 09.03.2013).
  5.  IBM Software. Native, web or hybrid mobile-app development. [Electronic resource] //IBM Corporation. – 2012. – The electronic version of the printing publication. – Access from „Computerworld“.
  6.  Программирование под Android/ З. Медникс [и др.] – Спб.:Питер, 2012. – 496 с.
  7.  Баклин Д. Профессиональное программирование приложений для iPhone и iPad / Джин Баклин. – М.: Эксмо, 2012. – 672 с.
  8.  Adobe AIR 3 [Электронный ресурс] // Adobe: официальный интернет-сайт. – Электрон. дан. – 2013. -  URL: http://www.adobe.com/ru/products/air.html (дата обращения: 01.03.2013).
  9.  Lee Brimelow. Native Android Development Or Adobe AIR? [Electronic resource] // Lee Brimelow. - Electronic data. – 2010. -  URL: http://www.leebrimelow.com/comparing-native-android-development-and-adobe-air/ (access date: 01.03.2013).
  10.  Igor Razhnov. Opportunities and Limitations of Flex Development for iPhone. [Electronic resource] // Altoros systems. – Electronic data. – 2010. - URL: http://blog.altoros.com/opportunities-and-limitations-of-flex-development-for-iphone.html (access date: 02.03.2013).
  11.  Joseph Dickerson. Native Mobile Apps Offer Advantages Over "Wrapper Apps" for Financial Services. [Electronic resource] // Fiserv. – Electronic data. – 2012. - URL: http://www.fiserv.com/blog/the-point/native-mobile-apps-offer-advantages-for-financial-services.htm (access date: 03.02.2013).
  12.  Porting a Web-Based Mapping Application to a Smartphone App. H. Samet [and other] // Proceedings of the 19th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems. – 2011. - Pages 525–528.
  13.  Мук К. ActionScript 3.0 для Flash. Подробное руководство / К. Мук. – Спб.:Питер, 2011. – 992 с.
  14.  Заметки о выпуске | Flash Player® 11.4 AIR® 3.4 [Электронный ресурс] // Adobe: официальный интернет-сайт. – Электрон. дан. – 2013. -    URL: http://helpx.adobe.com/ru/flash-player/release-note/fp_114_air_34_release_notes.html (дата обращения: 01.03.2013).
  15.  Google Play Developer Console. [Электронный ресурс] // Google Play. – Электрон. Дан. – 2013. - URL: https://play.google.com/apps/publish/ (дата обращения: 16.05.2013).
  16.  Android (operating system) [Electronic resource] // Wikipedia, the free encyclopedia. – Electronic data. – 2013. - URL: https://en.wikipedia.org/wiki/Android_%28operating_system%29 (access date: 16.05.2013).


EMBED Visio.Drawing.11

EMBED Visio.Drawing.11

EMBED Visio.Drawing.11

EMBED Visio.Drawing.11

EMBED Visio.Drawing.11

EMBED Visio.Drawing.15

EMBED Visio.Drawing.11

*


 

А также другие работы, которые могут Вас заинтересовать

35898. Производство алкогольной продукции 49.44 KB
  Дальнейшая перегонка дрожжей с водяным паромдает возможность получить энантовый эфир и дрожжевое масло. Фильтрат кубового остатка барды дрожжей может служить сырьем для получения с помощью ионообменных смол аминокислот в чистом виде. Более полно можно извлечь виннокислые соединения из осадков винных дрожжей методом высокого давления путем автоклавирования барды. Барабанные сушилки применяют для сушки винных дрожжей; для сушки виннокислой извести они менее пригодны так как часть материала в виде пыли уносится потоком горячего воздуха...
35899. Реляционная модель. Свойства и основные особенности реляционной модели Информационный принцип наполнения БД. Замкнутость реляционных систем, проявление замкнутости в синтаксе языка SQL 45 KB
  Техническая статья Реляционная модель данных для больших разделяемых банков данных доктора Е. 12 правил Кодда Реляционная СУБД должна быть способна полностью управлять базой данных через ее реляционные возможности. Онлайновый реляционный каталог описание БД и ее содержания должны быть представлены на логическом уровне как таблицы к которым можно применять запросы используя язык базы данных. Он должен поддерживать описание структуры данных и манипулирование ими правила целостности авторизацию и транзакции.
35901. Учет начисления амортизации по нематериальным активам 47 KB
  Учет начисления амортизации по нематериальным активам. Стоимость нематериальных активов НМА погашается частями в течение всего времени их использования в организации посредством начисления амортизации п. Для определения суммы амортизационных отчислений за месяц организации необходимо: установить срок полезного использования объекта НМА; выбрать способ начисления амортизации по объекту; рассчитать норму амортизационных отчислений по каждому объекту. СПБЫ НАЧИСИЯ АМОРТИИ Пунктом 15 ПБУ...
35902. Этапы развития СПО 47.5 KB
  Создание ассемблеров. Создание абсолютных и перемещающих загрузчиков. Создание описания процесса в виде контекста 4. Создание КПК.
35906. Оператор SELECT как проекция результатов реляционных вычислений. Соединение отношений (JOIN) в операторе. Виды соединений (INNER и OUTER, LEFT, RIGHT) 77 KB
  Оператор SELECT как проекция результатов реляционных вычислений. SELECT селект оператор DML языка SQL возвращающий набор данных выборку из базы данных удовлетворяющих заданному условию. При формировании запроса SELECT пользователь описывает ожидаемый набор данных: его вид набор столбцов и его содержимое критерий попадания записи в набор группировка значений порядок вывода записей и т. SELECT [Предикат] Поля FROM Таблицы [IN БазаДанных] [WHERE .