Tag: 轮询

iOS:推送通知作为Web服务轮询的“触发器”?

我刚刚开始学习OBJ-C,但我有一个目标应用程序,我正在努力build设; 这个应用程序将是iPad上的主/细节应用程序,将需要保持自己更新与“实时”的web服务。 当多个用户中的一个(在独立的iPad上)在应用程序内执行某些操作时,还需要将数据发送到远程MySQL DB。 编辑:正如lxt已经很有帮助地澄清:“是否适合使用推送通知作为提示轮询web服务” – 答案是有点。 我为这个问题设想的例子是一个Widget库存pipe理器,它具有stream入表格视图的“传入”库存和用户将库存拖放到详细视图中的“库存存储箱” 。 像这样: 注:我的应用程序不要求自己保持更新,当不在前台。 它可以愉快地睡觉,直到它再次启动; 此时需要用最新的数据更新自己。 凯尔使用applicationWillEnterForeground为这个问题的具体方面提供了一个答案: 为了完成这个任务,我的webservice服务器已经过期了,我想到了一个解决scheme,它结合了webservice轮询和PUSH通知,当一个用户(iPad)对数据进行任何更改时触发轮询。 所以,stream量会是这样的: Web服务的“默认”轮询会每分钟触发,而不pipe用户可能执行的任何操作。 当用户从桌面视图中拖出一个库存项目并将其放入一个存储箱中时,该存储箱会向login到同一个总帐户的任何其他iPad发起一个PUSH通知,并触发一个web服务轮询来刷新其数据。 简而言之:任何时候,当iPad“A”上的用户改变任何东西时,推送通知被发送到iPad“B”,iPad“C”等。当B,C,D等接收到推送时,他们轮询服务器刷新他们的数据。 另一种方法是让每个触发Web服务的帐户上的每个iPad每15秒轮询一次; 这似乎对我来说是带宽昂贵的(并且通常会导致数据没有变化)。 我的问题不是“我怎么…?” 更多的是“我该怎么…?”。 我意识到StackOverflow可能会发现这有点“主观”,但我认为这是一个非常值得考虑的问题,考虑到我花了两天研究这个特定的做法(使用PUSH通知触发web服务轮询),并发现正好零相关的文章。 感谢您抽时间阅读。 任何帮助,将不胜感激。 示例代码和/或特定框架/套件信息将不胜感激。 但现在我真的需要知道这是不是一个好主意。

应用程序架构,当'状态改变'APNS失败

我已经看到了有关这个话题的几个问题。 但是,所有的简单的说,你只需要从其他手段恢复。 但是没有人解释其他方法是什么! 我找不到答案。 这也是这个问题的评论的后续。 假设我正在研究Uber应用程序。 司机需要知道乘客的位置。 一名乘客设置了123 XYZStreet一个取货地点。 2分钟后,她决定取消整个皮卡。 所以现在我需要通知司机。 这是一个重要的状态改变更新。 首先想到的是: 发送具有content-available:1的通知content-available:1以便在通知到达后立即更新应用程序;在didReceiveNotification中,我调用GET(PassengerInfoModel)并且还包含"alert" : "Pickup has been canceled. Don't go there'那么驱动程序也会被直观的通知,显然通知并不是pipe理更新的content-available的content-available被设置为1来pipe理。 但是这样做,当通知到达失败时仍然会发生什么情况? 那么最新的GET(PassengerInfoModel)将不会发生。 作为一个解决scheme,我听说过一个HEAD请求: HEAD方法与GET相同,除了服务器不能在响应中返回消息体 。 响应HEAD请求的HTTP头中包含的元信息应该与响应GET请求发送的信息相同。 这个方法可以用来获得有关请求隐含的实体的元信息,而不用传递实体主体本身。 此方法通常用于testing超文本链接的有效性,可访问性和最近的修改 。 不知道如果使用HEAD请求会发生什么,我们发现有更新! 然后,我们是否在HEAD的完成处理程序的成功情况下发出GET请求? Question1我们应该如何处理HEAD请求响应? (我猜测,服务器能够路由HEAD请求,必须有一些变化,但让我们假设这是超出了问题的范围)。 Question2我们多久需要做这个请求? 根据这个评论,一个解决scheme可能是在viewDidAppear设置一个重复计时器,例如每2分钟发一个HEAD请求。 这是一个好主意吗? Question3现在让我们说,我们做了HEAD请求,但GET(PassengerInfoModel)也是从其他2场景/ viewControllers请求。 服务器无法区分不同的场景/视图控制器。 我猜测一个解决scheme将是所有的应用程序的networking请求pipe理通过一个单身NetworkHandler。 这是一个好主意吗? 我知道这个问题很广泛,但是认为这个问题需要整体解决