База данных для мобильного приложения с элементами социальной сети и геолокацией

программирование приложение мобильный

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

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

1. Аналитический обзор

1.1 Актуальность

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

Узкая направленность приложения

Работа с картой и удобное отображение встреч на ней

Удобное создание встреч с указанием цели, времени и места

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

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

1.2 Обзорно-аналитическая часть

Оценка требований

Для разработчика требуется иметь в наличие компьютер или ноутбук с характеристиками не ниже следующих ОС не ниже Windows7, 8 Гб ОЗУ, двухядерный процессор частотой выше 2 Ггц. Устройство на базе Android с ОС v. 4.0 и выше, минимальная разрешающая способность сенсорного экрана 800x480 и доступ в интернет.

Так же необходимо скачать средства разработки как приложения клиента в данном проекте была выбрана android studio, так и для написания серверной части netbeans ide. На данный момент обе эти среды программирования бесплатны. Так же может потребоваться среда разработки eclipse которая так же бесплатна на данный момент.

Для базы данных и последующего веб сервиса нужен сервер. Так как проект основан на энтузиазме и без денежных вложений то был выбран бесплатный хостинг https://cpanelhosting.ru/ и так же за счет того что на нем уже предоставляется установленное ПО и СУБД это так же упрощает разработку серверной части.

Выбор платформы для разработки приложения

В настоящее время почти у каждого смартфон, что делает этот рынок очень прибыльным сейчас и в будущем. Со стороны разработчика для всех популярных мобильных систем есть среды разработки позволяющие создавать приложения под выбранную платформу. Чтобы выбрать платформу был проведен опрос среди целевой аудитории и проанализирована статистика продаж за 2016 год. Статистика продаж предоставлена ниже в соответствии с рисунком 1.1. [9]

Рисунок 1.1. Статистика продажи смартфонов

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

Общее представление о системе Android

Платформа Android представляет собой стек операционнои? системы на основе Linux, для управления устройством (аппаратурой), памятью и Различные компоненты этого стека представляют собой уровней иерархии и, в целом, обеспечивают мобильного устройства.

Архитектуру можно разделить на шесть уровней: уровень оборудования; уровень ядра Linux; уровень нативных библиотек; уровень среды выполнения Android; уровень каркаса приложений (Application Framework); уровень приложений. Ниже на рисунке 1.2 архитектура платформы Android показана более подробно.

Рисунок 1.2. Архитектура платформы Android

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

Уровень каркаса приложений (Application Framework)

Уровень каркаса приложений является связующим звеном между уровнем нативных библиотек и среды выполнения Android и уровнем приложений. Этот уровень предоставляет приложениям интерфейсы (набор Java классов, API) к функциям операционной системы. На этом уровне находятся основные службы Android для управления жизненным циклом приложений, пакетами, ресурсами и т.д. Пользовательские приложения имеют полный доступ к тем же API, что и системные приложения.

Уровень приложений

Мобильное устройство на платформе Android поставляется с набором основных или, другими словами системных приложений (таких как телефон, почта, сообщения, контакты, браузер, карты и т.д.). Так же существует возможность добавлять (устанавливать) сторонние (или пользовательские) приложения в систему. Все эти приложения написаны на языке Java. Важным фактом является то, что в Android нет разницы между системными и сторонними приложениями. Это означает в частности, что любое системное приложение можно заменить альтернативным (сторонним) приложением.

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

Среда разработки приложения Android

Средой разработки была выбрана Android Studio. Она является свободно распространяемой. Языком программирования является JAVA который является родным для платформы андроид, но так же студия предоставляет возможность использования С++. Первая стабильная версия 1.0 была выпущена в декабре 2014 года. [7]

Интерфейс среды представлен ниже на рисунке 1.3.

Рисунок 1.2. Вид среды Android studio

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

2. Техническое предложение

2.1 Анализ технического задания

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

2.2 Возможные решения поставленной задачи

Определившись с тем, что БД должна располагаться, удаленно есть два пути решения этой задачи:

1) На сервере находится БД, и обращения к ней осуществляются напрямую с приложения.

2) На сервере находится БД, и обращения к ней осуществляются через HTTP запросы, а ответы приходят в виде JSON

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

Подключение приложения напрямую к базе данных

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

Рисунок 2.1. Условная схема работы

Плюсы данного метода:

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

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

Минусы:

1) Низкая защищенность. Хостинг, пользователь, пароль к БД хранится непосредственно в приложении и в случае взлома приложения, злоумышленник сможет легко подключиться к БД и делать все что угодно.

2) Любое изменение в логике обработки данных, или изменение БД требует обновления приложения.

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

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

Подключение приложения через веб-сервис к базе данных

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

Рисунок 2.2. Условная схема работы

Плюсы данного метода:

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

2) Легкая масштабируемость. Веб сервис не обязательно должен располагаться на одном сервере с БД, и так же может быть больше одной БД с которыми работает один веб сервис. Все это позволяет такой системе легко масштабироваться, не затрагивая при этом приложения.

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

Минусы:

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

2) Высокие требования к быстродействию. Так как при таком варианте обработка данных происходит на сервере, то быстродействие приложения в целом зависит от скорости обработки данных.

3) Если сервис и БД находятся на разных серверах, то это увеличение трафика так как появляется дополнительный трафик в виде сервис-БД.

Этот подход является основным в настоящее время при построении сервис-ориентированных приложений. И для продукта такой вариант подходит. Построение на такой модели даст более легкую расширяемость системы в дальнейшем и сразу освобождает от привязки к выбранной платформе. [3]

Выбор решения поставленной задачи

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

3. Проектирование базы данных

Для разработки веб-сервиса был выбран язык php так как он сконструирован специально для ведения Web-разработок. Соответственно средой для разработки был выбран NetBeans IDE. Окно создания проекта предоставлено на рисунке 4.1.

Рисунок 4.1. Создание проекта

Далее идет выбор имени проекта, расположения, версии php (если мы создаем проект php) и используемой кодировки рисунок 4.2.

Рисунок 4.2. Выбор параметров проекта

На этом шаге можно нажимать готово и оставить остальное по умолчанию. После Этого мы попадаем в главное окно среды разработки представленное на рисунке 4.3.

Рисунок 4.3. Главное окно среды

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

Как видно из рисунка выше, а именно рисунка 4.3. php код содержит вставки html, но так как цель разработать веб сервис, а не сайт то html код использован не будет. В качестве проверки можно создать php скрипт и загрузить его на сервер, после чего зайти на адрес со скриптом и если все работает, то на экране будет надпись «Привет, я - скрипт PHP!». Пример такого кода ниже

<! DOCTYPE HTML>

<html>

<head>

<title>Пример</title>

</head>

<body>

<? php

echo «Привет, я - скрипт PHP!»;

?>

</body>

</html>[2]

4.2 Определение требований к сервису и разработка функционала

Главная задача сервиса это обеспечить взаимодействие между клиентом и БД соответственно функционал должен следовать этой цели. На данный момент создано пять скриптов которые выполняют основные функции сервиса, а именно:

1) authorization.php скрипт который ответственен за регистрацию пользователя в БД которая включает в себя проверку уникальности логина и выдачи сообщения, если такой логин уже есть. Если проверка на логин прошла, успешна, то данные заносятся в таблицу user и генерируется уникальный токен привязанный к пользователю, который возвращается с сообщением об успехе регистрации. Так же осуществляет хеширование пароля перед занесением его в таблицу.

2) authentication.php скрипт который служит для аутенфикации пользователя и проверки валидности токена, если токен не действителен то генерируется новый токен и выдается пользователю. Время генерации токена берется серверное, и проверка идет тоже согласно времени установленному на сервере. [5]

3) create_meeting.php скрипт который создает встречу в таблице meeting. В качестве подтверждения высылается клиенту сообщение об успехе.

4) Get_meeting.php скрипт получения встреч передаю. тся в JSON в виде массива данных.

5) Join_meeting.php скрипт присоединения к встрече. Заносит данные в таблицу user_meet.

Так как все скрипты работают с БД, то всех присутствует подключение к БД.

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

Рисунок 4.4. Диспетчер файлов

5. Связь приложения и web-service

5.1 Теоретическое описание связи

У нас имеется приложение, установленное на смартфонах и БД расположенная на удаленном сервере. Взаимодействие между ними было выбрано осуществить через веб сервис, описание которого приведено выше. Запрос от приложения к серверу будет осуществляться через HTTP, а сервер в ответ отсылать JSON содержащий ответ сервера. Условно взаимодействие показано ниже на рисунке 5.1.

Рисунок 5.1. Взаимодействие приложения и сервиса

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

5.2 Создание связи

Так как моя задача спроектировать БД и написать сервис для взаимодействия я не создавал класс для связи мобильного приложения. Мною был написан класс JAVA который посылает HTTP запрос на сервер, получает ответ в виде JSON и выводит его в буфере обмена, среды JAVA которая запускается с компьютера. Этот класс я послал разработчику мобильного приложения, а так приложение android тоже пишется на JAVA то этого класса хватило чтобы понять суть связи. Я же в дальнейшем использовал приложения на JAVA для тестирования работоспособности и корректности выполнения скриптов.

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

6. Выбор сервера для размещения системы

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

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

Рисунок 7.1. Время, которое измеряется

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

Время, которое запрос идет к серверу, и обратно измерим путем разницы между двумя полученными результатами оператора System.out.println (System.currentTimeMillis());, который выводит время в миллисекундах. Между ними расположим запрос к скрипту который просто возвращает «1» в JSON, сделано это для того чтобы время T2 при этом не учитывалось. В результате нескольких тестов получилось среднее время равным 90 миллисекунд, надо учитывать, что так нечего не посылалось в запросе, то при пересылке больших данных и приеме большого числа данных это время увеличится.

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

8. Развитие проекта. Масштабирование