Question

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

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

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

我可以检测到通知是否会立即过期并添加延迟 - 但这似乎并不理想（添加定时器来解决问题永远不是一个非常好的解决方案IMO，添加多少延迟，如果它足够了在大多数情况下延迟但不是全部延迟，所以要花费更长的时间来补偿，但是第二个VC的推动可能会被推迟，等等。）

当通知触发时，我可以查看VC是否已被推送，如果是，如果已经调用了它的viewDidAppear：并且如果没有推迟处理通知，直到它有。

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

如果没有其他替代方案，延迟处理通知的选项有哪些？他们是否真的可以重新安排操作系统，以便它们在下一个运行循环中执行（这应该给viewDidAppear：执行的机会）？

或者是否有必要使用navigationController：didShowViewController：animated：并检查并处理其中的通知队列？

还有其他选择吗？

由于

Answer 1

你可以试试这个

- (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
}

Answer 2

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

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

}

延迟处理本地通知解雇的策略

2 个答案: