42
Event Dispather.
Одной из важнейших составляющих любого приложения сегодня,
когда большинство девайсов снабжены тач-скрином, является возможность
взаимодействия пользователя с системой путем касаний. Cocos2d, как кросс-
платформенный движок, предоставляет возможности обработки касаний
экрана, нажатий клавиатуры, кликов и движений мышью.
В приложениях также доступна обработка событий акселерометра,
однако, самым распространенным способом взаимодействия являются
касания – тачи и свайпы. Например, в приложении «Английский с Puzzle
English» свайпом можно выдвинуть меню навигации по приложению, а без
обработки тачей невозможно было бы осуществить переход в конкретный
раздел меню.
В общем, механизм EventDispatch отвечает на действия
пользователя.
EventListener инкапсулирует код обработки события;
EventDispather сообщает EventListener’у о событии;
EventObject содержит информацию о событии.
Например, на всех кнопках, по окончанию тапа инициируется запуск
некоторой логики(см. Приложение А).
JSON и парсинг.
JSON – это один из используемых в настоящее время форматов
текстового обмена данными. Во многих языках программирования
существуют библиотеки для работы с форматом(мы использует rapidjson).
Строка данных такого формата содержит [массивы] и(ли) {объекты} и их
комбинации.
43
Парсинг – процесс анализа и разбора данных, целью которого является
извлечение информации.
2.4. Прочие инструменты разработки мобильных приложений.
При разработке приложения есть ряд основных и вспомогательных
инструментов. Если к основным относить такие как язык и IDE, то ко
вспомогательным – систему контроля версий, дизайн, тестирование. В этом
разделе будут описаны прочие инструменты, используемые при разработке
приложения: Git, Zeplin, Craыhlitics.
Система управления версионностью Git.
Git – это распределенная система управления версиями, облегчающая
работу с проектом: программное обеспечение, регистрирующее изменения в
проекте. Используется для того, чтобы у любого члена команды,
трудящегося над проектом в любой момент времени была возможность иметь
собственную копию проекта с уже утвержденными изменениями и локально
с ней манипулировать. Такая система позволяет фиксировать этапы
разработки на сервере с локальной машины и забирать в свою версию
изменения, внесенные другими разработчиками, возвращать к прежнему
состоянию весь проект или отдельные файлы. Распространенная модель
разработки в компании Паззл Инглиш происходит по следующему принципу.
Репозиторий содержит две ветки: master и dev. В ветке master всегда
находится стабильная версия проекта, валидная для продакшн сервера; dev –
ветка для разработки. На продакшн сервере Паззл Инглиш находится
удаленный репозиторий - стабильная рабочая версия проекта. При получении
задачи к реализации делается снимок состояния, разработчик получает
копию проекта на локальной машине и может изменять приступать к
реализации, при этом состояние проекта на сервере либо у других
разработчиком не изменяется. Таким образом, проект находится в
безопасности от нежелательных изменений.
44
Фиксация изменений в ветке разработки реализуется посредством
коммитов – записей изменений в локальный репозиторий, причем в любой
момент возможен переход к любому состоянию проекта. После окончания
работы над текущей задачей делается т.н. пуш – команда, вносящая
локальные изменения в удаленный репозиторий. Хорошей практикой
является объединять в коммит логически связанные изменения, при этом
накапливать очень большие группы изменений, чтобы обезопасить
работочасы в следствие непредвиденной утери изменений локально.
Рис 16. Работа над проектом в Git; ветвление.
Преимущества Git:
45
- Практически все операции с данными происходят локально, что
положительно влияет на быстродействие;
- Предоставление CVS-сервера для интеграции IDE;
- Наличие у каждого человека, работающего над проектом, «резервной
копии», что нивелирует опасности при потере связи с сервером;
- Гибкость и сложность возможностей рабочих процессов над проектом
в силу распределенности системы и независимости от сервера;
Zeplin.
Это сервис, предназначенный облегчить процесс разработки путем
упрощения коммуникации между разработчиком и дизайнером. Программа
генерирует руководство по стилям для скетчей-исходников, благодаря чему
дизайнеру не нужно создавать графику вручную, а разработчику доступны
все стили, размеры, спецификации, отступы и проч.
Рис.17. Иллюстрация работы в Zeplin.
JIRA.
JIRA по сути своей является баг-трекерм, системой отслеживания
ошибок: тестировщики заносят туда баг репорты, но про этот аспект
использования JIRA описано в производственной практике студента. Однако
JIRA можно вполне успешно использовать и для управления проектами: в
силу своей чрезвычайно гибкой настраивоемости она позволяет создавать
проекты, делить записи на группы версий и типы(Bug, Feature, Report, Task).
Как раз при создании записей типа Task или Feature менеджером проекта
формируется в том или ином виде задача, которая, так же как и баг репорт
46
тестировщиком – программисту, назначается, например, дизайнеру или
разработчику для выполнения. У нас в компании существуют несколько
крупных проектов(таких как Puzzle_English_WEB, Puzzle_English_MOBILE,
SERVER, MARKETING и т.д.).
В мобильном проекте Puzzle English настроена сортировка записей по
типам (bug, task и т.д.) и фильтрация по версиям. Для менеджмента очень
удобно отсортировать список записей по типу, исполнителю, сроку
выполнения или тэгу. Можно отслеживать готовность проекта к релизу и
проч. При разработке программист может отсортировать список записей так,
чтобы не отвлекаться от реализации текущей задачи и не упускать дэдлайны.
Например, настройка списка записей по тэгу «транслейты», исполнителю
«Сергей Мишунин», типу «Task»+ «NewFeature» и «DueTo: дата_релиза»
позволяет мне видеть все свои задачи по конкретной разработке, планировать
сроки выполнения задач, не забывать про отдельные задачи и не отвлекаться
на лишние записи.
Рис. 18. Иллюстрация учета версий мобильного проекта в JIRA.
Crashlytics.
Пакет программного обеспечения, позволяющий облегчить работу
разработчикам и тестировщикам путем предоставления данных об
47
устройстве и состоянии проекта в момент сбоев. Предоставляет платформу
для распространения бета-версий приложений, где можно добавить
пользователей с различными ролями (например, тестировщик) и наблюдать
их активность, собирая и анализируя различные данные. Бесплатна.
Вывод по второй главе.
В главе рассмотрены основные и вспомогательные инструменты
разработки приложения «Английский с Puzzle English» и мобильной
разработки в целом, используемые в отделе мобильной разработки компании
Паззл Инглиш для реализации приложения и, в частности, раздела
Транслейты. Описаны среда разработки с описанием используемых
инструсменов, язык программирования с выделением главных особенностей,
используемая при реализации концепция ООП, дано представление об
используемой системе управления версионностью продукта, инструмент
кооперации дизайнера и разработчика – программа Zeplin, инструмент
взаимодействия разработчика с тестировщиком - Crashlytics.
Основное внимание уделено описанию возможностей движка Cocos2d-
x. Приведены основные компоненты, описаны объекты, классы и методы,
приведены примеры шаблонов их использования. Это позволяет
сформировать общее представление о движке, механике его работы и
возможных применениях. Проведен анализ источников по теме и мысли об
их актуальности. Таким образом, подготовлено теоретическое обоснование,
позволяющее приступить к описанию самого процесса реализации раздела
Транслейты с приведением примеров.
48
Глава 3. Разработка раздела «Транслейты»
3.1. Проектирование
Раздел «Транслейты» структурно представляет собой один из основных
разделов приложения «Английский с Puzzle Englush» и входит в тип разделов
«Задания» иерархии разделов и интеграции в систему ограничений сервиса.
Архитектурно представляет собой набор сцен, смена которых
осуществляется по законом логики, отвечающим техническому заданию,
сформированному во второй главе. Переход в раздел осуществляется из
входной точки бургер-меню приложения(меню навигации по приложению,
доступное пользователю в любой момент: вызывается свайпом вправо,
отодвигает текущую сцену и предоставляет доступ к списку разделов). В
нашей компании при реализации раздела было важно соблюдать общие
архитектурные особенности приложения и стиль. За критериями,
отвечающими общей эргономичности следит дизайнер: разработчик
реализует концепт в четком соответствии с разработанными и
утвержденными макетами сцен с помощью программы менеджемта макетов
Zepplin. Т.е. визуальная часть реализуемого контента после обсуждения
деталей и, должна точно соответствовать соответствующему макету.
Точной входа в раздел транслейтов является тап по элементу бургер-
меню (CCMenuItem) «Транслейты». После тапа по пункту меню пользователь
отказывается на сцене с каталогом структур заданий типа «Транслейты».
Реализация каталога Транслейтов осуществлена в классе
TranslatesCatalogScene.cpp(.h). Замена сцен осуществляется посредством
класса SceneManager: пункт бургер меню по сути является кнопкой, а тип
сущности кнопка(CCButton) обладает методом контроля касаний
(TouchEventListener, имеющем три состояния: касание начато: движение:
касание окончено) и при окончании касания (вызов сцены реализован
посредством механизма director – LoadScene по свершении события
TouchEventListener::ENDED).
49
Рис.19. Механика смены сцен в разделе «Траснслейты»
Перед этапом проектирования происходит тщательный анализ
предъявленных к продукту требований, проверяется корректность
50
предъявленных требований, изучает документация и проверяется ТЗ. После
того, как эти пункты выполнены, и устранены все недочеты и изъяны в
формулировках, осуществляется непосредственно архитектурное
проектирование продукта. Имея опыт работы тестировщиком в компании
Паззл Инглиш, студент хорошо знаком с продуктами сервиса и конкретно с
приложением «Английский с Puzzle English». Мне известны общая,
характерная для приложения, архитектура, разделы и особенности системы
ограничений. Все вышеперечисленное, а также общение с дизайнером, тех-
лидом отдела мобильной разработки позволили реализовать процедуру
проектирования быстро и получить эргономичный продукт.
По итогам всех обсуждений студент получил от дизайнера двенадцать
макетов различных сцен раздела:
1. Макет входной сцены задания(Реализация в классе
CurrentTranslateScene.cpp).
Сцена состоит из следующих элементов:
o Отнаследованный от CCLayout TopPanel – навигационно-
информативный блок, главной целью которого является
предоставление информации о названии текущей сцены, а также в
зависимости от ситуации, вызов профиля, переход на предыдущую
сцену или закртие текущей сцены. В данном случае на нем
расположены название сцены(а именно название текущего транслейта),
кнопка возврата к каталогу транслейтов и кнопка добавления текущего
транслейта в избранное.
o Небольшой CCLayot под TopPanel’ю информативного характера: там
расположена информация о сложности текущего транслейта и
количество фраз для сборки в нем.
51
o Блок с текстом задания(scrollingText), визуально выглядящий как
полотно со скролящимся при необходимости текстом
задания(подробная реализация в подглаве 2).
o Под scrollingText находятся три кнопки, расположенные в соответствии
с дизайном: 1. «Список слов», осуществляет вызов сцены
(TRANSLATES_WORDS_AND_EXPRESSIONS_SCENE) посредством
метода SceneManager::PushScene со списком слов и выражений,
обозначенных редактором(приходят в API), которые находятся в этом
транслейте и полезны для выполнения. Список слов и выражений
содержит слово, его перевод, кнопку воспроизведения слова и кнопку
добавления в словарь; 2. Кнопку перехода к комментариям к текущему
транслейту(COMMENTS_SCENE), содержащую древовидную
структуру комментариев к текущему траснслейту и снабженную
механикой реализации базовых функций сервиса(ответы на
комментарии, оценка комментария, оставление собственного
комментария); 3. Непосредственно кнопка начала транслейта
(stratTranslate), реализованная на основе CCButton; при создании сцены
CurrentTranslateScene осуществляется проверка, находится ли
транслейт в процессе сборки (Начать/Продолжить).
2. Макет первой рабочей сцены транслейта (реализация в
TranslateWorkScene.cpp).
Сцена состоит из следующих элементов:
o TopPanel (аналогично);
o CCLayout небольшого размера динамически отображающий
прогресс сборки, содержит CCLabel’ы с информацией количества
собранных на настоящий момент фраз, общее количество фраз в
текущей сборке; тап по этому объекту осуществляет переход на
сцену собранных фраз(реализация в TranslateDonePhrasesScene.cpp,
описание приведу ниже);