Movee
A photo editor that allows users to create short videos by superimposing dynamic shaders on static pictures
Eurasia is probably the most common and sought-after sushi bar in Saint-Petersburg. So when the whole world went online and the number of delivery orders increased by a million times, Eurasia, like many other restaurants, faced the problem of optimizing the work of the delivery service.
Our app was designed to automate the monitoring of couriers. It shows the number of orders they deliver during the day, as well as their location on the map. And while the first function was quite simple to implement, the second one was a bit more interesting to solve.
So the main task was to develop an algorithm for sending geo-positioning. The first thing to start with was choosing a tool that would give the app the access to geolocation.
The customer’s old app ran on Google location services. It is a handy tool. Firstly, it can aggregate geolocation from several sources, including GPS, Wi-Fi and mobile network. Secondly, it optimizes the work with the received information.
But for us, Google was not a very relevant option. The main drawback is that it uses mobile networks that give off significant errors. When the device locates at a place where GPS or Wi-Fi are unavailable, and the mobile network remains the only source, this turns out to be a problem.
Therefore, one of the requirements for the app was the implementation of native geolocation. So we applied the built-in Android SDK, and as a source used only GPS.
As always, there is BUT. So now the SDK processes the geolocation from the GPS and gives the app access to it. Each specific time period, the app sends the information about the courier’s location to the server, which is displayed on the map with “dots”, forming the courier’s path.
The algorithm worked! But there were still some things to fix.
When the courier stops, the app continues to send geolocation. As a result, the server is filled with "identical dots", as they used to call them on the project, and it counts as an extra kilometer.
As a solution, we set the requirement to keep the last coming point: now the data of each new coordinate is compared with the previous ones and, if they match, the new signal is ignored.
Another point that needed to be considered was the missing signal. In order not to interrupt communication with the courier, we have put in the app a period in which one point should go.
In the event that the courier is not in place and the geolocation is not sent, the algorithm starts to request a point several times more frequently to reduce the time lag of the data being received.
The app was supposed to work in the background, so we also had to deal with all the complications that this might cause for its users, and above all the limitations that Android puts on energy-intensive apps.
When a device runs out of battery or runs out of memory, Android seeks to stop running its background apps. As a solution, we used a background worker that runs the main service every 15 minutes without restarting the courier app itself.
In addition to the basic settings from Android, there are settings of phone shells. For example, MIUI and EMUI, shells from Xiaomi and Huawei, have a rather aggressive energy saving policy. By noticing background services, they slow down their work, along with, in the case of our app, also slows down the sending of dots and increases the error. To avoid this, we had to implement the active mode retention in the app. When this problem was solved, we had to "overcome" the human settings.
In fact, still the most common problem that users face when working with background apps is not Android policy, but simple forgetfulness :)
Background apps can only work when the user has specified all permissions in the settings. Therefore, we have implemented a feature that offers users to allow the app to work in the background without restrictions.
We were extremely flattered to work with such a popular and beloved sushi bar in Saint-Petersburg. And we did our best to justify its trust.