Пример работы 2 (docx) - Казанский (Приволжский
advertisement
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
КАЗАНСКИЙ (ПРИВОЛЖСКИЙ) ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ
ВЫСШАЯ ШКОЛА ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И
ИНФОРМАЦИОННЫХ СИСТЕМ
Направление подготовки: 230700 – Прикладная информатика
ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА
ТЕМА
Работа завершена:
«___»_____________201 г.
Студент группы ______
____________________ И.О.Фамилия
Работа допущена к защите:
Научный руководитель
ученая степень, должность
«___»_____________201 г.
____________________ И.О. Фамилия
Директор Высшей школы ИТИС
«___»_____________201 г.
__________________ А.Ф. Хасьянов
Казань – 201 г.
1
Содержание
Введение ................................................................................................................... 4
1. Постановка задачи ............................................................................................ 7
1.1
Технология разработки мобильного приложения ................................... 7
1.3
Техническое задание ................................................................................ 11
2. Платформа Windows Phone 8 ......................................................................... 16
2.1
Архитектура платформы .......................................................................... 16
2.2
Безопасность Windows Phone .................................................................. 20
2.3
Ядро ............................................................................................................ 22
2.4
Windows Runtime ...................................................................................... 23
2.5
Инструменты для разработки .................................................................. 24
2.6
Пользовательский интерфейс платформы ............................................. 24
2.7
Структура проекта Windows Phone ........................................................ 25
2.8
Жизненный цикл приложения................................................................. 26
2.9
Model-View-ViewModel (MVVM)........................................................... 28
3. Реализация приложения ................................................................................. 31
3.1
Модель базы данных ................................................................................ 31
3.2
Реализация архитектуры клиент-серверного приложения................... 34
3.3 Использование QR-кодов. Использование камеры для сканирования
QR-кода ............................................................................................................... 39
3.4
Работа с картой ......................................................................................... 40
4. Интерфейс и функционал ............................................................................... 41
4.1
Стартовая страница .................................................................................. 47
4.2
Страница Новое событие ......................................................................... 51
4.3
Страница Настройки ................................................................................ 53
4.4
Страница информации об институте ...................................................... 53
4.5
Страница карты ......................................................................................... 56
4.6
Страница Настройки карты. .................................................................... 58
4.7
Страница информации о кафедре ........................................................... 59
4.8
Страница камеры ...................................................................................... 60
2
4.9
Страница результата сканирования ........................................................ 61
5. Тестирование ................................................................................................... 63
6. Магазин приложений Windows ..................................................................... 65
Заключение ............................................................................................................ 66
Список использованных источников .................................................................. 70
Приложение ........................................................................................................... 72
3
Введение
В современном мире трудно представить жизнь без мобильного телефона. Они стали неотъемлемой частью нашей жизни. Смартфоны с их
огромным функционалом и различными сенсорами делают нашу жизнь гораздо проще. А производители смартфонов и разработчики программного
обеспечения все чаще радуют нас дешевыми, но довольно-таки мощными
устройствами. Теперь не обязательно идти в магазин за газетой, чтобы узнать
новости, даже не обязательно вставать с постели, чтобы зайти в интернет, достаточно просто протянуть руку к смартфону и у тебя появится доступ к неограниченному объему информации.
В связи с популярностью смартфонов, разработка программного обеспечения для них, стала одним из востребованных направлений на рынке. На
данный момент существует огромное количество различных мобильных приложений, выполняющих совершенно разные функции. Перед разработчиками
открываются огромные возможности для разработки своих приложений, ведь
они получают доступ к различным датчикам, которых нет на компьютере, таких как: гироскоп, компас, акселерометр и т.д. Одна только камера, установленная на мобильном устройстве, открывает огромный простор для фантазии
разработчика.
Разработка идеи мобильного приложения не так проста, как может показаться на первый взгляд. Приложение должно быть актуальным и решать
проблему пользователя. Приложение «KFU Guide» предназначено для решения проблемы с навигацией по Казанскому Федеральному Университету и с
доступом к наиболее актуальным событиям университета.
В связи с расширением, которое произошло совсем недавно, структура
нашего университета претерпела значительные изменений. Большинство факультетов стали институтами, многие переименовались, некоторые переехали
в другие здания. В итоге подразделения нашего огромного университета рас4
кинулись по всему городу, и ориентироваться в них стало намного труднее,
чем раньше. Вследствие этого, одной из наших задач стала реализация приложения, которое помогло бы нашим студентам, преподавателям, абитуриентам, а так же гостям нашего университета легко ориентироваться в нашем
огромном университете.
Актуальность выбора мобильной платформы. По данным статистических исследований наиболее популярными мобильными платформами являются Android, iOS и Windows Phone. Они занимают 98,7% всего рынка мобильных операционных. По данным аналитической компании Strategy
Analytics за 3-й квартал 2013 года Windows Phone признана самой быстрорастущей мобильной операционной системой. Доля рынка для данной платформы за год увеличилась почти в 2 раза. Еще один аргумент в пользу выбора
платформы Windows Phone – рынок мобильных приложений еще не настолько велик, как у Android и iOS, вследствие чего там намного легче найти свободный сегмент.
На фоне современных тенденций было принято решение о создании
клиент-серверного мобильного приложения «KFU Guide» для платформы
Windows Phone 8 для Казанского Федерального Университета с использованием технологии сканирования и расшифровки QR-кодов.
Приложение создано на базе 3 платформ: Android, iOS и Windows
Phone 8, с использованием удаленного сервера, разработанного с помощью
фреймворка Ruby On Rails.
Цели дипломной работы:
1. Проектирование архитектуры и интерфейса мобильного приложения, удовлетворяющие общим стандартам платформы Windows
Phone 8.
2. Сбор и анализ информации о подразделениях университета и расписании аудиторий. Организация хранения и работы с данными.
3. Проектирование архитектуры взаимодействия клиента и сервера.
5
4. Разработка приложения «KFU Guide» и его публикация в магазине
приложений Windows.
6
1. Постановка задачи
1.1 Технология разработки мобильного приложения
Была поставлена задача о разработке мобильного приложения для трех
платформ: Android, iOS, Windows Phone. Теперь необходимо определить, какой подход к написанию мобильных приложений наиболее подходящий для
реализации наших целей.
Существует различные подходы к написанию мобильного приложения:
web-приложение, нативное мобильное приложение, гибридное приложение.
Рассмотрим плюсы и минусы каждого подхода.
1.1.1 Web–приложение
Мобильное web–приложение – это сай
, адаптированный для просмотра на мобильном устройстве. Пользовательский интерфейс, интерактивные объекты создаются с помощью классических web-технологий, таких как JavaScript, HTML, CSS. Такие приложения
открываются в обычном браузере телефона и всегда требуют подключения к
интернету.
Плюсы:
Важнейшим плюсом в данном подходе является кроссплатформенность – возможность работы на всех устройствах без дополнительной адаптации.
Не требует загрузки из магазина мобильных приложений.
Нет ограничений на продажу контента.
Обновления вступают в силу немедленно, после внесения изменений.
Минусы:
7
Приложение всегда требует подключение к интернету.
Вне зависимости от платформы, web-приложение никогда не имеет
доступ к системным возможностям смартфона. Оно не может использовать ни датчики, ни камеру, ни любое другое программное
обеспечение смартфона.
При продаже контента требуется использовать свою платежную систему.
Web-приложение существенно уступает по интерактивности нативному приложению.
Мобильное web-приложение подходят для адаптации сайта для отображения на мобильных устройствах.
1.1.2 Нативное мобильное приложение
Нативные приложения – приложения, разрабатывающиеся под конкретную платформу. Такое приложение поставляется через специальные магазины для приложений.
Плюсы:
Нативное приложение может в полной мере использовать все возможности устройства. У них есть доступ ко всем сенсорам, камере,
галерее, телефонной книге и т.д.
Приложение такого типа будет наиболее точно соответствовать стилистике конкретной операционной системе, что тоже очень важно,
так как пользователя может сбить с толку неочевидный и неожиданный пользовательский интерфейс.
Нативное приложение наиболее производительное, так как оно оптимизировано под архитектуру конкретной операционной системы.
Нативное приложение может функционировать без подключения к
интернету.
8
Приложение поставляется из официальных магазинов, что внушает
пользователю наибольшее доверие.
Для нативных приложений не обязательно писать свою платежную
систему. Чаще всего они использую платежную систему компании,
производящей операционную систему.
Минусы:
Для каждой платформы приходится писать свое решение.
Обновление приложение так же проходит контроль перед публикацией, что оттягивает выход обновления.
Приложение может стоить дороже, чем другие версии, так как от
разработчиков требуются знания различных технологий для каждой
платформы.
При продаже приложения, компании-производители операционных
системы берут комиссию в 30% от продажи приложения.
Нативные приложения наиболее предпочтительный вариант, так как
они в полной мере могут использовать все возможности операционной системы и наиболее точно отражают все тонкости пользовательского интерфейса, характерного для конкретной платформы.
1.1.3 Гибридное приложение
Компромиссный вариант между web-приложение и нативным решением. Оно идеально подходит для тех, кто хочет пользоваться средствами webразработки, но кому так же нужен доступ ко многим системным функциям
мобильной операционной системы. Приложение пишется с помощью средств
web-разработки, а потом транслируется на нативные языки платформы.
Плюсы:
Кроссплатформенность. Достаточно написать один код, для большинства платформ.
9
Гибридные приложения имеют доступ к различным системам
устройства.
Разработка обходится дешевле, чем разработка нативного приложения для каждой мобильной операционной системы.
Приложение работает быстрее, чем web-приложение.
Поставляются из официальных магазинов на ряду с нативными приложениями.
В зависимости от платформы, могут применятся различные стили
приложения.
Минусы:
Гибридные приложения получают доступ к системным функциям
устройства с помощью различных плагинов, которые, в свою очередь, ничто иное, как JavaScript обертка для нативного кода платформы. Это значительно снижает производительность приложения.
Стиль приложения может и меняться, но вот логика приложения
остается прежней, вне зависимости от платформы. Что может не соответствовать принципам пользовательского интерфейса определенной платформы.
Гибридные приложения не смогут воспроизвести все особенности
пользовательского интерфейса и общего стиля платформы.
Гибридные приложения выглядят привлекательно с точки зрения кроссплатформенности, простоты написания и возможности использования системных функций платформы. Но со стороны производительности и пользовательского интерфейса гибридные приложения все равно уступают нативным решениям.
1.2 Вывод
После анализа плюсов и минусов трех подходов разработки мобильных
приложений, для наиболее быстрого и оптимизированного приложения, ис10
пользующего различные сенсоры смартфона, решено было создать нативные
приложение, позволяющее наиболее эффективно использовать все ресурсы
платформ и создавать типизированный интерфейс для каждой платформы.
1.3 Техническое задание
1.3.1 Общие сведения
1.3.1.1 Полное наименование системы
Мобильное клиент-серверное приложение «KFU Guide» для операционной системы Windows Phone.
1.3.1.2 Краткое наименование системы
Мобильное приложение «KFU Guide» для платформы Windows Phone.
1.3.2 Назначение и цели создания системы
1.3.2.1 Назначение системы
Приложение «KFU Guide» предназначено для упрощение навигации по
Казанскому Федеральному Университету и повышения оперативности доступа к последним событиям, проводящимся в стенах университета.
1.3.2.2 Цели создания системы
Приложение «KFU Guide» создается с целью:
Обеспечения быстрого доступа к информации о подразделениях
университета, такой как местоположение зданий университета на
карте города, адреса директоратов институтов, контактная информация подразделений университета;
Предоставления информации о занятости аудиторий в зданиях университета;
Обеспечения быстрого доступа к событиям университета;
В результате создания приложения «KFU Guide» должны быть улучшены следующие показатели:
Скорость доступа к информации о подразделениях университета;
11
Скорость доступа к информации о мероприятиях университета и
время на организацию мероприятий в аудиториях;
Удобство ориентирования на территории университета.
1.3.3 Требования к системе
1.3.3.1 Требование к системе в целом
1.3.3.1.1 Требование к структуре и функционированию системы
В системе выделены следующие функциональные подсистемы:
Подсистема сканирования и обработки Qr-кодов. Предназначена для
быстрого доступа к информации об объекте, находящегося рядом с
пользователем;
Справочно-информационная подсистема. Предназначена для хранения, обработки и предоставления информации;
Подсистема UGC (user-generated content). Предназначена для отображения информации о мероприятия, сгенерированной пользователями.
Система является частью архитектуры клиент-сервер, где клиентами
выступают мобильные приложения для платформ Android, iOS и Windows
Phone. Связь между клиентами и сервером на транспортно-сетевом уровне
осуществляется по протоколу TCP/IP. Для организации информационного
обмена используется протокол прикладного уровня HTTP и его расширение
HTTPS. Взаимодействие осуществляется согласно архитектуре REST.
1.3.3.2 Показатели назначения
1.3.3.2.1 Требования к приспособляемости системы к изменениям
Обеспечение приспособляемости системы должно выполняться за счет
Своевременного обновления информации о подразделениях;
Модернизации архитектуры и интерфейса в соответствии с новыми
требованиями;
Своевременного администрирования сервера;
Оперативного реагирования на пожелания пользователей.
12
1.3.3.3 Требования к надежности системы
Надежность должна обеспечиваться за счет:
Применения технических средств соответствующих классу решаемых задач;
Тщательного тестирования программного продукта перед публикацией в магазин;
Использования проверенного программного обеспечения для разработки приложения.
1.3.3.4 Требования к эргономике и технической эстетике
Приложение должно предоставлять пользователю удобный и интуитивно понятный интерфейс для быстрого доступа к информации. Интерфейс
приложения должен соответствовать общей стилистике платформы.
1.3.3.5 Требования к информационной безопасности системы
Информационная безопасность в приложении осуществляется за счет:
Использования защищенного протокола HTTPS для передачи информации о пользователе на сервер;
Регистрация и авторизации на сервере происходит через социальные
сети с использованием официальных API;
Приложение не сохраняет информацию о логинах и паролях, используемых пользователем для авторизации в социальных сетях.
1.3.4 Требования к функциям, выполняемым системой
1.3.4.1 Подсистема сканирования и обработки QR-кодов
Выполнение сканирования QR-кодов;
Декодирование QR-кодов;
Получение и отображение информации в зависимости от результата
декодирования.
1.3.4.2 Информационная подсистема
Хранение информации о подразделениях и сотрудниках университета;
13
Предоставление информации по запросу;
Обеспечение целостности информации;
Обеспечение корректного отображения информации.
1.3.4.3 Подсистема UGC (user-generated content)
Обеспечение корректного взаимодействия с сервером;
Сохранение сессии пользователя;
Обеспечение корректного отображения информации о мероприятиях университета.
1.3.5 Требования к информационному обеспечению
Информация должна быть получена из надежных источников и своевременно обновляться. Информация, которая редко претерпевает изменения
хранится во встроенной базе данных, для экономии интернет-трафика пользователя. Информация, которая постоянно обновляется пользователями и
должна быть общедоступной, хранится в базе данных на удаленном сервере.
Структура данных должна быть организована так, чтобы поиск информации осуществлялся как можно быстрее.
1.3.6 Требования к лингвистическому обеспечению
При реализации системы должен применяться язык высокого уровня
C# и язык разметки XAML.
Для реализации заполнения базы данных необходимо использовать
стандартный язык запросов SQL.
Для кодирования и декодирования данных для обмена с сервером применяется кодировка UTF-8. Данные с сервера должны быть получены в формате JSON.
Для организации диалога пользователя и системы должен применяться
графический пользовательский интерфейс, соответствующий стандартам мобильной платформы Windows Phone.
1.3.7 Требование к программному обеспечению
14
Разработка приложения должна происходить на компьютере с установленной операционной системой Windows 8, в среде разработки Visual Studio
2012 и с использование Windows Phone 8 SDK. База данных, используемая
для хранения статичной информации внутри приложения, должна быть нативной базой данных для платформы, а именно SQL CE.
1.3.8 Состав работ по созданию системы
2. Проектирование архитектуры и интерфейса приложения;
3. Сбор информации о подразделениях университета;
4. Реализация основных функций для доступа к информации об институтах, реализация сканирования QR-кодов;
5. Оптимизация и тестирование первой версии приложения;
6. Публикация первой версии приложения в магазин приложения Windows;
7. Получение списка учебных зданий. Получение средств для доступа
к расписанию аудиторий зданий университета;
8. Организация взаимодействия с сервером: получение списка мероприятий, регистрация и авторизация на сервере, публикация новых
событий и получение списка свободных аудиторий;
9. Оптимизация и тестирование приложения;
10.Выпуск финальной версии приложения.
15
2. Платформа Windows Phone 8
Платформа Windows Phone 8 принадлежит к линейке Windows NT, что
означает, что она основана на одном ядре с настольной операционной системой Windows 8. Это открывает доступ мобильной операционной системе к
мощностям, доступным обычной настольной операционной системе. Ядро
Windows NT прекрасно оптимизировано для работы с многоядерными процессорами, имеет возможность обращения к сменным носителям и многое
другое.
2.1 Архитектура платформы
На рисунке 1 изображена архитектура платформы Windows Phone 8.
Рассмотри подробнее, что означают компоненты архитектуры.
Рисунок 1, архитектура платформы Windows Phone
TaskHost и CoreApplication – две различные модели приложений.
TaskHost – модель приложений, реализованных с помощью XAML разметки.
Этот подход был основным еще с запуска первой версии платформы Windows Phone 7. CoreApplication представляет новую модель приложений на
Windows Phone 8, которая основана на модели приложений для Windows 8. В
выпуске для Windows Phone 8 эта модель поддерживает возможности натив16
ных приложений с использованием Direct3D для пользовательского интерфейса.Win32/Com могут быть использованы в управляемых приложениях, а
так же если они обернуты в пользовательский компонент Windows Runtime.
Эти две модели приложений базируются на основных сервисах платформы:
Package Manager
Package Manager отвечает за установку и удаление приложений, за сохранение всех метаданных приложений на протяжении всего периода жизни
приложения. Он не только следит за тем, какие приложения были установлены и аттестованы, но и сохраняет информацию обо всех плитках приложений, которые пользователь закрепил на начальном экране и обо всех местах,
где приложение может отображаться.
Execution Manager
Execution Manager контролирует всю логику, связанную с выполнением
приложения на протяжении всего жизненного цикла приложения. Он создает
хостинг-процесс для исполнения приложения и вызывает события, связанные
со стартом / выключением / деактивацией приложения. Он выполняет аналогичную задачу для фоновых процессов приложения, а так же определяет
надлежащий порядок их выполнения.
Navigation Server
Navigation Server управляет переключением между активными приложениями на телефоне. Когда пользователь нажимает на иконку приложения
на стартовом экране, он переходит со стартового экрана к приложению, которое выбрал. Navigation Server отвечает за передачу намерения в Execution
Manager, чтобы выбранное приложение могло запуститься. Также, когда
пользователь нажимает и удерживает кнопку Назад и выбирает приложение,
которое запускал до этого, Navigation Server сообщает в Execution Manager,
какое приложение должно быть реактивировано.
Resources Manager
17
Resources Manager отвечает за обеспечение быстроты и отзывчивости
интерфейса. Он следит за использованием системных ресурсов всеми активными процессами, особенно за использование центрального процессора и
памяти, и ограничивает количество этих процессов. Если приложение или
фоновый процесс превышает отведенный пул ресурсов, то он завершается.
Все это лежит на вершине объединенного ядра Windows.
Windows Phone 8 поддерживает несколько различных типов приложений, описанных в таблице 1.
Таблица 1, типы приложений Windows Phone
Тип
Поддержи-
UI
Поддерживае-
прило-
ваемые
Frame-
мые API
жения
языки
work
XAML
Описание
Наиболее
тип
общий C#
XAML
приложений Visual Basic
Microsoft .NET
Windows Phone
для Windows Phone
API
7.x. Эти приложе-
Windows
ния
Runtime API
написаны
только с помощью
XAML и управляемого кода.
Сме-
Эти приложения
С#
шанный
следуют структуре
Visual Basic Direct3D
Phone API
тип
приложений
C/C++
Windows
XAML
(via Draw-
.NET Windows
XAML, но позво-
ing Surface Runtime API
ляют добавлять
)
Win32/COM
код на C/C++,
API (в пределах
обернутый в ком-
компонент
понент Windows
Windows
18
Продолжение таблицы 1
Runtime.
Runtime)
Это хорошо подходит для приложений, в которых
необходимо
ис-
пользовать
суще-
ствующую
биб-
лиотеку С/C++.
Это так же полезно
в случаях, когда
нужно
написать
большую
часть
приложения
С/С++
на
(включая
Direct3D), но так
же нужен доступ к
XAML UI Framework и к особенностям, которые доступны только в
XAML
приложе-
ниях,
например
возможность
здавать
со-
живые
плитки на начальном экране.
Direct3D
Подходит для игр.
Чистые нативные
C/C++
Direct3D
Windows
Runtime API
19
Продолжение таблицы 1
приложения,
ис-
пользующие
Win32/COM
API
Direct3D могут извлекать
макси-
мальную производительность
смартфона. Кроме
того,
поскольку
этот тип приложений
основан
модели
на
приложе-
ний Windows, он
обеспечивает
наибольшую
сте-
пень совместимости
кода
между
Windows и Windows Phone.
2.2 Безопасность Windows Phone
Современные смартфоны хранят очень много личной информации
пользователя. Эта информация должна быть хорошо защищена.
Модель безопасности Windows Phone основана на модели контейнеров
безопасности – изолированные контейнеры, в которых процесс создается и
выполняется. Права доступа к контейнерам предоставляются системой. Система предоставляет права по старому принципу наименьших привилегий,
что означает, что приложение не имеет доступа ни к чему, кроме того, что
необходимо для выполнения поставленных функций. Например, приложение
20
почты не может произвольно открыть камеру, так как это не является его основной функцией.
Каждый контейнер начинается с ограниченного набора привилегий,
достаточных для написания самостоятельного приложения, такого как калькулятор или простая игра, но недостаточных для использования всех функций смартфона. Если приложению нужно использовать дополнительные
функции смартфона, такие как контакты пользователя или определения местоположения, эти функции должны быть явно указаны в списке Возможностей, который изображении на рисунке 2. Список Возможностей используется как набор механизмов контроля доступа к функциям смартфона. Система
должна явно предоставить доступ к контейнеру.
При разработке приложения разработчик сам указывает функции, которые ему необходимы для создания приложения.
Рисунок 2, список возможностей приложения Windows Phone
21
Все возможности смартфона, которые необходимо использовать в приложении, отображаются в магазине на странице приложения, и тогда пользователь сам может решить, хочет ли он давать доступ вашему приложению к
необходимым возможностям и установить ваше приложение или нет.
2.3 Ядро
Как уже было сказано, платформа Windows Phone 8 получила общее
ядро с настольной Windows 8. На самом деле, ядро содержит два разделенных компонента. Первый компонент – Системное ядро Windows, которое
включает в себя основные функции ОС Windows, в том числе ядро NT, файловая система NT (NTFS) и сетевой стек. Это минимальное ядро, которое является результатом совершенствования архитектуры в течение многих лет,
целью которого было обеспечить общую базу для разных типов устройств, в
том числе и для смартфонов.
Над системным ядром собран набор функций Windows, которые не
входят в ядро, но так же доступны для смартфонов. Это такие компоненты,
как Мультимедиа, CoreCRL, DirectX и Trident – движок рендеринга для Internet Explorer. Этот набор – Мобильное Ядро – это отдельный архитектурный
объект для Windows Phone. Windows содержит те же компоненты, что и мобильное ядро Windows Phone, но они являются частью более широкого набора функциональных возможностей. Это обозначено пунктиром на рисунке 3.
Системное ядро и Мобильное ядро представляют объединение Windows и Windows Phone 8, когда две операционные системы выполняют один
и тот же код.
22
Рисунок 3, состав ядра Windows Phone 8, Windows 8
2.4
Windows Runtime
Для потребителей наиболее радикальным изменением в Windows 8 является интерфейс, а для разработчиков - это новая модель программирования и набор API(application programming interface – интерфейс прикладного
программирования), общеизвестный как Windows Runtime. Windows Runtime
представляет собой не просто набор новых функций и возможностей, но и
принципиально новый подход к разработке приложений и компонент для
Windows. Она является основой для разработки приложений магазина Windows.
Платформа Windows Runtime основана на Component Object Model
(COM – Объектная модель компонентов), дополненной детальными метаданными, описывающими каждый компонент. Эти метаданные позволяют методам и компонентам Windows Runtime быть легко переносимыми в разные
среды программирования, построенные на них. В Windows Phone существуют две таких среды: CoreCRL – основная версия .Net(C# или Visual Basic) и
чисто нативный код (С/С++).
23
2.5
Инструменты для разработки
Для разработки приложений под Windows Phone 8, компания Microsoft
предоставила бесплатный набор инструментов разработчика Windows Phone
8 SDK. Он включает в себя
Microsoft Visual Studio 2012 Express для Windows Phone – среда разработки программного обеспечения.
Microsoft Blend 2012 Express для Windows Phone – среда для построения пользовательского интерфейса. Необходима для реализации нетривиальных задач дизайна пользовательского интерфейса приложения.
Эмулятор устройства на платформе Windows Phone 8 – необходим для
тестирования приложений.
Шаблоны проектов, ссылки на сборки, библиотеки и заголовки библиотек.
Эмулятор устройства основан на последний версии Microsoft Hyper-V,
который требует 64-х битный ЦПУ, который поддерживает технологию SLAT(Second Level Address Translation – преобразование адресов
второго уровня), технология виртуализации памяти, поддерживаемая
большинством современных процессоров.
2.6
Пользовательский интерфейс платформы
Пользовательский интерфейс Windows Phone основан на концепции
минимализма. Майкрософт придерживается принципа: главное место в пользовательском интерфейсе должна занимать важная информация, за которой
пользователь обратился к устройству. Все остальные элементы интерфейса
либо не нужны, либо должны отойти на второй план. Основу пользовательского интерфейса составляют динамические плитки (Tiles), которые отображают динамически меняющуюся важную информацию. В начале своего существование этот стиль назывался Metro, но в 2012 году компания Майкрософт приняла решение больше не использовать этот термин. В настоящий
24
момент, приложения, созданные в этом стиле, называют – приложения магазина Windows .
2.7
Структура проекта Windows Phone
Главным и самым важным файлом проекта является WMAppManifest.xml. Он содержит всю важную информацию, которую операционная система
должна
знать
о
приложении.
Некоторые
пункты
в
WMAppManifest.xml, например системные требование, используются в процессе принятия приложения в магазин Windows Phone. Манифест включает в
себя:
Название приложения;
Иконки приложения для начального экрана и для списка приложений;
Поддерживаемые разрешения приложения;
Список требований к оборудованию, которое необходимо приложению для выполнения своих функций. Например, наличие камеры;
Список возможностей, которые необходимы приложению для выполнения его функций. Например, доступ к галерее фотографий
пользователя.
В Visual Studio 2012 доступен графический интерфейс для редактирования Манифеста приложения.
Папка Assets (Активы) предоставлена для хранения изображений, необходимых для приложения.
Файлы Resources\AppResources.resx и LocalizedStrings.cs обеспечивают
платформу для локализации приложения.
App.xaml обеспечивает удобное расположение для хранения ресурсов,
которые необходимы для приложения. Например, стили элементов управления. App.xaml.cs содержит код, обеспечивающий запуск приложения, а так
же обработчики событий жизненного цикла приложения. Для того чтобы
25
определить события при открытии или закрытии приложения, перехода приложения в паузу или возобновления приложения, нужно заполнить уже сгенерированные обработчики этих событий.
Приложение Windows Phone состоит из страниц, по которым происходит навигация. Начальную страницу можно так же указать в Манифесте приложения. По умолчанию, начальная страница называется MainPage.xaml и
генерируется автоматически с общим шаблоном страницы приложения.
Это основные составляющие каждого приложения для Windows Phone.
Структура может изменяться в зависимости от парадигмы программирования, которой пользуется разработчик.
2.8 Жизненный цикл приложения
В жизненном цикле Windows Phone приложения существует три состояния. В каждый момент времени приложение может быть, либо Не запущено,
либо Запущено, либо Приостановлено, что проиллюстрировано на рисунке 4.
Рисунок 4, жизненный цикл приложения.
2.8.1 Активация/Запуск приложения
Приложение может быть запущенно только тогда, кода оно находилось
в состоянии Не запущено. При запуске приложения отображается экран26
заставка, во время которого приложение должно инициализировать пользовательский интерфейс – должна произойти регистрация обработчиков событий и расстановка элементов управления пользовательского интерфейса, которые приложение должно загрузить. Это время не должно превышать пяти
секунд, иначе приложение вообще не будет запущенно. Для того чтобы добавить дополнительные действия при запуске приложения, необходимо заполнить метод Application_Launching, инициализированный в файле App.xaml.cs.
2.8.2 Возобновление приложения
Приложение может быть возобновлено, если оно находилось в состоянии Приостановлено. При возобновлении приложение возвращается в то состояние, в котором оно находилось до перехода в режим паузы. Для того
чтобы загрузить данные, которые были сохранены при приостановке приложения или выполнить другие действия во время возобновления приложения,
необходимо заполнить метод Application_Activated, инициализированный в
файле App.xaml.cs.
2.8.3 Приостановка приложения
Приложение может быть приостановлено, если оно находилось в состоянии Запущено. Это происходит, когда пользователь переключается на
другое приложение, либо блокирует устройство, либо переходит в меню. Пока приложение приостановлено, оно продолжает находиться в памяти, поэтому пользователи могут быстро переключаться между запущенными приложениями. Однако операционная система может при нехватке памяти завершить приложение, чтобы освободить память. Если приложение завершается, оно прекращает свою работу и выгружается из памяти. В таком случае
операционная система не предупреждает приложение о завершении, поэтому
необходимо сохранять данные во время приостановки приложения. Для того
чтобы это сделать, необходимо заполнить метод Application_Deactivated в
файле App.xaml.cs.
27
2.8.4 Завершение приложения
Приложение может быть завершено, когда оно находится либо в состояние Запущено, при нажатии на кнопку назад на главной странице приложения, либо в состоянии приостановлено, из диспетчера запущенных приложений или самой операционной системой, как это было описано выше. Для того
чтобы описать действия при закрытии приложения, необходимо заполнить
метод Application_Closing в файле App.xaml.cs.
2.9 Model-View-ViewModel (MVVM)
Шаблон проектирования Model-View-ViewModel (MVVM) – очень часто используется при написании современных приложений, в том числе Windows Phone приложений. Это эволюция шаблона Model-View-Controller
(MVC). MVVM используют для того, чтобы отделить код от пользовательского интерфейса. Такой подход облегчает параллельную работу над кодом и
дизайном приложения. Дизайнер работает в среде Expression Blend, а программист параллельно пишет код в Visual Studio. Это так же облегчает тестирование. Разработчик может писать тесты независимо от других слоев разработки. Существуют три раздельные части:
View (визуальна часть) – это пользовательский интерфейс, представленный кодом XAML и страницами приложения;
Model (модель данных) – это объекты данных, представляющие
связь с источником данных;
ViewModel (Модель представления) – эта часть эквивалентна контроллеру в MVC, который выступает посредником между моделью
данных и представлением данных. Как правило, DataContext (Контекст данных) представления (View) связан с экземпляром модели
представления (ViewModel). А модель представление, как правило,
связана с экземпляром модели данных (Model).
28
В Windows Phone так же применяются Dependency Injection (DI – Внедрение зависимости – процесс предоставления внешней зависимости программному коду). С DI, когда компонент зависит от другого компонента, то
это не является жесткой зависимостью: вместо этого, является списком сервисов, которые необходимы одному компоненту от другого. В Windows
Phone DI используется для обеспечения связи представления (View) , модели
представления (ModelView) и моделью данных (Model), так что приложению
не нужно непосредственно связывать их.
На рисунке 5 видно, что Представление, Модель данных и Модель
преставления полностью разделены. Учитывая основанный на страницах
пользовательский интерфейс Windows Phone приложений, очень важно отметить, что можно использовать одни и те же представления на разных страницах. По этим причинам, представления (страницы) не влияют на создание
Модели представления. Скорее, приложение создает Модель представления и
раскрывает ее как свойство, которая становится доступной с любой страницы.
Подход MVVM приветствуется в коде, и несколько шаблонов Visual
Studio генерируются на его основе.
29
Рисунок 5. Обзор уровней паттерна MVVM
30
3. Реализация приложения
3.1
Модель базы данных
Для хранения данных была выбрана база данных Microsoft SQL Server
Compact Edition из линейки SQL Sever. База данных хранится в едином файле. SQL Server Compact позволяет создавать компактные базы данных, которые могут быть развернуты на настольных компьютерах и смартустройствах, а также обеспечить функциональность реляционной базы данных: надежный источник данных, оптимизацию обработчика запросов, масштабируемость компонентов связи. SQL CE является нативной базой данных
для Windows Phone.
Для взаимодействия с базой данных создается контекст данных (Data
Context), а также прокси-классы для моделирования таблиц базы данных. Для
увеличения скорости выполнения запросов к базе данных, таблицы индексируются, а в коде C# классы, моделирующие таблицы, снабжаются атрибутом
[Index].
База данных состоит из 5 таблиц, представляющих основные единицы
информации в приложении. База данных не может быть изменена из приложения. Архитектура базы данных представлена на рисунке 6.
31
Рисунок 6, архитектура базы данных.
3.1.1 Таблица Здания (Buildings)
В таблице хранится информация обо всех зданиях, которые входят в
состав университета.
Здания определяются полями:
Id – уникальный идентификационный номер здания, который совпадает с идентификационным номером здания на сервере. Является
первичным ключом для таблицы;
Name – название здания;
Address – адрес здания;
Latitude –координата широты, на которой располагается здание;
Longitude – координата долготы, на которой располагается здание.
Координаты широты и долготы необходимы для расположения здания
на карте города в приложении.
32
… остальные таблицы аналогично
Заполнение базы данных осуществлялось .Net-приложением, которое
извлекало информацию с сайта университета и генерировало sql-запросы для
заполнения таблиц.
С помощью API системы занятости аудиторий КФУ была создана таблица зданий и аудиторий университета, в которых проводятся занятия. В течение месяца проводился сбор и анализ информации об аудиториях, которые
используются в учебном процессе. Для данной цели было написано приложение на .Net, которое забирало данные с сервиса и обрабатывало их. В результате чего, был сформирован список аудиторий и зданий.
3.1.1 Реализация поиска по базе данных.
Для быстрого доступа к информации из базы данных было принято
решение, реализовать страницу поиска в приложении. Для удобства пользователя был продуман и реализован алгоритм динамического поиска - результаты поиска появляются в списке результатов, по мере ввода запроса. База
данных состоит из достаточно большого числа записей, поэтому поиск был
распараллелен, для увеличения скорости генерации результатов.
Процессы поиска запускаются после ввода четвертого символа. Сначала определяется приоритетная таблица для поиска. После этого запускаются
распараллеленные процессы поиска по таблицам, для каждой из таблиц создаются коллекции результатов. По завершению каждого процесса генерируются события, информирующие о завершении поиска в конкретной таблице. После завершения поиска во всех таблицах, результаты объединяются в
общую коллекцию и выводятся на экран. Распараллеливание избавляет пользовательский интерфейс от состояния ожидания во время выполнения алгоритмов поиска, оставляя его доступным пользователю, без блокировки.
В случае изменения содержимого поля ввода, запускается следующий
шаг, на котором происходит выборка результатов из результирующих коллекций по количеству символов, введенных на текущий момент.
33
Таким образом, выборка, выводимая на экран, сокращается по мере
ввода.
3.2 Реализация архитектуры клиент-серверного приложения
Приложение реализует архитектуру клиент-сервер для задач, связанных с мероприятиями университета.
Архитектура клиент-серверного приложения подразумевает наличие
удаленного сервера, обрабатывающего запросы клиентов. Клиенты, в данном
случае, просто отображают информацию, полученную с сервера.
В приложении «KFU Guide» сервер реализован с помощью фреймворка
Ruby On Rails. Клиентами являются мобильные приложения для платформ
Windows Phone, iOS, Android.
Связь между клиентами и сервером на транспортно-сетевом уровне
осуществляется по протоколу TCP/IP (набор сетевых протоколов передачи
данных, используемых в сетях, включая сеть Интернет). Для организации
информационного обмена используется протокол прикладного уровня HTTP
и его расширение HTTPS, поддерживающее шифрование. Взаимодействие
осуществляется согласно архитектуре REST – стиль построения архитектуры
распределенного приложения, в котором данные должны передаваться в виде
небольшого количества стандартных форматов (HTML, XML, JSON).
Моя задача заключалась в написании клиента для платформы Windows
Phone. Общая архитектура системы KFU Guide изображена на рисунке 7.
3.2.1 Регистрация на сервере.
Для регистрации и авторизации на сервере было решено использовать
социальные сети. Так как это позволяет наиболее точно идентифицировать
личность зарегистрировавшегося пользователя с помощью Api, предоставляемого социальными сетями. Для этой цели были выбраны следующие социальные сети:
Вконтакте – наиболее популярная в России социальная сеть;
34
Facebook – международная социальная сеть.
3.2.1.1 Синхронизация с Вконтакте.
Перед использованием Api Вконтакте, необходимо зарегистрироваться
в социальной сети как разработчик и зарегистрировать свое приложение. После этого выдается идентификационный номер приложения, с помощью которого осуществляется дальнейшее взаимодействие с сервисом.
Для авторизации и регистрации пользователя, социальная сеть Вконтакте использует протокол авторизации OAuth. OAuth – популярный протокол, который позволяет социальным сервисам интегрироваться между собой
и предоставляет безопасный способ обмена персональной информацией.
Процесс авторизации приложения состоит из 3-х этапов:
Открытие окна браузера для аутентификации пользователя на
сайте Вконтакте;
Разрешение пользователем доступа к своим данным;
Передача в приложение ключа access_token для доступа к API.
В приложении авторизация осуществляется через страницу браузера.
Данный способ не дает приложению сохранить личные данные пользователя,
вводимые для авторизации в социальной сети.
Для отображение страницы авторизации Вконтакте необходимо перейти по адресу
https://oauth.vk.com/authorize?client_id=3737326&scope=pages&redirect_
uri=https://oauth.vk.com/blank.html&display=wap&v=4.8&response_type=token,
где
client_id – идентификационный номер приложения,
scope – запрашиваемые приложением права доступа,
redirect_uri – адрес, на который будет передан access_token,
display – внешний вид окна авторизации, поддерживаются: page, popup
и mobile.
35
v – версия API.
После успешного входа на сайт, пользователь должен разрешить доступ приложению к необходимым настройкам, запрошенным при помощи
параметра scope.
После успешной авторизации браузер пользователя будет перенаправлен по адресу redirect_uri, а ключ доступа к API и другие параметры будут
переданы приложению в URL-фрагменте ссылки:
https://oauth.vk.com/blank.html#access_token=
533bacf01e11f55b536a565b57531ad114461ae8736d6506a3&expires_in=86400&
user_id=8492, где
access_token – ключ доступа к API Вконтакте,
expires_in – время актуальности ключа доступа в секундах, если время
ключа доступа истекло, необходимо повторить все предыдущие шаги,
user_id – идентификационный номер пользователя Вконтакте.
После получения ключа доступа, приложение получает доступ к API.
3.2.1.2 Синхронизация с Facebook
Алгоритм авторизация пользователя через Facebook схож с алгоритмом
авторизации через Вконтакте.
Первым шагом синхронизации является регистрация приложения и получение его идентификационного номера.
Для авторизации пользователя Facebook так же использует протокол
OAuth.
Процесс авторизации в социальной сети Facebook состоит из 3-х шагов:
Открытие окна браузера для аутентификации пользователя на
сайте Facebook;
Передача в приложение ключа access_token для доступа к API ;
Запрос и получение идентификационного номера пользователя
user_id.
36
Для отображения страницы авторизации пользователя приложению
необходимо перейти по ссылке
https://www.facebook.com/dialog/oauth?client_id=497295983680210&redir
ect_uri=https://www.facebook.com/connect/login_success.html&scope=email&dis
play=wap&response_type=token, где
client_id – идентификационный номер приложения,
scope – запрашиваемые приложением права доступа,
redirect_uri – адрес, на который будет передан access_token,
display – внешний вид окна авторизации, поддерживаются: page, popup
и mobile.
После успешный авторизации приложение получает ключ access_token
в URL-фрагменте.
После получения ключа access_token необходимо получить идентификационный номер пользователя социальной сети. Для этого необходимо отправить запрос по адресу
https://graph.facebook.com/me?fields=id&access_token=ACCESS_TOKEN
, где ACCESS_TOKEN – ключ доступа, полученный на предыдущем этапе.
3.2.2 Передача информации на сервер
После авторизации через социальную сеть полученные данные отправляются по защищенному протоколу на сервер с помощью Post-запроса.
Запрос отправляется по адресу http://guiddy.fosslabs.ru/sessions.
Сервер обрабатывает данные и возвращает идентификатор сессии, с
помощью которого осуществляется дальнейшее взаимодействие с сервером.
Идентификатор сессии сохраняется в локальном хранилище настроек смартфона и передается параметром в запросах отправки событий на сервер.
3.2.3 Отправка нового события
Для реализации отправки события на сервер используется Post-запрос с
параметрами: заголовок события, подробное описание события, дата проведения, время начала и время конца, идентификационный номер здания, иден37
тификационный номер аудитории, в которой проводится событие, идентификационный номер типа мероприятия. К параметрам добавляется идентификатор сессии для того, чтобы установить личность автора события. Запрос отправляется по адресу http://guiddy.fosslabs.ru/event_with_room.
3.2.4 Получение списка событий
Для получения списка мероприятий нашего университета необходимо
отправить запрос на сервер по адресу http://guiddy.fosslabs.ru/events.json. Ответ приходит в формате JSON – текстовый формат обмена данными, основанный на JavaScript. Его главное преимущество заключается в том, что
JSON легко читается и понимается людьми. Для того чтобы осуществить
разбор данного формата, была использована библиотека Newtonsoft.Json.
К событиям применяются два типа фильтров. Для того чтобы применить фильтр по типу события, необходимо отправить запрос по адресу
http://guiddy.fosslabs.ru/TYPE_events, где TYPE – один из типов событий:
study, science, sport, cultural, meeting, other. Ответ приходит в формате JSON.
Фильтр по аудитории применяется с помощью отправки запроса на
сервер по адресу http://guiddy.fosslabs.ru/rooms/ROOM_ID, где ROOM_ID –
идентификационный номер аудитории, по которой применяется фильтр. Ответ приходит в формате JSON.
3.2.5 Поиск свободной аудитории
Для получения списка свободных аудиторий необходимо отправить
Post-запрос по адресу http://guiddy.fosslabs.ru/empty_rooms с параметрами:
идентификационный номер здания и временной промежуток. В ответ приходит список аудиторий в формате JSON, которые свободны в выбранный промежуток времени.
38
3.3 Использование QR-кодов. Использование камеры для сканирования QR-кода
В 1994 году японская компания «Denso-Wave» представила матричной
код – QR-код, который позволяет зашифровать до 7089 цифр или до 4296
символов. Основное достоинство QR-кода – легкое распознавание сканирующим устройством, что дает возможность широкого использования в различных сферах. QR-коды уже около 15 лет пользуются популярностью в
Японии, и около 5 лет популярны в Европе и США. До России они дошли
относительно недавно, но их уже можно встретить на рекламных вывесках, и
телевизионной рекламе, а так же на продуктах массового производства.
В приложении QR-коды используются для доступа к геоконтекстным
данным и представляют собой метки, связанные с информацией об институтах, находящихся в здании и о событиях, проводящихся в аудиториях.
Сканирования QR-кода осуществляется основной камерой телефона.
Для использования основной камеры устройства, необходимо прописать разрешение на использование этой функции в манифесте приложения. После
перехода приложения на экран сканирования, инициализируется камера и запускается процесс захвата изображения с камеры и передача его в функцию
библиотеки для декодирования QR-кода. Если функция вызывает исключение – это означает, что декодирование не удалось – изображение не являлось
QR-кодом или не удалось декодировать QR-код – в таком случае, функция
захвата изображение рекурсивно запускается заново. После того, как удалось
распознать QR-код и декодировать его, результат сканирования передается
параметром на следующую страницу приложения.
Для декодирования QR-кодов использовалась библиотека ZXing. Данная библиотека была выбрана в связи с множеством положительных отзывов
в сети Интернет, бесплатным распространением и хорошей документацией.
Библиотека встраивается в приложение с помощью с помощью NuGet - расширения среды разработки Visual Studio, которое упрощает добавление, обновление и удаление библиотек в проекты Visual Studio.
39
3.4 Работа с картой
Для отображения карты был использован стандартный элемент управления Map (Карта). Страница карты необходима для отображения местоположения зданий институтов и соотнесения его с местоположением пользователя. Для использования GPS-служб устройства, необходимо было прописать
в манифесте приложения данную возможность. А перед определением местоположения пользователя, необходимо объяснить пользователю, для чего
приложение использует его местонахождение, и попросить подтверждения
того, что пользователь согласен, чтобы приложение использовало его местоположение. Данное требование указано в требованиях к сертификации приложений для магазина Windows.
Определение местоположения осуществляется асинхронно, благодаря
чему, карта все так же остается доступной для пользователя во время определения местоположения. Для визуализации того, что местоположение определяется, используется стандартный элемент управления под названием ProgressIndicator, отображаемый над системной панелью телефона. После того,
как алгоритм определения местоположения завершит свою работу, генерируется событие, и карта центрируется по координатам местоположения пользователя.
В приложении реализована возможность изменять режимы карты и
включать или выключать дополнительные функции.
40
4. Интерфейс и функционал
Интерфейс приложения составляют страницы с уникальным функционалом и правилами перехода. На рисунках 7 – 16 изображены UML диаграммы вариантов использования (use case diagrams) подсистем приложения.
Рисунок 7, UML- диаграмма общей схемы навигации между страницами в
приложении.
41
Рисунок 8, UML-диаграмма экрана поиска.
Рисунок 9, UML-диаграмма вариантов использования результатов поиска.
42
Рисунок 10, UML-диаграмма вариантов использования информации об институтах и кафедрах.
Рисунок 11, UML-диаграмма использования карты.
43
Рисунок 12, UML-диаграмма использования страницы сканирования QRкодов.
Рисунок 13, UML-диаграмма вариантов использования результатов сканирования QR-кода.
44
Рисунок 14, UML-диаграмма вариантов использования экрана списка событий.
45
Рисунок 15, UML-диаграмма создания нового события с авторизацией.
Рисунок 16, UML-диаграмма добавления нового события без авторизации.
46
4.1 Стартовая страница
При открытии приложения пользователь видит стартовую страницу,
представляющую из себя элемент управления Pivot (несколько экранов, переключение между которыми осуществляется посредством горизонтального
свайпа), состоящий из панели приложения(ApplicationBar) и трех экранов:
Поиск, Навигация, Мероприятия.
4.1.1 ApplicationBar
Application Bar (Панель приложения) представляет собой всплывающую панель внизу окна приложения, которая может содержать от одной до
четырех кнопок, позволяющих выполнить какие-то действия. Кроме того, тут
может присутствовать не иерархическое текстовое меню. Меню может быть
привязано к одной из кнопок панели и в основном используется для выбора
одной из опций приложения.
На экране поиска и навигации на панели приложения располагается
кнопка для перехода к сканированию QR-кода и элемент меню «Настройки
приложения». По нажатию на элемент меню осуществляется переход на
страницу настроек приложения.
4.1.2 Поиск.
На экране поиска содержится статичная строка ввода. Ниже располагается список результатов поискового запроса. По мере ввода запроса формируется список результатов.
Элементы списка результатов поиска интерактивны. В зависимости от
того, какого типа является элемент, при касании происходит переход на соответствующую им страницу.
Примеры интерфейса изображены на рисунках 17 – 18.
47
Рисунок 17, сохраненные
Рисунок 18, новый поиск
результаты поиска
4.1.3 Навигация
В навигации находится список всех институтов с указанием их номеров
телефонов. При касании элемента осуществляется переход на соответствующую страницу, содержащую подробную информацию.
Пример интерфейса экрана Навигация изображен на рисунке 19.
48
Рисунок 20, экран навигации.
4.1.4 События
Экран содержит список всех мероприятий, проводимых в университете. Внизу экрана располагается панель приложений, на которой находятся
кнопка для добавления нового события, кнопка для фильтрации событий,
кнопка обновления списка событий и кнопка сканирования QR-кодов.
После нажатия на кнопку добавления события, если пользователь зарегистрирован на сервере и вход в аккаунт осуществлен, то открывается страница Новое событие. Если пользователь еще не зарегистрирован в системе
или вышел из аккаунта, то всплывает диалоговое окно с уведомлением о том,
что для того, чтобы добавлять события к аудиториям, необходимо зарегистрироваться в системе или войти в свой существующий аккаунт, и предложением войти через социальные сети. Если пользователь выбирает войти через социальные сети, то открывается страница с браузером для осуществления входа через социальные сети.
49
Кнопка фильтрации позволяет ограничить список мероприятий. После
нажатия на эту кнопку, появляется диалоговое окно с различными видами
фильтрации.
Фильтр по аудитории. Для этого необходимо сначала выбрать здание, а
потом аудиторию.
Фильтр по типу события. Типы мероприятий: культурные, учебные,
спортивные, научные, собрания (совещания), другое.
Для применения фильтра необходимо нажать кнопку Ok.
При нажатии на элемент списка мероприятий, он раскрывается и появляется подробное описание мероприятия.
Примеры интерфейса экрана Мероприятий изображены на рисунках 21
– 24.
Рисунок 21, экран списка
Рисунок 22, описание события
мероприятий
50
Рисунок 23, сообщение о
Рисунок 24, список свободных
необходимости авторизоваться
аудиторий
4.2 Страница Новое событие
Страница содержит поля ввода информации, необходимой для создания нового события.
Поле ввода здания. Для ввода подходит как адрес, так и название здания. Есть возможность выбора здания из списка, после нажатия кнопки добавления. После того, как выбрано здание, появляется поле для выбора аудитории, в которой будет происходить событие.
Поле ввода аудитории. Имеет аналогичный предыдущему полю функционал.
Заголовок события. Текстовое поле для ввода заголовка события.
Тип
события.
ListPicker
-
элемент
управления
пакета
Mi-
crosoft.Phone.Controls.Toolkit. Разворачивающийся список, позволяющий выбрать один из элементов. Типы мероприятий:
Учебные
51
Научные
Спортивные
Культурные
Собрания, совещания
Другое
Дата и время проведения события. Элементы управления пакета Microsoft.Phone.Controls.Toolkit. Стандартный элемент ввода даты и времени
для платформы Windows Phone. После нажатия открывается старица
настройки даты и времени.
Описание события. Текстовое поле для ввода подробного описания события.
Панель приложения содержит кнопку отправки события на сервер. А
так же элемент меню – настройки приложения.
Примеры интерфейса страницы Новое событие изображены на рисунках 25 – 26.
Рисунок 25, страница Новое
Рисунок 26, заполненная
Событие
страница Новое событие
52
4.3 Страница Настройки
На данной странице предлагаются несколько настроек приложения.
Так как приложение требует регистрации для создания событий, на этой
странице пользователь может войти в свой аккаунт, либо выйти из него.
Стандартная тема приложения выбрана светлой. Но светлая тема потребляет
больше энергии, чем темная. Для пользователей, которые экономят заряд батареи есть возможность сменить тему приложения со светлой на темную и
наоборот. Для данной цели используется элемент управления ListPicker, который позволяет выбрать элемент из списка.
Пример интерфейса страницы Настройки изображен на рисунке 27.
Рисунок 27, страница
Настройки.
4.4 Страница информации об институте
Страница является элементом управления Panorama, навигация по которой осуществляется горизонтальным свайпом.
53
На первом экране находится контактная информация об институте/факультете: Номер аудитории директората/деканата, номер телефона, адрес, электронный адрес деканата и ссылка на страницу института/факультета
на сайте университета. Все поля, кроме аудитории, являются интерактивными:
После нажатия на номер телефона, появляется диалоговое окно с вопросом о подтверждении желания позвонить по номеру.
После нажатия на адрес института, открывается страница карты.
После нажатия на электронный адрес, открывается диалоговое окно с
предложением выбрать учетную запись, с которой пользователь хочет отправить письмо. После выбора учетной записи, открывается стандартное окно
для ввода и отправки письма.
После нажатия на ссылку, открывается стандартный браузер и переходит на страницу института/факультета на сайте университета.
На втором экране находится список кафедр института/факультета.
Отображается название кафедры и ее заведующий. При нажатии на элемент
списка открывается страница выбранной кафедры.
Примеры интерфейса страницы информации об институте изображены
на рисунках 28 – 31.
54
Рисунок 28, общая информация
Рисунок 29, список кафедр
об институте
института
Рисунок 30, вызов по номеру
телефона института
Рисунок 31, отправка
сообщений на Email института
55
4.5 Страница карты
Страница представляет собой элемент управления Карта(map). При открытии страницы отображается карта местности с центром в точке, где располагается здание института/факультета. Эта точка отмечена элементом
управления Pushpin с названием института/факультета, местонахождение которого пользователь захотел увидеть на карте. Также в приложении есть возможность определить местоположение пользователя.
Для доступа к этим функциям внизу экрана находится панель приложения с двумя кнопками и одним элементом меню.
При нажатии на первую кнопку, пользователь может узнать, где он
находится. Исходя из требований сертификации приложений, после нажатия
пользователем кнопки, если у приложения нет разрешения использовать местоположение, всплывает диалоговое окно с вопросом об использовании геолокационных служб. Если пользователь разрешает приложению использовать его местоположение, запускается алгоритм определения местоположения. После завершения работы алгоритма, карта центрируется на координатах пользователя, отмеченных элементом управления Pushpin.
При нажатии на вторую кнопку, центр карты возвращается на местоположение здания института.
Элемент меню - Настройки карты. После нажатия на элемент меню,
приложение переходит на страницу Настройки карты.
Примеры интерфейса страницы карты изображены на рисунках 32 -35.
56
Рисунок 32, страница карты,
режим местности
Рисунок 33, страница карты
с определенным местоположением
пользователя, режим карты
Рисунок 34, страница карты,
Рисунок 35, страница карты,
режим спутника.
гибридный режим
57
4.6 Страница Настройки карты.
На этой странице пользователь может разрешить или запретить использование геолокационных служб. Для этого используется элемент управления ToggleSwitch.
Есть возможность переключения режима карты. У карты всего 4 режима: Карта, Спутник, Местность и Гибридная.
Существуют дополнительные функции карты. Есть возможность показывать пешеходные зоны на карте, а так же достопримечательности местности.
Для того, чтобы сохранить настройки, необходимо нажать на кнопку
Сохранить на панели приложения.
Пример интерфейса страницы настроек карты изображен на рисунке
36.
Рисунок 36, страница Настройки карты
58
4.7 Страница информации о кафедре
Страница содержит информацию о кафедре: заведующий кафедрой,
контактная информация и список сотрудников кафедры.
Контактная информация является интерактивной. После нажатия на телефонный номер, появится диалоговое окно с запросом на подтверждение
вызова по номеру. После нажатия на электронный адрес, появится диалоговое окно, предлагающее выбрать электронный ящик пользователя, с которого
он желает отправить письмо. После выбора электронного ящика, открывается
стандартное окно для создания и отправки письма.
Список преподавателей так же является интерактивным. Если у преподавателя на сайте университета был указан контактный электронный адрес,
то при нажатии на преподавателя из списка, можно отправить ему электронное письмо.
Примеры интерфейса использования страницы информации о кафедре
изображены на рисунках 37 – 39.
Рисунок 37, страница
информации о кафедре
Рисунок 38, страница выбора
почты, с которой будет отправлен Email
59
Рисунок 39, вызов кафедры
по номеру телефона.
4.8 Страница камеры
После перехода на страницу сканирования QR-кода, запускается камера и начинается захват и обработка изображения. Если на QR-коде был закодирован идентификационный номер здания, то приложение переходит на
страницу списка институтов, находящихся в этом здании. Если на QR-коде
был закодирован номер аудитории, то приложение переходит на список событий, закрепленных за этой аудиторией.
Пример интерфейса страницы камеры изображен на рисунке 40.
60
Рисунок 40, страница сканирования
QR-кодов.
4.9 Страница результата сканирования
Существует два варианта результатов сканирования.
Отсканирован адрес зданий. Переход на страницу со списком институтов/факультетов, располагающихся в этом здании.
Элемент списка содержит название института/института, номер телефона директората/деканата, а так же кнопку для звонка в директорат/деканат.
После нажатия на сам элемент списка, приложение осуществляет переход на
страницу выбранного института.
Отсканирован номер аудитории. Переход на страницу со списком
событий, закрепленных за этой аудиторией.
Элемент списка содержит заголовок и дату проведения события. При
нажатии на элемент списка, он расширяется и появляется подробное описание события. Внизу экрана располагается панель приложения, на которой
61
находится кнопка для добавления нового события в «отсканированную»
аудиторию и кнопка для нового сканирования.
Примеры интерфейса страницы результатов сканирования изображены
на рисунках 41 – 42.
Рисунок 41, результат
Рисунок 42, результат
сканирования – институты
сканирования – мероприятия
62
5. Тестирование
Тестирование для сертификации приложения для магазина Windows
Phone проводилось с помощью стандартных инструментов среды разработки
Visual Studio 2013. Тесты комплекта сертификации приложений содержит
следующие тесты:
1. Тест на соответствие пакета
Проверяет допустимость содержимого пакета приложения:
1.1 Допустимость манифеста приложений;
1.2 Расширение файлов и протоколы;
1.3 Правила зависимости платформы;
1.4 Размер пакета приложения – размер не должен превышать 4ГБ.;
1.5 Наличие в наборе только одного пакета приложения для архитектуры ARM.
2. Проверка компонентов безопасности Windows.
Проверяет безопасность приложения:
2.1 Способы программирования и сборки двоичных файлов;
2.2 Правильность использования средств безопасности;
2.3 Наличие двоичных файлов для подписи частного кода в пакете
приложения.
3. Проверка поддерживаемых API.
Позволяет убедиться, что в приложении не используются несовместимые API.
4. Проверка ресурсов манифеста приложения.
Позволяет убедиться, что ресурсы, определенные в манифесте приложения присутствуют и допустимы.
5. Проверка конфигурации отладки.
Позволяет убедиться, что сборка не является отладочной.
6. Проверка кодировки файлов.
63
Проверяет содержимое пакетов приложения на предмет правильности
используемой кодировки.
7. Проверка метаданных среды выполнения Windows.
8. Тест соответствия файлов платформе.
9. Тест на производительность.
Позволяет определить скорость отклика приложения на команды пользователя, количество используемой приложением памяти, стоимость элементов для каждой операции рисования. Тест на производительность графически
отображает потребление памяти приложением и позволяет просмотреть
участки кода, где память расходуются не эффективно.
В ходе разработки приложении тестировалось на физическом устройстве Nokia Lumia 820 с 1 ГБ оперативной памяти и разрешением 800x480, а
также после обновления данного устройства до операционной системы Windows Phone 8.1. Для тестирования на физическом устройстве необходимо
сначала разблокировать его для разработки с помощью аккаунта разработчика. Дополнительно тестирование проводилось на эмуляторах различных
разрешений и количеством оперативной памяти.
64
6. Магазин приложений Windows
Публикация приложения в фирменный магазин – очень кропотливый
процесс, требующий особого внимания к деталям.
Первый этап публикации в магазин – создание аккаунта разработчика.
Для студентов университетов существует возможность бесплатного создания
учетной записи разработчика с помощью программы Dreamspark. Для создания и публикации нашего приложения был использован студенческий аккаунт разработчика.
Второй этап публикации приложения – проверка приложения на требования сертификации приложений магазина Windows. Для решения этой задачи использовались тесты среды разработки Visual Studio 2013, которые были
описаны в разделе тестирование.
Третий этап публикации приложения – сбор снимков экрана, заполнение информации о приложении, определение категории и цены приложения.
После заполнения всей информации, приложение отправляется на сертификацию. Сертификация длится около недели, после чего на почту приходит
электронное письмо с информацией о том, прошло ли приложение сертификации. Если приложение не прошло сертификацию, к письму прилагается отчет в формате pdf с описанием причины отклонения приложения. Если приложение было отклонено, после исправления ошибок, оно снова отправляется на сертификацию в магазин Windows.
65
Заключение
В результате выполнения дипломной работы были разработаны и спроектированы архитектура и интерфейс мобильного приложения «KFU Guide»
для платформы Windows Phone 8, позволяющее упростить навигацию по Казанскому Федеральному Университету, обеспечить быстрый доступ к контактной информации подразделений и преподавателей университета, своевременно информировать о намечающихся мероприятиях университета.
В процессе выполнения дипломной работы были решены следующие
задачи:
Спроектирована архитектура и интерфейс мобильного приложения, удовлетворяющие общим стандартам для платформы Windows Phone 8;
Собрана и проанализирована информации о подразделениях университета и расписании аудиторий. Организовать хранение и работу с данными;
Спроектирована архитектуру взаимодействия клиента и сервера;
Разработан программный продукт «KFU Guide» и опубликован в
магазине приложений Windows.
Дальнейшее развитие приложения
Функционал приложения
Для улучшения навигации по университету планируется добавить
навигацию внутри зданий, с использованием интерактивных планов зданий,
этажей.
Поддержка устройств
На данный момент приложение поддерживается версиями операционной системы Windows Phone 8 и Windows Phone 8.1. В дальнейшем планируется перенести дизайн интерфейса на настольную и планшетную версию
операционной системы Windows 8, что позволит значительно расширить потребительскую аудиторию.
66
Список использованных источников
1. Whitechapel A. Windows Phone 8 Development Internals / S. McKenna, A.
Whitechapel – North Sebastopol: «O`Reilly», 2013. – 965 с.
2. Троелсен Э. Язык программирования C# 5.0 и платформа .Net 4.5 / Э.
Троелсен – Санкт-Петербург: «Наука», 2013. – 1311 с.
3. Руководство Microsoft по проектированию архитектуры приложений
[Электронный ресурс] / Режим доступа: http://apparchguide.ms/, свободный.
4. Пугачев С. Разработка приложений для Windows Phone 7.5 / Пугачев
С., Павлов С., Сошников Д. – Санкт-Петербург: «БХВ-Петербург», 2012. –
374 с.
5. Берн Э. Практические советы по созданию более качественных приложений для Windows Phone / Э. Берн // Журнал MSDN Magazine. – 2012. –
№7.
6. Строушейн М. Использование камер в Windows Phone 7.5 / М. Строушейн // Журнал MSDN Magazine. – 2012. – №1.
7. Либерти Д. Связывание с данными / Д. Либерти // Журнал MSDN
Magazine. – 2012. – №3.
8. Кириати Й. Навигация в Windows Phone: основы / Й. Кириати, Д. Родригез // Журнал MSDN Magazine. – 2011. – №3.
9. Кириати Й. Навигация в Windows Phone. Часть 2: Более сложные задачи / Й. Кириати, Д. Родригез // Журнал MSDN Magazine. – 2011. – №3.
10. Курс Новые возможности Windows Phone 8 для разработчика [Электронный ресурс] / Официальный сайт Microsoft Virtual Academy. – Режим доступа:
http://www.microsoftvirtualacademy.com/training-courses/new-
possiblities-windows-phone-8-for-developers-rus, свободный.
11. Курс Расширенные возможности разработки для Windows Phone 8
[Электронный ресурс] / Официальный сайт Microsoft Virtual Academy. – Ре-
67
жим
доступа:
http://www.microsoftvirtualacademy.com/training-
courses/advanced-possibilities-appdev-windows-phone-8-rus, свободный.
12. Курс Сложные приемы разработки для Windows Phone 8 [Электронный ресурс] / Официальный сайт Microsoft Virtual Academy. – Режим доступа: http://www.microsoftvirtualacademy.com/training-courses/windows-phone-8for-begginers, свободный.
13. Курс Разработка Windows Store приложений на XAML/C# [Электронный ресурс] / Официальный сайт Microsoft Virtual Academy. – Режим доступа:
http://www.microsoftvirtualacademy.com/training-courses/windows-store-
xaml-c-rus, свободный.
14. How to: Create UML How to: Create UML Modeling Projects and Diagrams [Электронный ресурс] / Официальный сайт Microsoft Developer Network. – Режим доступа: http://msdn.microsoft.com/ru-ru/library/dd409445.aspx,
свободный.
15. Implementing the Model-View-ViewModel pattern for Windows Phone 8
[Электронный ресурс] / Официальный сайт Microsoft Developer Network. –
Режим
доступа:
http://msdn.microsoft.com/en-
us/library/windowsphone/develop/gg521153(v=vs.105).aspx, свободный.
16. Data binding for Windows Phone 8 [Электронный ресурс] / Официальный
сайт
Microsoft
Developer
Network.
–
Режим
доступа:
http://msdn.microsoft.com/enus/library/windowsphone/develop/cc278072(v=vs.105).aspx, свободный.
17. Требования сертификации для приложений Магазина Windows [Электронный ресурс] / Официальный сайт центра разработчиков - приложения
Магазина
Windows.
–
Режим
доступа:
http://msdn.microsoft.com/ru-
ru/library/windows/apps/hh694083.aspx, свободный.
68
Приложение.
Класс поиска SearchClass.cs:
using KFU_Guide.Database;
using KFU_Guide.Model;
using KFU_Guide.View;
using Microsoft.Phone.Controls;
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Linq;
using System.Text;
using System.Text.RegularExpressions;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Threading;
using KFU_Guide.Resources;
namespace KFU_Guide.ViewModel
{
public class SearchClass
{ int test = 0;
public ObservableCollection<BaseItemModel> result;
private ObservableCollection<BaseItemModel> oldResultOfRooms;
private ObservableCollection<BaseItemModel> oldResultOfTeachers;
private ObservableCollection<BaseItemModel> oldResultOfBuildings;
private ObservableCollection<BaseItemModel> oldResultOfInstitutes;
private ObservableCollection<BaseItemModel> oldResultOfDepartments;
public ObservableCollection<BaseItemModel> resultOfRooms;
public ObservableCollection<BaseItemModel> resultOfTeachers;
public ObservableCollection<BaseItemModel> resultOfBuildings;
public ObservableCollection<BaseItemModel> resultOfInstitutes;
public ObservableCollection<BaseItemModel> resultOfDepartments;
private bool teachersIsReady = false;
private bool departmentsIsReady = false;
private bool institutesIsReady = false;
private bool roomsIsReady = false;
public bool allIsReady = false;
public SearchClass()
{
resultOfRooms = new ObservableCollection<BaseItemModel>();
resultOfTeachers = new ObservableCollection<BaseItemModel>();
resultOfBuildings = new ObservableCollection<BaseItemModel>();
resultOfInstitutes = new ObservableCollection<BaseItemModel>();
resultOfDepartments = new ObservableCollection<BaseItemModel>();
RoomsSearchIsDone += SearchClass_RoomsSearchIsDone;
TeachersSearchIsDone += SearchClass_TeachersSearchIsDone;
BuildingsSearchIsDone += SearchClass_BuildingsSearchIsDone;
InstitutesSearchIsDone += SearchClass_InstitutesSearchIsDone;
DepartmentsSearchIsDone += SearchClass_DepartmentsSearchIsDone;
SearchIsDone += SearchClass_SearchIsDone; }
#region Search is Done definition
void SearchClass_SearchIsDone(object sender, EventArgs e)
{
if (oldResultOfRooms != null && oldResultOfRooms.Count > 0)
{
result = new ObservableCollection<BaseItemModel>(oldResultOfRooms);
}
else if (oldResultOfTeachers != null && oldResultOfTeachers.Count > 0)
{
result = new ObservableCollection<BaseItemModel>(oldResultOfTeachers);
if (oldResultOfDepartments != null && oldResultOfDepartments.Count > 0)
{
69
result = new ObservableCollection<Model.BaseItemModel>(result.Concat(oldResultOfDepartments).ToList()); }
if (oldResultOfInstitutes != null && oldResultOfInstitutes.Count > 0)
{
result = new ObservableCollection<Model.BaseItemModel>(result.Concat(oldResultOfInstitutes).ToList()); }
}
else if (oldResultOfInstitutes != null && oldResultOfInstitutes.Count > 0)
{
result = new ObservableCollection<Model.BaseItemModel>(oldResultOfInstitutes);
if (oldResultOfDepartments != null && oldResultOfDepartments.Count > 0)
{
result = new ObservableCollection<Model.BaseItemModel>(result.Concat(oldResultOfDepartments).ToList());
}
}
else if(oldResultOfDepartments!= null && oldResultOfDepartments.Count>0)
{
result = new ObservableCollection<Model.BaseItemModel>(oldResultOfDepartments);
}
else
{
result = new ObservableCollection<Model.BaseItemModel>();
}
allIsReady = true;
}
void SearchClass_DepartmentsSearchIsDone(object sender, EventArgs e)
{
IStorageSettings.Save("dSearch", true);
departmentsIsReady = true;
if (teachersIsReady && institutesIsReady)
{
RaiseSearchIsDoneEvent();
}
}
void SearchClass_RoomsSearchIsDone(object sender, EventArgs e)
{
IStorageSettings.Save("rSearch", true);
roomsIsReady=true;
RaiseSearchIsDoneEvent();
}
……..
70