Главная страница

Разработка мобильного приложения «Регистрация заказов в службе доставки». Исследование и ее проектирование 4 1 Формулировка и описание и задачи 4


Скачать 1.94 Mb.
НазваниеИсследование и ее проектирование 4 1 Формулировка и описание и задачи 4
АнкорРазработка мобильного приложения «Регистрация заказов в службе доставки
Дата06.09.2022
Размер1.94 Mb.
Формат файлаdocx
Имя файла27062(1).docx
ТипИсследование
#664482
страница2 из 4
1   2   3   4

1.2 Разработка требования к программному продукту


Данное приложение должно предоставлять возможность пользователям:

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

  • просматривать информацию по выполняемым заказам и проводить операции с ними: отменить заказ или передать заказ другому курьеру, указать время прибытия к клиенту или оповестить клиента, что курьер не может с ним связаться;

  • получить оповещение (например, о том, что через 30 минут курьеру нужно быть на указанном адресе, чтобы взять посылку);

  • пополнить баланс для работы;

  • просмотреть информацию о работе в приложении.


1.3 Проектирование мобильного приложения «Регистрация заказов в службе доставки»


Приложение должно состоять из ряда страниц:

  • страница с доступными заказами;

  • страница с активными заказами;

  • страница с информацией о работе в «Ptichka»;

  • страница с уведомлением для пользователя;

  • страница с информацией о балансе пользователя.

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

2.1 Проектирование web api


Приложение должно предоставлять возможность определения геолокации пользователя и отправки ее на сервер.

Приложение должно иметь возможность взаимодействовать с вебсервером путем отправления запросов к нему за информацией о:

  • доступных пользователю заказах;

  • выполняемых пользователем в данный момент заказах;

  • завершенных заказах пользователем за последние 48 часов;

  • текущем балансе пользователя;

  • истории операций, проводимых с балансом пользователя;

  • материалах, содержащих информацию о работе «Ptichka».

Передаваемая и получаемая информация должна быть представлена в формате JSON.

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

Приложение должно иметь возможность получать push-уведомления от сервера, содержащие информацию о:

  • новом доступном заказе;

  • отмене клиентом заказа, который выполняет пользователь;

  • уведомлении для пользователя.

Приложение должно быть доступно на:

  • Android версии 4.4 или более поздней;

  • IOS версии 9.0 или более поздней;


2.2 Сравнительный анализ СУБД


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

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

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

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

Возможные варианты реализации приложения:

  • проектировать и реализовывать приложение для каждой платформы отдельно на нативных языках: Java для Android и Swift для IOS;

  • использовать технологии, позволяющие писать один код для обеих платформ.

Создание приложения для каждой платформы отдельно имеет ряд плюсов:

  • приложение будет оптимизировано: быстрый запуск и быстрая работа, а также малый размер установочного файла;

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

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

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

Данный подход позволяет

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

  • переиспользовать написанный код;

  • легко добавлять новый функционал и обновлять версии существующих приложений;

Среди таких технологий самыми популярными и развитыми являются Xamarin и React Native. Обе технологии являются фреймворками для разработки кроссплатформенных приложений и позволяют определять один пользовательский интерфейс и привязывать к нему единственную логику приложения для разных платформ [1].

При использовании Xamarin исходный код приложения пишется на языке C#. При использовании React Native исходный код реализуется на языке JavaScript.

В связи с наличием практического опыта разработки с использованием JavaScript и его технологий, и отсутствие такового в разработке с использованием C#, было принято решение реализовывать приложение при с использованием React Native.

React Native – это фреймворк для разработки кроссплатформенных приложений для IOS и Android от компании Facebook.

На протяжении всего периода разработки и поддержки проекта, с использованием этого фреймворка, разработчик работает с кодовой базой, написанной на JavaScript. При необходимости написанный код компилируется в нативные форматы: .apk для Android и .ipa для IOS, которые можно будет добавить в магазины: PlayMarket для Android и Appstore для IOS, где их смогут загрузить потенциальные пользователи.

Проектирование архитектуры приложения, описание классов, функций, методов реализуется основываясь на функционале и возможностях этого языка. React Native никак не ограничивает разработчика в использовании JavaScript – фреймворк лишь предоставляет элементы, которые могут быть скомпилированы в нативные и методы для работы с функциями мобильного устройства: получение геолокации, работа с камерой устройства, доступ к локальному хранилищу устройства и тд. [2].

Поэтому все преимущества работы с JavaScript, также доступны и в разработке мобильных приложений, используя React Native:

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

  • JavaScript имеет низкий порог вхождения: этот язык можно изучить в короткие сроки и сразу же начать писать код для решения реальных задач;

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

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

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

Как было описано ранее, использование React Native не накладывает никаких ограничений на структуру проекта и работу с JavaScript. Поэтому можно было использовать разные архитектурные подходы при реализации приложения.

При создании приложения было принято решение использовать Flux, как архитектурный подход. Такое решение было обосновано:

  • наличием опыта работы с данным подходом ранее;

  • популярностью Flux в сообществе разработчиков. Поэтому в большинстве примеров и обучающих материалах (в том числе по React Native) использовался именно он;

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

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

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

Flux-архитектура состоит из трех компонентов:

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

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

  • действие – простой объект. На самом деле, может иметь любую структуру, но общепринято имеет два поля: поле, определяющее тип действия, и поле, хранящее данные для этого действия. Тип действия представляется строкой, в зависимости от типа будет вызван нужный обработчик в хранилище. Данные для действия представлены объектом с произвольной структурой.

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

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

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

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

Язык программирования JavaScript имеет динамическую типизацию: типы для всех переменных определяются уже во время выполнения программы [4]. Этой несет за собой большие недостатки при создании приложений на нем:

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

класса [5];

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

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

Ускорить работу JavaScript не предоставляется возможным, но возможность добавить статическую типизацию в процесс разработки приложения на нем есть. Существует ряд технологий, позволяющих реализовать статический контроль типов в языке JavaScript. Самыми популярными на данный момент является TypeScript от компании Microsoft и Flow от компании Facebook. Обе технологии являются статическими типизаторами кода и предоставляют набор синтаксических конструкций, для прямого указания типа переменной [6].

В связи с тем, что Flow существенно проще интегрировать в проект, чем TypeScript и то, что его разрабатывает та же компания, что и используемый при разработке фреймворк React Native, а из этого следует, что поддержка React Native у Flow лучше, чем у TypeScript, было принято использовать при разработке именного его.

Expo – это набор утилит, библиотек и сервисов, упрощающих разработку на React Native. Использование Expo при разработке мобильных приложений с React Native избавляет от решение некоторых технических вопросов, и также позволяет использовать дополнительный функционал при разработке и после создания приложения [7]:

  • для компиляции JS-файлов в формат исполняемых файловприложений (.apk/.ipa) не будут требоваться инструменты для нативной разработки (такие как Xcode для IOS и Android Studio для Android). Компиляция JavaScript кода в исполняемые файлы будет происходить на сервере Expo. После завершения установочный файл можно будет загрузить с сервера на свой компьютер. Данное преимущество очень весомое, как минимум из-за того, что Xcode, который необходим для сборки приложений под IOS, может быть установлен только на устройствах с операционной системой MacOS;

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

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

  • еще одной особенностью Expo является обновление приложения, установленного на устройстве, в реальном времени: после сборки и публикации новой версии, все приложения, ранее установленные пользователями, будут обновлены. Это очень мощный функционал, он решает одну из главных проблем в мобильной разработке - совместимость между версиями. Без возможности обновления приложений в реальном времени, при выпуске новых версий для него всегда нужно реализовывать совместимость со старыми, так как пользователи не всегда сразу же обновляют установленные приложения [8].
    1. 1   2   3   4


написать администратору сайта