J'écris ma première application iPhone / Cocoa. Il a deux vues de table à l'intérieur d'une vue de navigation. Lorsque vous touchez une ligne de la première vue sur la première table, vous êtes dirigé vers la deuxième vue de la table. J'aimerais que la deuxième vue affiche les enregistrements des entités de Coredata liées à la ligne que vous avez touchée dans la première vue.
J'ai les données Coredata montrant une amende dans la première vue de table. Vous pouvez toucher une ligne et aller à la deuxième vue de la table. Je suis capable de passer des informations de l'objet sélectionné de la première à la deuxième vue. Mais je ne peux pas obtenir la deuxième vue pour faire sa propre récupération de Coredata. Pour la vie de moi, je ne peux pas obtenir l'objet ManageDObjectContext pour passer au deuxième contrôleur d'affichage. Je ne veux pas faire la recherche dans la première vue et passer un dictionnaire parce que je souhaite pouvoir utiliser un champ de recherche pour affiner les résultats dans la deuxième vue, ainsi que insérer de nouvelles entrées aux données CoreData de là.
Voici la fonction qui passe de la première à la deuxième vue à la deuxième vue. p> et ceci est la fonction à l'intérieur de secondViewController qui se bloque: p> - (void)viewDidLoad {
[super viewDidLoad];
self.title = tName;
NSError *error;
if (![[self fetchedResultsController] performFetch:&error]) { // <-- crashes here
// Handle the error...
}
}
- (NSFetchedResultsController *)fetchedResultsController {
if (fetchedResultsController != nil) {
return fetchedResultsController;
}
/*
Set up the fetched results controller.
*/
// Create the fetch request for the entity.
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
// Edit the entity name as appropriate.
// **** crashes on the next line because managedObjectContext == 0x0
NSEntityDescription *entity = [NSEntityDescription entityForName:@"SecondEntity" inManagedObjectContext:managedObjectContext];
[fetchRequest setEntity:entity];
// <snip> ... more code here from Apple template, never gets executed because of the crashing
return fetchedResultsController;
}
10 Réponses :
Êtes-vous sûr qu'il y a une entité appelée "Dachresse"? (Ce serait le moyen simple d'interpréter le message d'erreur.)
Toutefois, s'il s'agit d'une liste de saisie de la liste principale -> Interaction de type de détail, je vous suggère de transmettre l'objet sélectionné directement sur le deuxième contrôleur d'affichage, plutôt que de le donner Juste le "TNAME". Cet objet contient probablement tout ce dont vous avez besoin pour renseigner la deuxième table directement via ses propriétés.
De cette façon, vous ne prenez pas de récupération explicite dans le deuxième contrôleur d'affichage. I.e:
Oui, l'entité existe. Ce n'est pas la liste des maîtres-> détail .. Cela ressemble plus à la catégorie-> Articles, et je souhaite pouvoir interagir directement avec le magasin de données, car la deuxième vue est vraiment l'écran d'interaction principal, donc je ne veux donc pas simplement Passez un instantané à la deuxième vue.
juste pour des coups de pied. Essayez de remplacer:
NSEntityDescription *entity = [NSEntityDescription entityForName:@"SecondEntity" inManagedObjectContext:[self managedObjectContext]];
Intéressant. Je vais essayer cela quand je rentrerai à la maison.
Alors cela signifie-t-il self.title = tname est également une forme de mauvaise forme?
Pas du tout. Bien que je ne sois pas sûr où vient Tname. Syntaxe de points dans l'objectif C est appeler vos méthodes d'accessoir, même si cela peut apparaître frapper des ivars.
Oh, c'est intéressant. J'ai passé du temps de qualité avec la trace de la pile et je pense que je l'ai compris.
SO PushViewController appelle ViewDidLoad non une fois, mais deux fois . La première fois qu'elle appelle viewdiDidLoad, les objets semblent ne pas être instanciés correctement. La deuxième fois, ils sont. Donc, la première fois que ce code est exécuté, il ne peut pas accéder à ManageedObjectContext et il jette une exception. La deuxième fois qu'il court, tout va bien. Pas de crash.
Il y a beaucoup de références à des problèmes avec la vue ViewDidLoad exécutant plusieurs fois sur Google. Je pense donc que la solution est de ne pas faire cette initialisation de demande de récupération dans la vue ViewDidLoad.
J'ai eu du mal avec le même problème et je suis toujours juste un débutant. Je pense que j'ai compris ce qui se passe. Faites-moi savoir si cela a du sens.
En bref, vous essayez de chercher une entité d'un objetContext qui n'avait pas encore été configuré. Vos options sont donc de la configurer à droite puis ou à faire ailleurs dans l'application avant que cette vue ne se charge.
Si votre application est configurée comme la démo d'applications CoreDatabooks à partir du Centre d'iPhone DeV avec un UIAPplication principaleDelegate Gestion également la pile de CoreData, vous devriez être capable de procéder comme suit:
Cela devrait faire l'affaire.
Si (gantedObjectContext == nil) {
ManageedObjectContext = [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[UIAPPLICATION SharedApplication] Délégué] GestionedObjectContext];
}
Une chose à coup sûr, la ligne: secondviewController.managedObjectContext = [auto-gestionnaireObjectContext];
devrait être: secondviewController.ManagedObjectContext = Self.ManagedObjectContext;
Sauf si l'objet actuel implémente une méthode appelée «ManageedObjectContext» qui renvoie cette variable.
Cela pourrait être le problème.
Réponse courte: supprimez votre application puis exécutez-la à nouveau.
longue réponse:
Si vous construisez et exécutez votre projet, CoreData permettra de sauvegarder votre modèle à l'endroit où vous avez dit (lieu de magasin persistant).
Si vous modifiez quelque chose dans le modèle COREDATA, lorsque vous exécutez l'application à nouveau, le nouveau modèle ne correspond pas au modèle enregistré vous donnant cette erreur.
Pour résoudre ce problème, supprimez votre application. Cela se débarrassera du modèle sauvegardé et lorsque vous l'exécutez à nouveau, il recréera votre nouveau modèle.
Vous pouvez supprimer le "-ManageDObjectContext" non trouvé dans les protocoles AVERTISSEMENT en casnant votre délégué de l'application:
if (managedObjectContext == nil) { managedObjectContext = [(MyAppDelegateName *)[[UIApplication sharedApplication] delegate] managedObjectContext]; }
J'ai eu ce problème et j'ai constaté que le message d'initial de mon objet accédait à GestionedObjectContext avant que le SetManageDObjectContext soit appelé ...
Avant: P>
dataController = [DataController alloc]; [dataController setManagedObjectContext:[self managedObjectContext]]; [dataController init];
Apple fournit un exemple de projet appelé "iPhonecoreDaTareeces". Il y a un article très intéressant sur le passage de NsmanagedObjectContext Ici Si vous essayez de mettre en œuvre ce type de logique que chaque ManageedObjectContext est comme une île à part entière dans chaque UIViewController
essayez de changer de code avec cette < Pré> xxx
Dans votre premier TableViewController , vous pouvez transmettre le gantedObjectContext par: secondTablecontroller.managedObjectContext = [(uiapplication *) [[uiapplication SharedApplication] délégué] GestionedObjectContext] , peut-être que c'est ok
Que se passe-t-il lorsque vous mettez le code qui initialise le contrôleur de résultats récupéré dans ViewDidLoad? J'ai une application qui fait essentiellement la même chose, et cela fonctionne bien pour moi, mais je crée mon contrôleur de résultats récupéré directement dans ViewDidLoad avec initwithfetchrequest: GestionedObjectContext: SectionNameKeypath: Cachename:.
@Tim je viens d'essayer cela, il se bloque de la même manière. La chose étrange est que si je définissais un point d'arrêt, toutes les variables de membres de soi sont nuls, mais le titre est correctement défini pour pouvoir être vrai.