iOS - Conflitto di modello di dati di base con Mail Framework?

Question

Ho un oggetto Core Data, Account, rappresentato come una sottoclasse di NSManagedObject:

@interface Account : NSManagedObject 

Tutta la mia applicazione ha sviluppato bene, tuttavia, quando aggiungo il MessageUI.framework modo da poter ottenere un controller della vista e-mail comporre , si scatena l'inferno. L'app collega e compila bene, e funziona bene. Finché, cioè, inizio ad interfacciarmi con gli oggetti Account che funzionano in precedenza. Poi, ho iniziare a ricevere questi:

*** 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 

Questo particolare uno dei quali è stata causata da:

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

Ora, sto cercando di indovinare che c'è qualche classe nella MessageUI.framework causa il conflitto, ma io hanno un paio di domande:

1. l'applicazione compila e funziona bene, nessun nome in fase di compilazione in conflitto
2. Gli altri componenti del framew ork sembra essere un prefisso-namespace (es .: MFMailComposeViewController), quindi l'account teorico non dovrebbe essere MFAccount?
3. Non sto nemmeno facendo uno #import <MessageUI/MessageUI.h> o leggermente più stretto #import <MessageUI/MFMailComposeViewController.h>, l'ultimo dei quali ho ispezionato e non ho visto nessuna definizione di Account, quindi non sono sicuro del motivo per cui potrebbero essere caricati anche i conflitti possibili.
4. Giusto per essere sicuro, ho rigenerato le mie classi Core Data e ripristinato tutte le impostazioni del simulatore, ancora senza dadi.
5. La rimozione del framework dal progetto e le impostazioni di costruzione risolvono immediatamente il problema.

Answer 1

Ho avuto questo accada a me, con questo è il framework esatto (la classe è stata chiamata Broadcaster). In questo caso, il framework privato Message è collegato da MessageUI e questo framework fornisce l'implementazione Account.

È possibile verificare che il quadro MessageUI carica una classe Account facendo un nuovo progetto, e nel metodo l'applicazione del delegato application:didFinishLaunchingWithOptions:, aggiungere il seguente codice:

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

su un progetto fresco questo stampa accountClass = (null) ma dopo aver aggiunto MessageUI, stamperà accountClass = Account.

Inoltre, se si utilizza class-dump nel framework privato Message, verrà visualizzata la dichiarazione dell'interfaccia per Account.

Ora, vi elenco 5 articoli nel tuo post come domande, cercherò di affrontarle

1. Non conosco abbastanza circa il processo di collegamento in tempo per lavorare con quadri dire con certezza , ma ho il sospetto che il framework Message sia debolmente collegato e quindi non causerà un errore di simbolo duplicato al momento del collegamento.
2. Le finestre pubbliche sono denominate correttamente ma alcune non documentate non lo sono. Inoltre, la classe in conflitto è nel framework privato Message.
3. Questo non ha importanza. Il compilatore utilizzerà #import, ma al tempo di esecuzione , tutte le classi sono caricate con l'applicazione e lì non è "visibilità" o qualcosa di simile applicato nel runtime.
4. N/A
5. In accordo con altre prove

Per quanto riguarda una linea di condotta, ho appena rinominato mia classe del modello per avere un prefisso. Non sono a conoscenza di alcuna altra soluzione.

Answer 2

È possibile che la struttura del messaggio non sia affatto il problema. Cose come questa possono accadere inaspettatamente con i dati di base, come quando si modifica il modello in qualche modo. Prova a pulire la build, a eliminare le app di test installate sul simulatore/hardware e a eseguire nuovamente. La ragione geraldWilliam suggerito rinominandolo, credo, è quello di risolvere questo problema, ma potrebbe non essere necessario rinominare nulla

Partenza questa discussione: Could not locate NSManagedObjectModel for Entity