Utiliser Core Data comme modèle dans une app sans document.

PyrohPyroh Membre
août 2013 modifié dans API AppKit #1

Bonjour à  tous, je suis nouveau ici mais pas forcément débutant au niveau du développement Obj-C/Cocoa (sans être un expert non plus, entendons-nous).


 


Là  je suis sur un tout petit projet qui me permettra de calculer la taille d'une image en pixel selon la taille requise pour l'impression. Un DPI calculator en somme mais en standalone et un peu plus pratique que ce qui se trouve actuellement sans être révolutionnaire.


 


Quoi qu'il en soit je compte utiliser Core Data parce que je l'ai déjà  utilisé et que je peux déporter tout les calculs dans le modèle et ainsi grâce au KVO/KVC avoir le moins de code possible tout en ayant un UndoManager gratos. Je me suis dit que j'allais utiliser NSObjectController donc j'ai :


 


 - Un NSObjectController dans mon NIB, l'entity est AppData comme dans mon modèle.


 - Le Managed Object Context est bound sur celui de l'App Delegate.


 - J'ai une property value_wide que j'ai bound sur un NSTextField et un NSStepper (sur value) au travers du NSObjectController.


 - Le NSObjectController est référencé dans l'App Delegate par un IBOutlet appelé objectController.


 - Dans applicationDidFinishLunching fais [[self objectController] add:self]; logiquement tout va bien et on doit contrôler un objet.


 


Seulement :


 


 - self.objectController.content renvoie toujours nil.


 - Dans les logs j'ai ça : valueForUndefinedKey:]: this class is not key value coding-compliant for the key value_wide.


 


Bien entendu rien ne fonctionne... Que faire ? Ou plus généralement comment utiliser une entity Core Data sans NSArrayController et avec juste un seul objet tout en utilisant les bindings ? Merci d'avance  o:)


Mots clés:

Réponses

  • Utiliser Core Data sans permanent Storage ? C'est ça la question ?


    Il faut voir du côté de MagicalRecord et de la méthode +setupCoreDataStackWithInMemoryStore


  • T'as réellement besoin d'une base de donnée pour ton truc ? Les binding peuvent s'utiliser sans CoreData...


     


    Tu compte pouvoir lancer le calcul de plusieurs images dans une seule instance ?


  • Je veux tout simplement utiliser la puissance de CoreData pour avoir simplement un modèle à  coder en me concentrant sur les calculs (relativement simples) et je n'ai pas envie d'avoir à  implémenter le undo/redo moi-même. 


    Je veux faire ça vite et bien en exploitant les Frameworks mis à  notre disposition par Apple. Voyez ça comme un exercice, je pourrais faire comme d'habitude et tout implémenter moi-même mais l'idée est d'utiliser un autre moyen cette fois-ci  ^_^


    (Je précise que je suis dessus depuis 3 jours je suis pas venu directement demander de l'aide, d'où le côté exercice)


  • Commence par passer par la case présentation comme il se doit, dans la section adéquat, qu'on sache à  qui on parle.


     


    Du reste, j'ai l'impression que tu fait fausse piste mais bon... D'ailleurs le undo/redo c'est plus avec du NSObjectController que du CoreData en particulier...


  • AliGatorAliGator Membre, Modérateur
    Je vois pas trop non plus le rapport et la justification de l'utilisation de CoreData avec ta problématique... à  se demander si tu a bien compris son but/fonctionnement ?!
  • berfisberfis Membre
    août 2013 modifié #7

    Bonjour Pyroh,


     


    Je me demande si tu n'es pas à  la recherche de la même solution que moi dans un autre sujet: http://forum.cocoacafe.fr/topic/11075-rajouter-un-modèle-core-data-après-coup/


     


    Là  je suis sur un tout petit projet


     


    Core Data est adapté aux projets simples, parce qu'il se charge de beaucoup de travail qui devrait être codé par le développeur (et en général toujours le même: créer des enregistrements, les modifier, les marquer comme modifiés, les enregistrer sur disque etc.). Je ne sais pas s'il est adapté aux "tout petits projets", parce qu'il s'agit quand même d'une usine à  gaz en soi, et il y a plus de choses auxquelles il faut être plus attentif que ne le laissent croire ceux qui font des tutos "pour montrer comme c'est génial".


     


     


    Déporter tous les calculs dans le modèle


     


    Par lui-même, Core Data ne se livre à  aucune manipulation particulière. Si tu veux personnaliser les ManagedObjects, tu vas devoir les dériver. Dès lors, au bout d'un moment à  jongler entre le modèle CD et tes objets dérivés, tu en viens à  te demander où est l'intérêt, et la simplicité du framework se retourne contre toi: au lieu d'être à  ton service, il commence à  dicter sa loi.


     


    Je ne parle pas de l'héritage des NSManagedObjects qui peut aussi réserver quelques surprises...


     


    S'il s'agit vraiment d'un tout petit projet qui nécessite des objets possédant une bonne autonomie et une certaine "intelligence", et qui surtout n'accède pas au disque, ne te sers pas de Core Data, mais dérive tes classes de simples NSObjects, dont tu auras le contrôle complet et que tu pourras organiser en hiérarchie à  ta guise.


     


    Bonne chance !


     

  • L'implémentation d'un undoManager n'est pas si complexe que ça. S'y investir vaut sans doute le coup.




  • - self.objectController.content renvoie toujours nil.


     


    Ou plus généralement comment utiliser une entity Core Data sans NSArrayController et avec juste un seul objet tout en utilisant les bindings ? Merci d'avance  o:)




    Comme tu l'as fait: NSObjectController est l'équivalent, pour un seul enregistrement, de NSArrayController. Son contenu est équivalent à  objectController.selection.


     


    Le content est nil probablement parce que CD ne l'a pas encore chargé en mémoire (c'est un de ces fameux trucs "c'est-génial-tant-qu'on-reste-sur-le-sentier-fleché*. Il fait ça pour gagner de l'efficacité: les objets ne sont effectivement chargés que lorsque l'application en a besoin, par exemple pour l'affichage).


     


    Essaie de forcer le chargement par:



    [self.objectController fetchWithRequest:nil merge:NO error:nil];
  • Bonsoir à  tous.


    Tout d'abord merci pour vos réponses, je n'ai pas eu le temps de consulter le forum ni même encore d'y poster parce que j'ai pris le temps de me marier ce week end  ^_^


     


    Je retouche un peu au code ce soir et j'ai réglé la plupart de mes soucis à  savoir que je n'ai plus de soucis avec l'accès aux données et que le undo manager fonctionne avec Core Data. Je vais pouvoir m'attaquer au modèle mais il y a encore une chose qui me chiffonne : j'ai le fichier .storedata qui grossit doucement mais surement (1k à  chaque lancement). C'est peu mais ça ne fait pas sérieux, il y a un problème de design. Je vais regarder ce que je peux y faire. 


     


    Sinon pour faire simple et pour répondre à  la question que je posais il m'a suffit d'ajouter [_objectController add:self]; à  l'AppDelegate et mettre cet AppDelegate en question en delegate de la NSWindow pour que tout fonctionne (c'est plus facile à  décrire en anglais tout ça...). Le reste des soucis a disparut comme par magie (sans rire, j'ai pas tout compris).


     


    Bref quoi qu'il en soit merci de votre temps. Je prendrais du miens pour me présenter et je vous tiens au courant concernant le projet qui n'est rien de mirobolant mais qui est plutôt pratique. En fait c'est pour calculer la taille d'une image pour la rendre compatible avec l'impression. Inutile avec un soft comme photoshop mais oh combien utile quand on destine des rendus Blender à  l'impression.


     


    Bonne soirée à  vous et merci.


Connectez-vous ou Inscrivez-vous pour répondre.