Remplacer l'instanciation d'objets de Builder Interface?

Question

Je développe pour l'iPhone, et j'ai une classe DataManager, qui est utilisée pour gérer mes données d'application. Lorsque l'application se lance/quitte, les données sont lues/écrites sur le disque pour créer une instance de cette classe, en utilisant les classes NSKeyedArchiver (et Unarchiver), puisque le DataManager adhère au protocole NSCoding. Un problème que j'ai est que j'ai besoin que le DataManager soit accessible par plusieurs de mes autres classes IB, donc il est défini comme un objet dans IB, et ces classes ont un débouché. Le DataManager est créé en utilisant la méthode standard init: (ou peut-être initWithCoder :?), mais comme IB n'a pas le bon fichier (ou NSData du fichier) pour instancier l'objet, il n'a pas de contenu initial.

Donc, est-il possible de dire à IB pas à d'instancier automatiquement la classe? Ce sera plutôt être effectuée en utilisant mon délégué de l'application, quelque chose comme:

AppDelegate.h

IBOutlet DataContext *context; 

AppDelegate.m

context = [NSKeyedUnarchiver unarchiveObjectWithData:dataLoadedFromFile]; 

Comme vous pouvez le voir, cela pose un problème . Le contexte ne serait-il pas instancié deux fois, une fois par InterfaceBuilder, puis une seconde fois par mon délégué d'application?

Je voudrais éviter de conserver le contexte en tant que ivar dans le délégué, car cela semble s'écarter du paradigme MVC, et se pencher plutôt vers le modèle singleton. (Le contrôleur ne devrait pas être responsable des données dans mon esprit, il peut évidemment conserver une référence, mais ne devrait pas être responsable de l'offrir à d'autres classes.)

Answer 1

Lorsque l'application est lancée/sortie, les données sont lues/écrites sur le disque pour créer une instance de cette classe, en utilisant les classes NSKeyedArchiver (et Unarchiver), puisque le DataManager adhère au protocole NSCoding. Un problème que j'ai est que j'ai besoin que le DataManager soit accessible par plusieurs de mes autres classes IB, donc il est défini comme un objet dans IB ... Comme vous pouvez le voir, cela pose un problème. Le contexte ne serait-il pas instancié deux fois, une fois par InterfaceBuilder, puis une seconde fois par mon délégué d'application?

Yup. En premier lieu, vous devez déterminer s'il s'agit d'un contrôleur ou d'un objet de modèle. Cela me semble être un contrôleur. Si tel est le cas, vous devez déplacer le modèle vers un objet ou des objets distincts, rendre ces NSCoding compatibles et charger le gestionnaire de données et enregistrer ces objets. Un avantage de cette solution est que vous pouvez demander au gestionnaire de données d'enregistrer les objets et de les purger lorsque vous recevez un avertissement de mémoire insuffisante, et pas seulement au moment de la fermeture.