iOS: conflicto de modelo de datos básicos con Mail Framework?

Question

Tengo un objeto de datos básicos, Account, representada como una subclase de NSManagedObject:

@interface Account : NSManagedObject 

toda Mi aplicación ha estado desarrollando muy bien, sin embargo, cuando agrego el MessageUI.framework para que pueda obtener un controlador de vista Redactar correo electrónico , todo el infierno se desata. La aplicación enlaza y compila bien y funciona perfectamente. Hasta que, es decir, empiezo a interactuar con mis objetos Account que anteriormente trabajaban. Entonces, comienza a recibir estos:

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', 
reason: '"Account" is not a subclass of NSManagedObject.' 
*** First throw call stack: 
(0x202b012 ... 0x2385) 
libc++abi.dylib: terminate called throwing an exception 

Esta en particular de las cuales fue causada por:

// we need to insert a new account 
Account *newAccount = [NSEntityDescription 
          insertNewObjectForEntityForName:[Account entityName] 
          inManagedObjectContext:self.managedObjectContext]; 

Ahora, supongo que hay una cierta clase en el MessageUI.framework que causa el conflicto, pero algunas preguntas:

1. la aplicación compila y ejecuta muy bien, sin nombre en tiempo de compilación en conflicto
2. los otros componentes en el framew ork parece ser prefix-namespaced (es decir: MFMailComposeViewController), por lo que la cuenta teórica no debe ser MFAccount?
3. Ni siquiera estoy haciendo un #import <MessageUI/MessageUI.h> o el #import <MessageUI/MFMailComposeViewController.h> ligeramente más apretado, el último de los cuales inspeccioné y no vi ninguna definición de Account, así que no estoy seguro de por qué los posibles conflictos incluso se cargarían.
4. Solo para estar seguro, volví a generar mis clases de datos básicos y restablecí todas las configuraciones del simulador, todavía no hay dados.
5. Al eliminar el marco del proyecto y la configuración de la construcción soluciona el problema de inmediato.

Answer 1

que he tenido que esto ocurra a mí, con este es el marco exacto (la clase se llamó Broadcaster). En este caso, el marco privado Message está vinculado por MessageUI, y este marco proporciona la implementación Account.

Puede verificar que el marco MessageUI carga una clase Account al hacer un nuevo proyecto, y en el método del delegado de la aplicación application:didFinishLaunchingWithOptions:, añada el siguiente código:

NSString *account = @"Account"; 
Class accountClass = NSClassFromString(account); 
NSLog(@"accountClass = %@",accountClass); 

En un nuevo proyecto, esto imprimirá accountClass = (null) pero después de agregar MessageUI imprimirá accountClass = Account.

Además, si usa class-dump en el marco privado Message, verá la declaración de interfaz para Account.

Ahora, la lista 5 artículos en su puesto como preguntas, voy a tratar de abordarlos

1. No sé lo suficiente sobre el proceso de tiempo de enlace para trabajar con marcos decir a ciencia cierta , pero sospecho que el marco Message está débilmente vinculado y por lo tanto no causará un error de símbolo duplicado en el tiempo del enlace.
2. Las caras públicas se nombran correctamente, pero algunas no documentadas no. Además, la clase en conflicto está en el marco privado Message.
3. Eso no importa en absoluto. El compilador utilizará #import, pero al tiempo de ejecución, todas las clases se cargan con su aplicación y allí no hay "visibilidad" ni nada de eso aplicado en el tiempo de ejecución.
4. N/A
5. consistente con otras evidencias

En cuanto a un curso de acción, sólo rebautizado mi clase de modelo para tener un prefijo. No estoy al tanto de ninguna otra solución.

Answer 2

Es posible que el marco de mensaje no sea el problema en absoluto. Cosas como esta pueden ocurrir de forma inesperada con los datos centrales, como cuando cambia el modelo de alguna manera. Intente limpiar la compilación, elimine las aplicaciones de prueba instaladas por el simulador/hardware y vuelva a ejecutar. La razón geraldWilliam sugirió el cambio de nombre, creo, es para solucionar este problema, pero puede que no sea necesario cambiar el nombre nada

Salida en este tema: Could not locate NSManagedObjectModel for Entity