To Core Data or not to Code Data : )
Radada
Membre
Salut à tous,
J'espère que vous n'allez pas me lyncher en disant "ouais sujet traité des milliards de fois, etc.", ce qui est vrai, je le reconnais. Mais plus qu'une question philisophique, c'est surtout par rapport à mon appli que je vois ça avec une approche vachement plus pratique...
Alors voilà : j'ai pour projet (beaucoup trop gros pour moi, mais je suis tenace
) de créer une sorte de Journal pour Mac (genre MacJournal) mais spécialisé.
Et avant de commencer, en bon développpeur, j'essaie déjà d'écrire des specs, puis un cahier des charges et un doc technique histoire de partir le plus propre possible.
Mais d'entrée de jeu, la façon dont je vais stocker mes données va avoir une importance capitale. En effet, un journal (ou une entrée pour prendre l'élément de base ou presque) est un fourre-tout qui contient du texte, des images, des vidéos, des liens, etc... Du coup, je me demande si CoreData est bien pour ce genre de truc ou pas? Ou alors, est-ce qu'il vaut mieux que je rédéfinisse toutes les classes dont je vais avoir beoin pour ensuite les encapsuler dans un MegaObject?
Il y aussi la solution du XML avec des Bundle où une entrée pourrait simplement correspondre à un bundle avec des liens vers les différents élements sous forme d'un graphe XML...
Bref, les possiblités ne manquent pas, surement elles ont toutes leurs qualités et leurs défauts, mais il va bien falloir que j'attaque à un moment ou à un autre ; )). Les principaux points concernent au final le stockage (pour pouvoir faire de l'import/export/Drag n' drop), et surtout permettre une recherche dans le texte rapide!!!!
Merci d'avance pour vos lumières.
J'espère que vous n'allez pas me lyncher en disant "ouais sujet traité des milliards de fois, etc.", ce qui est vrai, je le reconnais. Mais plus qu'une question philisophique, c'est surtout par rapport à mon appli que je vois ça avec une approche vachement plus pratique...
Alors voilà : j'ai pour projet (beaucoup trop gros pour moi, mais je suis tenace
) de créer une sorte de Journal pour Mac (genre MacJournal) mais spécialisé.Et avant de commencer, en bon développpeur, j'essaie déjà d'écrire des specs, puis un cahier des charges et un doc technique histoire de partir le plus propre possible.
Mais d'entrée de jeu, la façon dont je vais stocker mes données va avoir une importance capitale. En effet, un journal (ou une entrée pour prendre l'élément de base ou presque) est un fourre-tout qui contient du texte, des images, des vidéos, des liens, etc... Du coup, je me demande si CoreData est bien pour ce genre de truc ou pas? Ou alors, est-ce qu'il vaut mieux que je rédéfinisse toutes les classes dont je vais avoir beoin pour ensuite les encapsuler dans un MegaObject?
Il y aussi la solution du XML avec des Bundle où une entrée pourrait simplement correspondre à un bundle avec des liens vers les différents élements sous forme d'un graphe XML...
Bref, les possiblités ne manquent pas, surement elles ont toutes leurs qualités et leurs défauts, mais il va bien falloir que j'attaque à un moment ou à un autre ; )). Les principaux points concernent au final le stockage (pour pouvoir faire de l'import/export/Drag n' drop), et surtout permettre une recherche dans le texte rapide!!!!
Merci d'avance pour vos lumières.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Tu serais le seul (?) à tenir ce journal ? (donc à accéder à la base ).
Par ce que si tu envisages une sorte de base de données à partager (avec d'autres auteurs ...) c'est pas la peine de réfléchir plus loin.
CoreData est MONO-Utilisateur.
Non, le journal serait en local sur le poste du gars. Ensuite, s'il veut partager, il utilise des fonctionnalités genre drag n' drop, export, mail etc.
Ce n'est pas un journal collaboratif en fait...
Merci
De toute façon, je dirais: commence avec Core Data, dans deux semaines, tu nous annonceras que tu abandonnes tellement c'est compliqué
Au moins, ça t'auras permis de modéliser tes objets.
Lol merci Ceroce : )
Du coup, toi tu partirais sur quoi : création d'objets "classiques" comme en C++ (c'est mon langage de base
Ceci pose un second problème : quid de la façon de stocker les données? Binaire? Xml?
Merci chef
Dans le deuxième cas, tu peux utiliser des fichiers XML, des fichiers PLIST (un autre format XML, spécifié par Apple) ou des binaires.
Tu disposes pour chacun d'un ensemble de classes. Respectivement: NSXMLDocument, NSPropertyListSerialization et NSKeyedArchiver.
L'effort de développement est plus important pour NSXMLDocument que pour NSPropertyListSerialization, lui même plus important que celui de NSKeyedArchiver. Mais l'interopérabilité du format de fichier est inversement proportionnelle.
J'espère ne pas avoir écrit trop de bêtises, n'hésitez pas à me corriger.
Tu peux tout de même essayer de te mettre à CoreData, qui fonctionne main dans la main avec les Bindings, au moins pour ta culture personnelle. Tu apprendras beaucoup sur Cocoa.
Si j'ai tout compris, le NSKeyedArchiver est facile, mais limité alors que le NSXMLDocument est plus complexe mais plus souple, c'est ça?
Par ce que derrière, est-ce que je peux gérer ça "facilement" avec un bundle? Mettre toutes les données multimédia dans des dossiers et gérer le tout avec un fichier plist ensuite? On peut parcourir un plist comme un XML et mettre en forme ensuite? Et le texte, je l'inclus dans le plist ou dans un dossier aussi histoire d'externaliser le tout? Merci chef ;p
Ben Core Data, j'ai fait avec le livre de Hillglass, et c'est vrai que ça à l'air marrant, mais assez limité je pense dés qu'on doit gérer certaines données. Pour un CRM par contre, ça doit être de la balle du coup
Dsl de ne pas poster le nom des objets Cocoa, mais je suis au taf avec mon PC tout pourri : ))))
Merci.
Les webviews ne permettent pas (en tout cas pas directement) l'édition.
Ce n'est pas une question de souplesse, c'est une question d'interopérabilité. Un fichier XML (pourvu que son DTD soit complet) se suffit à lui même. Il peut donc être exploité par un programmeur qui ne connaà®t pas le format de fichier.
Son autre avantage, c'est que tous les langages possèdent aujourd'hui des ensembles de classes pour traiter les fichiers XML. C'est intéressant si tu veux faire un traitement derrière, ou générer un fichier avec un script.
Un exemple de PLIST:
Comme tu le vois, c'est du XML, sauf que le DTD définit les clefs utilisées par Apple (key, real, string, etc.), mais pas à quoi correspondent les valeurs des clefs (BottomMargin, Height...), qui dépendent du programme.
Quant aux keyed archivers, je crois qu'ils génèrent des fichiers binaires, donc pas lisibles par un humain.
Non, non, c'est basé sur SQLite, c'est vraiment performant et efficace. Ses seuls inconvénients sont ceux que nous avons évoqué: la complexité, et le fait que la BdD est forcément locale.
En réalité cela semble être un PLIST au format binaire derrière (l'utilisation de plutil permet de convertir l'archive binaire en XML), mais le PLIST XML derrière est illisible pour le commun des mortels (y'a des IDs partout, des $machin avec des clés réservées, beaucoup de trucs abstraits pour éviter la redondance d'objets ou pour stocker la classe de chaque objet, etc... bref un vrai boxon à décrypter à la main, ce qui est normal ce n'est vraiment as fait pour
A contrario, si l'objet A pointe sur l'objet B qui pointe sur l'objet C qui pointe sur l'objet A, NSArchiver se rend compte de la boucle de références et s'arrête à C. Une fois désarchivé, les relations sont bien rétablies.
D'ailleurs, c'est pareil pour CoreData, c'est pour cela en partie que son format XML est si illisible.