- 交换方式的选择。 API说明。
- 1C端的API实现。
- 广播接收器 我们收到有关ATOL Smart.Lite示例的条形码。
- OnKeyUp。 使用键盘仿真从扫描仪获取条形码
- 菜单，伴随对象
- 我们实现数据交换和存储。 我们使用改造2，房间，协程。
- 使用者介面 LiveData，PagedList。
为谁
前两章试图构建将1C与其他应用程序和Web服务集成的经验。 我认为，周期本身对于试图超越平台并尝试新事物的1C程序员来说很有趣。 Android应用程序开发人员不会为自己学习任何新知识，但也许他们会对1C方面的外观感兴趣。 从第四部分开始，将尝试结合使用Internet合并一些来自Internet的分散文章，并更新它们上的数据。 该周期被认为是一本教科书，它描述了开发实际应用程序的经验。 我自己不是Android开发人员。 但我希望在本系列的结尾处成为其中一员。
2.交换方式的选择。 API说明
以其当前形式，可以以千一百种方式联系1C。 考虑几个选项，以及为什么我不使用它们。
- 本机组件 -在大多数情况下，最好将其用于脱机共享。 对于Online，它的适应性很差。 当1C开始实施其与商业设备交换的标准时，情况变得更加糟糕。 并且此组件在1C端也被称为。 不适合我。
- WEB服务 -专为开发不同团队的应用程序之间的交换而设计。 重量级，使用XML。 就个人而言，我很难发展。 甚至更难集成到JavaScript，Golang等中。 不适合。
- HTTP服务 -几乎与WEB服务相同，但是我们完全描述了工作逻辑和交换协议。 在这里，我们不仅限于自己的自行车的发明。 因此，选择了这种特定的交换机制。
我们的应用程序解决的任务。 “ TSD上可以完成的所有工作都必须在TSD上完成。” 好吧，作为一个标准集：验收，库存，标签，价格标签。
完整的任务清单- 处理货物：打印标签和价格标签，分配条形码（条形码），检查条形码，删除条形码，查看仓库中的价格和数量。
- 库存 -实际进行库存。
- 收据 -发票上的货物验收，差异打印，内部凭证打印，发票状态。
- 货物的收取，实现（零售） -想法是卖方不在收银台处，而是与买方同行或应要求收取货物等。 结帐柜台只有一个人，TSD会发送一份准备就绪的支票。 买方只为货物付款。
- 收货，实现（批发） -我们在帐户上收货。 我们检查可用的内容。 我们形成装运（带有必要文件的包装）。 不要忘记检查运送到对方的可能性。
- 收货，装运准备 -我们应要求收集货物，将其放在托盘上，打印文件：装箱单等。
- 搬家 -我们收集要搬家的货物，我们交运。
- 货物收集，任意清单 -需要进行重新评估，更新价格标签，标签以及其他类似操作。
回到API结构。 TSD和1C之间的交换将采用JSON格式。 在答案中，我们将分别只有两个对象
{result，payload} ：
result和
payload 。 结果，我们将返回两个字段
{code，msg} 。 而且，我们将始终以HTTP代码200进行响应。因此，对于客户端而言，我们更容易解析响应结构。 所有其他答案将以字符串形式出现。 1C不允许我们在平台外部自定义答案。
为什么给200比较容易当接收非200的代码时，大多数用于处理数据（包括Retrofit）的库都不会解析结果。 我们必须用笔“解析”它。
现在我们得到下图。 如果答案是200，则我们在1C中的程序运行良好。 如果答案不同，那么下面有一个问题。 在这里我们不能深入探究，出了什么问题，而是立即向用户显示出什么错误及其描述。 有人可能会说需要在没有用户干预的情况下处理错误，但是我们可以有两种情况：1-服务器返回了错误。 2 -corny没有连接。 在第一种情况下，我们甚至可能都不知道发生了什么故障（例如，错误404：应用程序请求了不存在的方法。500：平台因异常而崩溃）。 第二，我们无法将分析结果传送到服务器。 因此，我们显示错误，并期待进一步的用户操作。
有效负载将包含不同的对象。 这可以是货物清单，文件清单，行动清单。 在应用程序方面，我们将用模型来描述它们，并将它们仔细地折叠到数据库中。 我们将启动要执行的动作列表，并将结果仔细添加到数据库中。
与TSD的交换周期如下：
- 应用程序打开命令将请求发送到1C。
- 1C形成响应并返回包含结果和数据的结构。 在1C中，信息寄存器在TSD（Web服务）的上下文中累积更改的数据。
- 根据应用程序的请求，将发送要调用的方法列表。
选择这种方案是因为可以关闭TSD，关闭网络等。 但是，没有什么可以阻止我们最终确定1C，以便在更改数据时将其通知另一个应用程序（Web服务）。 通过这次交换，我们通知有新数据。 应用程序询问那里有什么数据，然后重复循环。 该图中提供了一个交换示例。
仅此而已。 如果您有任何问题，意见或建议，请在评论中写。