部网络货运信息交互系统位置信息插件SDK接入总结

背景

APP接入部网络货运信息交互平台，这里记录一下接入想法和过程。

实现

iOS SDK提供的方法，共有下面6个

• init
• start
• send
• pause
• restart
• stop

看起来很简单，但是需要考虑SDK某个方法可能会失败，而且可能会有同一个司机多个托运单、或者同一托运单分段多个司机运输以及托运过程中换车、司机运输中换手机等场景，想要持续记录位置信息，完成完整的一个单据链路就不那么容易了。

而这些场景的处理，需要服务端的协助，但是服务端没有和部网络货运信息平台直接交互的接口，无法直接从货运信息平台读取状态和数据，所以处理就显得麻烦了。

我们的设想是，服务端兜底处理异常，所以，首先要让服务端知道当前处理的单据和步骤，故而需要一个记录接口，每次执行SDK的方法后，成功或失败都同步给服务端。

为了避免出现其他手机或其他用户或后台手动关闭单子的情况，需要服务端提供另一个查询是否有待结束运单的接口，同样，这个接口在每次执行SDK的方法后，都要调用，用于获取是否有待关闭的运单。

而还有一种情况，即用户开始运单后，APP被杀掉了再次打开时，这时候应该执行SDK的什么方法？或者司机中途换了另一个手机登陆了账号，这时候原手机上再次打开应该执行什么方法？新手机上应该执行什么方法？所以需要一个查询接口，用于这种情况下查询待执行的步骤。

但是问题来了，同一个司机，由于顺路或者车型大的原因，可能同时有多个运单，而每个运单的间隔发送时间不一定相同？所以如何同时开启多个timer，不会混乱，且又能保证运单结束后，关闭对应的timer？通过运单号和分单号作为key，创建timer封装到单独的Model中，model作为value，存储在字典中。每次要创建timer前，根据运单号和分单号查询对应timer是否存在，存在则不重复创建；不存在则创建。当执行了SDK 的Stop或Pause方法后，同样的方法获取到对应timer，然后停止这个timer。

但在实际中，遇到了SDK由于某种原因Stop失败，实际上这个运单已经结束的情况；还遇到了SDK执行方法成功，但是保存状态到服务端时失败的情况。这些异常情况，单独根据同步记录表是没有办法处理的，只能从业务表中获取对应状态后，再返回对应要执行的方法。