2

在 Android 中，我有一个与服务器保持实时通信的套接字。此应用程序套接字由服务控制，该服务在启动时和/或应用程序发出请求时启动。

因为我不能依赖 Google PlayStore，所以我完全手动控制推送消息的发送和接收。

每当有新的推送消息从服务器到达时，socket-service 就会发送一个本地广播消息，并且监听活动可以按照自己的操作进行操作。如果没有找到活动，则会向用户提供默认的 android 通知，说“[ ap] 您有 {n} 条新消息'...

这有其稳定性问题（例如，当内存不足时，操作系统可以关闭服务）但没关系。

现在，考虑以下几点：

我有多个活动来监听并显示未读消息的计数。

  • 主页
  • 对话概览页面
  • 'The' 对话页面 (chatpage)

每个活动都可以在前台，但也可以在用户按下并返回 1 个活动时在内存中。因此，在理论上，可能存在您想要一次更新不同/多个活动的情况。这可以防止当用户返回“已保存实例”时必须从服务器“重新加载”未读消息。所以我认为广播模式效果最好。

保持全局跟踪未读消息的最佳实践是什么，同时最大限度地减少每个活动实例上的服务器行程：

  1. 非常简单：对每个活动实例发出服务器请求，然后为每个活动再次编写更新代码。但这会导致用户看到延迟，因为应用程序需要一秒钟才能从服务器接收数据并显示“未读消息”气球。

  2. Simpel：有一个全局类..为每个对话保留未读消息，但我觉得这可能会导致数据不完整的问题..尤其是当应用程序不是“活动”时

  3. 我的旧票：让另一个服务跟踪未读消息，该服务在启动时启动（就像套接字一样）。只有当服务启动/启动时，它才会从服务器请求所有未读消息数据。每个活动都可以“询问”未读消息数据，而不必再担心了。 但这可能是矫枉过正吗？

  4. 我的新投票：保留套接字服务，并为该服务添加一个单独的类。它包含未读数据。但这也感觉不对。。因为活动必须向服务询问一些事情-of-scope .. 它不是管理未读消息（关注点分离）的套接字问题，对吧？

非常感谢经验丰富的开发人员的感谢！

4

1 回答 1

1

第三个选项没问题。不确定具体在哪里overkill。显然，您不应该在每次启动或套接字重新连接时下载所有未读消息。最重要的经验法则是在应用程序真正需要数据时加载数据。关于我如何开发同一个应用程序的一些时刻：

  • 有Service处理连接、断开连接、发送数据（消息）和接收数据的套接字。
  • 有Notification managerwhich 从 接收事件SocketService。它保存来自服务器的新数据并决定应该发送哪个广播通知。
  • 当套接字连接时，它从服务器接收状态数据：
    1. 每次聊天的最后更新日期（时间戳）。例如，如果本地数据库包含A昨天更新的聊天，但从服务器新收到的数据表明聊天A在几秒钟前更新，您需要广播事件chat A has been updated since last connection并保存更新日期。如果有任何活动以某种方式显示A它加载（通过 http 或其他）新数据的聊天。
    2. last messages每次聊天。该应用程序只是比较本地保存last messages和新收到的。如果有新的应用程序再次广播事件，如there is unread message/messages from user x. 如果有显示更新聊天的可见活动，则会更新数据，否则应用程序会显示通知。

所以处理未读消息的基本流程是：连接到服务器>检查是否有关于未读消息的>数据保存新数据到本地数据库>广播关于新数据的事件。

我建议您同时使用GCM和套接字连接。GCM确实有助于保持数据更新。当由于网络问题而无法建立套接字连接时，它会唤醒电话并有时会传递数据。

于 2015-07-24T13:33:25.993 回答