Меня зовут Анна, я проджект-менеджер в InstaDev. С «Веселым водовозом», компанией, о кейсе в которой пойдет речь в этой статье, мы успешно сотрудничаем уже 2 года. На данный момент мы для них написали 2 приложения: водительское (служит для помощи в доставке и передаче заказа клиенту) и клиентское (служит для упрощения процесса заказа воды).

Далее расскажу как мы решали задачу по разработке услуги "доставка за час".

Конкуренция за место под солнцем

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

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

Аналитики из "Веселого водовоза" решили перестраховаться и пришли к нам с запросом на реализацию доставки за час.

Выбор пути

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

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

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

Следующей идеей было сделать отправку с бэкенда silent-push уведомлений, которые выводили бы приложение из background режима и вызывали бы отправку координат на сервер.

Описание решения нашего от flutter-разработчика Дамира Вильямова

Кстати, обращаем ваше внимание:

FirebaseMessaging.onBackgroundMessage
-это правильный метод

FirebaseMessaging.onForegroundMessage
-неправильный

На этапе первых тестов столкнулись с тем, что разработчик по ошибке указал не тот метод ю, и поэтому пуши попросту не принимались. Еще подробнее про тестирование расскажем ниже.

Тестирование решения

Для того, чтобы проверить решение, мы сделали ветку со счётчиком пришедших silent-push уведомлений на главной странице приложения.

Нужно было проверить 2 сценария.

1.Работа в бэкграунде, если приложение свернуто:

• запускаем приложение;
• открываем маршрутный лист;
• проверяем, что координаты начали идти;
• отмечаем у себя время начала тестов;
• переходим в другое приложение(либо просто выходим из приложения по кнопке "Домой");
• оставляем девайс на час;
• открываем приложение;
• проверяем количество пришедших уведомлений (с учётом того, что они отправляются раз в 30 сек, счётчик должен показывать 120);
• далее проверяем количество пришедших координат (мы запрашивали у заказчика скрин из их CRM-системы, на нем был отображён список всех пришедших по маршрутному листу координат с указанием времени, количество с момента открытия должно было равняться количеству пришедших сайлент пушей).

2.Работа приложения в бэкграунде, если экран телефона заблокирован:

Все шаги те же, но вместо перехода в другое приложение/выхода по кнопке "Домой", мы блокировали экран.

Минусы этого решения:

• если смахнуть приложение из системного трея (это меню всех недавно открытых приложений) - работать не будет;
• если у приложения не стоит доступ к геолокации "всегда" - работать не будет.

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

Как это было

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

Спустя 4 часа упорного тестирования, чтения документации, паники и попыток понять, где ошибка, до нас дошло, что проблемы, в общем-то, и не было.

При переустановке сборки слетело разрешение "использовать геолокацию всегда", стояло "только при использовании".

Итак, решение для iOS сработало, но возникла другая проблема - этот вариант не подходил для Android.

Для начала нужно было описать входную точку, которая будет работать с нативным кодом через Dart API/

Описание решения Никиты Кима, flutter-разработчика

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

Описание решения от Никиты Кима, flutter-разработчика

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

Описание решения от Никиты Кима, flutter-разработчика

После чего, при запуске основного экрана, был подвешен обработчик ивента, отправляемого Dart'ом в background mode.

Описание решения от Никиты Кима, flutter-разработчика

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

Описание решения от Никиты Кима, flutter-разработчика

Тестирование решения для Android

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

1.Работа в бэкграунде, если приложение свернуто:

• запускаем приложение;
• открываем маршрутный лист;
• проверяем, что координаты начали идти;
• отмечаем у себя время начала тестов;
• переходим в другое приложение(либо просто выходим из приложения по кнопке "Домой");
• оставляем девайс на час;
• открываем приложение;
• проверяем количество пришедших координат(мы запрашивали у заказчика скрин из их CRM-системы, на нем был отображён список всех пришедших по маршрутному листу координат с указанием времени, количество с момента открытия должно было быть не ).

2. Работа приложения в бэкграунде, если экран телефона заблокирован

Здесь все было куда проще, чем с iOS, но и это решение оказалось не без минусов.

Все шаги те же, но вместо перехода в другое приложение/выхода по кнопке "Домой", мы блокировали экран.

Минусы:

• работает только если не смахивать приложение из меню “последних”;
• сильно съедает заряд батареи.

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

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

Хотите реализовать подобную фичу у себя? Тогда пишите/звоните нам любым удобным способом.

Источник: VC.ru