CoreData Plusieurs Store
Salut tout le monde,
Je suis débutant, et je suis entrain de développer une application cocoa de type "Document based application".
J'ai besoin dans cette application d'avoir deux "store" différents; un qui va me servir a sauvegarder le document de l'utilisateur (ça c'est facile, c'est fait); et d'un autre qui est une base de données pour faire fonctionner l'application (ça c'est deja moins facile).
Je ne sais pas comment m'y prendre pour rajouter et venir charger ce second store ... Est ce que je dois rajouter un Appdelegate et venir charger le store la dedans ? J'essaye de trouver une réponse sur internet mais je me noie dans les solutions.
Si vous pouviez me mettre sur une piste ça serait sympa.
Merci d'avance
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est quoi un "Store pour faire fonctionner l'application" ?
beh un fichier sqlite, une base de données ...
Un fichier sqlite et une base de données servent à stocker des données. Je reformule ma question : c'est quoi un fichier sqlite pour faire fonctionner une application ?
Dans ton cas c'est simplement plusieurs NSManagedObjectContext avec des NSPersistantStoreCoordinator distinct, tu duplique simplement le code. L'un en singleton pour ton application (bien que à mon humble avis, NSUserDefault est bien plus adapté à cet usage), et l'autre est dans ta sous classe de NSDocument et permet de charger le fichier.
Hormis le fait que pour tes réglages d'application, NSUserDefault est mieux, attention à une autre chose, le modèle de données CoreData est fait pour OS X et iOS, ce ne sera pas forcément compatible avec un autre OS si tu veux devenir portable, à ce moment là il te faudra créer un nouveau format de fichier.
D'accord.
"pour faire fonctionner l'application" = "pour stocker les préférences de l'application"
Où est ce que je peux prendre des cours ?
?
Dans ma langue à moi ces deux morceaux de phrases ne sont pas équivalents, mais toi (@yoann) tu as immédiatement compris. Donc je demande où je peux prendre des cours (de traduction).
Simple, il suffit de donner des cours soi-même et de faire du support utilisateur final pour ses client IT aussi... Avec ça tu apprends très rapidement à passer de la question posé au problème d'origine ^^
Une phrase courante en IT c'est "Ne me parle pas de ta solution mais plutôt de ton problème d'origine", avec le temps tu arrive à passer de l'un à l'autre sans trop d'explications.
Alors je suis sur la mauvaise voie car je suis un gros fainéant (Toulon c'est encore plus au sud que Marseille). Je donne des cours depuis une vingtaine d'années, quand je ne comprends pas la question je demande au questionneur de reformuler (c'est ce que j'ai commencé à faire dans mon post#2). Il arrive alors que le questionneur trouve la réponse tout seul. Dans ce cas j'en profite pour montrer que la bonne formulation d'un problème est une partie de la solution.
merci pour l'aide yoann,
Je ne vais pas utiliser NSUserDefault, j'ai vraiment une base de données de plusieurs tables à intégrer et je ne pense pas que ça soit prévu à cet effet.
Tu sais ou je pourrais trouver un tuto ou un exemple de code pour voir comment je peux arriver à gérer les NSManagedObjectContext et les NSPersistantStoreCoordinator?
Attention... core data n'est pas une base de données relationnelles. Vu que tu parles de tables...
Avec les endusers tu peux pas te permettre de leur faire reformuler, ils n'en sont pas capable. Et comprendre ce que cherche le student avant coup c'est pratique pour lui montrer que sa question est débile, sa permet de lui montrer la route. Après c'est juste une question de manière d'enseigner et de vocabulaire différent entre certain langage (genre donner des cours Cocoa a des dev .Net ou des dev web c'est donner cours en anglais a des chinois...)
pas de soucis, je vais parler d'entity alors
Yoann t'a donné la réponse dans le post #5. Il suffit de créer deux piles Core Data distinctes.
jpimbert,
merci j'ai bien lu.
Comme j'ai dis plus haut, je suis débutant, donc je chercher un lien tutorial ou exemple de code, pour voir la pratique.
Les choses qui sont simples pour toi ne le sont pas forcement pour tout le monde !
Décidément jpimbert ce soir il comprend rien à rien !
Désolé de mêler mon grain de sel, Messieurs, mais rvzip64 dit qu'il est débutant, et vous l'envoyez se renseigner sur du Core Data à plusieurs Managed Object Context? Wow, wow, wow... Je n'aimerais pas être à sa place (mais bon, je suis peut être plus obtus que lui)...
Heu bah on répond à sa question hein... Débutant ou pas il a besoin de ça donc il apprends...
Il est loin le temps où les débutants commençaient par des applis plus simple et à leur niveau pour apprendre à un rythme correct et assimiler les concepts petit à petit pour être sûr de bien les maà®triser avant d'aller plus loin ! Maintenant tout le monde fait de l'iOS "c'est tendance et puis ça doit être simple si tout le monde le fait", donc tout le monde veut tout de suite faire une application de ouf sans maà®triser les bases...
Heureusement qu'ils ne sont pas maçons, les maisons seraient peut-être construites mais ne tiendraient pas très longtemps debout et les fondations seraient bien bancales ^^
C'est désolant mais ça me fait du boulot.
Je constate une double tendance paradoxale. Là ou auparavant il y avait une grosse moyenne et des extrêmes marginaux, je constate maintenant :
- une prise en compte croissante de la nécessité de produire du code de bonne qualité dans une partie des entreprises/développeurs
- et parallèlement, de plus en plus qui négligent la qualité du code
Il m'arrive de plus en plus souvent de travailler pour des clients au bord du gouffre. Ils ont produit rapidement de grosses applications bien compliquées, puis quelques années ou quelques mois plus tard ils se retrouvent à 80 voire 100% d'activité sur de la correction de défauts, activités souvent très peu rémunératrice par rapport à la production de nouvelles fonctionnalités.
Salut tout le monde,
Je suis assez déçu du comportement que vous avez vis à vis des débutants.
Je viens sur un forum francophone qui parle de cocoa, ou je pose un problème et au lieu de m'expliquer et de me mettre sur la voie, vous passez votre temps sur un pseudo débat : c'était mieux à mon époque;
c'est super ça va me faire du boulot en plus .... encore un nul qui écrit une application; ...
(n'est pas jpimbert ?).
On arrive donc a une dizaine de post ou seulement un ou deux sont réellement constructifs et se préoccupe du problème que j'expose, le reste ne servant à rien( jpimbert ....), c'est assez loin de la vision que je me fais d'un forum.
Merci en tout cas à ceux qui m'ont aidé, pour moi, je vais clôturer mon compte ici, et me diriger vers un forum un peu plus amical.
Bon courage à vous ..... et aux débutants qui viendront ici.
Cordialement
En effet, à tel point que quand on cherche une solution à son problème MacOS, on rencontre en général des trucs farcis de "UI" et des nib qui se reproduisent comme des lapins en chaleur. Et jamais entendu parler des bindings...
Les temps sont rudes.
C'est bien ça confirme que quand les débutants débarquent sur iOS ils se lancent dans des trucs haut niveau comme déjà CoreData direct et en plus avec Plusieurs Stores (ce que même ceux qui utilisent souvent CoreData font déjà rarement...), et qu'en plus quand on leur dit que faudrait commencer par un truc un peu + de leur niveau et d'apprendre à faire les fondations avant de vouloir construire un gratte-ciel, ils se braquent et se barrent au lieu d'écouter et de réaliser qu'ils faut qu'il abordent leur apprentissage autrement...
Là faut être vraiment enragé pour ne pas tomber sur les avertissements d'Apple, parce qu'ils auraient plutôt tendance à nous bassiner avec des "Core Data c'est pas pour les débutants", et "il faut éviter d'additionner les objectContexts"... Moi, sans le bouquin d'Hillegass je n'aurais jamais su par où commencer. Et après un an, je suis toujours dans le flou avec ces "fetching requests" à tire-larigot...
Cela dit, rien de tel que de se cogner la tête dans la doc pour avancer un peu. Avec l'aide bienveillante des membres du forum
@ Draken : tu exagères à peine, hélas...
sinon pour pas réinventer le fil à couper le beurre (et faire plein d'autres choses avec tout le temps gagné), y'a https://github.com/magicalpanda/MagicalRecord