高效的自动刷新移动应用程序设计

Question

几天前我被问到了这个问题.要求是设计一个向用户提供体育内容的移动应用程序(比如足球).该应用程序将允许用户订阅特定团队.根据用户的团队选择,应用程序仅在用户主屏幕上提供与该团队相关的内容.当然,用户可以选择查看所有团队的内容(通过菜单选项).

特别关注的是如何自动刷新用户主屏幕上的内容,还应考虑用户是否(或尚未)订阅特定团队.

对于最后一个问题,我建议遵循2个解决方案:

1)应用程序可以向服务器发送微小的请求,该请求仅包含用户的标识符,用户的团队选择.根据输入请求中的团队选择,服务器将仅返回与团队相关的内容.

2)如果内容量较少且不同团队的数量很少,则广播所有信息并让应用程序进行必要的过滤(当然,与#1相比,效率较低).

在论坛上分享这个以获得其他可能的设计决策.如果这不是正确的论坛,请在评论中回答,我将在适当的论坛发帖.

谢谢

Answer 1

基本上当你想做一个自动刷新系统时，你只有两种方法：

1：客户端定期发送请求。如果满足以下条件就足够了：

1. 刷新间隔不要太短
2. 您不希望您的应用程序为数百万人运行
3. 计算结果不会花费太多

这可以通过在数据库服务器端简单地使用一些查询来实现。当然，如果你需要更多的性能，你可以有一些中间层。

2：从服务器推送结果：正确架构有点棘手，但这里有一些优点：

• 您只向客户发送新数据
• 性能明智它是最好的

然而，限制更重要：

• 处理丢失的连接有点困难
• 您需要捕获更新数据的每个事件，以便将您的刷新推送到客户端。

但是因为需要这种架构解决方案的人比您多：这里是 Javaworld 中最适合您的解决方案：

JMS：Java 消息服务，它是一个面向消息的中间件 (MOM)。

JMS 是一种具有不同实现的规范，我个人会选择 activeMQ，它是 Apache 的一个。这是一个关于此的主题：您使用哪种 JMS 实现？

如果您不/不能使用 JMS，请记住这一点：Messare-Oriented-Middleware。谷歌应该可以帮助你找到你需要的东西。

Answer 2

肯定是选项 1)。

我们在其他行业开发了类似的东西，用户有兴趣获取有关不同资源状态的信息。架构是这样的：

1. 服务器保留所有用户的订阅。您可以在其中保存以下内容：SubscribedUserId、EventType（获胜、失败、numberOfPointsChanged、所有，无论情况如何）、deliveryChannel（http 通知、电子邮件、手机推送通知）
2. 每当资源发生问题时，我们都会将消息放入队列中。消息包含以下内容：teamEventIsFor、SubscriberUser、DeliveryChannel、DeliveryAddress等...
3. 单独的 Windows 服务（处理所有传递类型 [电子邮件、http、推送] 的服务或每个通道一个）使用队列消息并将实际内容传递给用户。就您而言，这将是通过推送通知。

现在，请记住，推送通知不能保证交付（尽管总体交付率相当不错），您可能还想实现某种 http 资源，移动应用程序可以不时轮询以检查是否有一些新闻对于该特定用户（这是可选的）。