Когда ты чем-то гордишься, то хочется об этом рассказывать снова и снова. Мы уже писали о нашем проекте 5Star Service в блоге, где затронули маркетинговую сторону (идеи, задачи и решения и т. д.) — тут, конечно, мы всё и всех победили. Приложение получилось уникальным в своем роде, при этом остается универсальным и адаптируется под любой B2C-бизнес. Но в этой статье мы поговорим о технической стороне процесса и приоткроем тайны разработчиков.
Что важно для приложения, которое занимается сбором отзывов? Отвечаем: быстрая работа и отзывчивый, располагающий к взаимодействию интерфейс. Чтобы поставить оценку, пользователь должен оставить собственные данные (номер телефона и оценку) — да уж, не самый «простой» нюанс! Поэтому мы постарались настолько ускорить работу и проработать дизайн, чтобы все прошло мгновенно.
Проблема № 1: Скорость превыше всего
Первоначальный алгоритм был таким: данные на сервер будут отправляться после каждого действия пользователя, причем только в случае успешного ответа от сервера происходил переход на новый экран.
Но что делать, если возникнут неполадки на сервере или будет плохой интернет (ситуация известная)? Пользователь не сможет оставить отзыв и уйти побыстрей от навязчивых глаз персонала, он будет ждать ответ сервера, снова вводить данные и т. д. Этого мы допустить не могли, поэтому поменяли логику работы приложения.
Вся основная работа 5Star Service выполнятся «в фоне», поэтому пользователю не нужно выжидать — его взаимодействие с приложением осуществляется параллельно, а отделение модуля с сервером от главного потока обеспечило скорость.
Проблема № 2: Дойдет или нет?
Нестабильное подключение к интернету — это не проблема, а условие, с которым нужно мириться. Из-за этого тестовый запуск приложения показал, что некоторые запросы могут не доходить до сервера и, как следствие, часть оценок была просто утеряна. Выход из этой ситуации только один — реализация offline-режима. Если данные на сервере не сохранятся по каким-либо причинам, то они окажутся в локальной базе приложения. Позаботились и о безопасности — шифрование базы данных включено!
Проблема № 3.: А если все-таки не дойдет?
После реализации базы данных и отслеживания неотправленных данных с последующим их сохранением, понадобилось реализовать проверку статуса сети. Для этого был создан механизм, который отслеживал подключение к сети Wi-Fi. Как только устройство подключается к Wi-Fi, производится проверка наличия не отправленных данных в нашей базе данных, которые отправляются на сервер. При успешном сохранении данных осуществляется удаление из локального хранилища. Это все позволило свести к минимуму проблему с утратой данных, вызванную перебоями в работе сети или сервера.
Вместо резюме
Для всех интересующихся указываем интерфейсы и библиотеки, которые использовались при разработке приложения:
- SQLite для работы с базой данных
- Retrofit для работы с сетью
- ResultReceiver для сохранения неотправленных данных в базу данных
- IntentService для отправки запросов на сервер с использованием Retrofit
- Fabric.io для отслеживания ошибок в работе приложения.
