CocoaHeads Rennes : CocoaPods & MagicalRecord
AliGator
Membre, Modérateur
Bonjour à tous,
Une petite annonce, surtout pour les rennais d'entre vous (ou ceux qui seraient prêts à faire le déplacement).
Les CocoaHeads reprennent à Rennes dès demain.
Thomas Dupont vous présentera CocoaPods, ou comment faciliter drastiquement l'intégration de composants et librairies tierces dans vos projets
Quant à moi je vous présenterai MagicalRecord, ou comment faciliter drastiquement l'utilisation de CoreData dans vos projets.
Vous l'aurez compris, pour la rentrée aux CH Rennes on veut vous simplifier la vie ! (Et prendre l'apéro à la fin, ça va de soi)
Viendez nombreux
Une petite annonce, surtout pour les rennais d'entre vous (ou ceux qui seraient prêts à faire le déplacement).
Les CocoaHeads reprennent à Rennes dès demain.
Thomas Dupont vous présentera CocoaPods, ou comment faciliter drastiquement l'intégration de composants et librairies tierces dans vos projets
Quant à moi je vous présenterai MagicalRecord, ou comment faciliter drastiquement l'utilisation de CoreData dans vos projets.
Vous l'aurez compris, pour la rentrée aux CH Rennes on veut vous simplifier la vie ! (Et prendre l'apéro à la fin, ça va de soi)
Viendez nombreux
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Urf, sujets intéressants, mais ça fait cher le déplacement
Y aura-t-il un enregistrement?
* je parle bien évidemment de l'apéro.
C'est du breton?
Bretons ivres-mort ? ça n'existe pas ça !
Effectivement, mais bon, Rennes c'est loin
Ben, qu'est-ce que tu dirais si tu habitais comme nous dans le sud-est ?
moi, Yoann, le chat Noir, ...... etc
Pour moi, c'est un pléonasme.
Un oxymore, ce serait un breton sobre
.
J'attends les videos avec impatience ! N'oublie pas de la lancer. Merci d'avance
Un breton ne peut pas être ivre-mort, il tient tellement bien l'alcool qu'il n'arrive jamais à ce stade.
Le record récent (15/04/2013) d'alcoolémie est de 11g d'alcool par litre de sang. C'était un breton?
Enfin, D'avance merci pour les vidéos.
C'était en Provence !! Du côté de chez moi ^^
Aliiiiii, as-tu pensé a record?
Cool, j'ai hate de voir ca
Merci
En même temps, avec le temps que tu dois y consacrer, ça serait normal...
Pour tes 10.000 premiers posts constructifs, d'accord.
Dis Ali, je vais devoir stocker des nouvelles données et cette fois, je vais opter pour CoreData.
Je ne connais pas mais j'ai vu que Magical Record permettait de bien se simplifier la vie.
Question : dois je d'abord apprendre les bases de CoreData ou est ce que je peux me plonger dans Magical direct ?
Merci
Toutes les classes NSPersistentStore, NSPersistentStoreCoordinator, NSManagedObjectModel, NSFetchRequest et tout ça tu t'en fous, MagicalRecord les abstrait pour toi et au final avec MR tu n'as pas à manipuler ces trucs obscurs.
Donc en pratique, je dirais que tu n'as pas grand chose à connaà®tre de CoreData pour t'y mettre avec MagicalRecord. Juste savoir qu'on décrit son modèle objet à Xcode dans un fichier xcdatamodel " tu peux lire la doc de l'outil Core Data Model Editor au besoin " et c'est tout.
Tu fais ton modèle avec cet outil, tu lui demandes de te générer le code des classes correspondantes (les fichiers .h et .m, qu'il sait générer automatiquement à partir de ton modèle), et après tu utilises directement MagicalRecord sans trop avoir à connaà®tre autre chose.
---
Dans un premier temps il y a tout une gamme de méthodes de MagicalRecord que tu ne vas sans doute pas utiliser, je pense en particulier aux variantes qui prennent un NSManagedObjectContext en paramètre, car tu ne sais sans doute pas encore ce qu'est cette classe bizarre, mais c'est pas grave, tu peux t'en passer dans un premier temps. Plus tard quand tu auras déjà fait mumuse avec les bases de CoreData via MR, il sera toujours temps de creuser pour aller plus loin, découvrir des concepts un peu plus avancés comme justement les contextes et découvrir ce qu'ils peuvent te permettre de faire. Mais si tu débutes totalement avec CoreData, ne t'en soucie pas trop pour l'instant, tu peux te débrouiller sans dans un premier temps
(c'est un peu comme le concept de branches dans GIT, ça peut s'avérer très utile mais si tu débutes tu peux déjà faire plein de choses sans avoir à aborder ce concept, avant d'aller le découvrir un jour quand tu veux aller plus loin, mais chaque chose en son temps)
D'accord merci. Une dernière question me turlupine... J'utilise bcp les fichiers properties. Je trouve ça pratique et je n'ai jamais vraiment été "bridé" par ce mode de fonctionnement.
Je les charge dans des dictionary ou des array et roule mon chaton
Du coup, pour mes nouvelles données, je m'étais dit que passer à CoreData serait une bonne chose. Vu que tu encenses MagicalRecord, je me dirigeai donc par là (d'où ma question précédente).
Mais dans le fond... Qu'est ce que ça va m'apporter à part une perte de temps, le temps de l'apprentissage. Alors qu'avec un plist, j'ai ttes mes routines rôdées, prêtes à oeuvrer...
Question existentielle et hautement philosophique... ;-) J'arrive pas à me décider... Une idée qui me ferait basculer d'un côté ou de l'autre ?
Précision : je ne vais pas manipuler un volume de données très important. Qques centaines d'enreg.
- Possibilité implicite de faire des relations entre les objets de façon (sans avoir besoin de gérer des ID dans ton PLIST pour éviter de répéter les objets si tu as des objets A qui sont référencés/contenus par plusieurs objets B par exemple)
- Lazy loading du graphe (c'est ce qu'on appelle le "faulting" en CoreData) autrement dit il ne charge que les données nécessaires en mémoire plutôt que de charger tout le PLIST et tirer toute la pelote de laine (tu vas me dire que tu ne vas pas manipuler un volume de données très important mais il n'empêche que c'est intéressant quand même dans tous les cas)
- Possibilité de faire des requêtes sur tes objets, et ça c'est le top. Par exemple "retourne moi tous les lieux d'escalade qui ont plus de 3 pistes de difficulté >2" ou "retourne moi toutes les pistes qui sont marquées comme ayant été testées" ou "retourne moi toutes les pistes qui sont noté 3 ou +"... tout ça en une seule ligne (grâce à MR) plutôt que d'avoir à boucler sur toutes tes données et construire un tableau des données trouvées etc. (Et plus rapide car sous le capot ce sont des requêtes SQL)
- NSUndoManager intégré, la possibilité d'annuler les dernières modifications sur les données est du coup déjà intégrée tu n'as rien à coder pour ça. Possibilité également (avec les fameux contextes en particulier) d'avoir des bacs à sable dans lesquels tu fais tes modifs avant de sauver (par exemple si tu affiches un ViewController en modal pour permettre à l'utilisateur de modifier une piste, son nom, sa note, etc... et puis qu'en fait l'utilisateur annule ses modifications, t'as rien à faire. Tu modifies tes objets CoreData directement, leurs propriétés, et si l'utilisateur ne clique pas sur Sauver mais sur Annuler, tu oublies ton contexte et ces modifications ne seront pas sauvées, tu n'auras pas à restaurer leur ancienne valeur à la main (ni à créer des objets intermédiaires le temps de l'édition et recopier leurs propriétés dans les vrais objets à la validation) ou autres trucs du genre
- Visualisation et modification aisée du modèle. Avec l'éditeur graphique du modèle tu vois très rapidement tes objets modèle en présence et leurs relations entre eux, tu peux parcourir ton graphe d'objets intuitivement sans te poser de questions, faire des relations cycliques si besoin ça ne pose pas de pb. Et si tu as besoin plus tard de faire un changement dans ton modèle de données, c'est bien plus visuel
- Tu peux mettre des contraintes de validation sur tes objets, validation que telle valeur n'est pas vide, que tel objet A contient au maximum N objets B, etc
- Et enfin last but not least, contrairement aux PLIST, ce sont des objets modèle personnalisés que tu manipules. Ce ne sont pas juste des NSArray de NSDictionary, avec l'obligation de respecter les noms des clés (et de pas faire de faute de frappe quand tu les utilises), non, ce sont de vrais objets avec des @property (et même des méthodes si tu veux en ajouter), avec donc une liste de propriétés bien définies et pas des clés d'un dico
Justement c'est sans doute un très bon terrain pour se mettre à CoreData la première fois : un projet pas trop complexe, mais qui va te faire découvrir par la pratique tout ce que CoreData peut t'apporter !Ben tu vois, quand je vois le coeur que tu as mis à me répondre, je crois que je vais faire l'effort du coup.
Merci bien.
Effectivement, je vois mieux les apports maintenant.
Du coup, je vais peut être tout basculer en CoreData au final.
Mais je vais suivre ton conseil. Je vais me faire la main sur mes nouvelles données et je migrerai mes plists si c'est concluant.
Merci encore ! :-*
PS : en escalade, on parle de voies ou de problèmes (pour le bloc), pas de pistes