Android сервис

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

Оглавление

Определения, обозначения и сокращения

Введение

Глава 1. Исследование рынка и особенности архитектуры Android приложений

1.1 Сервисы для организации и поиска событий

1.2 Обзор существующих решений

1.3 Описание архитектуры Android приложений

1.4 Основные компоненты Android

1.5 Жизненные циклы

Глава 2. Архитектура и основные технологии приложения

2.1 Архитектура приложения

2.2 Работа с HTTP запросами

2.3 Схема базы данных

Глава 3. Разработка мобильного приложения

3.1 Инструменты разработки

3.2 Код приложения

3.3 Дизайн

3.4 Работа с сетью

3.5 Работа с картами и изображениями

3.6 Авторизация в приложении

3.7 Сбор аналитики

3.8 Обработка ссылок

3.9 Работа с системой Android

3.9 Интерфейс приложения

Заключение

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

Приложения



Определения, обозначения и сокращения

android приложение мобильный архитектура

Сокет - программный интерфейс, обеспечивающий обмен данными между объектами.

Тэг - идентификатор для категоризации, описания, поиска данных внутри определенной системы.



Введение

Количество интересных мест, событий, заведений в каждом городе мира растет с каждым днём. И если человек живет в большом городе (например, Москва), то выбрать куда пойти в свое свободное время становится порой большой проблемой.

Еще более явной является эта проблема для туристов, оказавшихся в незнакомом городе. Последние годы все самые крупные компании, такие как Apple, Google, Яндекс добавили в свои сервисы функционал для решения вышеописанных проблем.

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

Получать больше рекомендаций.

Получать постоянные обновления о новых событиях.

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

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

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

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

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

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

Глава 1. Исследование рынка и особенности архитектуры Android приложений

В этой главе приводится исследование рынка сервисов для поиска событий, а также описание архитектуры Android приложений.

1.1 Сервисы для организации и поиска событий

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

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

Пользователь может каким-то образом сохранить себе это событие (вступить, подписаться, добавить в избранное и т.д.)

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

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

1.2 Обзор существующих решений

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

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

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

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

Рисунок 1. Создание события ВКонтакте

События в данном случае являются достаточно масштабными (концерты, фестивали, конференции и т.д.), из чего следует первый существенный недостаток событий в социальных сетях - пользователи не могут создавать и искать события, рассчитанные для двоих/троих людей, например, поход в кино. Точнее будет сказать, что создать такое событие можно, теоретически его можно и найти, однако оно не является “правильным” использованием событий в Вконтакте и Facebook. Для такого вида событий обычно существуют сообщества для поиска спутников, которых достаточно много в вышеназванных социальных сетях.

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

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

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

Рисунок 2. Страница события Facebook

Одним из самых “опытных” и развитых игроков на рынке сервисов для организации и поиска событий является EventBrite.

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

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

Рисунок 3. Интерфейс EventBrite

Другим интересным решением является приложение Fever.

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

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

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

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

Рисунок 5. Интерфейс Fever

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

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

Рисунок 6. Логотип SongKick

Рисунок 7. Логотип HeyLets

Ниже представлена таблица с кратким описанием основных “игроков” рынка сервисов для поиска событий.



Таблица 1 - Краткий обзор существующих сервисов

Название	Аудитория	Карта	Создание событий	Доступен во всем мире	Специфично	Покупка билетов	Рекомендации
Songkick	50k	+	-	+	+	+	+
DoStuff	15k	+	-	-	-	-	+
Bandsintown	10m	-	-	+	+	+	+
Jukely	10k	+	-	-	+	+	+
Applauze	50k	-	-	-	-	+	+
Fever	1m	-	-	-	-	+	+
ShowApp	1k	-	+	+	-	-	+
EventBrite	10m	+	+/-	+	-	+	+
Heylets	10k	+	-	+	-	+/-	+
Mates	-	+/-	+	+/-	-	+/-	+

На основании этой таблицы и всего вышенаписанного выделим основные функции разрабатываемого сервиса:

Возможность коммуникации внутри приложения;?

Обмен сообщениями между пользователями;

Комментирование событии?;

Рассылка приглашении?;

Лента событии?, основанная на интересах пользователя и интересах его друзеи? внутри приложения;

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

Функциональный? поиск событии? внутри приложения(по дате, категории и т.д.);

Функциональный? профиль пользователя, дающии? достаточно информации о человеке;

Возможность создания событий;

Система рекомендаций событий;

Сбор аналитики внутри приложения(Количество установок, количество сбоев, количество отправленных уведомлений, количество открытий каждого из экранов приложения);

Добавление друзей из социальных сетей в приложении.

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

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

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

1.3 Описание архитектуры Android приложений

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

Android - это операционная система, основанная на Linux, созданная для поддержки разных устройств. Архитектура Android состоит из пяти частей:

Ядро Linux

Слой HAL - Hardware abstraction layer - слой, содержащий библиотеки для работы системами мобильного устройства, например с камерой.

Native libraries и Android runtime - слой содержащий множество библиотек, в частности OpenGL для доступа к сложной графике и средства для работы с базами данных, а также Android ART.

Java API Framework - слой, содержащий библиотеки, которые разработчики могут использовать у себя в коде, все основные возможности системы именно на этом слое. Разработчикам доступны все те же функции, что и встроенным - системным приложениям Android. Если разработчики хотят, они могут также пользоваться Android NDK, для использования нативных библиотек в C/C++ коде.

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

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

Рисунок 8. Архитектура Android

1.4 Основные компоненты Android

Android состоит из нескольких основных компонентов: Activity, Service, Fragment, Intent, ContentProvider.

Activity - основной класс, представляющий конкретное представление экрана. Activity может содержать внутри множество Fragment-ов и элементов - View. Android формирует стэк activity, благодаря чему мы можем передвигаться между ними с помощью системной кнопки - назад. Activity может быть запущено и другим приложением, если разработчик добавит такую возможность.

Fragment - класс, который предоставляет похожие на activity возможности, однако сам по себе не является экраном, а является его частью. Обычно используется для часто изменяемых частей activity (например, pager - элемент, который переключает страницы движениями пальцами вправо-влево - каждая страница внутри pager представляется фрагментом). Fragment может содержать в себе другие фрагменты и view, однако Android не предоставляет стэка фрагментов, поэтому системная кнопка “назад” никак не влияет на фрагменты, разработчик должен сам реализовывать стэк, если ему это нужно.

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

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

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

Кроме того Android предоставляет “приемщик сообщений” - Broadcast Receiver - компонент принимающий определенные сообщения приложению. Типичный пример использования - обработка уведомлений.

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

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



1.5 Жизненные циклы

Activity, fragment, service обладает определенным жизненным циклом внутри Android.

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

Рисунок 9. Activity lifecycle

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

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

Помимо этого описана архитектура системы Android, ее основные компоненты и их жизненный цикл.



Глава 2. Архитектура и основные технологии приложения

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

2.1 Архитектура приложения

В качестве архитектуры приложения при разработке была выбрана архитектура MVP - Model - View - Presenter.

Суть данного шаблона проектирования состоит в том, что архитектура разделяется на 3 раздела:

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

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

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

Рисунок 10. MVP

Код разделен на независимые разделы для работы с HTTP запросами, моделями, адаптерами списков (Adapter - класс, реализующий заполнение списка RecyclerView) и самих экранов.

Помимо описанного выше также реализуются стандартные шаблоны Android - например, View holder - шаблон, позволяющий переиспользовать view в списках RecyclerView.

Данный шаблон реализует интерфейс, который разделяет работу со списком на два принципиально разных метода: onCreateViewHolder - вызывается для создания нового view для списка (не вызывается для каждой из ячеек списка) и onBindViewHolder - метод для установки информации в ячейке на основе модели (вызывается для каждой ячейки в списке). Сами данные хранятся в виде списка в качестве поля массива, а элементы view хранятся в специальном классе ViewHolder, создаваемом в методе onCreateViewHolder.

Каждое activity в приложении наследуется от базового класса BaseActivity, представляющего возможность показывать всплывающие подсказки, которые являются одинаковыми для всех экранов (например, сообщение об отсутствии интернет соединения).

2.2 Работа с HTTP запросами

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

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

Запросы реализованы с помощью REST модели, в качестве формата данных, служащих для связи с сервером, используется JSON.

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



Рисунок 11. REST модель

Singleton - это шаблон проектирования, гарантирующий, что порожденный объект будет создан в единственном экземпляре во время выполнения программы.

Рисунок 12. Singleton pattern

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

Каждый model класс содержит метод, позволяющий получить экземпляр модели из JSON строки. Таким образом работа с сетью полностью отделена от логики работы с экраном.

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



Рисунок 13. Long polling

Long polling - вид связи с сервером, при котором сервер вместо мгновенного ответа на запрос запускает цикл и на каждой итерации проверяет возникновение новой информации, в случае чего отправляет её клиенту.

2.3 Схема базы данных

База данных на сервере содержит сущности, представленные в следующей таблице:

Таблица 2 - База данных

Название сущности	Поля	Описание
activities	integer "receiver_id" string "code" integer "invite_id" integer "submission_id" integer "friend_request_id" datetime "created_at", null: false datetime "updated_at", null: false	Активность
categories	string "name" datetime "created_at", null: false datetime "updated_at", null: false	Категория события
comments	string "content" integer "user_id" integer "event_id" datetime "created_at", null: false datetime "updated_at", null: false integer "respondent_id"	Комментарий
device_tokens	string "token" string "platform" integer "user_id" datetime "created_at", null: false datetime "updated_at", null: false	Токен устройства (используется для отправки push уведомлений)
events	string "name" datetime "starts_at" string "city" float "latitude" float "longitude" text "description" string "visibility" datetime "created_at", null: false datetime "updated_at", null: false string "address" integer "creator_id" string "photo" integer "category_id" integer "user_limit" integer "min_age" integer "max_age" string "gender" string "sharing_url" integer "extra_category_id" integer "memberships_count", default: 0, null: false datetime "deleted_at"	Событие
friend_requests	integer "user_id" integer "friend_id" datetime "created_at", null: false datetime "updated_at", null: false boolean "accepted"	Заявка в друзья
friendships	integer "user_id" integer "friend_id" datetime "created_at", null: false datetime "updated_at", null: false	Связка пользователей, принявших друг друга в друзья
interests	integer "category_id" integer "user_id" datetime "created_at", null: false datetime "updated_at", null: false	Интересы пользователя (выбранные им при регистрации категории интересующих его события)
invites	integer "user_id" integer "event_id" datetime "created_at", null: false datetime "updated_at", null: false boolean "accepted"	Приглашение
memberships	integer "user_id" integer "event_id" datetime "created_at", null: false datetime "updated_at", null: false	Членство в событии
photos	integer "user_id" string "image" datetime "created_at", null: false datetime "updated_at", null: false	Фотография
reports	text "content", null: false t.integer "user_id" t.integer "event_id" t.datetime "created_at", null: false t.datetime "updated_at", null: false	Жалоба
searches	string "name" integer "category_id" string "visibility" datetime "min_starts_at" datetime "max_starts_at" datetime "created_at", null: false datetime "updated_at", null: false date "dates", array: true float "latitude" float "longitude" integer "distance" integer "category_ids", array: true integer "user_id"	Запрос на поиск события или пользователя
submissions	integer "user_id" integer "event_id" datetime "created_at", null: false datetime "updated_at", null: false boolean "accepted"	Заявка на событие
users	string "first_name" string "last_name" date "birthday" string "gender" string "api_token" datetime "created_at", null: false datetime "updated_at", null: false string "avatar" string "city" string "phone_number" datetime "visited_at" string "avatar_original" string "website_url" boolean "notifications_friends", default: true, null: false boolean "notifications_events", default: true, null: false string "vk_id" string "fb_id" string "tw_id" string "sharing_url"	Пользователь
verification_tokens	string "token" string "phone_number" string "code", null: false boolean "verified" datetime "created_at", null: false datetime "updated_at", null: false	Токен проверки авторизации

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



Глава 3. Разработка мобильного приложения

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

3.1 Инструменты разработки

Для разработки проекта используется среда Android Studio. Эта среда рекомендована Google для разработки приложений под Android и предоставляет все необходимые технологии и языки.

В качестве языков разработки использовались Java, как основной язык для разработки под Android, а также Kotlin, представляющий такие важные свойства, как null-safety. Кроме того Kotlin позволяет существенно сократить количество кода в некоторых местах программы (например, при написании моделей).

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

Для контроля версий использовался Git и GitHub.

При разработке приложения также использовались разные библиотеки, упрощающие работу с системой Android. В частности использовалась библиотека Picasso для работы с изображениями. Она позволяет, используя несколько строк кода, загрузить изображение в ImageView, предоставляет инструменты для кэширования изображений, а также для их преобразования. Для работы с push уведомлениями использовалась библиотека Airship, гарантирующая (в отличие от стандартного решения от Google) доставку уведомлений пользователям. Помимо этого для разработки дизайна экранов использовалась Google Android support library.

Для работы с http запросами используется библиотека Retrofit. Для работы с сокетами AndroidAsync.

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

Таблица 3 - Api сервера

PATCH users/{id}	Метод для обновления данных о текущем пользователе
POST events	Метод для создания события
PATCH events/{id}	Метод для обновления события
POST users	Метод для создания пользователя
POST searches	Метод для поиска событий
POST reports	Метод для отправки жалобы
GET users/search	Метод для поиска людей
GET offers	Метод для получения предложений
GET offers/number_of_incoming	Метод для получения количества непрочитанных предложений
GET friend_requests/number_of_incoming	Метод для получения количества непрочитанных заявок в друзья
GET events/{id}/available_friends	Метод для получения пользователей, которых возможно пригласить на событие
GET feed/recommended	Метод для получения событий, рекомендованных пользователю
GET feed/friends	Метод для получения событий, в которых учавствуют друзья
GET activity	Метод для получения истории действий пользователя
GET users/{id}	Метод для получения информации о пользователе
GET events/{id}	Метод для получения информации о событии
GET users/{id}/friends	Метод для получения списка друзей пользователя
GET users/{id}/memberships	Метод для получения списка событий, в которых учавствует пользователь
GET events/{id}/comments	Метод для получения комментариев события
GET events/{id}/memberships	Метод для получения участников события
GET friend_requests	Метод для получения заявок в друзья
POST events/default_photo	Метод для получения стандартной фотографии при создании события (в случае если пользователь не выбрал фотографию)
DELETE invites/{id}	Метод для удаления приглашения
DELETE submissions/{id}	Метод для удаления заявки на событие
PATCH invites/{id}/decline	Метод для отклонения приглашения
PATCH friend_requests/{id}/decline	Метод для отклонения заявки в друзья
PATCH submissions/{id}/decline	Метод для отклонения заявки на событие
PATCH friend_requests/{id}	Метод для принятия заявки в друзья
DELETE friend_requests/{id}	Метод для удаления заявки в друзья
DELETE events/{id}	Метод для удаления события
DELETE comments/{id}	Метод для удаления комментария
DELETE memberships/{id}	Метод для удаления участника события
DELETE friends/{id}	Метод для удаления друга
POST friend_requests	Метод для создания заявки в друзья
POST events/{id}/comments	Метод для создания комментария
PATCH invites/{id}	Метод для принятия приглашения
PATCH submissions/{id}	Метод для принятия заявки на событие
POST events/{id}/submissions	Метод для создания заявки на событие
POST events/{id}/invites	Метод для создания приглашения
POST social_tokens	Метод для автозирации через социльную сеть

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

3.2 Код приложения

В ходе работы над приложением были разработаны классы, представленные в таблице ниже:

Таблица 4 - Таблица классов

CreateAccountActivity	Класс, описывающий экран создания нового аккаунта
EditEventActivity	Класс, описывающий экран редактирования события
EditProfileActivity	Класс, описывающий экран редактирования профиля
FeedActivity	Класс, описывающий экран с основной лентой событий
InviteActivity	Класс, описывающий экран отправки приглашения на событие
InviteFriendsActivity	Класс, описывающий экран отправки приглашений друзьям из социальных сетей в приложение
LicencesActivity	Класс, описывающий экран со списком лицензий, используемых в приложении
MyProfileActivity	Класс, описывающий экран профиля авторизованного пользователя
NewEventActivity	Класс, описывающий экран создания нового события
OffersActivity	Класс, описывающий экран с лентой приглашений и заявок на события
PhotoActivity	Класс, описывающий экран просмотра полноразмерной фотографии
PickCategoryActivity	Класс, описывающий экран выбора категории при создании события
ProfileActivity	Класс, описывающий экран профиля пользователя
ReportActivity	Класс, описывающий экран отправки жалобы на событие или пользователя
SearchEventActivity	Класс, описывающий экран поиска событий
SearchPeopleActivity	Класс, описывающий экран поиска пользователей
SettingsActivity	Класс, описывающий экран отправки приглашения на событие
SplashActivity	Класс, описывающий экран загрузки данных в приложении
StartActivity	Класс, описывающий экран стартовой страницы приложения
TextActivity	Класс, описывающий экран просмотра текста
TimeLineActivity	Класс, описывающий экран ленты активности пользователя
ActivityAdapter	Класс, описывающий интерфейс создания списка активностей пользователя
CommentsAdapter	Класс, описывающий интерфейс создания списка комментариев на экране события
EventMembersAdapter	Класс, описывающий интерфейс создания списка участников события
EventTypesAdapter	Класс, описывающий интерфейс создания списка категорий событий
FeedAdapter	Класс, описывающий интерфейс создания списка событий
IncomingOffersAdapter	Класс, описывающий интерфейс создания списка входящих приглашений
InviteFriendsAdapter	Класс, описывающий интерфейс создания списка друзей, доступных для приглашения на событие
LicencesAdapter	Класс, описывающий интерфейс создания списка лицензий, используемых в приложении
MyProfileFriendsAdapter	Класс, описывающий интерфейс создания списка друзей на экране моего профиля
OutgoingOffersAdapter	Класс, описывающий интерфейс создания списка исходящих приглашений
PickUserAdapter	Класс, описывающий интерфейс создания списка пользователей с возможностью выбора
UsersAdapter	Класс, описывающий интерфейс создания списка пользователей
AuthorizationActivity	Класс, описывающий экран авторизации в приложении
App	Класс, описывающий базовый интерфейс приложения
BaseActivity	Класс, описывающий базовый интерфейс экрана
BaseEmptyViewFragment	Класс, описывающий базовый интерфейс фрагмента
BaseProfileActivity	Класс, описывающий базовый интерфейс экрана профиля
InternetConnectionDependentActivity	Базовый класс, реализующий методы для показа сообщения об ошибке интернет соединения
AvatarView	Класс, описывающий стандартный аватар пользователя (круг и заглавные первые буквы имени и фамилии)
RecyclerListView	Класс, описывающий базовый интерфейс списков
SquareView	Класс, описывающий элемент интерфейса с одинаковыми шириной и высотой
CommentsFragment	Класс, описывающий фрагмент с комментариями на экране события
EventInfoFragment	Класс, описывающий фрагмент с основной информацией на экране события
MembersFragment	Класс, описывающий фрагмент со списком участников на экране события
FriendsFeedFragment	Класс, описывающий фрагмент со списком событий друзей пользователя
SuggestFeedFragment	Класс, описывающий фрагмент со списком рекомендованных событий
EventsHelpFragment	Класс, описывающий фрагмент с обучающие подсказки на экране со списком событий
MyProfileHelpFragment	Класс, описывающий фрагмент с обучающие подсказки на экране моего профиля
OffersHelpFragment	Класс, описывающий фрагмент с обучающие подсказки на экране предложений
IncomingOffersFragment	Класс, описывающий фрагмент со списком входящих предложений
OutgoingOffersFragment	Класс, описывающий фрагмент со списком исходящих предложений
ProfileEventsFragment	Класс, описывающий фрагмент со списком событий на экране профиля
ProfileFriendsFragment	Класс, описывающий фрагмент со списком друзей пользователя
ActivityLoader	Класс, описывающий интерфейс загрузки информации на экран активности пользователя
FeedLoader	Класс, описывающий интерфейс загрузки информации на экран со списком событий
ProfileLoader	Класс, описывающий интерфейс загрузки информации на экран профиля пользователя
UsersStack	Класс, описывающий стэк открытых экранов профиля
ActivityItem	Класс, описывающий модель активности
ActivityType	Перечисление, описывающее тип активности
AppColors	Класс, хранящий основные цвета, используемые в приложении
Comment	Класс, описывающий модель комментария
Event	Класс, описывающий модель события
EventCategory	Перечисление, описывающее категорию события
EventStatus	Перечисление, описывающее доступность события (приватное, публичное и т.д.)
EventTypeValues	Класс, описывающий методы для получения данных о событии
EventUser	Класс, описывающий модель участника события
FriendRequest	Класс, описывающий модель заявки в друзья
Gender	Перечисление, описывающее пол пользователя
ListEvent	Класс, описывающий модель события
ListUser	Класс, описывающий модель пользователя
Membership	Класс, описывающий модель членства в событии
Offer	Класс, описывающий модель предложения
OfferType	Перечисление, описывающее тип предложения
SmallEvent	Класс, описывающий модель события
User	Класс, описывающий модель пользователя
CustomFactory	Класс, описывающий создание уведомления
MatesAirshipReceiver	Broadcast Receiver для приёма уведомлений
ApiEndpoints	Интерфейс, описывающий методы для работы с сервером
CustomTwitterApiClient	Интерфейс, описывающий методы для работы с api Twitter
DeviceInfoStore	Класс для работы с внутренним хранилищем Android
ServerApi	Singleton для работы с сервером
ServerConfig	Класс, хранящий конфигурацию сервера и внутреннего хранилища Android
Utils	Класс, содержащий вспомогательные методы для работы с сервером
ShareUtility	Класс, реализующий методы для распространения информации о приложении
AndroidUtilities	Класс для работы с Android
Animations	Класс, содержащий методы для анимаций в приложении
AnimationStartListener	Базовый класс для работы с анимациями
AppConfig	Класс, содержащий параметры приложения
AppUtil	Класс, содержащий вспомогательные методы для работы с приложением
CancelableThreadObject	Класс, содержащий данные произвольного типа с возможностью отмены исполнения операции внутри потока
CodeTimer	Класс, описывающий интерфейс таймера
DateUtils	Класс, содержащий вспомогательные методы для работы с датами
Image	Класс, содержащий методы для работы с изображениями
LogUtil	Класс, содержащий методы для работы с системой логирования Android
OnOperationFinishedListener	Интерфейс, содержащий методы для отслеживания окончания операций внутри приложения
ParseHelper	Класс, содержащий методы для парсинга данных с сервера
UnreadIndicators	Класс, содержащий информацию о непрочитанных уведомлениях
EventActivity	Класс, описывающий экран события

3.3 Дизайн

При разработке дизайна за основу были взяты наработки от предыдущих версий, а также Material design guidelines. Цветовая палитра белый-черный-розовый.

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

Кроме того в приложении используются нестандартные элементы библиотеки, такие как CoordinatorLayout и FloatingActionButton. CoordinatorLayout позволяет реализовать поведение экрана, как на рисунках 23 и 24, когда заголовок экрана “заезжает” за основной список.

Рисунок 19. Экран события - 1



Рисунок 20. Экран события - 2

Рисунок 21. Мой профиль-1

Рисунок 22. Мой профиль-2



Рисунок 23. Первый вариант дизайна -1

Рисунок 24. Первый вариант дизайна -2

3.4 Работа с сетью

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

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

Для описания запросов в Retrofit используется следующий формат описания метода интерфейса:

@<Операция(GET, POST)>("<url запроса без учета базового адреса сервера(он указывается при создании объекта для работы с интерфейсом)>")

Call<[Тип возвращаемого значения]> [Имя метода](@Query("api_token") String token - параметры запроса);

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

Retrofit retrofit = new Retrofit.Builder()

.client(initClient(context))

.baseUrl(ServerConfig.INSTANCE.getApiURL())

.addConverterFactory(GsonConverterFactory.create())

.build();

apiService = retrofit.create(ApiEndpoints.class);

Далее в коде можно обращаться к этому синглтону для вызова методов интерфейса.

Для реализации long polling запросов необходимо поставить timeout запроса на 60 секунд.

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

В приложении запросы long polling работают следующим образом: при входе на экран события (запросы long polling используются в приложении для работы комментариев на экране события) приложение отправляет инициирующий запрос на сервер. После этого каждые 60 секунд запрос завершается и сервер присылает либо пустой ответ либо список новых комментариев. После этого запрос реинициируется и снова ждет 60 секунд. При выходе из экрана приложение отправляет запрос на прекращение связи с сервером и подключение закрывается.

Для работы с сокетами в приложении используется библиотека Android Async. Библиотека позволяет отправлять как стандартные http запросы, так и работать со всеми видами сокетов - udp, tcp и web socket.

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

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

Рисунок 14. Интерфейс диалогов

Рисунок 15. Уведомления

В коде необходимо реализовать специальный Broadcast Receiver для обработки уведомлений. В качестве обертки над Firebase используется сервис Airship. Сервис является платным, однако решает основные проблемы Firebase и добавляет больше возможностей. Во первых сервис обеспечивает гарантированную доставку push уведомлений, так как стандартный интерфейс Firebase не гарантирует их доставку пользователю. Во вторых Airship позволяет разделить уведомления на категории, а также отправлять их по местоположению. Кроме того Airship позволяет просмотреть статистику уведомлений.

@Override

protected void onPushReceived(@NonNull Context context, @NonNull PushMessage message, boolean notificationPosted) {

try {

Bundle bundle = message.getPushBundle();

String action = bundle.getString("action", "null");

int count = Integer.parseInt(bundle.getString("count", "0"));

switch (action) {

case "FRIEND_REQUEST": {

UnreadIndicators.friends = count;

break;

}

case "INVITE": {

UnreadIndicators.offers = count;

break;

}

case "NEW_SUBMISSION": {

UnreadIndicators.offers = count;

break;

}

}

EventBus.getDefault().post(new BaseActivity.MessageEvent());

} catch (Exception e) {

}

}



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

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

В приложении таким классом является базовый класс BaseActivity, что позволяет обновлять индикаторы на любом экране в приложении.

@Subscribe(threadMode = ThreadMode.MAIN)

fun onMessageEvent(event: MessageEvent) {

try {

setIndicators()

} catch (e: Exception) {}

}

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

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



3.5 Работа с картами и изображениями

Для работы с фотографиями и картинками внутри приложения используется библиотека Picasso (созданная теми же разработчиками, что и Retrofit). Данная библиотека позволяет загружать фотографии в ImageView из интернета или с устройства используя всего одну строку кода, а также позволяет преобразовывать изображение после загрузки (rotate, scale).

Picasso.with(context)

.load(path)

.fit()

.centerCrop()

.into(imageView, callback);

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

Для отображения превью карты на экране события с меткой проведения события используется сервис Google static map. Он позволяет получить в виде изображения участок карты с меткой, указанной в запросе.

Для выбора места проведения события на экране создания события используется специальный view, предоставляемый Google - PlacePicker. Это отдельный экран с картой, на которой отмечены популярные места, как то было бы в официальном приложении Google Maps. Разработчик может, используя всего лишь несколько строк кода, вызвать этот экран для того, чтобы пользователь выбрал необходимое местоположение. Кроме того, этот вызываемый экран можно стилизовать, используя основные цвета приложения.



Рисунок 16. Google PlacePicker

PlacePicker.IntentBuilder builder = new PlacePicker.IntentBuilder();

startActivityForResult(builder.build(NewEventActivity.th is), 3);

3.6 Авторизация в приложении

Для авторизации в приложении было решено использовать социальные сети - Facebook, Вконтакте и Twitter.

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

Для авторизации используются библио...