Информационная, Техническая информация

Мобильное приложение доставки еды

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

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

  1. Авторизация, регистрация пользователей
  2. История заказов
  3. Отображение информации о заказе
  4. Служба поддержки
  5. Нотификации
  6. Интеграция с API сервиса
  7. Тестирование и доработка
  8. Логирование с отправкой логов на почту
  9. Управление стоп-листами ресторана

При проектировании приложения мы использовали трехуровневую архитектуру. Такая модель программного комплекса предполагает наличие 3-х слоев, в нашем случае — это Presentation, Domain и Data. Опишем каждый слой подробнее.

Presentation — слой взаимодействия с UI. На этом слое применяется архитектура MVP, а также механизм databinding, представленный Google (сокращается количество boilerplate кода, возможность использования ViewModel для отображения данных во вью), что обеспечивает хорошую поддерживаемость (время вхождения новых членов команды сокращается за счет использования стандартизированных паттернов проектирования), тестируемость отдельных компонентов, с помощью UNIT test, а также презентационный слой получается разбитым на модули, что облегчает возможность добавления нового функционал (в виде экранов).

Domain — слой, который является связующим звеном между презентационным слоем и слоем данных. В приложении представлен в виде interactors, взаимодействие происходит через презентер. Интеракторы запрашивают данные со слоя Data, обрабатывают их соответствующим образом и возвращают в презентер для отображения во вью. Такой подход позволяет гибко реагировать на изменения бизнес-логики приложения, смены источников данных (либо добавления новых).

Data — слой, где хранятся модели данных, а также сервисы обеспечивающие взаимодействие с Rest API и realm db.

Данное архитектурное решение существенно облегчило разработку приложения, поскольку Rest API и модели данных начали разрабатываться через 2 месяца после начала разработки самого приложения и постоянно изменялись. При этом необходимостью стало создание mock ответов от сервера, разделение данных на модели и модели отображения, что положительно сказалось на времени интеграции с API, т.к. нужно было только переделать небольшие участки кода, где осуществлялась конвертация из модели данных в модель отображения.

Android Studio 2.3.3 — стал основным инструментом, использовавшимся в разработке.

Ниже приведены библиотеки, которые были использованы при разработке данного приложения. Все сторонние, но фактически являются стандартом:

  • Retrofit 2 — для REST-запросов к серверному API (разрабатывалось на стороне заказчика);
  • Dagger 2 — для облегчения применения паттерна Dependency Injection (все зависимости классов создаются в тн-модулях, что уменьшает связность между собой отдельных классов приложения);
  • Java port — библиотеки SocketIO для получения информации из веб-сокетов;
  • RxJava — для облегчения обеспечения многопоточности и взаимодействия с жизненным циклом приложения;
  • AutoValue — для уменьшения boilerplate кода при создании моделей данных.

В процессе эксплуатации приложения будут приходить фидбеки от пользователей. На данном этапе очень важно настроить и запустить системы краш-репортинга и аналитики. Для отслеживания падений вполне подойдет и сам Google Play. Мы бы еще предложили Firebase, только его надо “подружить” с Google Analytic. Последний отлично собирает статистику в реальном времени. Вы получите информацию об источниках аудитории, анализ ее поведения в приложении, фиксирование ошибок, с которыми сталкиваются пользователи и еще много чего полезного.

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

Нет комментариев.