ios - 苹果通知可靠性

Question

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

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

我同意。

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

这是一个简单的例子，当应用程序启动时，我有一个数据更新过程，比如消息和其他东西。更新完成后(大约 3 秒后)，我会发送一个通知，让我的所有 Controller 都收听，以便它们相应地更新它们的 UI。如果我在主屏幕上，我会显示那些红色的小角标(Badge)，如果我在对话中，我会在表格 View 中添加消息，等等。

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

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

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

与它的 addObserver: 显然是对应的。

我选择这种工作方式真的错了吗？我应该怎么办？或者这样可以吗？还是那更棒？

可悲的是，这是一个完全基于意见的问题，因为它是关于标准和良好实践的，但我觉得它不够广泛，不足以违反规则，因为我真的真的觉得有人会提出技术原因来解释这个或应该/不应该做的事情，或者阐明应该在何时何地使用什么。

无论如何，如果需要，请让我澄清任何事情，我真的很想知道所有的回复，我很期待。

Answer 1

iOS 世界中有多种通知，每种都有不同的用途，不应相互混淆。

1. 推送通知:这些是唯一不可靠的，因为它们依赖于网络连接和苹果的推送系统......

2. UILocalNotification:这些是在某些事件发生时通知您的用户的方法(您可以将其与推送通知进行比较，只是它不是从服务器发送的，而是由您自己的应用在本地触发的)

3. NSNotification:这些纯粹是技术性的，基本上它们提供了一种广播机制，可用于启用应用程序某些部分之间的通信。我知道乍一看，在您的代码中经常使用 NSNotification 似乎很方便，因为这是让 2 个(或更多)类相互通信的简单直接的方法。但是，您的高级开发人员是对的，他建议您不要过度使用此机制。主要是因为当您的项目变大时，它会导致困惑的编码结构并且不能很好地扩展。另一个大问题是它使调试非常困难。另一方面，当使用 delegates 或完成 block 时，您有机会以合理的方式构建代码，以确保您按应有的方式封装功能，使代码更具可读性并且更合适大规模使用。