multi-publisher、multi-subscriber 在 Android 上进行数据交换的良好做法
Good practice for multi-publisher, multi-subscriber data exchange on Android
我正在 Android 应用程序之间共享道路交通信息，想知道什么是好的传输机制。
有两个 类 应用程序： 发布者 post 传输他们从各种来源（例如，Internet 服务或 TMC 接收设备）获得并转换为标准格式的消息。订阅者收听消息并使用它们（例如，将它们显示在列表中或引导司机绕过拥堵）。该系统旨在去中心化：将有多个发布者，多个订阅者，用户可以随意组合和匹配它们。
消息由唯一 ID 标识，该 ID 在整个生命周期中保持稳定。它们有一个过期时间，过期后它们将被视为无效。在此之前，它们可以随时更新。更新也可以取消消息（用墓碑替换它直到它过期），或者延长它的过期时间。
订阅者在收到新消息时会收到消息。 （过滤可能会在稍后阶段进行。）他们还需要一种方法来检索所有发布者当前缓存的所有消息。
一条消息的大小约为 1 kByte。发布者可以在任何给定时间轻松地拥有数百条活动消息。
为了安全起见，消息一般都是public信息。唯一的敏感信息是地理数据，因为它可以得出关于设备位置或用户打算去哪里旅行的结论。此类数据的精度很低，从城市到国家级别的任何地方。因此，我认为没有必要对任何应用程序隐藏此信息，只要它具有位置权限即可。
现在我想知道什么是好的传输机制：
选项 1：广播意图
最初我一直在使用广播意图：每当发布者有任何新消息时，它都会发送一个隐式广播，其中包含额外的消息。订阅者可以在 运行 时间注册广播接收器以接收消息。他们还可以选择发送轮询广播（显式广播，在发布者的清单中声明相应的广播接收器）。然后，发布者将以所有当前缓存消息的提要作为响应。为解决安全问题，任何发送带有地理数据的广播的应用程序都要求接收方持有其中一项位置权限。
大型提要存在问题，因为 Android 请求代理支持所有并发事务的最大 1 兆字节（因此如果事情很忙，提要中的最大数据量可能会更少).我目前正在通过将提要分解为 100 条或更少消息的块来解决这个问题。
该系统的一个优点是所有中央基础设施都由 OS 提供。安装一个发布者和一个订阅者应用程序就足够了。
选项 2：内容提供商
有些人指出广播意图不是最好的方法，并建议我实施内容提供程序，这是我迄今为止尚未涉足的领域。查看文档，不清楚是否有办法让多个后端（每个后端都是一个单独的应用程序）实现功能相同的内容提供者并宣传它们。由于内容提供者支持读取和写入操作，我可以将一个中央组件设置为内容提供者，并让发布者和订阅者连接到它。但是，这需要提供一个中央组件才能工作，我宁愿避免这种情况。
问题：
- 有没有办法通过内容提供商实现上述 multi-publisher、multi-subscriber 模型，并且不必提供 OS 尚未提供的中央组件？
- 具体来说，一个内容提供者可以有多个后端吗？或者，多个功能相同的内容提供商能否将自己作为一个整体进行宣传？
- 我将如何使用内容提供商实现上述内容？
- 我可能错过了广播意图或内容提供商的优点和缺点是什么？
Is there a way to implement the above multi-publisher, multi-subscriber model with content providers
保持广播。替换载荷。
发布者将实施 ContentProvider 来提供当前的消息名册。您可以将 ContentProvider 视为一种古怪的 REST-style Web 服务，其中 Uri 值映射到提供者的响应。
然后发布商将像今天一样发送广播，但可能只有两个额外内容：
一个标识广播使用的协议版本，因为您有很多 independently-updated 方。接收者需要知道如何解释广播，因为您可能会随着时间的推移更改规则。
包含 Uri 指向发布者的 ContentProvider。
如果您今天使用的其他附加功能将保持较小，并且您仍希望将它们放在广播中，那很好。只让 indeterminate-sized 个不在广播中。
然后接收者会：
查看额外的协议版本并分支到处理该版本的代码（今天，只有一个分支，但是，嘿，future-proofing）
使用 Uri 和 ContentResolver 从发布者那里获取消息（以及其他需要的东西）
您可以考虑将此通信基础设施开发为 SDK。即使您是唯一一个开发应用程序的人，您也会希望避免在应用程序中重复所有这些逻辑。而且，如果第三方将开发应用程序，你最好给他们一个 SDK 来工作，而不是强迫他们 "roll their own".
我正在 Android 应用程序之间共享道路交通信息，想知道什么是好的传输机制。
有两个 类 应用程序： 发布者 post 传输他们从各种来源（例如，Internet 服务或 TMC 接收设备）获得并转换为标准格式的消息。订阅者收听消息并使用它们（例如，将它们显示在列表中或引导司机绕过拥堵）。该系统旨在去中心化：将有多个发布者，多个订阅者，用户可以随意组合和匹配它们。
消息由唯一 ID 标识，该 ID 在整个生命周期中保持稳定。它们有一个过期时间，过期后它们将被视为无效。在此之前，它们可以随时更新。更新也可以取消消息（用墓碑替换它直到它过期），或者延长它的过期时间。
订阅者在收到新消息时会收到消息。 （过滤可能会在稍后阶段进行。）他们还需要一种方法来检索所有发布者当前缓存的所有消息。
一条消息的大小约为 1 kByte。发布者可以在任何给定时间轻松地拥有数百条活动消息。
为了安全起见，消息一般都是public信息。唯一的敏感信息是地理数据，因为它可以得出关于设备位置或用户打算去哪里旅行的结论。此类数据的精度很低，从城市到国家级别的任何地方。因此，我认为没有必要对任何应用程序隐藏此信息，只要它具有位置权限即可。
现在我想知道什么是好的传输机制：
选项 1：广播意图
最初我一直在使用广播意图：每当发布者有任何新消息时，它都会发送一个隐式广播，其中包含额外的消息。订阅者可以在 运行 时间注册广播接收器以接收消息。他们还可以选择发送轮询广播（显式广播，在发布者的清单中声明相应的广播接收器）。然后，发布者将以所有当前缓存消息的提要作为响应。为解决安全问题，任何发送带有地理数据的广播的应用程序都要求接收方持有其中一项位置权限。
大型提要存在问题，因为 Android 请求代理支持所有并发事务的最大 1 兆字节（因此如果事情很忙，提要中的最大数据量可能会更少).我目前正在通过将提要分解为 100 条或更少消息的块来解决这个问题。
该系统的一个优点是所有中央基础设施都由 OS 提供。安装一个发布者和一个订阅者应用程序就足够了。
选项 2：内容提供商
有些人指出广播意图不是最好的方法，并建议我实施内容提供程序，这是我迄今为止尚未涉足的领域。查看文档，不清楚是否有办法让多个后端（每个后端都是一个单独的应用程序）实现功能相同的内容提供者并宣传它们。由于内容提供者支持读取和写入操作，我可以将一个中央组件设置为内容提供者，并让发布者和订阅者连接到它。但是，这需要提供一个中央组件才能工作，我宁愿避免这种情况。
问题：
- 有没有办法通过内容提供商实现上述 multi-publisher、multi-subscriber 模型，并且不必提供 OS 尚未提供的中央组件？
- 具体来说，一个内容提供者可以有多个后端吗？或者，多个功能相同的内容提供商能否将自己作为一个整体进行宣传？
- 我将如何使用内容提供商实现上述内容？
- 我可能错过了广播意图或内容提供商的优点和缺点是什么？
Is there a way to implement the above multi-publisher, multi-subscriber model with content providers
保持广播。替换载荷。
发布者将实施 ContentProvider 来提供当前的消息名册。您可以将 ContentProvider 视为一种古怪的 REST-style Web 服务，其中 Uri 值映射到提供者的响应。
然后发布商将像今天一样发送广播，但可能只有两个额外内容：
一个标识广播使用的协议版本，因为您有很多 independently-updated 方。接收者需要知道如何解释广播，因为您可能会随着时间的推移更改规则。
包含
Uri指向发布者的ContentProvider。
如果您今天使用的其他附加功能将保持较小，并且您仍希望将它们放在广播中，那很好。只让 indeterminate-sized 个不在广播中。
然后接收者会：
查看额外的协议版本并分支到处理该版本的代码（今天，只有一个分支，但是，嘿，future-proofing）
使用
Uri和ContentResolver从发布者那里获取消息（以及其他需要的东西）
您可以考虑将此通信基础设施开发为 SDK。即使您是唯一一个开发应用程序的人，您也会希望避免在应用程序中重复所有这些逻辑。而且，如果第三方将开发应用程序，你最好给他们一个 SDK 来工作，而不是强迫他们 "roll their own".