Apple 通知可靠性答案

【问题标题】：Apple notifications reliabilityApple 通知可靠性
【发布时间】：2015-05-27 23:58:17
【问题描述】：

好的，很明显推送通知并不总是可靠的，如文档中所述。

如果我错了，请纠正我，这仅仅是因为某人可能长时间没有互联网，并且通知可能会过期，或被替换，甚至由于某种宇宙原因而丢失。

我没关系。

但作为一名初级程序员，我使用了很多本地通知，不是为了显示，而是在某些进程完成时调用不同的方法。

这是一个简单的例子，当应用程序启动时，我有一个数据更新过程，比如消息和内容。更新完成后（大约 3 秒后），我会发送一条通知，让我的所有控制器都监听，以便他们相应地更新其 UI。如果我在主屏幕上，我会显示那些红色的小徽章，如果我在对话中，我会在表格视图中添加消息，等等。

而且，作为一名初级开发人员，我有机会与一位不喜欢这种风格的高级开发人员一起工作。他说这不可靠，我应该使用委托回调和完成处理程序。考虑到应用程序的构建方式，我发现很难做到这一点。我的系统实际上是一个单线并且从未失败，而他的系统需要在每个单独的类中实现大量不同的方法。看起来既多余又凌乱。

我终于到达了我想要的地方：本地通知是否可靠，我正在谈论这个：

[[NSNotificationCenter defaultCenter] postNotificationName:NOTIF_SOMETHING_SOMETHING object:self];

显然与 addObserver: 对应。

我选择这种工作方式真的错了吗？我应该怎么做？或者这样可以吗？或者这甚至很棒？

可悲的是，这是一个相当基于意见的问题，因为它是关于标准和良好做法的，但我觉得它不够宽泛，无法违反规则，因为我真的觉得有人会提出一个技术原因，为什么这样做或应该/不应该做的事情，或者澄清应该在何时何地使用什么。

无论如何，如果需要，请让我澄清任何事情，我对所有即将到来的回复非常感兴趣，我很期待。

【问题讨论】：

您正在搞乱远程推送通知、本地通知和NSNotificationCenter 发布的通知。只有远程通知是不可靠的。 NSNotificationCenter 通知没问题，解决方案取决于哪种设计模式最能准确地涵盖您的任务
在谈论通知时要小心...您使用了术语 本地通知，但很确定您在谈论 NSNotification 而不是 UILocalNotification，这些是两种截然不同的东西！
好吧，这揭示了一些东西。我一直使用 NSNotifcation 并考虑使用本地通知。现在我的问题似乎毫无意义。
是的，这些是非常不同的 :) 我在回答中解释了不同类型的通知，并指出为什么您可能不想经常使用 NSNotification（正如您的高级开发人员建议的那样... )。让我知道是否还有更多需要澄清的事情:) @Zil

【解决方案1】：

iOS 世界中有不同种类的通知，每一种都有不同的目的，不应该相互混淆。

推送通知：这些是唯一不可靠的，因为它们依赖于网络连接和苹果的推送系统......
UILocalNotification: 这些是在某些事件时通知您的用户的方法（您可以将其与推送通知进行比较，只是它不是从服务器发送，而是由您自己的应用在本地触发）
NSNotification: 这些纯粹是技术性的，基本上它们提供了一种广播机制，可用于在您的应用程序的某些部分之间启用通信。我明白，乍一看，在代码中经常使用NSNotification 似乎很方便，因为这是让 2 个（或更多）类相互通信的简单直接的方法。但是，您的高级开发人员是对的，他建议您不要过度使用此机制。主要是因为它会导致编码结构混乱，并且当您的项目变大时不能很好地扩展。另一个大问题是它使调试非常困难。另一方面，当使用 delegates 或完成块时，您有机会以合理的方式构建代码，以确保您封装了应有的功能，使代码更具可读性并且更合适大规模使用。

【讨论】：

【解决方案2】：

不要将NSNotificationCenter 通知与本地（或远程）推送通知混淆。它们完全不同。

来自NSNotificationCenter 的通知是可靠的。这些不使用互联网。它们是在您正在运行的应用程序中进行的简单方法调用。它们与使用其他形式（例如委托）一样安全。

当您只是想向应用广播发生的事情并且您不关心谁知道该事件或有多少听众参与该事件时，使用 NSNotificationCenter 非常棒。

典型的委托模式通常只在事件最多只有一个侦听器时才有效。

【讨论】：