Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение

высшего образования «Поволжский государственный университет телекоммуникаций и информатики»

Факультет Факультет заочного обучения

Направление (специальность) Информационные системы и технологии

Кафедра Информационных систем и технологий

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

(БАКАЛАВРСКАЯ РАБОТА)

Разработка клиентского приложения по управлению списком задач для платформы Android

Разработал С.С.Сорочинский

Самара 2017

Реферат

Название	Разработка клиентского приложения по управлению списком задач для платформы Android
Автор	Сорочинский Сергей Сергеевич
Научный руководитель	Новикова Марина Викторовна
Ключевые слова	Клиентское приложение, web-приложение, языки программирования
Дата публикации	2017 г.
Библиографическое описание	Сорочинский С.С. Разработка клиентского приложения по управлению списком задач для платформы Android: дипломный проект / С.С. Сорочинский. Поволжский государственный университет телекоммуникаций и информатики (ПГУТИ). Факультет информационных систем и технологий (ИСТ). Кафедра информационных систем и технологий (ИСТ): науч. рук. М.В. Новикова - Самара. 2017. - 95 с.
Аннотация	Для повышения удобства записи ближайших персональных целей пользователя или иных заметок, разработано Android-приложение с поддержкой устаревших версий. В тех случаях, когда поблизости находится браузер, для возможности быстрого доступа к списку задач реализовано веб-приложение с тем же функционалом что и мобильное приложение. В результате получился сервис для управления списком персональных задач.

Руководитель ВКР ____________ ____________ М. В. Новикова

Подпись Дата Инициалы Фамилия

Введение

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

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

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

Все вышесказанное определило актуальность темы работы - «Разработка клиентского приложения по управлению списком задач на платформе Android».

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

Для достижения поставленной цели необходимо решить следующие основные задачи:

· Создать HTTP-сервер с возможностью работы с БД

· Реализовать процессы авторизации и аутентификации на сервере

· Разработать мобильное приложение для управления списком задач

· Добавить возможность синхронизации мобильного приложения c сервером

· Разработать веб-приложение с тем же функционалом, что и мобильное приложение.

Объектом исследования являются инструментальные среды для разработки мобильных приложений.

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

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

Цель и задачи написания работы определили ее структуру, которая состоит из введения, 3 глав и заключения.

Во введении обосновывается актуальность работы, цель, задачи, объект и предмет исследования.

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

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

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

В заключении сделаны основные выводы и результаты по проделанной работе.

1. Постановка задачи

1.1 Описание задачи

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

? добавление новой задачи;

? разделение задач на группы, с возможностью просмотра всего списка или только группы задач;

? возможность отметить задачу как завершенную;

? просмотр списка завершенных задач;

? редактирование уже созданных задач;

? возможность удалить задачу;

? установка приоритета задачам.

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

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

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

В случае мобильного приложения добавление и удаление задач, изменение статуса задач и их редактирование должно происходить локально на устройстве пользователя. При наличии доступа к сети Интернет, изменения должны автоматически синхронизироваться с сервером приложения. Если пользователь работает с веб-приложением, то изменения должны сразу же примениться на сервере. Приложение должно содержать раздел настроек, который предоставляет настройки приложения и настройки учетной записи пользователя.

Аналоги

Аналогами данного сервиса являются проекты вроде «Remember The Milk» [14], «AnyDO» [2] и «Evernote» [7].

Приложение «Remember The Milk» представляет собой сервис для задач и управления временем. Оно позволяет пользователям управлять задачами с компьютера или мобильного устройства. Создано в 2004 году двумя программистами из австралийской компании. Веб приложение изображено на Рис. 1.1

Рис. 1.1 - Веб-приложение «Remember The Milk»

Комплект мобильных приложений «AnyDO» является сервисом для планирования задач. Первый продукт компании был сделан в качестве приложения для платформы Android в ноябре 2011 года и представлял собой приложение для управления задачами. Позже были созданы приложения для iPhone и Chrome в июне 2012. Веб-приложение было выпущено в мае 2014 года. Приложение для iPhone изображено на Рис. 1.2

Рис. 1.2 - Мобильное приложение «AnyDO»

Сервис «Evernote» представляет собой веб-приложение и набор программного обеспечения для создания и хранения заметок. В качестве заметки может выступать фрагмент форматированного текста, веб-страница целиком, фотография, аудиофайл или рукописная запись. Заметки могут также содержать вложения с файлами другого типа. Заметки можно сортировать по блокнотам, присваивать им метки, редактировать и экспортировать. Поддерживает несколько мобильных платформ, а также предлагает синхронизацию. Был представлен в виде открытой бета-версии в июне 2008 года. К июлю 2013 года сервис набрал 65 миллионов пользователей. Доступен в платном и ограниченном бесплатном вариантах. Использование бесплатной версии подразумевает ограничение на объём ежемесячно размещаемых заметок, который может быть увеличен при переходе на платную подписку. Приложение для платформы Android изображено на Рис. 1.3

Рис. 1.3 - Мобильное приложение «Evernote»

Хранение информации

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

Язык интерфейса

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

Механизм работы при отсутствии подключения к сети Интернет

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

Обратная связь

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

? внешний вид кнопок изменяется при нажатии на них (меняют оттенок);

? поля, заполняемые пользователем, выделяются цветом;

? для соответствия рекомендациям для приложений Android от Google, нужно придерживаться принципов Material Design [11].

Ориентация экрана

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

Работа с API

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

Требования к дизайну

? Соответствие принципам Material Design мобильных приложений Google;

? Дизайн приложения должен быть адаптирован для корректного отображения при различных разрешениях экрана;

? Дизайн веб-приложения должен одинаково отображаться в разных популярных браузерах и соответствовать принципам Material Design.

Операционная система и устройства, обеспечивающие работу приложения

Мобильное приложение должно работать на устройствах под управлением операционной системы Android версии 2.3 и выше. Веб-приложение является частью сервиса на сервере приложений. Для работы сервиса требуется сервер со следующими установленными программными компонентами:

? Node.js

? MongoDB

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

1.2 Используемые языки и программное обеспечение

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

? Java

? JavaScript

? Jade Template Engine

? Android SDK

? Node.js

? MongoDB

? SQLite

Язык Java - это объектно-ориентированный язык программирования. Приложения Java транслируются в специальный байт-код, поэтому они могут работать на любой виртуальной Java-машине вне зависимости от компьютерной архитектуры. Виртуальная машина Java (JVM) - программа, обрабатывающая байтовый код и передающая инструкции оборудованию как интерпретатор.

Язык Java был выбран, т.к. платформа Android подразумевает разработку приложений на этом языке. В Android используется собственная версия JVM, которая активно поддерживается и является основной средой выполнения приложений для данной платформы.

Язык JavaScript (JS) - прототипно-ориентированный сценарный язык программирования. Является реализацией языка ECMAScript [6]. Наиболее широкое применение язык нашел в браузерах как язык сценариев для придания интерактивности веб-страницам. Именно по причине его большой популярности среди браузеров было решено использовать его для реализации веб-приложения. Основные архитектурные черты: динамическая типизация, слабая типизация, автоматическое управление памятью, прототипное программирование, функции как объекты первого класса. У языка большое сообщество разработчиков, которые поддерживают в актуальном состоянии множество библиотек и программных платформ (framework) для реализации типовых и узкоспециализированных задач.

Jade Template Engine - это язык для написания HTML-шаблонов. Генерирует HTML (HTML - язык гипертекстовой разметки), поддерживает динамический код, поддерживает возможность многократного использования (DRY - Don't Repeat Yourself). Реализован как библиотека для Node.js. Был выбран для генерации статических страниц за удобство использования для создания разметки.

Android - операционная система для смартфонов, планшетов, электронных книг, цифровых проигрывателей, наручных часов, игровых приставок, нетбуков, очков Google, телевизоров, мультимедийных систем в автомобилях и других устройств. В качестве ядра операционной системы используется Linux [1] и реализации виртуальной машины Java от Google [5]. Android позволяет создавать Java-приложения, управляющие устройством через разработанные Google библиотеки. Данная платформа была выбрана как самая популярная и широко распространенная платформа для мобильных устройств.

Для разработки используется среда Android Studio, основанная на IntelliJ IDEA от JetBrains [9]. Процесс создания Android приложения не требует дополнительных устройств, кроме, Android устройства (можно использовать эмулятор). Andriod Studio характеризуется:

? гибкой системой сборки Gradle;

? расширенной поддержкой сервисов Google и различных типов устройств;

? богатым функционалом редакторов экранов приложений с поддержкой редактирования тем интерфейса;

? возможностью подписания приложений;

? встроенной поддержкой облачной платформы Google и возможности простой интеграции с Google Cloud Messaging и App Engine [8].

Node.js - программная платформа, основанная на V8 Engine (специальная программа, транслирующая JavaScript в машинный код), позволяющая языку JavaScript становиться языком общего назначения. Node.js добавляет возможность JavaScript взаимодействовать с устройствами ввода-вывода через свой API (написанный на C++), подключать другие внешние библиотеки, написанные на разных языках, обеспечивая вызовы к ним из JavaScript-кода. Node.js применяется преимущественно на сервере, выполняя роль веб-сервера. Есть возможность разрабатывать на Node.js и оконные приложения и даже программировать микроконтроллеры. В основе Node.js лежит событийно-ориентированное и асинхронное программирование с неблокирующим вводом/выводом.

В состав Node.js входит собственный установщик пакетов npm [13], позволяющий получить множество библиотек и программных платформ, созданных различными разработчиками для Node.js. Данная платформа была выбрана для реализации серверной части т.к. удобна для разработки, содержит необходимые библиотеки для взаимодействия с документно-ориентированной базой данных MongoDB, изначально может обрабатывать объекты JSON, которые используются в веб-приложении.

Express.js - это программная платформа для Node.js. Используется для разработки сервера веб-приложений. Предназначена для создания одностраничных и многостраничных веб-приложений. Является стандартной программной платформой серверной инфраструктуры для Node.js. Cодержит множество функций, доступных в виде плагинов. Express.js является частью стека технологий MEAN [12], вместе с базой данных MongoDB и Angular.js. Был выбран для реализации по причине популярности и поддержки сообществом разработчиков.

Mongoose - это объектно-реляционное отображение (ORM - Object-Relational Mapping) для MongoDB, расширение, написанное для Node.js. Mongoose дополняет MongoDB, делая его более удобным для использования. Был выбран за удобные функции, а именно:

? создание вложенных, типизированных схем;

? возможность спецификаций полей схем быть универсальными, или заданными разработчиком;

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

Angular.js - программная платформа на JavaScript с открытым исходным кодом. Предназначена для разработки одностраничных приложений. Цель - расширение веб-приложений на основе MVC шаблона, а также упрощение тестирования и разработки. Фреймворк работает с HTML, содержащим дополнительные пользовательские атрибуты, которые описываются директивами, и связывает ввод или вывод области страницы с моделью, представляющей собой обычные переменные JavaScript. Значения этих переменных задаются вручную или извлекаются из статических или динамических JSON-данных.

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

MongoDB - документно-ориентированная система управления базами данных с открытым исходным кодом, не требующая описания схемы таблиц. Написана на языке C++. Основные возможности:

? документно-ориентированное хранение (JSON-подобная схема данных);

? JavaScript как язык для формирования запросов;

? динамические запросы;

? поддержка индексов;

? профилирование запросов;

? атомарная операция «Нашел и обновил»;

? эффективное хранение двоичных данных больших объёмов, например, фото и видео;

? журналирование операций, модифицирующих данные в базе данных;

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

MongoDB управляет наборами JSON-подобных документов, хранимых в двоичном виде. Хранение и поиск файлов в MongoDB происходит благодаря вызовам протокола GridFS. Подобно другим документно-ориентированным СУБД (CouchDB и др.), MongoDB не является реляционной СУБД, а именно:

? Нет такого понятия, как «транзакция». Атомарность гарантируется только на уровне целого документа, то есть частичного обновления документа произойти не может.

? Отсутствует понятие «изоляции». Любые данные, которые считываются одним клиентом, могут параллельно изменяться другим клиентом.

Данная СУБД была выбрана из-за возможности удобного хранения JSON-документов, которые реализуются по умолчанию в JavaScript и используются для взаимодействия мобильного приложения и веб-приложения с сервером.

Библиотеки, используемые в Node.js

Для реализации веб-приложения и сервера были использованы следующие расширения Node.js:

? Morgan - регистратор HTTP-запросов для node.js.

? Сsprng - безопасный генератор случайных чисел любого размера в различные системы счисления. Генерирует надежные случайные числа. Числа могут быть любой величины и в любой из систем счисления от 2 до 36.

? Connect - представляет собой расширяемый с помощью плагинов HTTP-сервер.

? Nodemailer - библиотека, позволяющая отправлять email сообщения.

? Crypto - библиотека криптографических стандартов.

? Express-session - используется для работы с HTTP-сессиями пользователей.

? Passport - библиотека для авторизации. Чрезвычайно гибкая и модульная. Поддерживает множество шаблонов авторизации, как используя имя пользователя и пароль, так и используя сторонние сервисы.

? Passport-local - шаблон для библиотеки Passport. Используется для аутентификации с помощью имени пользователя и пароля.

? Passport-local-mongoose - плагин, который упрощает хранение данных для аутентификации в базе данных MongoDB.

База данных для мобильного приложения

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

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

Используемые сервисы

Для хранения исходного кода приложений был выбран Bitbucket [3]. Bitbucket - это веб-сервис для хостинга проектов и их совместной разработки, основанный на системе контроля версий Mercurial и Git. Был выбран по причине предоставления бесплатных «закрытых репозиториев» для хранения и контроля версий исходного кода.

2. Анализ, проектирование и реализация приложения

2.1 Выбор подхода для реализации серверной части приложения

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

Многопоточная модель

В данной возможной реализации приложение создает несколько потоков, передавая каждому из них поступивший от клиента запрос. Потоки выполняются параллельно. Если потоки не имеют общих данных, то не будет накладных расходов на синхронизацию, что делает работу достаточно быстрой. После завершения работы поток не удаляется, а остается в пуле, ожидая следующего запроса. Это позволяет избавиться от накладных расходов на создание и удаление потоков. Допустим потоков достаточно большое количество, медленные запросы забирают поток надолго, быстрые - обрабатываются почти мгновенно, освобождая поток для другой работы. Это не позволяет медленным запросам забирать все процессорное время, заставляя ждать быстрые запросы. Может возникнуть ситуация, когда на сервер придет большое количество медленных запросов, например работающих с БД. Такие запросы заберут себе все потоки, что сделает невозможным выполнение других запросов. Это можно решить увеличением числа потоков, чтобы они могли обработать достаточно большое количество медленных запросов, но чем больше потоков создается, тем больше накладных расходов на их обработку и тем меньше процессорного времени выделяется каждому потоку.

Асинхронная модель

Асинхронная модель построена на очереди событий (event-loop). Когда на сервер приходит очередной запрос, он помещается в конец очереди. Поток, который обрабатывает эту очередь, берет запрос с начала очереди, и выполняет связанный с ним код. Пока очередь не пуста процессор будет занят работой. По такой схеме работает Node.js. В данном случае имеется единственный поток, обрабатывающий очередь событий. Использование блокирующих операций не рекомендуется. Разберем на примере некоторого запроса. Из очереди сообщений берется запрос. Node.js его обрабатывает и при этом тратит 1мс. Далее делается асинхронный неблокирующий запрос к базе данных и управление сразу же передается дальше. Node.js берет из очереди следующий запрос и выполняет его еще 1 мс. Допустим, после этого приходит ответ базы данных на самый первый запрос. Событие, связанное с ним помещается в очередь. Если в очереди ничего не было - он сразу же выполнится и данные отправятся клиенту. Если в очереди что-то есть - то событие будет ждать обработку других событий. Процессор всегда будет занят полезной работой. При этом на обработку очереди и переходе от события к событию тратится гораздо меньше времени, чем на переключение между потоками в многопоточной системе.

После анализа было принято решение использовать стек технологий MEAN (MongoDB, Express, Angular.js, Node.js), как популярное и поддерживаемое в сообществе Node.js решение. В результате для обмена данными между клиентами используется JSON. Для отправки запросов к серверу - REST [15] подход взаимодействия компонентов распределенного приложения.

2.2 Реализация сервера

Создание HTTP-сервера с возможностью работы с БД

Сначала был создан простой MEAN проект и установлены нужные библиотеки. В результате получился каркас сервера. Настройка проекта происходит в файле package.json. После редактирования файла настроек проекта Node.js нужно выполнить команду npm install. В моем случае сервер содержит в себе Express версии 4.6.1, Mongoose версии 3.8.13 и Morgan версии 1.1.1. Содержимое файла package.json представлено в листинге 2.1

Листинг 2.1 - Файл проекта package.json

{

"name": "todoWebApp",

"version": "0.0.1",

"description":"Todo Application.",

"main": "server.js",

"author": "Sergei Sorochinskiy",

"dependencies": {

"express": "~4.6.1",

"mongoose": "~3.8.13",

"morgan": "~1.1.1"

}

}

Содержимое главного модуля сервера Node.js является каркасом для будущего сервиса.

Листинг 2.2 - Главный модуль сервера Node.js

var port = process.env.PORT || 8080;

var express = require('express');

var app = express();

app.use(express.static(__dirname + '/public'));

app.listen(port);

console.log("App listening on port " + port);

module.exports = app;

В результате после запуска сервера командой «node server.js» стало возможным обратиться из браузера к HTTP-серверу, который прослушивает порт 8080.

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

? todoTaskData - представляет собой объект, содержащий поля:

а. text - текст заметки, строковое значение;

б. group - название группы, к которой относится заметка, строковое значение;

в. priority - приоритет задачи, числовое значение;

г. removed - флаг, определяющий состояние задачи как удаленной, логическое значение;

? completed - флаг, определяющий статус задачи как завершенной, логическое значение;

? key - временный ключ, используемый мобильным приложением для синхронизации, строковое значение;

? updatedTimestamp - значение unix timestamp, дата и время в формате UTC, содержащие отметку последней модификации, значение дата и время;

? userId - идентификатор пользователя, которому принадлежит задача, строковое значение.

После того как были созданы описания объектов для работы со схемой MongoDB и указаны настройки соединения сервер получил возможность делать запросы к документам в БД. Код для работы с Mongoose представлен в листинге 2.3

Листинг 2.3 - Код для работы с Mongoose

var Todo = new mongoose.Schema(

{

todoTaskData: {

text: { type: String, default: '' },

group: { type: String, default: '' },

priority: { type: Number, default: 0 },

removed: { type: Boolean, default: false }

},

completed: { type: Boolean, default: false },

key: { type: String, default: '' },

updatedTimestamp: { type: Date, default: null},

userId: { type: String, default: '' }

},

{versionKey: false}

);

module.exports = mongoose.model('Todo', Todo);

Реализация авторизации и аутентификации на сервере

Для доступа пользователей к создаваемой ими информации нужно было придумать системы авторизации и аутентификации, для этого в Node.js есть поддерживаемые сообществом разработчиков библиотеки: cookie-parser, express-session, passport, passport-local, passport-local-mongoose. После подключения этих библиотек в package.json в server.js была добавлена логика по работе с пользователями и описана схема документов в БД.

Листинг 2.4 - Логика для работы с пользователями

var Account = new mongoose.Schema(

{

email: String,

password: String,

token: { type: String, default: '' },

temp_str: String

}, {versionKey: false}

);

Account.plugin(passportLocalMongoose, {

usernameField: 'email', hashField: 'hashed_password'

});

В данной реализации были созданы поля:

? email - адрес электронной почты пользователя, используется в качестве логина, строковое значение;

? password - пароль пользователя, в БД хранится в виде хешированного пароля с добавленной случайной строкой, строковое значение;

? token - ключ для мобильного приложения, используется для однозначной идентификации аутентифицированного пользователя при получении запросов от клиента, строковое значение;

? temp_str - временная строка, в которой при необходимости хранится код для восстановления утерянного пароля, строковое значение.

Для использования механизма аутентификации был добавлен соответствующий код в server.js.

Листинг 2.5 - Использование механизма аутентификации

passport.use(new LocalStrategy({usernameField: 'email'}, Account.authenticate()));

passport.serializeUser(Account.serializeUser());

passport.deserializeUser(Account.deserializeUser());

В результате после регистрации пользователя в БД будет создаваться JSON-документ с содержимым, приведенным в листинге 2.6

Листинг 2.6 - JSON, содержащий данные пользователя

{

"_id": ObjectId("56d2e258c5e567b2128da62a"),

"salt": "7c..b9",

"hashed_password": "e3..75",

"email": "user@mail.com",

"token": "4e..82"

}

В листинге 2.6 содержимое полей документа намеренно урезано, для лучшей читаемости. В действительности значения в полях salt, hashed_password token достаточны для обеспечения защиты от взлома.

У любого сервиса есть пользователи, которым будет полезен функционал для восстановления пароля. Для того чтобы обеспечить такую возможность было решено реализовать отправку пользователю временного кода, позволяющего указать новый пароль. На почту, указанную при регистрации, пользователю по запросу отправляется код. Когда пользователь введет соответствующий код и новый пароль, у его учетной записи будет изменен пароль на указанный. Для отправки электронной почты для сервиса была создана учетная запись на mail.yandex.ru [10]. Именно с учетной записи todo.app@yandex.ru происходит отправка пользователям кодов для восстановления пароля. В Node.js для работы с электронной почтой есть библиотека Nodemailer. Для реализации функционала восстановления и смены пароля был реализован вспомогательный модуль password-utils.js. Интерфейсы методов и некоторые фрагменты кода этого модуля приведены в листинге 2.7

Листинг 2.7 - Восстановление и смена пароля.

var APP_EMAIL = "todo.app@yandex.ru";

var APP_EMAIL_PASSWORD = "************";

var APP_EMAIL_PROTOCOL = 'SMTP';

var crypto = require('crypto');

var rand = require('csprng');

var mongoose = require('mongoose');

var nodemailer = require('nodemailer');

var passport = require('passport');

var Account = require('../models/account');

var smtpTransport = nodemailer.createTransport(APP_EMAIL_PROTOCOL,

{

auth: {

user: APP_EMAIL,

pass: APP_EMAIL_PASSWORD

}

});

function prepareMailOptions(email, code) {}

exports.changePassword = function(userToken, opass, npass, callback) {}

exports.initResetPassword = function(email, callback) {}

exports.resetPassword = function(email, code, npass, callback) {}

Где:

? prepareMailOptions - подготавливает объект, представляющий собой письмо с кодом восстановления пароля;

? changePassword - реализация изменения пароля авторизованного пользователя;

? initResetPassword - инициализация восстановления пароля зарегистрированного пользователя;

? resetPassword - завершение восстановления пароля зарегистрированного пользователя.

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

? флаг успешности выполнения запроса, логическое значение;

? текст сообщения, которое будет отправлено пользователю.

На успешно выполненные запросы сервер возвращает ответ со значением true в поле результата, иначе в поле результата отправляется false.

В остальных случаях мобильным клиентам отправляется ключ (значение token), который они будут передавать во всех последующих запросах. Для веб-приложения Node.js позволяет хранить в cookie браузера клиента запись connect.sid, содержащую идентификатор сессии. Библиотека passport.js позволяет осуществлять авторизацию и аутентификацию, используя контекст текущей сессии клиента, которая идентифицируется при помощи значения в connect.sid.

Реализация маршрутизации запросов на сервере

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

Листинг 2.8 - Описание реализации маршрутов

var routesAuth = require('./app/routes/auth');

var routesSyncApi = require('./app/routes/sync-api');

var routesWebApi = require('./app/routes/web-api');

var routesWeb = require('./app/routes/web');

app.use('/', routesWeb);

app.use('/auth', routesAuth);

app.use('/api/', routesWebApi);

app.use('/api/sync', routesSyncApi);

В соответствие с каждым маршрутом сопоставлен модуль, в котором описана реализация. Модуль авторизации и аутентификации представлен в листинге 2.9

Листинг 2.9 - Модуль авторизации и аутентификации

var crypto = require('crypto');

var rand = require('csprng');

var express = require('express');

var passport = require('passport');

var passwordUtils = require('../authorization/password- utils');

var Account = require('../models/account');

var router = express.Router();

function authenticateUser(req, res) {}

router.post('/register', function onPost(req, res) {});

router.post('/login', function onPost(req, res) {});

router.post('/password', function onPost(req, res) {});

router.post('/reset', function onPost(req, res) {});

router.post('/reset/code', function onPost(req, res) {});

module.exports = router;

В результате при получении запроса на соответствующий путь, будет выполнено действие:

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

? /login - обработка запроса на аутентификацию.

? /password - обработка запроса на изменение пароля

? /reset - обработка запроса на инициализацию восстановления пароля.

? /reset/code - обработка запроса на завершение восстановления пароля.

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

Для управления списками задач в сервере был предусмотрен соответствующий API. Подход для работы со списками задач отличается для веб-приложения и для мобильного приложения. Веб-приложение подразумевает непрерывное взаимодействие с сервером. В данной реализации веб-приложение является частью сервера, что объясняется архитектурой решения MEAN. В роли веб-приложения выступает клиентская часть, использующая библиотеку Angular.js. Мобильное приложение может работать при отсутствии соединения с сетью Интернет. Изменения в списках задач будут храниться в мобильном устройстве, а после появления соединения с сетью Интернет будут синхронизироваться с сервером. Соответственно для мобильного приложения автором был продуман другой API. В результате был реализован web-api для веб-приложения и sync-api для мобильного приложения.

Листинг 2.10 - API для веб-приложения

var express = require('express');

var Todo = require('../database/todo');

var router = express.Router();

function getTodos(res, id) {};

function getCompletedTodos(res, id) {};

router.get('/todos', function onGet(req, res) {});

router.get('/todos/completed', function onGet(req, res) {});

router.post('/todos', function onPost(req, res) {});

router.post('/todos/update/:todo_id', function onPost(req, res) {});

router.post('/todos/complete/:todo_id', function onPost(req, res) {});

router.post('/todos/undo-complete/:todo_id', function onPost(req, res) {});

router.delete('/todos/:todo_id', function onDelete(req, res) {});

module.exports = router;

Где:

? getTodos - обращается к БД и получает список незавершенных задач пользователя, от которого пришел запрос.

? getCompletedTodos - обращается к БД и получает список завершенных задач пользователя от которого пришел запрос.

? router.get('/todos', function onGet(req, res)) - функция обработки HTTP запроса GET по пути /todos - возвращает список задач пользователя, который вернула функция getTodos.

? router.post('/todos', function onPost(req, res)) - функция обработки HTTP запроса POST по пути /todos - добавляет в список задач новую и возвращает измененный список задач.

? router.post('/todos/update/:todo_id', function onPost(req, res)) - функция обработки HTTP запроса POST по пути /todos/update/:todo_id, где todo_id - идентификатор задачи. Обновляет задачу с идентификатором todo_id задачей, которая пришла в запросе. Возвращает измененный список задач.

? router.post('/todos/complete/:todo_id', function onPost(req, res)) - функция обработки HTTP запроса POST по пути /todos/complete/:todo_id, где todo_id - идентификатор задачи. Помечет задачу с идентификатором todo_id как завершенную, возвращает измененный список задач.

? router.post('/todos/undo-complete/:todo_id', function onPost(req, res)) - функция обработки HTTP запроса POST по пути /todos/undo-complete/:todo_id, где todo_id - идентификатор задачи. Восстанавливает задачу с идентификатором todo_id из списка завершенных в список незавершенных, возвращает измененный список завершенных задач.

? router.delete('/todos/:todo_id', function onDelete(req, res) - функция обработки HTTP запроса DELETE по пути /todos/:todo_id, где todo_id - идентификатор задачи. Помечает задачу в БД как удаленную, возвращает измененный список задач.

Идентификатор задачи представляет собой ключ документа в БД. Соответственно он генерируется на сервере и MongoDB контролирует его уникальность.

Синхронизация мобильного приложения c сервером

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

1) На мобильном клиенте происходит инициализация списка коллекций, требующих синхронизации.

2) Получение изменений с сервера. Для каждой коллекции, требующей синхронизации выполняются следующие действия: в получившемся списке коллекций ищется самая большая отметка времени последней синхронизации, если записей нет, то отправляется минимальное значение unix timestamp равное 1970-01-01T00:00:00Z.

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

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

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

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

7) Получение списка локальных изменений на мобильном устройстве для обновления на сервере.

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

Для устранения конфликтов синхронизации, когда изменения были как на мобильном устройстве, так и на сервере используется отметка времени изменения записи на мобильном устройстве. Временная отметка локальной записи сравнивается с отметкой времени из пришедшей от сервера записи. В результате сохраняется актуальность и корректность данных. Упрощенный текст модуля sync-api.js приведен в листинге 2.11

Листинг 2.11 - Модуль sync-api.js

var express = require('express');

var Account = require('../models/account');

var Todo = require('../database/todo');

var router = express.Router();

function prepareAddedTasks(userId, tasks, isCompleted) {}

function prepareTasks(tasks, isCreated) {}

function prepareUpdatedTasks(tasks, isCompleted) {}

function prepareUpdatedTasksResult(updatedTasks) {}

router.post('/add/:token', function onPost(req, res) {});

router.get('/new/:token/:max_updated_timestamp',

function onGet(req, res) {});

router.post('/update/:token', function onPost(req, res) {});

module.exports = router;

Где:

? prepareAddedTasks - функция, которая устанавливает дату последнего изменения у добавленных задач.

? prepareTasks - функция, которая подготавливает списки к отправке.

? prepareUpdatedTasks - функция, которая обновляет дату последнего изменения у обновленных задач.

? prepareUpdatedTasksResult - функция, которая подготавливает обновленные списки задач к отправке.

? router.post('/add/:token', function onPost(req, res)) - функция, которая обрабатывает HTTP запрос POST по пути /sync/add/:token, где token - значение ключа для идентификации пользователя мобильного приложения. В результате обработки запроса на сервере в БД добавляются новые задачи, которые были созданы в мобильном приложении.

? router.get('/new/:token/:max_updated_timestamp', function onGet(req, res)) - функция, которая обрабатывает HTTP запрос GET по пути /sync/new/:token/:max_updated_timestamp, где token - значение ключа для идентификации пользователя мобильного приложения, а max_updated_timestamp - временная отметка последней обновленной задачи на мобильном устройстве. В результате обработки запроса мобильному приложению отправляется список измененных или созданных задач, которые были изменены или созданы после отметки времени max_updated_timestamp.

? router.post('/update/:token', function onPost(req, res)) - функция, которая обрабатывает HTTP запрос POST по пути /sync/update/:token, где token - значение ключа для идентификации пользователя мобильного приложения. В результате обработки запроса на сервере в БД обновляются пришедшие в запросе задачи.

2.3 Реализация мобильного приложения

Выбор поддерживаемых версий платформы Android

Для того чтобы охватить большое количество мобильных устройств, было решено провести анализ того, какие версии платформы Android наиболее часто используются и в каком процентном соотношении. В таблице 2.1 приведена история версий платформы Android. Для анализа использовались данные об относительном количестве устройств, работающих под управлением различных версий платформы Android. Данные собраны в течение 7-дневного периода, закончившегося 1 февраля 2016 года.

Таблица 2.1

История версий платформы Android

Кодовое имя	Версия	Дата выпуска
Cupcake	1.5	April 27, 2009
Donut	1.6	September 15, 2009
Йclair	2.0-2.1	October 26, 2009
Froyo	2.2-2.2.3	May 20, 2010
Gingerbread	2.3-2.3.7	December 6, 2010
Honeycomb	3.0-3.2.6	February 22, 2011
Ice Cream Sandwich	4.0-4.0.4	October 18, 2011
Jelly Bean	4.1-4.3.1	July 9, 2012
KitKat	4.4-4.4.4, 4.4W-4.4W.2	October 31, 2013
Lollipop	5.0-5.1.1	November 12, 2014
Marshmallow	6.0-6.0.1	October 5, 2015

Данные собраны из приложения Google Play, которое поддерживается начиная с версии Android 2.2 и выше, так что устройств, работающих под управлением более старых версий в статистике нет. Тем не менее, в августе 2013, версии старше, чем Android 2.2 составляли около 1% устройств, проверено при помощи серверов Google.

Рис. 2.1 - Диаграмма относительного количества устройств на платформе Android

Таблица 2.2

Относительное количество устройств на платформе Android

Версия	Кодовое имя	API	Количество
2.2	Froyo	8	0.1%
2.3.3 -2.3.7	Gingerbread	10	2.7%
4.0.3 -4.0.4	Ice Cream	15	2.5%
	Sandwich
4.1.x	Jelly Bean	16	8.8%
4.2.x	Jelly Bean	17	11.7%
4.3	Jelly Bean	18	3.4%
4.4	KitKat	19	35.5%
5.0	Lollipop	21	17.0%
5.1	Lollipop	22	17.1%
6.0	Marshmallow	23	1.2%

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

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

Для отображения списка задач было решено реализовать простой экран (Activity) для отображения группы текстовых меток (TextView) в виде списка (ListView) Рис. 2.2

Рис. 2.2 - Экран для списка задач

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

Рис. 2.3 - Экран для добавления новой задачи или изменения существующей

android приложение список задача

Для разработки основного функционала приложения была выбрана архитектура MVC (Model - View - Controller), как наиболее подходящая для этой задачи.

В качестве модели (Model) для приложения выступает класс TodoTaskList, который реализован как Singleton. В данном классе хранится информация о списках задачах, а именно список текущих задач, список завершенных задач и список удаленных задач. Для доступа к спискам задач в этом классе используются внутренние ключи. Эти ключи уникальны в пределах одного экземпляра класса. Соответственно они уникальны для всего приложения, т.к. класс Singleton. Элементами списков являются экземпляры класса TodoTask. В этом классе хранится все информация, необходимая для жизненного цикла задачи, а именно:

? идентификатор задачи в базе данных сервера;

? временная отметка последнего изменения задачи на сервере;

? отметка последнего изменения задачи в мобильном приложении;

? экземпляр класса TodoTaskData.

Класс TodoTaskData представляет собой описание информации, характеризующей задачу, а именно:

? текст задачи;

? название группы, к которой относится задача;

? приоритет задачи;

? флаг, определяющий задачу как удаленную.

При добавлении и изменении задачи, при синхронизации задач с сервером, в качестве контроллера (Controller) используется класс TodoListAdapter. Этот класс взаимодействует с моделью, с базой данных, куда записывается измененная модель, а также с представлением (View). Данный класс содержит методы для обработки добавления новой задачи, изменения, удаления, отметки задачи как завершенной и прочие служебные методы. Сокращенный код этого класса приведен в листинге 2.12

Листинг 2.12 - Класс для работы с задачами

public class TodoListAdapter extends BaseAdapter {

public int getCount() {}

public Object getItem(int position) {}

public TodoTask getItemByKey(String key) {}

public long getItemId(int position) {}

public void addItem(TodoTask item) {}

public void updateItem(String key, TodoTaskData todoTaskData)

{}

private void itemClick(int position) {}

public void deleteTask(String key) {}

public String selectGroup(int position) {}

public void clearTasks() {}

public View getView(final int position, View convertView,

ViewGroup parent) {}

public void updateKeysList() {}

public String getTasksType() {}

public void setTasksType(String tasksType) {}

}

Метод getView в данном классе возвращает представление элемента списка задач. В зависимости от режима отображения (отображать текущие задачи, отображать конкретную группу задач или отображать завершенные задачи) возвращается соответствующий элемент разметки, с текстовой меткой (TextView) и изображением, выступающим в качестве кнопки (Button). Пример такого элемента это task_item_layout.xml, приведен в листинге 2.13

Листинг 2.13 - Пример разметки элемента списка

<Button android:layout_alignParentLeft="true"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:textAppearance =

"?android:attr/textAppearanceMedium"

android:text="Text"

android:textColor="#000000"

android:id="@+id/buttonTask"

android:layout_gravity="left|center_vertical"

android:gravity="left"

android:padding="16dp"

android:background="#ffffff"

android:focusable="true"

android:layout_toLeftOf="@+id/imageButtonEdit"

android:layout_toStartOf="@+id/imageButtonEdit" />

<ImageButton

android:id="@+id/imageButtonEdit"

android:layout_width="wrap_content"

android:layout_height="36dp"

android:paddingTop="24dp"

android:paddingLeft="16dp"

android:paddingRight="16dp"

android:src="@drawable/ic_more_horiz_black_24dp"

...