因此,作为一种解决方法,我正在创建一种方法来识别这些无效匹配,以便我可以适当地处理它们.损坏的matchData似乎是一种很好的方法.但是,到目前为止,我一直无法识别它们.当我这样做：

// "match" is an existing GKTurnBasedMatch object
NSLog(@"match data is: %@",[match matchData]);
NSLog(@"match data is nil? %@",[match matchData] == nil ? @"YES" : @"NO");
NSLog(@"match data equals empty nsdata? %@",[match matchData] == [NSData data] ? @"YES" : @"NO");

我得到以下内容：

match data is: <>
match data is nil? NO
match data equals empty nsdata? NO

所以匹配数据显示为一对空括号“<>”,我希望可以将其识别为零,但显然不是.

顺便说一句,我将此matchData存储在NSData属性下的核心数据实体中.当我保存NSManagedObjectContext,然后NSLog NSManagedObject来查看其中的内容时,有问题的NSData属性仍显示为“<>”！

但是,如果我然后创建一个新的NSManagedObjectContext,从中检出相同的NSManagedObject,然后NSLog其值,NSData属性现在显示为nil.

因此,似乎在某些时候,核心数据将该属性“清理”为其价值.我的问题是,在将该值添加到核心数据存储之前,我实际上需要在该点之前将该值标识为nil.