NSOutlineView Source List et CoreData
aurel
Membre
Bonjour,
Après le développement iPhone j'ai décidé de me lancer dans le développement mac et là c'est le drame lol.
Donc dans ma vue qui géré par mon AppDelegate j'ai mit une NSOutlineView Source List ou je cherche à lister mes données de CoreData qui est juste des noms.
J'ai déjà essayé plusieurs tutoriels trouvé sur google mais aucun fonctionne chez moi et puis vu que j'ai un anglais limité c'est pas facile.
Donc comment doit-je faire?
Merci d'avance.....
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Si c'est une liste de nom, une NSTableView semble plus appropriée. Il se trouve que NSOutlineView hérite de NSTableView (c'est d'ailleurs une tragique erreur de conception), et que NSOutlineView est plus difficile à utiliser. Je te conseillerais de partir sur une simple NSTableView dans un premier temps.
Comme une UITableView, une NSTableView est alimentée par un objet répondant au protocole NSTableViewDataSource. Il te suffit d'implémenter les méthodes exigées.
Pour une NSOutlineView, c'est pareil, sauf que le protocole est NSOutlineViewDataSource, et qu'il faudra parfois aller fouiller dans la doc de NSTableView pour trouver les méthodes nécessaires.
Une autre solution est d'utiliser les bindings. Pour une NSTableView, il faut utiliser un NSArrayControler et binder son contentArray sur le NSArray à afficher. Ensuite, il faut binder une NSTableViewColumn.value sur arrayController.arrangedObjects.<titre>.
Pour l'outline view, c'est similaire, sauf que l'objet dans le NSArray doit comporter une propriété isLeaf pour dire si on arrive au bout d'une branche. Je ne me rappelle plus des détails, mais en pratique, binder une NSOutlineView est trop compliqué par rapport au temps gagné à ne pas écrire un data source.
Je te déconseille l'approche bindings dans un premier temps, ça parait magique, mais c'est bien plus complexe qu'il n'y paraà®t, et ça te posera de gros problèmes quand tu voudras quelque chose d'un peu poussé.
Tu verras qu'on peut binder directement un NSArrayController sur un NSManagedObjectContext et préciser le type d'entité. Dans ce cas, le NSArrayController lance lui-même la NSFetchRequest pour récupérer les objets. Là encore, ça va vite à utiliser, mais il y a beaucoup de concepts sous-jacents.
Mon conseil est de commencer simple: NSTableViewDataSource, et lance les requêtes Core Data toi-même pour obtenir un NSArray de tes entités.
Bienvenue dans l'Ancien Monde
Merci berfis
@Céroce en faites je voulais prendre ça car le design est plus beau je trouve mais ok je vais me lancer dans un simple NSTableView et après je verrais si j'arrive à modifier le design pour ressembler à une NSOutlineView.
Et les méthode que j'avais trouvé c'était soit avec un NSArrayController ou un TreeController mais rien fonctionnait en faites si un fonctionnait j'avais bien mes cellules mais je n'avais pas le texte dedans elles étaient vides j'ai du loupé un épisode.
Merci beaucoup je vais pouvoir en fin avancer.....
Core Data + NSTreeController... le moins que l'on puisse dire c'est que tu as fixé la barre très haut pour une entrée sous MacOS... Core Data n'est pas précisément un framework d'entrée de gamme, quant au NSTreeController... ben c'est pas le plus simple des contrôleurs.
Sans vouloir te décourager, commence par des trucs plus simples utilisant ce que tu connais déjà sous iOS, genre NSTableView, ArrayController et... d... da... datasource (aà¯e j'ai les doigts qui saignent).
Sous ios coredata c'est carement plus simple et même les tableview etc je trouve qu'il se sont compliqué la vie sous mac
Non, Core Data est identique, c'est le même framework.
Il y a des changements au niveau de l'interface, le UIKit, et surtout des bindings, inexistants sous iOS pour une raison qui est expliquée quelque part, j'ai oublié où, qui est en rapport avec l'arrangement des vues et de la fenêtre unique.
Je crois que cela te parait plus simple parce que tu le maà®trises mieux. Pour moi, c'est l'inverse, je trouve que le code iOS encourage à la verbosité, à la redondance et au fouillis. Mais c'est parce que je l'ai à peine effleuré...
Bon, ci-joint une mini-application Core Data bâtie sur le principe MVC. Code ajouté à celui fourni par Apple lors de la création du projet : zéro ligne. Fais-en autant sur iOS ^_^
1) c'est plutôt qu'ils se sont simplifié la vie sous iOS ; faut pas oublier que OSX (et ses APIs) est bien antérieur à iOS (et ses APIs), et qu'alors que les APIs de OSX étaient déjà existantes depuis un bail, quand ils ont sorti les APIs de iOS ils en ont profité pour se servir de leur expérience acquise depuis pour améliorer ces API. Puis iOS a eu un énorme succès au niveau des développeurs qui sont devenus plus nombreux que ceux sur OSX, donc au final ils n'ont pas tout de suite mis à jour les APIs d'OSXpour profiter des améliorations apportées par iOS
2) il ne faut pas oublier qu'avant c'était pire, OSX ayant ouvert la voie et ayant une legacy venant de NeXTStep, avant par exemple pour les TableViews pour customiser les cellules c'était encore plus costaud, fallait sous classer des NSCell et c'était assez galère, alors que maintenant on peut faire des View-Based cells pour les NSTableView, amélioration qui vient d'iOS à la base
3) OSX n'adresse pas les mêmes choses que iOS car les deux n'ont pas la même cible en terme d'écran d'affichage en particulier. Sous OSX tu vas beaucoup plus souvent faire des tables à plusieurs colonnes, où tu peux trier selon une colonne en cliquant dessus, tu vas avoir des fenêtres plus grandes que sur un device mobile, des fenêtres qui peuvent bouger, etc. Sous iOS la logique n'a rien à voir, c'est plutôt des tables à une seule colonne (donc plutôt des listes que des tableaux), il n'y a qu'un ecran à la fois (et pas plusieurs fenêtres qu'on peut bouger à notre guise), l'info est plus concise, la logique est plutôt à l'enchaà®nement d'écrans et de VC qu'à du multi fenêtre. Donc nécessairement les APIs sont différentes car adaptées à la plateforme et sont plus complexes sous OSX car l'univers est plus complexe ou du moins différent.
---
En tous les cas on est tous d'accord pour dire que au niveau des APIs depuis qu'ils en ont pondu des nouvelles quand ils ont lancé iOS et sont répartis un peu d'une feuille blanche (bon pas tout à fait mais quand même) pour sortir UIKit qui a quand même pas mal de divergences avec AppKit, ça aurait été bien de réinjecter les améliorations d'API (apportées par le redesign de UIKit) dans AppKit. Mais c'est un travail de longue haleine et ils vont pas casser les APIs existantes de longue date sur OSX du jour au lendemain et casser les habitudes à ce point des développeurs OSX qui font ça depuis des lustres (voire n'ont jamais fait d'iOS mais que du OSX), j'imagine sinon les plaintes qu'il y aurait à tout changer à ce point en si peu de temps, certes pour améliorer les APIs, mais qui sont quand même bien implantées... mais bon faudrait qu'ils se décident un jour à le faire quand même, parce qu'aujourd'hui les APIs d'OSX sont quand même en retard par rapport à celles d'iOS !!!
Là je suis d'accord, un petit "refresh" ne ferait pas de mal aux API d'OSX. J'avoue avoir eu la tentation de sous-classer des trucs pour améliorer le look. Un exemple de hideur OSX: les tabViews...
C'est sur que c'est grâce à Osx que iOS est là , car ils ont tout repris pour l'adapté.
Mais moi ce que je vois c'est que sur iOS pour ajouter des données à une tableview il suffit de mettre deux fonction et voilà ça marche, hors que là non il faut passer par des ArrayController puis paramétrer ce array puis la tableview etc...
J'aurais aimé pouvoir faire une tableview Osx comme sur iOS en ajoutant juste 2 fonction dans le contrôleur.
Ben sous OSX... tu ne rajoutes rien du tout, ça se fait dans IB.
1. Tu crées un arrayController, Mode = Entity Name, Entity name = le nom de ton entité, Parameters: Managed Object Context bind to: AppDelegate managedObjectContext;
2. Tu mets deux boutons "Add" et "Remove", tu les relies aux méthodes add et remove du contrôleur.
3. Tu bindes la colonne de la tableView au contrôleur, Controller Key = arrangedObjects, Model Key Path = le nom de ton attribut Core Data
Et... c'est tout. Magie des bindings. Tu crées, tu édites, tu supprimes. Quand tu quittes, le contenu de ta tableView est automatiquement sauvegardé.
Lectures conseillées + reprendre l'exemple donné + décortiquer mon exemple fourni + une bonne nuit de sommeil. Rome ne s'est pas faite en un jour
- Sous iOS y'a pas les bindings donc fait fournir les données par code : on affecte (souvent par IB) un dataSource et on code les méthodes pour fournir les données (design pattern Délégation).
- Sous OSX on peut faire ça aussi (pattern Délégation avec le même principe de dataSource, même si les noms des méthodes sont un peu différentes)... ou on peut le faire par les bindings (pattern Observer+KVC, au travers d'un ArrayController) souvent entièrement via IB (ce qui donne l'impression qu'on shunte la partie Controlleur du design pattern MVC omniprésent dans Cocoa alors qu'en fait non c'est juste qu'on utilise un Controlleur très générique qui est piloté par des keyPath et du KVO+KVC). Mais on a les deux choix, les 2 possibilités.
Certains préfèrent les bindings (parce que ça fait moins de code à écrire et que grace au KVO la moindre modification du modèle est répercutée dans la vue automatiquement et vice-versa, et qu'au final grâce aux bindings tu peux faire une appli avec très très peu de lignes de code car tu auras tout câblé et configuré via IB), d'autres préfèrent la délégation / dataSource (parce que c'est plus clair pour eux et moins abstrait/alambiqué à debuguer), chacun choisit.
----
Le tuto que tu as l'air d'avoir suivi semble expliquer la façon de faire avec des bindings (souvent mise en avant dans les tutos de l'époque car qui dit bindings dit moins de code à écrire car tout se fait dans IB, et donne du coup un côté magique et vendeur avec une accroche "faites une appli OSX complète avec seulement 15 lignes de code"...) mais ce n'est pas la seule méthode possible, l'autre méthode nécessitant un peu plus de code mais des concepts moins abstraits " et une méthode bien plus proche de celle qu'on retrouve sous iOS " car il faut être honnête, les bindings ça a un côté magique certes mais aussi dans le sens négatif du terme (= "ça marche mais on comprend pas trop comment ni pourquoi", du moins quand on débute dans le domaine) qui n'aide ni à comprendre ou faire évoluer un projet au delà de ce qui a été couvert par le tuto, ni à debuguer en cas de problème voire crash.
[EDIT] Je viens de vérifier en 2s dans la doc, y'a bien une méthode "setDataSource:" sur NSTableView et un protocole NSTableViewDataSource (qui se base un peu sur les mêmes principes que UITableviewDataSource de iOS à quelques détails près).
à‰videmment comme d'habitude tout est expliqué en détail dans un Programming Guide dédié, en particulier dans ce chapitre dudit Programming Guide pour ce qui est de la solution de remplissage de la tableview par code (et non par IB avec des bindings) si tu préfères cette solution, plus proche de ce dont tu as l'habitude avec iOS.
Malheureusement cela reste un hack sur l'ancienne table view.
Il n' y a pas de sections par exemple.
J'ai bien peur que la simplification des API OSX n'arrive jamais.
L'ideal pour moi serait la creation d'un appkit2 reprenant completement les principes de UIKit.
On préfèrera plutôt une présentation Master/Détail avec 2 TableViews par exemple ou une OutlineView avec chaque section qui est un item racine et chaque contenu de section qui peut s'affiche ou se masquer avec le disclosureTriangle en face de la section.
Ce qui va mieux avec de la navigation Desktop car on a + de place sur un Mac qu'un iPhone ou iPad pour mettre 2 TableViews côté à côté Master/Détail et les visionner en même temps, qu'on peut redimensionnes et bouger les fenêtres si certains éléments nous gênent, cliquer plus facilement sur un disclosureTriangle avec la souris qu'on touch sur un écran tactile, etc. Du coup le concept de section à bien moins de sens sur OSX qu'il n'en a sur iOS, même si ça pourrait être pratique parfois c'est quand même beaucoup moins nécessaire.
C'est vrai que d'un côté c'est pas mal trouvé pour faire du neuf avec de l'ancien, mais au niveau IB ça sent vraiment le bricolage.
Notez, depuis NSTableView, tout sent un peu le bricolage: NSOutlineView, NSCollectionView, NSTreeController, ça fait un peu chantier "on verra si on a le temps plus tard, de toute façon les ingénieurs qui ont conçu ça ont tous foutu le camp, notre priorité c'est iOS, on va leur mettre plein de machins colorés avec des bouts de code à recopier histoire que chacun puisse s'exprimer et nous amener du chiffre"... Non ?
1899 applications différentes pour transformer son iPhone en lampe de poche, c'est tout de même pas mal... http://www.blogdumoderateur.com/app-store-apple-400-000-applications-nont-jamais-ete-telechargees/
Je pense qu'au rythme où les bugs sont corrigés et au-delà des annonces "fracassantes" de la WWDC, on n'est pas près de voir évoluer les API MacOS dans le bon sens. Des surcouches, des user-defined attributes, pas de plug-ins...
Par contre, quelques grammes gagnés sur l'ipad, ça c'est une avancée technologique! A quoi bon un Retina Display si c'est pour en faire une lampe de poche...
Bon, je suis un peu de mauvais poil, j'arrive à rien avec une NSOutlineView + Core Data, ne m'en voulez pas trop.