NSManagedObject实例的核心数据未触发故障,作为应用程序委托的属性 [英] Core Data not firing fault for an NSManagedObject instance as property on app delegate

查看:59
本文介绍了NSManagedObject实例的核心数据未触发故障,作为应用程序委托的属性的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我将登录的用户数据从服务器导入到名为用户的核心数据实体中。我还将对该特定User对象的引用保留在我的AppDelegate上(作为属性),以便可以在我的应用程序中的其他位置访问它。我面临的问题是,当我推送另一个视图控制器并尝试访问appdelegate.loggedInUser.id时,我看到 id为nil。调试器为对象显示了此信息:

I import the logged in user's data from server into a Core Data Entity called "User". I also keep a reference of this specific User object onto my AppDelegate (as a property) so I can access it elsewhere in my app. The problem I am facing is, when I push another view controller and try to access appdelegate.loggedInUser.id , I see that "id" is nil. Debugger shows this for the object :

$24 = 0x0b28ad30 <User: 0xb28ad30> (entity: User; id: 0xb261160 <x-coredata:///User/tC48E8991-B8A6-4E68-9112-93F9F21DB5382> ; data: <fault>)

我的理解是,当我尝试访问该对象的属性之一时,Core Data框架将引发故障。对于为什么我访问用户的 id属性在这种情况下没有引发错误,我感到困惑?

My understanding was that the Core Data framework would fire the fault the moment I try to access one of the properties of this object. I am confused as to why me accessing the "id" property of the user is not firing a fault in this case?

编辑

这是创建和使用loggingInUser对象的方式:

This is how create and use the loggedInUser object :

//method to get bgContext 
+(NSManagedObjectContext *)getContextOnBgWithParentSetToMainMOC
{
  NSManagedObjectContext *tmpContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
  [tmpContext setParentContext:[Utils getAppDelegate].managedObjectContext];
  return tmpContext;
}

//in App Delegate
NSManagedObjectContext *bgContext = [NSManagedObjectContext getContextOnBgWithParentSetToMainMOC];
   self.loggedInUser = [User importFromObject:loggedInUserData inContext:bgContext completionBlock:^(NSManagedObjectContext *theContext, NSManagedObject *theManagedObjectWithValuesImported) {}];

//In User.m file
+ (User *)importFromObject:(NSDictionary *)dictionary inContext:(NSManagedObjectContext *)context completionBlock:(TemporaryContextImportReturnBlock)block {

  if ( !context ){
    context = [NSManagedObjectContext getContextOnBgWithParentSetToMainMOC];
  }

  NSManagedObjectContext *localContext = context;
    User *newUserEntity = [NSEntityDescription insertNewObjectForEntityForName:@"User" inManagedObjectContext:localContext];
    NSArray *emailsArray = [dictionary objectForKey:@"emails"];
    NSString *emailsString = @"";
    if ([emailsArray count] > 0){
      emailsString = [emailsArray componentsJoinedByString:@","];
    }
    newUserEntity.emails = emailsString;
    newUserEntity.id = [dictionary objectForKey:@"id"];
    newUserEntity.n = [dictionary nonNullObjectForKey:@"n"];
  return newUserEntity;
}

//Access in one of the view controllers
    User *loggedInUser = [Utils getAppDelegate].loggedInUser;
//    loggedInUser.id /*nil*/


推荐答案

我有同样的问题。事实证明,根据此答案,其中引用了 Apple文档,即 NSManagedObject 可以如您所料, not 强烈引用其 NSManagedObjectContext 。我怀疑如果检查对象时未能正确触发 [myObjectmanagedObjectContext] == nil

I have the same problem. It turns out, according to this answer, which references the Apple docs, that an NSManagedObject does not hold a strong reference to its NSManagedObjectContext as you might expect. I suspect that if you inspect your object when it doesn't fire the fault properly that [myObject managedObjectContext] == nil.

我不知道这里有什么最佳实践。一个明显的(但可能很困难)的解决方案是找出为什么要取消分配MOC。另外,尽管我不确定这样做是否安全,但是您可以保留每个 NSManagedObject 实例中的MOC。 (我在这里对此有疑问。)

I don't know what best practices are here. The obvious (but potentially difficult) solution is to find out why your MOC is being deallocated. As an alternative, although I'm unsure whether it's safe to do, you could retain the MOC from each NSManagedObject instance. (I have question about that open here.)

这篇关于NSManagedObject实例的核心数据未触发故障,作为应用程序委托的属性的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆