Background#
This document records the integration ideas and process of accessing the Department Network Freight Information Interaction Platform through the APP.
Implementation#
The iOS SDK provides the following 6 methods:
- init
- start
- send
- pause
- restart
- stop
These methods may seem 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 shipment or a single shipment is divided into multiple segments with different drivers. There may also be cases where the vehicle is changed during the shipment or the driver switches phones. 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. However, the server does not have direct interfaces to interact with the Department Network Freight Information Platform, so handling becomes complicated.
Our idea is to have the server handle exceptions as a fallback. Therefore, the server needs to know the current document and step being processed. This requires a recording interface that synchronizes with the server after each SDK method is executed, whether it succeeds or fails.
To avoid situations where other phones, users, or the background manually close the shipment, the server needs to provide another interface to query whether there are pending shipments to be closed. Similarly, this interface needs to be called after each SDK method is executed to determine if there are pending shipments to be closed.
There is also a situation where if the APP is killed and reopened after the user starts the shipment, what method should the SDK execute? Or if the driver switches to another phone and logs in to the account, what method should be executed when the original phone is reopened? What method should be executed on the new phone? Therefore, a query interface is needed to determine the pending steps in these situations.
However, here comes the problem. For the same driver, there may be multiple shipments at the same time due to convenience or the size of the vehicle, and the intervals for sending each shipment may not be the same. So how do we simultaneously start multiple timers without confusion, and ensure that the corresponding timer is closed when the shipment ends? We can create timers using the shipment number and sub-shipment number as keys, encapsulate them into separate models, and store the models as values in a dictionary. Before creating a timer, we can check if the corresponding timer exists based on the shipment number and sub-shipment number. If it exists, we do not create a duplicate; if it does not exist, we create a new timer. After executing the Stop or Pause method in the SDK, we can retrieve the corresponding timer using the same method and then stop the timer.
However, in practice, we encountered situations where the SDK failed to stop due to certain reasons even though the shipment had already ended. We also encountered situations where the SDK method was executed successfully but failed to save the status to the server. These exceptional cases cannot be handled solely based on the synchronization record table. We can only retrieve the corresponding status from the business table and then return the corresponding method to be executed.