62
6. Далее проверим, соответствует ли содержание этого списка выбранным
настройкам в методе getFilteredList. В зависимости от выбранных
настроек сортировки и фильтрации удалим ненужные элементы.
При тапе по блоку задания произойдет следующее:
Понадобится запросить у сервера данные по конкретному
транслейту – на вход функции запроса getFullTranslateInfo будет
подан идентификатор тапнутого транслейта.
По завершении запроса вызовется метод
onHttpFullTranslateInfoCompleted, где снова произведутся проверки
наличия ответа, проверки формата ответа, парсинг данных ответа.
Более подробно с методами можно ознакомиться в Приложении А.
По завершении проверок, парсинга и наполнения структуры
FullTranslateInfo, состоящей из полей: 1. Int progress (номер текущей
собираемой фразы), string textRu (текст задания), int userTaskId(для
определения задания на стороне сервера), Int
correctPhrasesCount(кол-ва верно собранных фраз), вектора структур
типа WordFullInfo, содержащих информацию о слове или
выражении(слово, перевод, ссылки на озвучки и видео и проч.),
вектора фраз задания, в свою очередь содержащего массив структур
типа FullTranslatePhrasesInfo (см. Приложение А), мы получим
данные, необходимые для дальнейшей корректной работы.
Пользователь, оказавшись на странице задания, сможет увидеть все
предусмотренные элементы.
Далее на сборке после ввода перевода текущей фразы, по нажатию
на кнопку «Отправить ответ» происходит очередной запрос к
серверу типа post: отправляем на сервер строку, введенную
пользователю для сравнения с вариантами ответов, заготовленных
редакторами (requestCheckAnswer, где входными параметрами
являются идентификатор задания, номер фразы, введенная строка).
63
OnHttpRequestChectAnswerComplited – проверим наличие ответа и
валидность данных, создадим строку, куда сохраним ответ,
создадим документ, куда расшифруем строку, распарсим и выведем
результат проверки на экран.
Повторим предыдущий пункт для всех фраз, запросим результат
выполнения задания (для всех сценариев имеем наполненные
структуры для отображения таких данных, как например, комментарии
редактора при ошибке).
После сборки всех фраз задания выполним новый запрос к
серверу по идентификатору задания для получения результатов –
requestFullTranslateInfoDone и по аналогии с ранее описанными
методами onHttpRequestComplited соберем и проверим нужную
информацию, для того, чтобы вывести ее обновленную на
финальной сцене задания.
Обобщение по пункту 2:
Большинство данных и вычислений хранятся и производятся на
стороне сервера, это позволяет экономить память устройства и не
уменьшать быстродействие. Стандартная модель взаимодействия
происходит по следующему сценарию:
Формируется запрос, производится поэтапная валидация ответа,
настраиваются callback’и для возврата данных в вызывающий метод,
парсинг и наполнение нужных структур. Метод парсинга возвращает
значение в метод onHttpRequestComplited, который в свою очередь
возвращает данные, готовые к работе. Производимые проверки
гарантируют наличие валидных данных.
Листинг класса TranslatesAPIManager приведен в Приложении А.
64
Рис. 22. Иллюстрация запроса и обработки данных от сервера.
65
Функциональные классы.
В основном целью этих классов является мониторинг состояний
данных, осуществление логики продуктов и вызовы нужных сцен. Рассмотрю
функциональные классы реализации раздела транслейтов на примере самого
интересного класса TranslateWorkScene:
При создании сцен первым выполняется метод init. Здесь создаются
элементы интерфейса и получение данных для работы(TranslatesAPIManager
хранит нужные данные, и их можно получить через геттер, обращаясь к
образцу класса).
Создадим TopPanel.
Имеем глобальные переменные нужных типов(TranslateInfo и
FullTranslateInfo, для работы понадобятся поля обеих структур),
осуществляем запрос и присвоение данных для работы.
Проведем проверку, какую фразу выдать на сборку
(TranslateInfo.current_piece_index) и присвоим значение переменной для
вывода пользователю строки с текущим номером фразы.
На основе CCLayerColor, CCLayout и CCScrollView создадим блоки-
родители, на которых разместим остальные элементы(CCLayerColor –
фон-родитель, на него помещу CCLayer – прогресс-бар и под ним
размещу CCScrollView – расширяющийся при необходимости по
вертикали рабочий блок).
Вызову методы обновления блоков для корректного отображения
текущих данных(методы showProgressBar и showWorkBody).
Метод showWorkBody получает на вход int номер фразы, bool первая или
вторая проверка, string текст, введенный пользователем.
Сначала очистим scroll.
66
Реализуем проверку, выполняется ли задание из Личного Плана (как
описано в первой главе, если пользователь проходит задание из
Личного Плана, то на время выполнения он освобожден от
ограничений)
Создадим CCLabel’ы для отображения номера текущей фразы,
используя входной параметр int num, и выведем фразу на русском.
Проверим, не равно ли нулю поле поле структуры hints структуры
FullTranslatePhrasesInfo, являющееся в свою очередь полем структуры
FulltranslateInfo равным нулю (если да, то слов-подсказок нет, и блок
подсказок не требуется создавать). Если нет, то создадим блок
подсказок CCLayout и в новом цикле создадим CCLabel’ы со словами-
подсказками.
Рис. 23. Иллюстрация полей структур FullTranslatePhrasesInfo и FullTranslateInfo.
Повторим цикл создания слов-подсказок количество раз равное
размеру вектора hints структуры FullTranslatePhrasesInfo.
67
Создадим CCEditBox, куда пользователь будет вводить свой перевод.
Добавим проверки для эдитбокса на пустое значение и наличие
недопустимых символов.
Создадим кнопку отправки ответа на проверку.
После получения ответа, очистим скролл и, в зависимости от результата
проверки, наполним контентом(Рис. 19 и описание ТЗ).
При неверном переводе во второй раз вызовется метод
showChectResultIncorrect, который принимает на вход номер фразы, текст,
введенный пользователем и структуру CheckResultFull, поле которой
isCorrectPhrase необходимо для выполнения проверки, какого типа блок
нужно будет создать (ошибки или неточности определят цвет и один из
CCLabel’ов на блоке).
Создадим CCLayout, на котором отобразим введенный пользователем
перевод с индикацией ошибок. Для этого в цикле создадим ряд кнопок,
на котроые поместим слова. В теле цикла произведем ряд проверок, по
итогам которых определится цвет слова и вывод троеточий на месте
пропусков. Не забудем отслеживать размер и позиции кнопок для
корректного переноса на следующую строку(Рис. 24.).
Рис. 24. Иллюстрация к описываемому моменту наполнения сцены.
68
Выведем в цикле подсказки, путем извлечения данных из поля
структуры FullTranslateInfo[i].hints, где i порядковый индекс в векторе
строк-вариантов перевода, если оно не пустое.
Создадим кнопку «Показать результат», по окончанию тапа по
которой вызовется метод ShowWorkBody, куда передадим номер
следующей фразы.
Обобщение:
- При создании классов и структур нужно четко понимать, какие
действия они будут совершать, и какие данные будут хранить.
- Манипуляции со сценами происходят посредством класса
SceneManger, работающего по принципу Director’а.
- При позиционировании важно корректно расставлять анкор поинты
объектов и выставлять относительные величины, чтобы разрешение
экрана девайса не влияло на позицию нода на сцене.
- При объявлении глобальных переменных и объектов нужно
задуматься, требуется ли это(локальные данные существуют только
пока работает метод, глобальные занимают место в памяти до
завершения программы).
- Для облегчения работы необходимо пользоваться доступными фичами
новых стандартов языка (лямбда выражения, автоопределение типов,
итераторы и проч.).
3.3. Тестирование, релиз, поддержка
Этот раздел ВКР запланировано небольшого размера в связи с тем, что
производственная и преддипломная практики были посвящены теме
тестирования, в т.ч. подготовке к релизу раздела транслейтов в веб-проекте.
В связи с этим, кратко основные моменты и тезисы:
69
Тестирование является крайне важным этапом в жизни продукта, т.к.
корректная работа (и отсутствие некорректного поведения, сбоев и багов)
благоприятно влияет на мнение пользователей о продукте, на что в конечном
итоге направлены усилия членов команды. Также часто это положительно
влияет на монетизацию проекта.
Во время разработки раздела транслетов для мобильного проекта было
обнаружено множество багов, некорректного поведения, логических,
проектировочных и дизайнерских упущений. Некоторые из них были
ликвидированы на этапе подготовки, некоторые – разработки, а какие-то –
только после релиза. Приведу несколько примеров:
Первая версия дизайна сцены сборки фраз транслейта была
сильно перегружена, было решено ее упростить.
На этапе проектирования была упущена сцена собранных фраз:
студент не знал, что тап по прогресс бару должен осуществлять
переход на сцену собранных фраз, а дизайнер забыл загрузить
макет.
Во время отладки было замечено и исправлено множество багов,
в т.ч. серьезных, приводящих к самому нежелательному исходу –
крашу. Наиболее частой причиной такого бага являлись
обращения к несуществующим элементам массивов.
При запуске приложения на симуляторе девайса с малым
разрешением экрана(iphone 4), «поплыла верстка», обнаружилось
некоторые элементы UI плохо запозиционированны.
Для проведения ручного тестирования релиз-канидата, было совершено
множество юнит-тестов и интеграционное тестирование. В особенности было
уделено внимание вхождение раздела в систему абонементов и ограничений.
(задания: 20 бесплатных фраз, вывод сцены ограничения при их окончании;
проверка отсутствия ограничений при прохождения траслейта из личного
70
плана, не в зависимости от наличия подписок; проверка отсутствия
ограничений для пользователей тарифа «Все включено» и проч.).
Во время ручного тестирования рк также был обнаружен ряд багов
minor’ного характера, связанных с позиционированием. Самым заметным
оказался неправильно высчитываемый индекс обращения к ссылке на
аудиофайл воспроизведения диктором слова в списке рекомендуемых к
изучению слов(краша не было в связи с проверками, упреждающими такие
обращения). Также наблюдались незначительные проблемы комментариями
в сборке андроид-проекта. Проблем при регрессионном тестирование после
интеграции раздела транслейтов не ожидалось, однако процесс
предрелизного тестирования состоит из нескольких групп чек листов, т.е. все
было проверено. Все замеченные багги были исправлены в сроки, новая
версия приложения, помимо раздела с транслейтами содержащая крупную
доработку по другому разделу, прошла модерацию и была опубликована в
сторах.
После публикации новой версии, посредством обращений пользователей в
техподдержку были обнаружены еще два незначительных бага, связанных с
выводом лишних троеточий при ошибках на сценах результата проверки и
финала задания, а также отсутствие блока с комментариями редактора при
определенных условиях. Второй баг был устранен, а первый должен быть
исправлен разработчиком API.
Вывод по третьей главе.
Глава содержит подробное описание процесса разработки, начиная с
проектирования и заканчивая поддержкой продукта. Приведены описания
модели проектирования, с учетом описанных в главе 1 особенностей сервиса
в целом и приложения в частности. Рассмотрены реализации и применения
механизмов, теоретическое рассмотрение которых было приведено в главе 2.
Насколько позволяет формат работы, подробно описаны процессы клиент-
71
серверного взаимодействия раздела и логика главного функционального
класса. Подведено резюме процесса тестирвоания.
Глава содержит описания классов, с помощью которых реализован раздел
транслейты, описано общее назначение спроектированных методов.
Выбраны два класса для подробного описания реализации, где
продемонстрирована способность применять на практике описанные в главе
2 особенности языка и движка. Глава содержит необходимые графисеские
иллюстрации к описываемым объектам и процессам.