How to Exchange Data with a Mobile Client Offline?

About the project

In the previous blog post, we explored how to achieve accuracy when receiving position and distance data from GPS. This blog post shares project details of the logistics application created by engineers at Altoros on the customer’s request. The purpose of the application was to exchange 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 solution 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

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. Therefore, there existed the need to figure out what data needs to be sent to the server when the device is back online.

If a truck is moving with its average speed during the period being offline, then all the data sent when the online mode is on stays relevant. However, if the truck is stuck in a traffic jam, moves very slowly, or stays in a parking lot, the device keeps recording multiple cargo coordinates within a certain range. This data is thought to be redundant and inaccurate. This way, there is no need data is saved in the offline mode and then sent to the server. Otherwise, the route will be displayed incorrectly, causing database redundancy and 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.

• 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.
• If the 100-meter limit is not reached every 30 seconds, the coordinate may never be recorded at all. That is 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.
• We wanted the position data to be accurate within 50 meters. So, 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 to minimize the number 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.

Enabling data accuracy

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. 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.

Further reading

• How to Omit Inaccuracy in Receiving Position and Distance Data from GPS?
• A Cross-Platform AIR 3.5 App Created as a Hobby Got Published in iTunes and Google Play
• Mandrill—a Free SMTP Server for Applications