Si l'usage de la mémoire explose dans certains cas en utilisant ARC, c'est parce que ce dernier n'est pas encore tout à fait mature.
Tu es précisément l'exemple dont Mala et moi parlions.
Crois-en notre expérience et notre expertise sur le sujet, et pour l'avoir étudié je sais parfaitement comment ARC fonctionne sous le capot et ses implications au niveau du Runtime ça n'a rien à voir avec une question de maturité.
Par exemple savoir si tu veux qu'une propriété ou variable ait une memory policy weak ou strong ça c'est pas une question de ARC pas assez mature pour savoir le deviner à ta place, c'est une question de "ça dépend de ce que tu veux faire".
Tu peux parfaitement créer des retain cycle et faire exploser la mémoire si tu en as envie et c'est pas parce que ARC n'est serait soit disant pas assez mature mais parce que tu aurais mal défini la logique d'ownership de tes objets.
ça ARC n'y peut rien et ne peux pas deviner.
Par contre le static analyzer peut te dire qu'il y a incohérence et retain cycle mais il ne pourra pas deviner lui non plus lequel des 2 strong il faut passer en weak (par exemple) puisque ça ça dépend de la sémantique de ton modèle.
Au final comme je le disais justement plus haut le problème avec les débutants qui utilisent ARC c'est que comme toi ils ont tendance à croire que ARC signifie qu'on n'a plus à se poser de question sur la gestion mémoire, alors que rien que l'ownership par exemple ça aucun mécanisme ne pourra jamais la deviner pour toi,
Si j'étais toi, je me concentrerai à fond sur toutes ces nouvelles techno avant que mes compétences, autrefois au top, ne servent plus à grand chose.
Je ne vois pas le rapport et ne comprend pas trop ta remarque ici...
D'une part Mala comme moi on n'a jamais dit qu'il ne fallait pas utiliser ARC. Perso je l'utilise tous les jours sur tous mes projets, je trouve ça génial et je ne voudrais surtout pas revenir en arrière et revenir sur du MRR.
On a juste dit que même si ARC c'est génial faut pas pour autant croire " comme ont l'air de le penser beaucoup de débutants " que ça fait tout en particulier que ça peut t'éviter de réfléchir sur l'ownership et les conséquences sur le lifecycle de tes objets.
Mais tout ça ne m'empêche en rien d'être au top des nouvelles technos, de faire de la veille et de connaà®tre à peu près toutes les nouveautés du Runtime, d'ObjC, et du SDK de iOS7 par exemple.
Je ne vois vraiment pas le rapport entre "avoir conscience que ARC n'empêche pas de devoir avoir conscience des risques de retain cycle" et "ne pas se concentrer à fond sur les nouvelles technos". Au contraire d'ailleurs je dirais que connaà®tre les nouvelles technos sur le bout des doigts comme moi " tout en ayant connaissance de leur historique " me permet de mieux connaà®tre aussi leurs limitations et les pièges dans lesquels il ne faut pas tomber (comme la certitude fatale que ARC peut tout résoudre)
Cette discussion est passionnante et très instructive pour un "développeur médiocre" comme moi.
On a juste dit que même si ARC c'est génial faut pas pour autant croire " comme ont l'air de le penser beaucoup de débutants " que ça fait tout en particulier que ça peut t'éviter de réfléchir sur l'ownership et les conséquences sur le lifecycle de tes objets.
Où peut-on trouver une initiation à la réflexion "sur l'ownership et les conséquences sur le lifecycle des objets" ? En gros, ici, les strong, weak et autres, que j'utilise sans rien y comprendre par analogie avec du code que je vois ici ou là ou que me propose Xcode ?
Une initiation faite pour un non-informaticien comme moi qui sait ce qu'il veut obtenir et qui se moque des choses qui font l'objet d'innombrables thèses universitaires, comme la persistance de données.
Au fait avec la quantité d'informations, de pratiques, de solutions proposées sur CocoaCafé, il y aurait de quoi faire un WikiCocoa ou un DidactiCocoa, non ?
Où peut-on trouver une initiation à la réflexion "sur l'ownership et les conséquences sur le lifecycle des objets" ? En gros, ici, les strong, weak et autres, que j'utilise sans rien y comprendre par analogie avec du code que je vois ici ou là ou que me propose Xcode ?
Une initiation faite pour un non-informaticien comme moi qui sait ce qu'il veut obtenir et qui se moque des choses qui font l'objet d'innombrables thèses universitaires, comme la persistance de données.
Au fait avec la quantité d'informations, de pratiques, de solutions proposées sur CocoaCafé, il y aurait de quoi faire un WikiCocoa ou un DidactiCocoa, non ?
A toutes ces questions, je répond : RTFM ^^ Car comme d'habitude, tout est dans la documentation Apple.
2) Et surtout pour savoir quand utiliser les strong ou les weak, tu as tout dans Transitioning to ARC Release Notes, y compris entre autres un paragraphe "Use Lifetime Qualifiers to Avoid Strong Reference Cycles" (mais pas que).
3) Pour ce qui est du WikiCocoa ou d'un DidactiCocoa, je ne vois pas trop l'intérêt étant donné que ce type de contenu existe déjà dans la doc Apple (genre la DevPedia Apple, ou la tonne de Programming Guides avec toutes les explications des concepts, les exemples de code, etc)...
---
Quand je lis "les strong, weak et autres que j'utilise sans rien y comprendre par analogie avec du code que je vois ici ou là " c'est justement ce que Mala et moi avons soulevé et ce qui me fait peur quand je vois des débutants utiliser ARC : le risque avec ARC que les gens ne comprennent plus la signification et les conséquences de ces qualifiers et les utilisent sans trop savoir à quoi ils correspondent (alors que Dieu sait qu'ils sont importants !), et ne prennent pas la peine de se former dessus, se disant qu'ARC est magique et qu'ils n'ont plus à se poser de questions sur la gestion mémoire...
Je ne vois pas le rapport et ne comprend pas trop ta remarque ici...
Ok, suite à tes précisions, je suis conscient de m'être fourvoyé.
C'est que j'ai tellement entendu des vieux de la vieille (pas ici) dénigrer et mépriser, par exemple, tout ce qui est GUI en les désignant comme des "clickodromes" que maintenant j'ai parfois de mauvais réflexes.
Ce que je veux, c'est, entre autres, réaliser une interface graphique qui tourne sur un Mac et qui me permette de gérer un herbier virtuel dont les données sont stockées dans une base de données PostgreSQL distante.
Apple offre un outil Xcode qui me permet de construire le programme (pardon, l'application) correspondante.
Xcode utilise le langage Objective-C et les bibliothèques Cocoa. J'arrive à construire mon application bien sûr, parce que je suis bête et obstiné, et qu'il y a CocoaCafé.
Objective-C est un langage de programmation comme tout autre langage de programmation. Il utilise les constructions du C auquel il ajoute celles qui permettent de dire que c'est un langage à objets. Bon, rien à dire jusque là . C'est même plutôt rigolo. Mais, je comprends mal qu'il faille aujourd'hui se préoccuper de strong et autres weak, qui ne concernent que la mémoire et qui pallient les déficiences intrinsèques des langages à objets. Qu'est-ce que ça apporte à la résolution de mon problème ?
La documentation Developer sur les NS... Class Reference est plutôt bien faite, si ce n'est qu'elle n'est pas à jour (cf. NextResponder et tient peu compte de ARC).
Le problème, c'est les Guide.
Les Guide sont fait pour des développeurs professionnels qui veulent comprendre ce qu'il y a sous le capot (ce qui se passe en mémoire), pour les autres c'est incompréhensible, sauf parfois des portions de codes, trop rares.
C'est l'image éculée, mais toujours pertinente, du conducteur et du mécanicien : je veux savoir à quoi sert le changement de vitesses et pourquoi l'utiliser ; comment il le fait ne m'intéresse pas : avec des courroies, avec des tiges articulées, etc.
Quant aux Example, ils sont choisis tellement compliqués, que les aspects qu'ils sont censés illustrer sont cachés au sein d'une application très lourde et introuvables, à quelques exceptions près.
J'ai cherché sur developer.apple.com le terme property.
Je n'ai rien trouvé. Et pourtant, c'est quelque chose d'essentiel, non ?
Y compris dans le Glossary, où il n'y a pratiquement rien ( même pas getter ou setter...).
Quant à DevPedia Apple, tu plaisantes, je suppose? C'est encore pire que le reste.
Quand, j'ai proposé un WikiCocoa, c'était dans l'idée pour permettre à des non informaticiens (ils me semble qu'il y en à ici), de débuter ou de continuer dans le développement d'application OSX (ou IOS), ce que ne permet pas de fait la documentation Apple.
C'est que j'ai tellement entendu des vieux de la vieille (pas ici) dénigrer et mépriser...........................
D'accord avec toi sur les vieux de la vielle et j'espère ne jamais en faire partie. Un chanteur que j'ai vu sur scène en 1966 a été un peu plus loin! et j'aime beaucoup!
Mais, je comprends mal qu'il faille aujourd'hui se préoccuper de strong et autres weak, qui ne concernent que la mémoire et qui pallient les déficiences intrinsèques des langages à objets. Qu'est-ce que ça apporte à la résolution de mon problème ?
Si tu regardes tous les autres langages objet, genre C++ ou autre, tu verras que c'est pas un problème propre à ObjC, mais à tout langage Objet. En C++ par exemple faire des new et des delete, et surtout gérer ça proprement dans une application multithread (où faut pas delete un objet si un autre thread l'utilise encore, mais pour le savoir c'est galère), tu comprendras que le Reference Counting t'apporte beaucoup. strong et weak sont des concepts qui viennent implicitement avec la gestion du life cycle des objets d'un langage orienté objet. Ces concepts sont aussi vrais dans d'autres langages sauf que dans les langages où ces mots clés ne sont pas intégrés au langage lui-même, faut gérer tout ça à la main, penser à détruire un objet fils quand son père est détruit, etc, et c'est une galère sans nom.
Donc la question "qu'est ce que ça m'apporte" n'a pas de sens (et montre que tu n'as sans doute pas assimilé tous les concepts de la POO). C'est un concept qui est présent intrinsèquement. (C'est comme si tu disais "je veux un véhicule qui roule, mais qu'est ce que ça m'apporte de lui mettre des roues ?" bah c'est la nature même d'un véhicule qui roule d'avoir des roues, la question n'a pas trop de sens...)
La documentation Developer sur les NS... Class Reference est plutôt bien faite, si ce n'est qu'elle n'est pas à jour (cf. NextResponder et tient peu compte de ARC).
Je suis d'accord que toute la documentation n'est pas forcément à jour. Les liens pour le signaler à Apple ne sont pas pour les chiens. Et c'est d'ailleurs pour ça que je t'ai remonté plus haut que c'est pas jouable de faire un CocoaWiki ou quoi de notre côté, car quand on voit le nombre pharamineux de pages de documentation (Class Ref, DevPedia, Guides, Samples, TechNotes, et j'en passe) qu'il y a à écrire vu le nombre de sujets, je vois pas en quoi on aurait + de chances de les garder toutes à jour qu'Apple.
On avait déjà fait à une époque sur PommeDev (l'ancêtre de CocoaCafé) l'essai de faire des tutoriels, des cours, des docs... rédigés par moi et d'autres membres du forum. En pratique non seulement c'était chronophage à un niveau sans nom, mais en plus on n'avait jamais le temps de le mettre à jour, et au final ça devenait obsolète et donc on avait fait un travail de dingue pour les rédiger... pour rien si on avait jamais le temps de mettre à jour.
Le problème, c'est les Guide. Les Guide sont fait pour des développeurs professionnels qui veulent comprendre ce qu'il y a sous le capot (ce qui se passe en mémoire), pour les autres c'est incompréhensible, sauf parfois des portions de codes, trop rares.
C'est l'image éculée, mais toujours pertinente, du conducteur et du mécanicien : je veux savoir à quoi sert le changement de vitesses et pourquoi l'utiliser ; comment il le fait ne m'intéresse pas : avec des courroies, avec des tiges articulées, etc.
Alors là par contre je ne peux que tomber des nues : au contraire, les Programming Guides sont très bien faits chez Apple (contrairement à chez certains concurrents ou autres SDKs) puisqu'ils expliquent les concepts. Ils expliquent le minimum à savoir, par exemple que les UITableViews utilisent le mécanisme de recycling qu'il faut absolument connaà®tre pour pouvoir manipuler des tableviews (sinon bonjour les dégâts), pour t'expliquer les concepts. Par contre ça parle pas de comment ça marche sous le capot.
Le Class Reference t'indique que tu as une méthode qui permet de changer les vitesses. Donc juste la bête liste exhaustive des méthodes de la classe
Le Programming Guide t'indique que attention, si tu veux changer de vitesse, il faut penser à appeler la méthode enfonceEmbrayage avant et relacheEmbrayage après. Donc comment utiliser les différentes méthodes ensemble pour que ça marche, quel enchaà®nement faire, ce à quoi il faut faire attention (ne pas lâcher la pédale d'embrayage trop vite, etc...)
Par contre Le Programming Guide n'est pas là pour t'expliquer que quand tu passes une vitesse tu as des pignons et une boite de vitesse en dessous et t'expliquer le détail mécanique de la boite de vitesse et comment c'est foutu pour le cas de la marche arrière et tout. Ca c'est dans des blogs comme celui de mikeash que tu vas retrouver ça, mais ça commence alors à rentrer dans du super technique qui n'est utile que si tu es curieux, mais qui ne t'es pas du tout utile pour conduire et passer les vitesses dans la vie de tous les jours.
Donc je pense que tu as mal compris l'objectif et le contenu des Programming Guides. Ils sont complets car expliquent des concepts. Si tu veux expliquer un concept de Design Pattern par exemple, comme le MVC, c'est un Programming Guide qui va l'expliquer, c'est un concept à mettre en pratique dans tes codes Cocoa, ça s'explique pas dans une Class Reference qui liste juste des méthodes. Ca explique des bonnes pratiques et comment utiliser au mieux tel ou tel truc, avec des exemples de code. Et ça remplit parfaitement ce rôle.
Après, si tu les trouve trop longs à lire, c'est que tu n'as pas réalisé que faire de la POO d'une part, sur un environnement mobile d'autre part (avec ses contraintes affiliées, réseau, etc), spécifique (iOS) d'autre part, et avec des bonnes pratiques génériques (ne pas bloquer l'utilisateur, etc), tout ça nécessite d'avoir assimilé beaucoup de concepts avant. On ne se lance pas dans une UITableView le premier jour où on fait de l'iPhone, parce qu'il faut d'abord comprendre que les UITableViews utilisent un mécanisme de recyclage et en comprendre donc surtout les conséquences (à savoir penser à réaffecter toutes les propriétés qui changent et pas que les trucs à afficher sinon il va y avoir des anciennes valeurs qui vont remonter, etc...) et comprendre pourquoi ça se comporte pas comme attendu quand on a pas respecté tout ça.
Quant aux Example, ils sont choisis tellement compliqués, que les aspects qu'ils sont censés illustrer sont cachés au sein d'une application très lourde et introuvables, à quelques exceptions près.
Tiens c'est marrant cette remarque, en général on entend à chaque fois tout l'inverse, la critique qui est faite sur les Sample Codes d'Apple c'est qu'ils ne sont pas forcément "bien codés" dans le sens où si on voulait faire les choses dans les règles de l'art avec une archi propre il aurait fallu faire ça autrement, sauf que vu que les Samples se contentent de démontrer un point bien précis, en général ils ne s'embarassent pas dans ce contexte de plein de trucs (traitement des cas d'erreur, bonnes pratiques de codage, etc...) au risque de faire une appli pas propre / pas éligible pour de la production, mais ça se comprend si c'est pour se concentrer uniquement sur un concept donné sans polluer l'exemple avec d'autres choses qui n'ont rien à voir...
J'ai cherché sur developer.apple.com le terme property. Je n'ai rien trouvé. Et pourtant, c'est quelque chose d'essentiel, non ? Y compris dans le Glossary, où il n'y a pratiquement rien ( même pas getter ou setter...).
Quand, j'ai proposé un WikiCocoa, c'était dans l'idée pour permettre à des non informaticiens (ils me semble qu'il y en à ici), de débuter ou de continuer dans le développement d'application OSX (ou IOS), ce que ne permet pas de fait la documentation Apple.
Cela ne fait que conforter mon idée que je pense qu'il y en a beaucoup qui ne réalisent pas que développer sur iOS nécessite des prérequis (que les Guides expliquent justement) à apprendre d'abord.
Si tu veux apprendre à conduire mais que tu ne sais même pas ton code de la route, je vais te dire "bah paluche toi d'abord le bouquin du code de la route" (le Programming Guide) on verra après pour la pratique de la conduite. Si tu veux apprendre à jouer du piano, il faut déjà apprendre le solfège, décoder les notes, le tempo, etc... Alors bien sûr c'est frustrant, on aimerait bien jouer tout de suite le super morceau qu'on adore ou qu'on a entendu à la radio et avoir un manuel qui nous permette de jouer notre chanson au bout de quelques jours. Mais en pratique, y'a pas de secret, faut bien travailler son solfège avant, faut bien assimiler tout plein de concepts avant, qui sont des bases sur lesquelles les autres éléments se basent pour avancer.
Sans les fondations, une maison ne va pas tenir bien longtemps debout. C'est sûr c'est frustrant car ça nécessite du temps, beaucoup de lecture, une phase d'apprentissage longue. Mais bon, y'a pas de solution miracle.
Et au risque de me répéter, comme j'ai dit plus haut, on l'a déjà essayé le CocoaWiki et les tutos et tout, du temps de PommeDev. D'expérience on voit bien ce que ça a donné, c'est pas viable.
Mais, je comprends mal qu'il faille aujourd'hui se préoccuper de strong et autres weak, qui ne concernent que la mémoire et qui pallient les déficiences intrinsèques des langages à objets. Qu'est-ce que ça apporte à la résolution de mon problème ?
La gestion mémoire n'est pas un problème intrinsèque aux langages objets. C'est plutôt lié à l'architectures de nos machines. De fait, tous les langages que je connais adressent cette problématique. Je suis totalement d'accord avec toi pour dire que c'est un détail de fonctionnement qui nous empêche de nous concentrer sur le problème à résoudre. Cela dit, on n'a pas le choix, et ARC nous simplifie énormément le travail.
Aujourd'hui un Mac possède une quantité de RAM phénoménale, au pire il fera du swap avec le disque dur. Tu pourrais mettre toutes tes propriétés en strong: tu verras, ça ne plantera jamais. Pour un projet perso, ça peut aller; au pire, tu quittes et redémarres ton appli. Cependant, en tant que professionnel, je vends des applications à des gens qui n'admettent pas que mon appli envahisse la mémoire. Je dois donc la gérer. De fait, si tu me demandes s'il faut mettre weak ou strong, je te réponds "ça dépends", et je vais te renvoyer vers la doc.
La documentation Developer sur les NS... Class Reference est plutôt bien faite, si ce n'est qu'elle n'est pas à jour (cf. NextResponder et tient peu compte de ARC).
C'est vrai.
Le problème, c'est les Guide. Les Guide sont fait pour des développeurs professionnels qui veulent comprendre ce qu'il y a sous le capot (ce qui se passe en mémoire), pour les autres c'est incompréhensible, sauf parfois des portions de codes, trop rares.
Le problème des guides, c'est qu'ils contiennent beaucoup d'informations. En général, on a du mal à dégager le cas général du cas particulier, tout se trouvant au même niveau. De même, les détails importants sont évoqués de façon anodine. De fait, s'attaquer à la programmation Cocoa en lisant les guides, c'est se confronter à un mur. C'est pour cela que les gens viennent prendre des formations avec moi: j'ai déjà digéré les concepts importants, et je les guide. Pour le Mac, nous conseillons toujours d'acheter Programmation Cocoa sous Mac OS X par Aaron Hillegass. La raison est justement que ce livre explique ce qui est important; les détails seront à pêcher dans les guides.
C'est l'image éculée, mais toujours pertinente, du conducteur et du mécanicien : je veux savoir à quoi sert le changement de vitesses et pourquoi l'utiliser ; comment il le fait ne m'intéresse pas : avec des courroies, avec des tiges articulées, etc.
Là , je ne suis pas d'accord. Programmer c'est faire de la mécanique. Et quand on fait de la mécanique, on ne connait pas nécessairement tous les détails. Par exemple, on peut savoir à quoi sert une boite de vitesse, avoir une idée de son fonctionnement, et comment elle est interfacée avec le reste du véhicule. Pour aller plus loin, on peut la démonter et voir comment les engrenages sont imbriqués. On peut aussi calculer les rayons des engrenages pour changer les rapports. Tout dépend du niveau d'expertise.
Quant aux Example, ils sont choisis tellement compliqués, que les aspects qu'ils sont censés illustrer sont cachés au sein d'une application très lourde et introuvables, à quelques exceptions près.
Sur Mac, c'est totalement vrai. On aurait besoin d'un exemple typique, et on trouve au contraire des exemples qui montrent tout ce qu'on peut faire avec la classe en bidouillant. Sur iOS, la situation est très différente, et heureusement, la situation change sur Mac aussi.
J'ai cherché sur developer.apple.com le terme property. Je n'ai rien trouvé. Et pourtant, c'est quelque chose d'essentiel, non ?
La recherche donne rarement un résultat probant.
Quand, j'ai proposé un WikiCocoa, c'était dans l'idée pour permettre à des non informaticiens (ils me semble qu'il y en à ici), de débuter ou de continuer dans le développement d'application OSX (ou IOS), ce que ne permet pas de fait la documentation Apple.
Non, ici il n'y a que des informaticiens. Pas que des professionnels, mais ce sont tous des gens qui s'intéressent fortement à l'informatique. La programmation est difficile ! Comme le disait Ali, un WikiCocoa est un travail monstrueux, qui de toute façon ne répondra jamais à tous les besoins. J'ai commencé à programmer Cocoa en 2001, avant même que sorte le livre de Hillegass. À l'époque, la seule solution pour savoir comment quelque chose fonctionnait était d'essayer. Tu n'imagines même pas les ressources auxquelles tu as accès aujourd'hui.
Comme le disait Ali, un WikiCocoa est un travail monstrueux, qui de toute façon ne répondra jamais à tous les besoins. J'ai commencé à programmer Cocoa en 2001, avant même que sorte le livre de Hillegass. À l'époque, la seule solution pour savoir comment quelque chose fonctionnait était d'essayer. Tu n'imagines même pas les ressources auxquelles tu as accès aujourd'hui.
Ha ça c'est vrai. Je n'ai jamais appris à "coder" (je vais relativiser parceque j'ai toujours besoin de la doc pour telle ou telle chose) un langage aussi vite. Bon je suis développer C++ de base du coup ça a aidé. Mais c'est vrai que quand même wahou. En un an et demi, j'ai sorti quelques applications, appris à gérer les pushs, .... etc... Je le dois en grande partie à ce forum d'ailleurs (que j'ai déjà remercier) qui m'ont aidé à comprendre quelques principe de gestion mémoire que je n'avais pas assimilé.
Là où je te rejoins peut-être, c'est que rendre plus facile l'accès au développement, amène un gros bataillon de programmeurs médiocres (comme moi) à sortir des applications à l'aune de leurs compétences: médiocres.
Mais bon, justement, ça permet aux bons de sortir du lot.
Heu, je n'ai jamais parlé de programmeurs médiocres. J'ai parlé d'infantilisation des développeurs. La nuance me semble de taille et nous met tous dans le même bateau.
Sinon, oui l'expérience amène à ne pas prendre pour argent comptant tous les beaux discours d'Apple. Est-ce un mal? Je ne pense pas. Le Garbage Collector d'Objective-C était un bon exemple pré-ARC qui a terminé aux oubliettes...
J'espère tout de même avoir le droit de ne pas utiliser ARC. Rassurez-moi, cela ne fait pas de moi un dynosaure?
à‰tant développeur médiocre, je me sens mal à donner ce conseil mais tant pis: si j'étais toi, je me concentrerai à fond sur toutes ces nouvelles techno avant que mes compétences, autrefois au top, ne servent plus à grand chose.
Après tout, c'est un conseil universel qui ne touche pas qu'à l'informatique :-*
J'y travaille tous les jours. Pour preuve, je suis même passé à Xcode 5... ;D
Si je cherche "property" ou "properties" ou "strong" ou "weak" dans la doc Xcode, j'obtiens des tas de liens mais rien de réellement utilisable : il faudrait en suivre et lire des centaines avant de repérer celui qui m'intéresse.
En fait, ce qui est évident comme toujours quand on a trouvé la solution, il faut chercher "property strong" pour avoir en tête le lien vers le guide "Programming with Objective-C", où d'ailleurs toutes ces notions sont fort bien expliquées ! Je commence à en comprendre la nature et l'utilité.
Au demeurant, j'ai appris, directement et indirectement, beaucoup de choses au cours de cette discussion et j'espère qu'elle va continuer.
Je partage totalement le ressenti de mybofy. La solution pour moi fut d'acheter les bouquins de Aaron Hillegass.
Quelques pas-à -pas très simples qui permettent d'une part de comprendre la philosophie du développement objective C/Cocoa,de
prendre en main Xcode et enfin de comprendre à lire la doc officielle.
Les tutos faits par les membres ne sont pas inutiles! Le déclic, chez moi fut celui de Tablier. Il suffit de deux ou trois trucs pour démarrer, compiler un petit programme, comprendre les outlets, comment les lier au contrôleur, s'habituer à la syntaxe d'objective-c.
Merci, je sens mes chevilles gonfler. Le tuto est obsolète pour une grande part. Je l'ai fait sous 10.3 ou 4 et j'ai commencé à le modifier pour 10.6. Mon but était d'entrer dans cocoa et objective-c. Un tuto comme ça est très long à faire: se donner un sujet pas trop large, lire beaucoup de Doc, sélectionner ce que l'on veut y mettre sachant que c'est fait pour des débutants, faire des tas de copies d'écran, rédiger, essayer, corriger....... et recommencer!!
Si quelqu'un veut le reprendre pour 10.8 ou 10.9 je lui passerai volontiers la totalité des fichiers.
Voilà c'est ce dont je parlais : bonne initiative au départ, mais tuto très long à écrire et chronophage (surtout pour des bénévoles comme nous tous), et surtout qui n'est jamais à jour.
Quand on avait concrétisé ce CocoaWiki-like à l'époque de PommeDev c'est précisément pour ces raisons que c'était tombé à l'eau au final et n'était pas utilisé ni rempli en pratique. Un bon bouquin papier et la doc Apple étant bien mieux aboutis et utiles.
Le seul ouvrage que j'ai conservé est "Objective-C 2 Précis et concis" mis à jour par Sylvain Gamel en 2010. Du fait qu'il ne traite que du langage, il ne se perd pas en conjectures autours des différentes versions d'Xcode. Il mériterait une petit mise à jour, pour combler les évolutions entre 2010-2013, mais déjà en l'état il traite beaucoup de notions qu'on voit régulièrement revenir dans les questions du forum.
2010... Il traà®te des blocks ? D'ARC ? J'imagine que non... A la vitesse où l'informatique évolue, ObjC en particulier, 2010 c'est malheureusement déjà une éternité...
Un chapitre de 7 pages sur les blocks et en ce qui concerne ARC, s'il n'est effectivement pas traité et pour cause, on retrouve déjà les notions de strong et week abordées à l'époque avec le ramasse miette. Ci-joint, un aperçu en captures du sommaire. Franchement, il ne lui manque pas grand chose pour être à jour.
Je l'ai rarement consulté, mais je me suis toujours dit que c'était intéressant d'avoir une sorte de mini-index/lexique (un peu plus détaillé) sur papier...
qui m'avait convaincu en ce qui concerne l'enregistrement/ouverture d'un document avec NSOpen/savePanel. C'est un cas pratique où tout peut se faire "à l'ancienne" dans un seul morceau de code, au lieu de se coltiner avec des callbacks qui éparpillent le travail (et donc le compliquent). De là à dire que ça "change la vie", je n'irai pas jusque là , mais ça permet de placer du code à l'endroit où on s'attend à le retrouver... deux ans après.
Pour simplifier la relecture ou faire fondre le code, et donc le nombre potentiel d'erreurs, je trouve que ARC et Objective-C 2.0 ("Modern") sont bien plus "révolutionnaires".
je trouve que ARC et Objective-C 2.0 ("Modern") sont bien plus "révolutionnaires".j
Modernes et révolutionnaire pour combien de temps?
Voilà c'est ce dont je parlais : bonne initiative au départ, mais tuto très long à écrire et chronophage (surtout pour des bénévoles comme nous tous), et surtout qui n'est jamais à jour.
Environ 4 mois et de 3 à 4 heures par jour. Heureusement j'étais déjà à la retraite! Le but était surtout pour moi d'apprendre! J'avais déjà développé pour Mac OS Classique en Pascal avec les "Inside Macintosh", puis en C avec Code Warrior. Il me fallait suivre les évolutions techniques.
Je continue à penser qu'un tutoriel qui fait faire une petite application fait gagner beaucoup de temps aux débutants même si elle n'est pas tout à fait à jour. La Doc d'apple est très complète, mais tellement grosse et elle est comme les écrits de Victor Hugo: illisible sauf par petits bouts. Les exemples sont pour plus de 50% à remettre à jour.
Réponses
Crois-en notre expérience et notre expertise sur le sujet, et pour l'avoir étudié je sais parfaitement comment ARC fonctionne sous le capot et ses implications au niveau du Runtime ça n'a rien à voir avec une question de maturité.
Par exemple savoir si tu veux qu'une propriété ou variable ait une memory policy weak ou strong ça c'est pas une question de ARC pas assez mature pour savoir le deviner à ta place, c'est une question de "ça dépend de ce que tu veux faire".
Tu peux parfaitement créer des retain cycle et faire exploser la mémoire si tu en as envie et c'est pas parce que ARC n'est serait soit disant pas assez mature mais parce que tu aurais mal défini la logique d'ownership de tes objets.
ça ARC n'y peut rien et ne peux pas deviner.
Par contre le static analyzer peut te dire qu'il y a incohérence et retain cycle mais il ne pourra pas deviner lui non plus lequel des 2 strong il faut passer en weak (par exemple) puisque ça ça dépend de la sémantique de ton modèle.
Au final comme je le disais justement plus haut le problème avec les débutants qui utilisent ARC c'est que comme toi ils ont tendance à croire que ARC signifie qu'on n'a plus à se poser de question sur la gestion mémoire, alors que rien que l'ownership par exemple ça aucun mécanisme ne pourra jamais la deviner pour toi,
D'une part Mala comme moi on n'a jamais dit qu'il ne fallait pas utiliser ARC. Perso je l'utilise tous les jours sur tous mes projets, je trouve ça génial et je ne voudrais surtout pas revenir en arrière et revenir sur du MRR.
On a juste dit que même si ARC c'est génial faut pas pour autant croire " comme ont l'air de le penser beaucoup de débutants " que ça fait tout en particulier que ça peut t'éviter de réfléchir sur l'ownership et les conséquences sur le lifecycle de tes objets.
Mais tout ça ne m'empêche en rien d'être au top des nouvelles technos, de faire de la veille et de connaà®tre à peu près toutes les nouveautés du Runtime, d'ObjC, et du SDK de iOS7 par exemple.
Je ne vois vraiment pas le rapport entre "avoir conscience que ARC n'empêche pas de devoir avoir conscience des risques de retain cycle" et "ne pas se concentrer à fond sur les nouvelles technos". Au contraire d'ailleurs je dirais que connaà®tre les nouvelles technos sur le bout des doigts comme moi " tout en ayant connaissance de leur historique " me permet de mieux connaà®tre aussi leurs limitations et les pièges dans lesquels il ne faut pas tomber (comme la certitude fatale que ARC peut tout résoudre)
Cette discussion est passionnante et très instructive pour un "développeur médiocre" comme moi.
Où peut-on trouver une initiation à la réflexion "sur l'ownership et les conséquences sur le lifecycle des objets" ? En gros, ici, les strong, weak et autres, que j'utilise sans rien y comprendre par analogie avec du code que je vois ici ou là ou que me propose Xcode ?
Une initiation faite pour un non-informaticien comme moi qui sait ce qu'il veut obtenir et qui se moque des choses qui font l'objet d'innombrables thèses universitaires, comme la persistance de données.
Au fait avec la quantité d'informations, de pratiques, de solutions proposées sur CocoaCafé, il y aurait de quoi faire un WikiCocoa ou un DidactiCocoa, non ?
1) Pour l'initiation à la réflexion sur l'ownership et les conséquences sur le lifecycle des objets, c'est évidemment expliqué en détail dans le Memory Managment Programming Guide (ici spécifiquement la page "Practical Memory Managment" qui parle de ça). Il y a un paragraphe dédié au retain cycle.
2) Et surtout pour savoir quand utiliser les strong ou les weak, tu as tout dans Transitioning to ARC Release Notes, y compris entre autres un paragraphe "Use Lifetime Qualifiers to Avoid Strong Reference Cycles" (mais pas que).
3) Pour ce qui est du WikiCocoa ou d'un DidactiCocoa, je ne vois pas trop l'intérêt étant donné que ce type de contenu existe déjà dans la doc Apple (genre la DevPedia Apple, ou la tonne de Programming Guides avec toutes les explications des concepts, les exemples de code, etc)...
---
Quand je lis "les strong, weak et autres que j'utilise sans rien y comprendre par analogie avec du code que je vois ici ou là " c'est justement ce que Mala et moi avons soulevé et ce qui me fait peur quand je vois des débutants utiliser ARC : le risque avec ARC que les gens ne comprennent plus la signification et les conséquences de ces qualifiers et les utilisent sans trop savoir à quoi ils correspondent (alors que Dieu sait qu'ils sont importants !), et ne prennent pas la peine de se former dessus, se disant qu'ARC est magique et qu'ils n'ont plus à se poser de questions sur la gestion mémoire...
Ok, suite à tes précisions, je suis conscient de m'être fourvoyé.
C'est que j'ai tellement entendu des vieux de la vieille (pas ici) dénigrer et mépriser, par exemple, tout ce qui est GUI en les désignant comme des "clickodromes" que maintenant j'ai parfois de mauvais réflexes.
Pour #35.
Ce que je veux, c'est, entre autres, réaliser une interface graphique qui tourne sur un Mac et qui me permette de gérer un herbier virtuel dont les données sont stockées dans une base de données PostgreSQL distante.
Apple offre un outil Xcode qui me permet de construire le programme (pardon, l'application) correspondante.
Xcode utilise le langage Objective-C et les bibliothèques Cocoa. J'arrive à construire mon application bien sûr, parce que je suis bête et obstiné, et qu'il y a CocoaCafé.
Objective-C est un langage de programmation comme tout autre langage de programmation. Il utilise les constructions du C auquel il ajoute celles qui permettent de dire que c'est un langage à objets. Bon, rien à dire jusque là . C'est même plutôt rigolo. Mais, je comprends mal qu'il faille aujourd'hui se préoccuper de strong et autres weak, qui ne concernent que la mémoire et qui pallient les déficiences intrinsèques des langages à objets. Qu'est-ce que ça apporte à la résolution de mon problème ?
La documentation Developer sur les NS... Class Reference est plutôt bien faite, si ce n'est qu'elle n'est pas à jour (cf. NextResponder et tient peu compte de ARC).
Le problème, c'est les Guide.
Les Guide sont fait pour des développeurs professionnels qui veulent comprendre ce qu'il y a sous le capot (ce qui se passe en mémoire), pour les autres c'est incompréhensible, sauf parfois des portions de codes, trop rares.
C'est l'image éculée, mais toujours pertinente, du conducteur et du mécanicien : je veux savoir à quoi sert le changement de vitesses et pourquoi l'utiliser ; comment il le fait ne m'intéresse pas : avec des courroies, avec des tiges articulées, etc.
Quant aux Example, ils sont choisis tellement compliqués, que les aspects qu'ils sont censés illustrer sont cachés au sein d'une application très lourde et introuvables, à quelques exceptions près.
J'ai cherché sur developer.apple.com le terme property.
Je n'ai rien trouvé. Et pourtant, c'est quelque chose d'essentiel, non ?
Y compris dans le Glossary, où il n'y a pratiquement rien ( même pas getter ou setter...).
Quant à DevPedia Apple, tu plaisantes, je suppose? C'est encore pire que le reste.
Quand, j'ai proposé un WikiCocoa, c'était dans l'idée pour permettre à des non informaticiens (ils me semble qu'il y en à ici), de débuter ou de continuer dans le développement d'application OSX (ou IOS), ce que ne permet pas de fait la documentation Apple.
D'accord avec toi sur les vieux de la vielle et j'espère ne jamais en faire partie. Un chanteur que j'ai vu sur scène en 1966 a été un peu plus loin! et j'aime beaucoup!
Donc la question "qu'est ce que ça m'apporte" n'a pas de sens (et montre que tu n'as sans doute pas assimilé tous les concepts de la POO). C'est un concept qui est présent intrinsèquement.
(C'est comme si tu disais "je veux un véhicule qui roule, mais qu'est ce que ça m'apporte de lui mettre des roues ?" bah c'est la nature même d'un véhicule qui roule d'avoir des roues, la question n'a pas trop de sens...)
Je suis d'accord que toute la documentation n'est pas forcément à jour. Les liens pour le signaler à Apple ne sont pas pour les chiens. Et c'est d'ailleurs pour ça que je t'ai remonté plus haut que c'est pas jouable de faire un CocoaWiki ou quoi de notre côté, car quand on voit le nombre pharamineux de pages de documentation (Class Ref, DevPedia, Guides, Samples, TechNotes, et j'en passe) qu'il y a à écrire vu le nombre de sujets, je vois pas en quoi on aurait + de chances de les garder toutes à jour qu'Apple.
On avait déjà fait à une époque sur PommeDev (l'ancêtre de CocoaCafé) l'essai de faire des tutoriels, des cours, des docs... rédigés par moi et d'autres membres du forum. En pratique non seulement c'était chronophage à un niveau sans nom, mais en plus on n'avait jamais le temps de le mettre à jour, et au final ça devenait obsolète et donc on avait fait un travail de dingue pour les rédiger... pour rien si on avait jamais le temps de mettre à jour.
Alors là par contre je ne peux que tomber des nues : au contraire, les Programming Guides sont très bien faits chez Apple (contrairement à chez certains concurrents ou autres SDKs) puisqu'ils expliquent les concepts. Ils expliquent le minimum à savoir, par exemple que les UITableViews utilisent le mécanisme de recycling qu'il faut absolument connaà®tre pour pouvoir manipuler des tableviews (sinon bonjour les dégâts), pour t'expliquer les concepts. Par contre ça parle pas de comment ça marche sous le capot.
- Le Class Reference t'indique que tu as une méthode qui permet de changer les vitesses. Donc juste la bête liste exhaustive des méthodes de la classe
- Le Programming Guide t'indique que attention, si tu veux changer de vitesse, il faut penser à appeler la méthode enfonceEmbrayage avant et relacheEmbrayage après. Donc comment utiliser les différentes méthodes ensemble pour que ça marche, quel enchaà®nement faire, ce à quoi il faut faire attention (ne pas lâcher la pédale d'embrayage trop vite, etc...)
- Par contre Le Programming Guide n'est pas là pour t'expliquer que quand tu passes une vitesse tu as des pignons et une boite de vitesse en dessous et t'expliquer le détail mécanique de la boite de vitesse et comment c'est foutu pour le cas de la marche arrière et tout. Ca c'est dans des blogs comme celui de mikeash que tu vas retrouver ça, mais ça commence alors à rentrer dans du super technique qui n'est utile que si tu es curieux, mais qui ne t'es pas du tout utile pour conduire et passer les vitesses dans la vie de tous les jours.
Donc je pense que tu as mal compris l'objectif et le contenu des Programming Guides. Ils sont complets car expliquent des concepts. Si tu veux expliquer un concept de Design Pattern par exemple, comme le MVC, c'est un Programming Guide qui va l'expliquer, c'est un concept à mettre en pratique dans tes codes Cocoa, ça s'explique pas dans une Class Reference qui liste juste des méthodes. Ca explique des bonnes pratiques et comment utiliser au mieux tel ou tel truc, avec des exemples de code. Et ça remplit parfaitement ce rôle.Après, si tu les trouve trop longs à lire, c'est que tu n'as pas réalisé que faire de la POO d'une part, sur un environnement mobile d'autre part (avec ses contraintes affiliées, réseau, etc), spécifique (iOS) d'autre part, et avec des bonnes pratiques génériques (ne pas bloquer l'utilisateur, etc), tout ça nécessite d'avoir assimilé beaucoup de concepts avant. On ne se lance pas dans une UITableView le premier jour où on fait de l'iPhone, parce qu'il faut d'abord comprendre que les UITableViews utilisent un mécanisme de recyclage et en comprendre donc surtout les conséquences (à savoir penser à réaffecter toutes les propriétés qui changent et pas que les trucs à afficher sinon il va y avoir des anciennes valeurs qui vont remonter, etc...) et comprendre pourquoi ça se comporte pas comme attendu quand on a pas respecté tout ça.
Tiens c'est marrant cette remarque, en général on entend à chaque fois tout l'inverse, la critique qui est faite sur les Sample Codes d'Apple c'est qu'ils ne sont pas forcément "bien codés" dans le sens où si on voulait faire les choses dans les règles de l'art avec une archi propre il aurait fallu faire ça autrement, sauf que vu que les Samples se contentent de démontrer un point bien précis, en général ils ne s'embarassent pas dans ce contexte de plein de trucs (traitement des cas d'erreur, bonnes pratiques de codage, etc...) au risque de faire une appli pas propre / pas éligible pour de la production, mais ça se comprend si c'est pour se concentrer uniquement sur un concept donné sans polluer l'exemple avec d'autres choses qui n'ont rien à voir...
C'est marrant moi quand je recherche je trouve pléthore de pages sur le sujet...
Cela ne fait que conforter mon idée que je pense qu'il y en a beaucoup qui ne réalisent pas que développer sur iOS nécessite des prérequis (que les Guides expliquent justement) à apprendre d'abord.
Si tu veux apprendre à conduire mais que tu ne sais même pas ton code de la route, je vais te dire "bah paluche toi d'abord le bouquin du code de la route" (le Programming Guide) on verra après pour la pratique de la conduite. Si tu veux apprendre à jouer du piano, il faut déjà apprendre le solfège, décoder les notes, le tempo, etc... Alors bien sûr c'est frustrant, on aimerait bien jouer tout de suite le super morceau qu'on adore ou qu'on a entendu à la radio et avoir un manuel qui nous permette de jouer notre chanson au bout de quelques jours. Mais en pratique, y'a pas de secret, faut bien travailler son solfège avant, faut bien assimiler tout plein de concepts avant, qui sont des bases sur lesquelles les autres éléments se basent pour avancer.
Sans les fondations, une maison ne va pas tenir bien longtemps debout. C'est sûr c'est frustrant car ça nécessite du temps, beaucoup de lecture, une phase d'apprentissage longue. Mais bon, y'a pas de solution miracle.
Et au risque de me répéter, comme j'ai dit plus haut, on l'a déjà essayé le CocoaWiki et les tutos et tout, du temps de PommeDev. D'expérience on voit bien ce que ça a donné, c'est pas viable.
Aujourd'hui un Mac possède une quantité de RAM phénoménale, au pire il fera du swap avec le disque dur. Tu pourrais mettre toutes tes propriétés en strong: tu verras, ça ne plantera jamais. Pour un projet perso, ça peut aller; au pire, tu quittes et redémarres ton appli. Cependant, en tant que professionnel, je vends des applications à des gens qui n'admettent pas que mon appli envahisse la mémoire. Je dois donc la gérer. De fait, si tu me demandes s'il faut mettre weak ou strong, je te réponds "ça dépends", et je vais te renvoyer vers la doc.
C'est vrai.
Le problème des guides, c'est qu'ils contiennent beaucoup d'informations. En général, on a du mal à dégager le cas général du cas particulier, tout se trouvant au même niveau. De même, les détails importants sont évoqués de façon anodine. De fait, s'attaquer à la programmation Cocoa en lisant les guides, c'est se confronter à un mur. C'est pour cela que les gens viennent prendre des formations avec moi: j'ai déjà digéré les concepts importants, et je les guide.
Pour le Mac, nous conseillons toujours d'acheter Programmation Cocoa sous Mac OS X par Aaron Hillegass. La raison est justement que ce livre explique ce qui est important; les détails seront à pêcher dans les guides.
Là , je ne suis pas d'accord. Programmer c'est faire de la mécanique. Et quand on fait de la mécanique, on ne connait pas nécessairement tous les détails. Par exemple, on peut savoir à quoi sert une boite de vitesse, avoir une idée de son fonctionnement, et comment elle est interfacée avec le reste du véhicule. Pour aller plus loin, on peut la démonter et voir comment les engrenages sont imbriqués. On peut aussi calculer les rayons des engrenages pour changer les rapports. Tout dépend du niveau d'expertise.
Sur Mac, c'est totalement vrai. On aurait besoin d'un exemple typique, et on trouve au contraire des exemples qui montrent tout ce qu'on peut faire avec la classe en bidouillant. Sur iOS, la situation est très différente, et heureusement, la situation change sur Mac aussi.
La recherche donne rarement un résultat probant.
Non, ici il n'y a que des informaticiens. Pas que des professionnels, mais ce sont tous des gens qui s'intéressent fortement à l'informatique. La programmation est difficile !
Comme le disait Ali, un WikiCocoa est un travail monstrueux, qui de toute façon ne répondra jamais à tous les besoins. J'ai commencé à programmer Cocoa en 2001, avant même que sorte le livre de Hillegass. À l'époque, la seule solution pour savoir comment quelque chose fonctionnait était d'essayer. Tu n'imagines même pas les ressources auxquelles tu as accès aujourd'hui.
Ha ça c'est vrai. Je n'ai jamais appris à "coder" (je vais relativiser parceque j'ai toujours besoin de la doc pour telle ou telle chose) un langage aussi vite. Bon je suis développer C++ de base du coup ça a aidé. Mais c'est vrai que quand même wahou. En un an et demi, j'ai sorti quelques applications, appris à gérer les pushs, .... etc... Je le dois en grande partie à ce forum d'ailleurs (que j'ai déjà remercier) qui m'ont aidé à comprendre quelques principe de gestion mémoire que je n'avais pas assimilé.
Merci Ali d'avoir répondu.
Heu, je n'ai jamais parlé de programmeurs médiocres. J'ai parlé d'infantilisation des développeurs. La nuance me semble de taille et nous met tous dans le même bateau.
Sinon, oui l'expérience amène à ne pas prendre pour argent comptant tous les beaux discours d'Apple. Est-ce un mal? Je ne pense pas. Le Garbage Collector d'Objective-C était un bon exemple pré-ARC qui a terminé aux oubliettes...
J'espère tout de même avoir le droit de ne pas utiliser ARC. Rassurez-moi, cela ne fait pas de moi un dynosaure?
J'y travaille tous les jours. Pour preuve, je suis même passé à Xcode 5... ;D
Si je cherche "property" ou "properties" ou "strong" ou "weak" dans la doc Xcode, j'obtiens des tas de liens mais rien de réellement utilisable : il faudrait en suivre et lire des centaines avant de repérer celui qui m'intéresse.
En fait, ce qui est évident comme toujours quand on a trouvé la solution, il faut chercher "property strong" pour avoir en tête le lien vers le guide "Programming with Objective-C", où d'ailleurs toutes ces notions sont fort bien expliquées ! Je commence à en comprendre la nature et l'utilité.
Au demeurant, j'ai appris, directement et indirectement, beaucoup de choses au cours de cette discussion et j'espère qu'elle va continuer.
J'espère qu'il en va de même pour d'autres.
Grand merci à tous.
Je partage totalement le ressenti de mybofy. La solution pour moi fut d'acheter les bouquins de Aaron Hillegass.
Quelques pas-à -pas très simples qui permettent d'une part de comprendre la philosophie du développement objective C/Cocoa,de
prendre en main Xcode et enfin de comprendre à lire la doc officielle.
Les tutos faits par les membres ne sont pas inutiles! Le déclic, chez moi fut celui de Tablier. Il suffit de deux ou trois trucs pour démarrer, compiler un petit programme, comprendre les outlets, comment les lier au contrôleur, s'habituer à la syntaxe d'objective-c.
Ensuite les progrès sont exponentiels.
@Rocou
Merci, je sens mes chevilles gonfler. Le tuto est obsolète pour une grande part. Je l'ai fait sous 10.3 ou 4 et j'ai commencé à le modifier pour 10.6. Mon but était d'entrer dans cocoa et objective-c. Un tuto comme ça est très long à faire: se donner un sujet pas trop large, lire beaucoup de Doc, sélectionner ce que l'on veut y mettre sachant que c'est fait pour des débutants, faire des tas de copies d'écran, rédiger, essayer, corriger....... et recommencer!!
Si quelqu'un veut le reprendre pour 10.8 ou 10.9 je lui passerai volontiers la totalité des fichiers.
Quand on avait concrétisé ce CocoaWiki-like à l'époque de PommeDev c'est précisément pour ces raisons que c'était tombé à l'eau au final et n'était pas utilisé ni rempli en pratique. Un bon bouquin papier et la doc Apple étant bien mieux aboutis et utiles.
Le seul ouvrage que j'ai conservé est "Objective-C 2 Précis et concis" mis à jour par Sylvain Gamel en 2010. Du fait qu'il ne traite que du langage, il ne se perd pas en conjectures autours des différentes versions d'Xcode. Il mériterait une petit mise à jour, pour combler les évolutions entre 2010-2013, mais déjà en l'état il traite beaucoup de notions qu'on voit régulièrement revenir dans les questions du forum.
Un chapitre de 7 pages sur les blocks et en ce qui concerne ARC, s'il n'est effectivement pas traité et pour cause, on retrouve déjà les notions de strong et week abordées à l'époque avec le ramasse miette. Ci-joint, un aperçu en captures du sommaire. Franchement, il ne lui manque pas grand chose pour être à jour.
Je l'ai il me semble...
Je l'ai rarement consulté, mais je me suis toujours dit que c'était intéressant d'avoir une sorte de mini-index/lexique (un peu plus détaillé) sur papier...
J'avais trouvé cet exemple : http://macresearch.org/cocoa-scientists-xxxii-10-uses-blocks-cobjective-c
qui m'avait convaincu en ce qui concerne l'enregistrement/ouverture d'un document avec NSOpen/savePanel. C'est un cas pratique où tout peut se faire "à l'ancienne" dans un seul morceau de code, au lieu de se coltiner avec des callbacks qui éparpillent le travail (et donc le compliquent). De là à dire que ça "change la vie", je n'irai pas jusque là , mais ça permet de placer du code à l'endroit où on s'attend à le retrouver... deux ans après.
Pour simplifier la relecture ou faire fondre le code, et donc le nombre potentiel d'erreurs, je trouve que ARC et Objective-C 2.0 ("Modern") sont bien plus "révolutionnaires".
Modernes et révolutionnaire pour combien de temps?
Environ 4 mois et de 3 à 4 heures par jour. Heureusement j'étais déjà à la retraite! Le but était surtout pour moi d'apprendre! J'avais déjà développé pour Mac OS Classique en Pascal avec les "Inside Macintosh", puis en C avec Code Warrior. Il me fallait suivre les évolutions techniques.
Je continue à penser qu'un tutoriel qui fait faire une petite application fait gagner beaucoup de temps aux débutants même si elle n'est pas tout à fait à jour. La Doc d'apple est très complète, mais tellement grosse et elle est comme les écrits de Victor Hugo: illisible sauf par petits bouts. Les exemples sont pour plus de 50% à remettre à jour.