2015-10-13 12 views

risposta

46

ho appena notato questo e anche non riusciva a trovare alcuna documentazione su di esso, ma ho sperimentato con questa nuova caratteristica e funziona così. La prima volta che genera NSManagedObject sottoclasse dal modello Core Data poi Xcode genererà 4 file:

DBUser.h

#import <Foundation/Foundation.h> 
#import <CoreData/CoreData.h> 

NS_ASSUME_NONNULL_BEGIN 

@interface DBUser : NSManagedObject 

// Insert code here to declare functionality of your managed object subclass 

@end 

NS_ASSUME_NONNULL_END 

#import "DBUser+CoreDataProperties.h" 

DBUser.m

#import "DBUser.h" 

@implementation DBUser 

// Insert code here to add functionality to your managed object subclass 

@end 

dbuser + CoreDataProperties .h

#import "DBUser.h" 

NS_ASSUME_NONNULL_BEGIN 

@interface DBUser (CoreDataProperties) 

@property (nullable, nonatomic, retain) NSNumber *id; 
@property (nullable, nonatomic, retain) NSString *name; 

@end 

NS_ASSUME_NONNULL_END 

dbuser + CoreDataProperties.m

#import "DBUser+CoreDataProperties.h" 

@implementation DBUser (CoreDataProperties) 

@dynamic id; 
@dynamic name; 

@end 

Così come si può vedere ora tutte le proprietà sono in un file separato con Categoria (CoreDataProperties). Successivamente, se si genera sottoclasse NSManagedObject per lo stesso modello, Xcode 7 regenarete solo 2 file con categoria (DBUser + CoreDataProperties.h e DBUser + CoreDataProperties.m) per aggiornare tutte le proprietà dal modello, ma non apporterà alcuna modifica a 2 altri file (DBUser.h e DBUser.m) in modo da poter utilizzare questi 2 file per aggiungere alcuni metodi personalizzati o proprietà ecc.

Nella versione precedente Xcode ha generato sempre solo 2 file (DBUser.h e DBUser.m) e metti le proprietà lì così non potresti facilmente modificare questi file perché la tua implementazione personalizzata è stata cancellata ogni volta che hai rigenerato le sottoclassi. Quindi era una pratica comune creare manualmente una categoria e mettere i tuoi metodi nella tua categoria che era oposite a ciò che possiamo vedere in Xcode 7. Che tuttavia aveva molti svantaggi perché dovevamo usare una categoria per l'implementazione dei nostri metodi che non permettere di fare certe cose e ora possiamo facilmente modificare l'interfaccia principale e i file di implementazione che ci permettono di fare qualsiasi cosa con esso. Evviva!

+0

In che modo i dati principali generano categorie con proprietà dinamiche ma allo stesso tempo non possiamo aggiungere proprietà nelle nostre categorie (almeno non senza oggetti associati)? –

+1

Immagino che le proprietà dei dati core siano gestite dalla classe genitore (cioè NSManagedObject) in modo molto diverso dalle normali proprietà in quanto devono essere lette da e salvate su un database locale mentre le normali proprietà funzionano solo su alcuni ivar in memoria. Forse NSManagedObjects potrebbe generare setter e getter per le sue proprietà di sottoclassi in runtime o qualcosa di simile, come è possibile in un linguaggio così dinamico come Objective-C (ad esempio http://sam.dods.co/blog/2014/01/04/dynamic -accessori -per proprietà-categoria/fornisce alcune idee possibili su come implementare questo tipo di cose). –

+0

, quindi stai dicendo che il motivo per cui possiamo avere dichiarazioni di proprietà in questa sottoclasse generata è che le proprietà sono "@dynamic"? –

2

In precedenza il codice generato è entrato in un EntityName.h e in EntityName.m che è stato necessario "estendere" con un'interfaccia come EntityName + Create.h e EntityName + Create.m.

Questo è stato difficile da capire per i principianti che hanno spesso modificato la classe EntityName.m e hanno perso il codice.

Ora è nel modo giusto: il generatore di codice non cancellerà il codice esistente.

Le altre risposte sono molto utili per spiegare il nuovo sistema.

ma nessuno ne parla il nuovo problema di compatibilità se si dispone di entità in base al vecchio sistema.

La mia soluzione: ho ancora messo il mio codice in EntityName + Create.m, ma in EntityName + Crea.h Mi riferisco a EntityName + CoreDataProperties.h invece di solo EntityName.h (ho svuotato il codice generato in precedenza in EntityName.h e EntityName.m). Questa soluzione mi ha permesso di spostare il mio codice da EntityName + Create.m e di modificare tutti i riferimenti in EntityName + Create.h.

Spero che questo ti abbia aiutato.

0

Per Swift e Xcode 7 è la stessa come la risposta da Leszek S, ma solo 2 file vengono creati inizialmente:

  • DBUser.swift
  • dbuser + CoreDataProperties.swift

Successivamente, se si apportano modifiche al modello CoreData e si rigenera la sottoclasse NSManagedObject, viene aggiornato solo lo DBUser+CoreDataProperties.swift. DBUser.swift non viene toccato.

Quindi inserire tutto il codice in DBUser.Swift.