Как мы вывезли «Весёлого водовоза» в доставку за час

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, решение для iOS сработало, но этот вариант не подходил для Androd, потому что в операционных системах разный механизм работы в background-режиме, для Android не предусмотрен вообще вариант работы с silent-push уведомлениями, как и для iOS, к сожалению, невозможна реализация варианта описанного ниже.

Единственный вариант сделать отправку координат непрерывной — реализовать работу приложения в background режиме, как если бы это был сервис. В этом случае координаты не переставали бы поступать на сервер.

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

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

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

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

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

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

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

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

• запускаем приложение;

• открываем маршрутный лист;

• проверяем, что координаты начали идти;

• отмечаем у себя время начала тестов;

• переходим в другое приложение (либо просто выходим из приложения по кнопке «Домой»);

• оставляем девайс на час;

• открываем приложение;

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

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

Здесь все было куда проще, чем с iOS, но и это решение оказалось не без минусов. Все шаги те же, но вместо перехода в другое приложение/выхода по кнопке «Домой», мы блокировали экран.

Минусы:

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

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

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

Какие выводы сделала я лично для себя?

От глубины понимания PM-ом задачи зависит успех проекта в целом.

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

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

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

В итоге, мы с разработчиками потратили вдвое больше времени на реализацию, а заработали, соответственно, меньше.

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

Еще больше полезной информации о мобильной разработке и полезных лайфхаках в нашем telegram-канале «Рупор InstaDev mobile» или во ВKонтакте.