Background#
This document records the ideas and process of integrating the app with the Departmental Network Freight Information Exchange Platform.
Implementation#
There are a total of 6 methods provided by the iOS SDK:
- init
- start
- send
- pause
- restart
- stop
It seems simple, but we need to consider the possibility of a method in the SDK failing. Additionally, there may be scenarios where multiple drivers handle the same consignment or a single consignment is transported by multiple drivers in segments, as well as scenarios where the vehicle is changed during the consignment process or the driver changes their phone. It is not easy to continuously record location information and complete a complete document chain in these scenarios.
Handling these scenarios requires assistance from the server, but the server does not have a direct interface to interact with the Departmental Network Freight Information Platform, making the handling process complicated.
Our idea is for the server to handle exceptions as a fallback. Therefore, it is necessary to let the server know the current document and step being processed. Therefore, an interface for recording is needed, which synchronizes with the server after each execution of an SDK method, whether it is successful or not.
To avoid situations where other phones, users, or the background manually close the consignment, the server needs to provide another interface to query whether there are pending consignments to be closed. Similarly, this interface needs to be called after each execution of an SDK method to obtain whether there are pending consignments to be closed.
There is also a situation where, after a user starts a consignment, the app is killed and reopened. In this case, which method of the SDK should be executed? Or if the driver switches to another phone and logs in to the account, what method should be executed when the app is reopened on the original phone? What method should be executed on the new phone? Therefore, a query interface is needed to determine the pending steps in these situations.
But here comes the problem. For the same driver, there may be multiple consignments at the same time due to convenience or the size of the vehicle, and the interval between sending each consignment may not be the same. So how do we simultaneously start multiple timers without confusion, and ensure that the corresponding timer is closed after the consignment is completed? By using the consignment number and sub-consignment number as keys, we can create timers and encapsulate them in separate models, which are then stored in a dictionary as values. Before creating a timer, we can check if the corresponding timer exists based on the consignment number and sub-consignment number. If it exists, we do not create a duplicate; if it does not exist, we create one. After executing the Stop or Pause method of the SDK, we can obtain the corresponding timer using the same method, and then stop this timer.
However, in practice, we encountered situations where the SDK failed to stop due to certain reasons, even though the consignment had actually ended. We also encountered situations where the SDK method was executed successfully, but the state was not saved to the server. These exceptional situations cannot be handled solely based on the synchronization record table. We can only retrieve the corresponding method to be executed based on the corresponding state from the business table.