Ios 延迟本地通知触发处理的策略

我的应用程序从服务器下载内容，一旦下载完成，它就会解析其内容，任何人也可以显示它。如果显示，则将VC推送到导航堆栈上

在处理内容的过程中，可能需要安排本地通知。 当通知触发时，VC也被推到导航堆栈上以显示某些内容

我有一个本地通知立即过期的问题-问题是在这种情况下，第二个VC的推送发生在ViewDid出现之前：从第一个VC推送开始执行

我可以检测到通知是否会立即过期并增加延迟，但这似乎并不理想（添加计时器来解决问题从来都不是一个很好的解决方案，IMO，添加多少延迟，如果在大多数情况下（但不是所有情况下）延迟足够，那么请延长时间进行补偿，但第二个VC的推送可能会明显延迟，等等）

当通知触发时，我可以查看VC是否已被推送，如果是，则查看其ViewDidDisplay:是否已被调用，如果没有，则推迟处理通知，直到它被调用为止

这是可行的，但有一点混乱，以保持跟踪，如果/什么阶段的VC推。 有更优雅的解决方案吗？我更愿意避免在应用程序中添加另一个队列

如果真的没有任何替代方案，那么延迟处理通知的选项有哪些？例如，是否可以使用操作系统重新安排通知的时间，以便在下一个运行循环中执行通知（这将使ViewDidAppeal:有机会执行）

或者是否需要使用navigationController:didShowViewController:animated:并检查和处理其中的通知队列

还有其他选择吗

谢谢你可以试试这个

- (void)pushVC {
    @synchronized (self) {
        HomeViewController *vc = [[[HomeViewController alloc] init] autorelease];
        [self.navController pushViewController:vc animated:YES];
    }
}

- (void)processLocalNotification:(UILocalNotification *)notification {
    [self performSelector:@selector(pushVC) withObject:nil afterDelay:2.0f]; // delay for animation
}

---

另一种方法是，检查现有通知，如果新通知太近，只需添加一些时间

UIApplication *app = [UIApplication sharedApplication];
for (UILocalNotification *notification in [app scheduledLocalNotifications]) {

}

---

你能澄清一下这一点吗？：“我有一个问题，本地通知立即过期-问题是在这种情况下，第二个VC的推送在ViewDid出现之前发生：从第一个VC推送开始执行。”1）VC被推送到导航堆栈2）它的视图将出现：被调用3）在它的ViewDidDisplay被调用didReceiveLocalNotification:被调用4）这将导致VC被另一次推送到导航堆栈。这会导致“开始/结束外观转换的调用不平衡”/“嵌套推送动画可能会导致导航栏损坏”。我需要确保VC的第二次推送不会发生，直到ViewDid出现：从第一次VC的推送开始执行。第二个VC的推送结果是本地通知触发的结果。谢谢，我尝试了一次延迟，并且成功了，但是正如前面提到的，如果可能的话，我希望尽量避免延迟。但如果这是最简单的处理方法，我们可能会去做。为什么@synchronized是必需的？如果几个本地通知同时触发，那么在这种情况下也可以吗？只需测试一下，添加几个具有相同fireDate的通知