How to Exchange Data with a Mobile Client when It Is Offline?

Igor Zubchenok

Authors: Stepan Churiukanov, Igor Zubchenok

With this post, we want to continue the topic started earlier. The logistics application created for one of our customers was exchanging data with a mobile client used by the company’s cargo vehicles. The mobile client tracked the driver’s location and sent it to the server. This data, including the distance covered by the vehicle, was graphically presented on a visual map in real time. The application also helped calculate the distance, fuel costs, and other expenses.

We discovered that natural inaccuracies in getting coordinates through GPS influenced both the route displayed and the database load. To avoid saving redundant data, we decided to filter it out on the level of the application architecture.

The offline mode

There was another issue that we had to find the solution for. Since the mobile client does not always work in the online mode, you can hardly exchange data with it in real time constantly. The signal may disappear due to the absence of satellites, poor weather conditions, or extreme locations, such as a winding road up in the mountains, a tunnel, etc.

This causes a major problem: what data needs to be sent to the server, when the device is back online?

If the truck is moving with its average speed during that period, then it is not a big deal. But what if the truck is stuck in a traffic jam, moves very slowly, or stays in a parking lot? Though it doesn’t move, the device keeps recording multiple cargo’s coordinates within a certain range.

Should the device send all this redundant and inaccurate data, when it is back online? Definitely, not. If the inaccurate data saved in the offline mode is sent to the server later, the route will be displayed incorrectly. It will also cause database redundancy and create a heavy traffic load.

Choosing the data to be transmitted

To solve this issue, we decided to have the mobile client save only those coordinates that comply with certain criteria.

    1) Coordinates should be recorded every 30 seconds, provided that the location of the cargo has changed over 100 meters during this period of time. Otherwise, the mobile client should wait for another 30 seconds.

    2) However, if the 100 meter limit is not reached every 30 seconds, the coordinate may never be recorded at all. That’s why the initial coordinates of the cargo should also be taken into account. The coordinate should be recorded disregarding the time limits if it exceeds 100 meters from the position where we started tracking the vehicle’s route.

    3) We wanted the position data to be accurate within 50 meters. That’s why the position is not recorded if it was captured with less than three satellites. In this case, the coordinates cannot be detected with a given accuracy.

New settings helped minimize the amount of coordinates recorded by the handheld device. Now, only the data that has been filtered out by the mobile client will be sent to the server.

This allowed the logistics application to reduce data redundancy and traffic load, display the route on the visual map correctly, and calculate the exact distance covered by the vehicle.

The solution proved to be beneficial not only from the technical side. Providing accurate data from the handheld terminal allows calculating the distance passed by the vehicle more precisely. This enabled the customer’s account managers to calculate fuel costs and driver’s salary correctly, without overpaying. In addition, the solution allowed for cutting down hosting and bandwidth fees, as the traffic load was also significantly reduced when sending this data to the server.

No Comments

Download Benchmarks and Research

© 2001 – 2019 Altoros