Core Data est une technologie très puissante et dans ce chapitre, je vais essayer de vous donner un aperçu de quelques-unes de ses autres fonctionnalités.
Utilisez les predicate
Pour l'instant, nous n'avons vu que des requêtes qui permettaient de récupérer seulement tous les objets d'une même entité. On a appris à les ordonner avec NSSortDescriptor. Mais je ne vous ai pas montré comment filtrer les données.
En effet, on n’a pas toujours besoin de tous les objets. Parfois on n'en veut que quelques-uns, choisis selon certains critères. Par exemple, dans notre application, on pourrait ne vouloir afficher que les dépenses d'une seule personne.
Pour faire cela, on utilise ce qu'on appelle les predicate. NSFetchRequest a une propriété predicate de type NSPredicate, qui s'utilise ainsi :
let request: NSFetchRequest<Spending> = Spending.fetchRequest()
request.predicate = NSPredicate(format: "person.name == %@", "Jean-Pierre")Les predicates ont une syntaxe très particulière qui se veut la plus proche possible de l'anglais. La nature du filtre est précisée entre les guillemets et lors de l'exécution, le %@ sera remplacé par la valeur indiquée ensuite : "Jean-Pierre".
Voici d'autres exemples de predicate :
// Récupérer les dépenses dont le montant est inférieur à 100
NSPredicate(format: "amount < %@", 100)
// Récupérer les dépenses dont la description contient le mot pizza
NSPredicate(format: "content CONTAINS %@", "pizza")Vous allez vite voir que vous pouvez faire des tris très puissants en utilisant des predicates.
Implémenter une Table View avec NSFetchResultController
Deuxième arrêt : NSFetchResultController !
Core Data est une technologie d'Apple, et donc elle s'intègre très bien avec l'écosystème iOS. Dans cette optique, NSFetchResultController facilite l'intégration entre Core Data et une Table View.
NSFetchResultController fonctionne très simplement. Il suffit de lui passer une requête NSFetchRequest et il va s'occuper de l'exécuter, de récupérer les données et de remplir la Table View.
Et là où c'est vraiment intéressant, c'est que NSFechResultController peut écouter les modifications qui ont lieu sur la requête : y a-t-il de nouveaux objets ? Certains ont-ils été modifiés/supprimés, etc.? Si c'est le cas, il recharge automatiquement les données en mettant à jour la Table View.
C'est extrêmement pratique !
Ajoutez des méthodes undo / redo
Souvent dans une application, on vous propose d'annuler votre dernière action. C'est le fameux cmd + z sur le Mac.
Avec Core Data, vous pouvez implémenter ce genre de fonctionnalité très simplement grâce au UndoManager.
undoManager est une propriété de type UndoManager de NSManagedObjectContext. Cette propriété enregistre toutes les modifications qui ont eu lieu dans le contexte. Via la méthode undo, vous pouvez annuler la dernière modification. Via la méthode redo, vous pouvez rétablir la dernière modification.
Faite la migration
Le dernier arrêt de ces aperçus n'est pas vraiment une fonctionnalité, mais plutôt quelque chose que vous devez absolument savoir sur Core Data avant d'envoyer vos applications à vos utilisateurs.
Imaginons la situation suivante
Vous avez votre superbe application qui utilise Core Data. Vous avez travaillé dessus depuis 6 mois et vous envoyez la version 1.0 de votre application pour la première fois sur l'App Store.
C'est un succès délirant, et vous avez des milliers d'utilisateurs. Forcément, vous ne voulez pas en rester là et vous décidez de rajouter de nouvelles fonctionnalités dans une version 1.1. Ces nouvelles fonctionnalités impliquent des changements dans votre modèle de données Core Data. Vous ajoutez une entité, en supprimez une autre et en modifiez une troisième.
Vous envoyez la mise à jour à tous vos utilisateurs. Ils l'installent tous et l'application plante ! Votre application ne fonctionne plus sur aucun iPhone ! Ils désinstallent tous votre application, vous avez une mauvaise presse, c'est la fin de l'aventure...
Que s'est-il passé ?
Lorsque les utilisateurs ont installé la version 1.0, c'était la première installation, donc la base de données Core Data était vide. Au fur et à mesure de l'utilisation de l'application, ils ont rempli leur base de données selon le modèle de données défini dans la version 1.0.
Ensuite, ils ont installé la version 1.1. Et c'est ici que le problème intervient. La base de données est toujours remplie selon le modèle de données de la version 1.0. Mais le modèle de données a changé ! Donc les nouveaux objets vont être ajoutés selon un modèle différent.
Or une base de données ne sait pas gérer deux modèles différents, donc l'application plante.
Découvrez la solution
La solution, c'est la migration. Le principe, c'est qu'on va modifier tous les objets de la base de données pour qu'ils se conforment au nouveau modèle.
Une fois la migration terminée, la base est conforme au nouveau modèle. Et on peut ajouter des objets, la base restera homogène.
Pour creuser ce sujet et voir concrètement comment faire une migration, je vous propose ce tutoriel.
Le cours est dorénavant terminé, je vous laisse prendre le temps de découvrir la conclusion !
