Ios CoreData获取请求返回空数组

我有更多的概念问题，而不是基于代码的问题，因为我的代码是有效的

当我的应用程序启动时，我从coreData获取sessionObject并验证authToken

在我的加载控制器中时，此代码有效。Fetch请求工作并返回会话对象数组。但是，在我验证authToken的应用程序内委托中，返回的数组为空。为什么代码在控制器中工作，而在应用程序委托中不工作？提取请求中没有错误。上下文不是零。这正是我在加载控制器中使用的代码，它可以正常工作

我是否必须在App Delegate中对CoreData执行不同的请求？我可以在应用程序委托中使用提取请求吗

应用程序委托中的示例代码DidBecomeActive方法。我使用DidBecomeActive，这样我们可以在从后台和初始化返回时进行验证

    // check for valid authtoken if present so the correct home screen will display
NSFetchRequest *request = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"CurrentSession" inManagedObjectContext:[self managedObjectContext]];

[request setEntity:entity];
CurrentSession *sessionObj = nil;
NSError *cdError = nil;
if([self managedObjectContext] == nil){
    NSLog(@"context is nil");
}
NSArray *sessionArray = [[[self managedObjectContext] executeFetchRequest:request error:&cdError] mutableCopy];
if (sessionArray != nil && [sessionArray count]) {

    sessionObj = (CurrentSession *)[sessionArray lastObject];
            NSLog(@"Found session %@",sessionObj.authToken);
    if (![sessionObj.authToken isEqualToString:@""]) {
        [Solid_Utilities validateAuthToken:[self managedObjectContext]];
    }
} else {
    NSLog(@"NO SESSION FOUND");
}

编辑 我相信我的问题可能与线程有关。 在loading controller中，我在单独的线程上运行许多任务，并且我假设AppDelegate在主线程上运行。 但是，我提供给加载控制器的上下文是在app delegate中生成的

编辑

---

我在应用程序委托和加载控制器中执行了isMainThread检查，结果都是真的。不知道为什么如果它们使用相同的上下文和存储，它们不会返回相同的对象数组。

看起来答案与我遇到的另一个问题有关。原来，最初的开发人员将核心数据堆栈添加到了基本控制器中，我在app委托中使用了该堆栈，并将其传递给了基本控制器。基本控制器将用它自己的堆栈覆盖我的上下文，这就是为什么我无法在app delegate中获得预期的获取结果

我想说，从我在这个项目中学到的是，在应用程序委托中创建上下文，并将其传递给您的第一个控制器。然后在prepareForSegue中或手动按下时传递上下文。此外，在视图中，您将检查是否返回并更新商店上下文。如果您执行任何多线程操作，请确保应用程序内委托您的上下文为nsmainconcurrencytype，以便您可以为其他线程创建子上下文。这将保持数据结果符合预期，并将冲突降至最低

---

谢谢你在这方面的所有意见。你的回答帮助我找到了那个愚蠢的问题

看来答案与我遇到的另一个问题有关。原来，最初的开发人员将核心数据堆栈添加到了基本控制器中，我在app委托中使用了该堆栈，并将其传递给了基本控制器。基本控制器将用它自己的堆栈覆盖我的上下文，这就是为什么我无法在app delegate中获得预期的获取结果

我想说，从我在这个项目中学到的是，在应用程序委托中创建上下文，并将其传递给您的第一个控制器。然后在prepareForSegue中或手动按下时传递上下文。此外，在视图中，您将检查是否返回并更新商店上下文。如果您执行任何多线程操作，请确保应用程序内委托您的上下文为nsmainconcurrencytype，以便您可以为其他线程创建子上下文。这将保持数据结果符合预期，并将冲突降至最低

---

谢谢你在这方面的所有意见。你的回答帮助我找到了那个愚蠢的问题

显示appDelegate的managedObjectContext方法。您是在视图控制器中也使用AppDelegate的managedObjectContext方法，还是视图控制器有自己的（不同的？）实现来获取managedObjectContext？根据Apple的指导原则，我在app delegate中生成上下文，然后在控制器之间传递。我使用Xcode在执行核心数据应用程序时为您提供的应用程序内委托的stock Core数据堆栈方法。如果上下文存在，则返回else生成新的上下文如果您在不同线程上工作，则需要为MOC使用一种队列并发类型（例如NSMainQueueConcurrency），然后使用一种基于块的MC调用，或者使用您自己的同步方案。至于应用程序委托，代码运行在你调用它的任何线程上，类没有什么特别的，因为它与线程有关。看起来它们都在主线程上。如果我将代码从应用程序代理中移出，并将其放入一个带有NSNotificationCenter for DidBecomeActive的控制器中，它将正常工作。我只是想弄明白为什么它不喜欢app delegate.Show appDelegate的managedObjectContext方法中的代码。您是在视图控制器中也使用AppDelegate的managedObjectContext方法，还是视图控制器有自己的（不同的？）实现来获取managedObjectContext？根据Apple的指导原则，我在app delegate中生成上下文，然后在控制器之间传递。我使用Xcode在执行核心数据应用程序时为您提供的应用程序内委托的stock Core数据堆栈方法。如果上下文存在，则返回else生成新的上下文如果您在不同线程上工作，则需要为MOC使用一种队列并发类型（例如NSMainQueueConcurrency），然后使用一种基于块的MC调用，或者使用您自己的同步方案。至于应用程序委托，代码运行在你调用它的任何线程上，类没有什么特别的，因为它与线程有关。看起来它们都在主线程上。如果我将代码从应用程序代理中移出，并将其放入一个带有NSNotificationCenter for DidBecomeActive的控制器中，它将正常工作。我只是想弄明白为什么它讨厌应用程序委托中的代码。