Développer sur Mac,
Sethy
Membre
Bonjour à tous,
Depuis quelques mois, je me pose une question sur l'évolution des outils mis à disposition pour le développement d'application.
J'ai commencé à développer sur iOS il y a deux ans. A ce moment, Mac OS et iOS avaient déjà plusieurs années derrières eux.
J'ai donc appris à tenir "compte" des utilisation d'objets, à travailler avec les nib et les xib, etc. Eu égard à la maturité des OS, j'ai considéré cet instantané comme une situation mûre et aboutie.
J'avais bien senti à l'époque qu'il y avait eu quelques évolutions (notamment les accès par dot qui semblait être assez récents) et que tout n'était pas "si figé que ça".
Bien sûr, en comparaison avec C#, Cocoa avait un côté "vintage".
Depuis, cette période, les évolutions de Cocoa ont été très importantes (c'est mon point de vue) : apparition d'ARC, des storyboards, etc.
Ces évolutions sont introduites de manière progressive, afin de maintenir une certaine compatibilité. Mais à la longue, ça me donne une impression d'inabouti, de fluctuant, de chaotique (au sens Moorcookien).
C'est peut être la rançon de la gloire. On ne peut avoir un nouvel iOS chaque année, souhaiter pouvoir profiter des nouveautés et en même temps refuser l'évolution.
Comment voyez-vous la situation ? Cette impermanence est elle consubstantielle d'Apple ? Va-t-on vers une zone de calme (peu de modifications) ou une zone de rapides ? Voyez-vous émerger une zone de stabilité ?
Sethy
Réponses
Ca c'est pas mal, pendant que, suite à la keynote d'Apple mardi, y'a plein de trolls sur la toile qui disent "y'en a marre le nouvel iPhone il est pas si innovant que ça Apple n'innove plus asssez", toi ton impression c'est "y'en a marre Apple arrête pas de faire des évolutions (sur le langage)"
Les évolutions apportées dans le langage Objective-C le rendent meilleur. Par exemple aujourd'hui j'apprécie énormément d'avoir ARC, de ne plus avoir à écrire mes @synthesize, d'avoir les Object Literals, et surtout d'avoir les blocks. Si je regarde en arrière, je me demande encore comment je faisais sans il y a qques années quand ça n'existait pas encore. Les blocks ça a changé ma vie, le développement sans les blocks c'était quand même du code éparpillé de partout au lieu d'une bien meilleure lisibilité et suivi du workflow du code...
Au final je suis bien content qu'Apple fasse évoluer son langage, et participe activement à l'évolution du compilateur LLVM en parallèle, pour rajouter toutes ces nouveautés. Sans ça, on aurait manqué plein de choses fortement pratiques, et on en serait encore à l'âge de Pierre (mon voisin, 26 ans...
). Moi je dis merci merci merci Apple d'avoir rajouté les blocks, les Object Literals et tout ça à Objective-C.
Ce n'est pas tant différent que ça du C# où les premières versions n'avaient pas par exemple les getters et setters implicites, on était obligé de fournir une définition aux "get" et "set" lors de la déclaration des propriétés si je me souviens bien. Alors que les versions plus modernes de C# ont rajouté ça après coup. Sauf que C# évolue bien moins vite/souvent qu'Objective-C. Est-ce parce qu'Objective-C était moins mature que C#, est-ce parce que c'est une surcouche du C et qu'il a fallu étendre le standard C et les compilateurs existants (voire faire une révolution en abandonnant GCC, compilateur historique en place depuis des années dans le monde C, pour le détrôner et passer au tout neuf LLVM) ? Peut-être, mais au moins Apple n'hésite pas à faire des révolutions de ce côté pour faire avancer les choses et nous apporter des outils de langage toujours plus puissants et nous faciliter la vie au fur et à mesure des versions et évolutions du langage.
Moi, j'ai envie de dire: c'est un peu pareil pour tous les langages et frameworks.
Cela n'arrête pas de changer et on doit constamment apprendre, bûcher, rechercher...
Et les compatibilités sautent souvent.
Par exemple, l'évolution de Ruby et Rails me pousse sans-cesse à changer de plugins, à avoir des problèmes de compatibilité...etc.
Celle-la est à mettre dans les annales !
L'évolution du langage Objective-C, c'est plutôt pas mal et la plupart des évolutions restent optionnelles.
La seule qui pose un peu problème avec les librairies third-parties, c'est ARC, et encore tu peux spécifier fichier par fichier l'activation de ARC, ce qui est génial.
Moi ce qui me gonfle un peu, c'est qu'au départ il fallait faire 1 icône et maintenant il faut en faire 40. Pareil pour les launch images.
Comme je suis nul en icône, ça me gonfle.
Et aussi tous les petits changements d'API qu'on oublie au fur et à mesure (genre rotation dans iOS 6), le caprice de Ive qui veut que les vues passent sous les toolbars, uniqueIdentifier qui devient interdit, etc, etc.
Et aussi tous les supers nouveaux framework que je n'ai pas le temps d'apprendre et d'utiliser.
L'avantage par rapport à l'environnement Microsoft et Google, c'est que les technologies sont rarement abandonnées. Ces deux là partennt dans tous les sens, font bucher les développeurs et ensuite laissent tomber les technos.
Pour répondre à la question, ça change (vite) mais on va quelque part. Je pense que ça ne vas pas ralentir.
Par exemple, on eu le droit à auto-layout, c'était pas terrible mais ça s'est amélioré, et on sait que si on fait l'effort de l'apprendre, c'est pas pour des prunes, dans un ou deux ans, il y aura un device avec un écran différent et on y aura été préparé progressivement.
Côté Mac OSX, je trouve que les API sont pas terribles et ne sont pas assez vites modernisées.
Franchement, hormis la scroll view, j'ai rien à redire à l'API d'OS X. Je la trouve vraiment bien, et surtout on a les binding, et ça c'est réellement bon quand tu as besoin de faire des outils qui manipulent beaucoup de données...
Je suis le seul à penser que ces évolutions sont à chaque fois un petit cadenas qu'on referme sur un gros coffre ?
En d'autre termes j'ai l'impression que l'Obj-C se modernise, certes, mais aussi se retrouve bloqué dans l'environnement Apple à chaque petit pas qui est fait. De tous les langages que j'ai pu utiliser l'Obj-C est vraiment mon préféré (quant à dire si il est le meilleur je laisse ça à d'autres personnes plus compétentes que moi) mais il est réservé aux macs.
Qui a déjà vu un soft Linux ou Windows développé en Obj-C ? Personnellement j'en ai vu 1 il y a une dizaine d'année sous Linux qui m'avait obligé à installer des tonnes de dépendances sur ma Gentoo et je ne comprenais pas pourquoi quelqu'un, quelque part, s'était amusé à coder un soft en Obj-C. Cette année je reprends des études et quand j'ai demandé aux profs si l'Obj-C allait être enseigné on m'a répondu non et que de toute manière personne ne savait comment ça fonctionnait... Par contre on fera du C#...
Là est le soucis l'Obj-C est développé uniquement par et pour Apple, de plus en plus de gens s'y mettent –développement iOS oblige– mais on n'est pas prêt de sortir de la pomme. Le C# est une techno MS mais a su s'exporter vers d'autres OS par le biais de Mono, les évolutions se reflètent d'une part et d'autre, elles sont moins nombreuses et apparaissent moins vite mais globalement un code se compile sous une multitude de système. L'Obj-C c'est une autre histoire il y a des implémentations libres mais qui ne suivent pas les évolutions d'Apple amenuisant largement la portabilité du code. Il y a surement des outils pour automatiser tout ça mais ça fleure trop le bricolage.
Pour résumer je suis content de voir que le langage évolue en nous simplifiant la vie au passage mais je déplore de le voir se fermer de plus en plus rendant de plus en plus hypothétique son utilisation sur les systèmes non-Apple et c'est dommage parce que c'est un bon langage.
Il est peut être bon de rappeler que Mono n'est pas une initiative Microsoft...
Et que tout comme Mono existe, il existe GNUStep et Cocotron depuis des années qui permettent de faire de faire de la crosscompilation.
Maintenant le problème que tu pointe est faux. Le problème ce n'est pas Objective-C qui est dispo sur llvm et gcc sans aucun souci. Le problème c'est les framework Cocoa qui en effet sont créé par Apple et pour Apple. Je peux te livrer un environnement GSWeb (clone de WebObject en ObjC) et tu sera tout autant perdu, car tu ne connais pas le framework.
C# et ObjC ne sont que des langages, une syntaxe, c'est tout. Ce qui fait la spécificité c'est les framework, .Net et Cocoa.
Prend le C++, toutes les plateformes le supportent. Pourtant si tu as utilisé les framework de Qt pour faire ton application tu te retrouve à installer des dépendances sur tous les OS cible.
C'est comme ça depuis toujours. À partir du moment où tu utilise des bibliothèques avancé tu dois les avoir avec toi, et vu que personne n'est d'accord sur quoi mettre dans une machine, et bien tu te démerde à connaitre 3000 choses qui font la même chose différemment.
Le seul environnement de dev qui aujourd'hui permet le code one run everywhere c'est le Java, et on sait tous l'échec que cela représente en application grand public. ça fait une application moche, qui s'intègre mal de partout et que les utilisateurs rechignent à acheter. Seuls les clients pro en prennent par ce que pas le choix.
Ton école t'enseigne un langage plutôt qu'un autre ? Ils ont tord. Ce que l'école est censé t'enseigner c'est apprendre à développer, pas t'apprendre à utiliser un langage en particulier. Les notions d'objets ils sont censé te les apprendre avec des mots génériques et non les mots clefs d'un langage.
Pour la petite histoire, Apple dispose d'une version de Cocoa qui fonctionne sous Windows depuis le début, c'était le projet YellowBox. Fait une recherche dans tes headers sur le mot clef win32 et tu verra... Ce projet permettait de faire tourner une application Cocoa sur Windows nativement. Il fut abandonné pour une raison principale, c'était soit la YellowBox et Cocoa sur Windows, soit la BlueBox, l'environnement Classic sur OS X qui permettait de lancer les applications OS 9. Le choix de classic fut imposé par Microsoft et Adobe qui refusaient de porter Office et Photoshop sur OS X s'ils devaient tout recommencer, même si cela aurait permis de n'avoir plus qu'un seul code à maintenir...
Il serait d'ailleurs intéressant de savoir avec quoi QT et iTunes Windows sont développé... Mais comme toujours avec Apple, ils nous donnent accès qu'à la partie émerger de l'iceberg qu'est leur techno interne. Cocoa sous Windows, Cocoa sur le web... Si l'on regarde pas mal de leur projet on s'aperçoit qu'ils ont tout et qu'ils ne partagent rien...
Je suis de l'avis de Yann...
Dans mon école, on enseigne à tous du C++ et du Java. C'est pour avoir des bases en POO sur deux langages utilisés et plus facilement multi-plateformes. Ils ne focalisent pas spécialement sur un langage. On a eu des cours un peu plus poussés sur les deux frameworks graphiques de Java (Swing et l'autre), un peu de Qt. Mais c'est plus une approche pour différencier les différents éléments (labels, listsbox, etc.) et ne pas se retrouver perdu par la suite.
Certaines filières voient du C# et de l'Objective-C, avec en sous-entendu les frameworks qui vont avec (.Net & Cocoa, ainsi que les trucs Android).
Qu'on ne comprenne pas l'Objective-C est une chose (pour tes profs), mais un apprentissage de la syntaxe est rapide en soit. Ce qui est plus dur, c'est d'apprendre à utiliser les Frameworks (en citant évidemment ce qui est hors du basique NSString, etc.) et leurs subtilités.
Je me suis visiblement mal exprimé...
Dans mon école on apprend à coder avant d'apprendre un langage, comme dans toutes les écoles d'infos (du moins j'espère). Si je citais cet exemple c'est pour illustrer à quel point l'Obj-C ne sort pas du monde Apple. Par rapport à C# qui est à la base un langage porté par MS mais qui est quand même sorti de l'encadrement de la fenêtre.
D'une autre manière Obj-C sans Cocoa a tout de suite moins d'utilité. Gtk et Qt ne peuvent pas être utilisés avec du code Objective-C. ça limite énormément. On est loin d'avoir un langage massivement utilisé dans l'industrie de l'informatique et c'est dommage.
Mais hormis le C il n'y a aucun langage qui est utilisé massivement hein...
Et C# portable avec Mono c'est bien joli mais il n'y a aucun projet qui s'en sert pour de vrai. Le seul que je connais c'est iFolder de Novell.
Les quelques gus qui font du C# pour iOS pour pas "apprendre un nouveau langage" le font avec un portage C# de l'API Cocoa, le truc totalement inutile, c'est même pas .Net qu'ils utilisent...
Chaque plateforme, chaque OS, à son langage et framework de prédilection. C'est ce qu'il y a de plus censé pour faire des produits de qualité, l'intégration verticale...
Quand le SDK iOS est apparu, toute la planète geek à hurlée : "Quoi, un langage inconnu de tous ! Quoi, il faut un Mac pour développer une application iOS ! Apple fait n'importe quoi, personne ne développera pour l'iPhone !!". On connaà®t la suite ..
Quelques logiques de fonctionnement :
- constructeur d'ordinateur : vendre des machines
- éditeurs de logiciels : vendre des logiciels sur le plus de machines possibles
- université : diffuser le plus possible de logiciels gratuits pour avoir de la notoriété et récupérer des financements
Tu as raison, c'est dommage.
Pour moi il y a 3 étapes pour rendre Objective-C utilisable sur d'autres plateformes (disons Windows desktop)
-le langage et le runtime (on y est presque avec LLVM)
-les classes utilitaires (NSString, NSDictionary, etc) (cocotron, CFLite, openCFLite)
-les API graphiques (fenêtre, animation). (cocotron)
En ce qui concerne, les classes utilitaires, je pense que ce qui existe pourrait suffire à condition de les mettre à jour pour utiliser les blocks. Là , évidemment , la vitesse des changements ces derniers temps gênent les initiatives third-party. Même Apple a plus ou moins abandonné Safari et iTunes sous Windows.
En ce qui concerne les classes graphiques, je pense que c'est une erreur de tenter de porter Cocoa.
Autant s'adapter à la plateforme cible. Par exemple sous Windows l'API 'C' Win32 pourrait tout à fait être utilisée, à condition à créer un wrapper Objective-C.
C'est tout à fait envisageable, je pense que c'est juste l'envie et un réel besoin qui manquent.
Porté tout foundation mais ne pas prendre AppKit pour coller une version ObjC de Win32 serait un peu con. ça voudrait dire aucune possibilité de cross compilation hors ce serait réellement là le bénéfice de ObjC/Cocoa sur Windows...
Si c'est pour dev en ObjC avec Foundation et Win32 autant fait du natif directement...
Pouvoir faire des applications en Objective-C sous Windows est un objectif atteignable.
Et c'est un objectif qui a un intérêt en soi pour les développeurs qui aime et maà®trise bien le langage.
Le langage a quand même un intérêt sans cocoa : les blocks, les protocols, les catégories, l'aspect dynamique du runtime, l'efficacité du langage 'C', ARC, etc
Dans un deuxième temps, l'esprit de cocoa a également un intérêt et on peut "porter" cette philosophie sous Windows : les règles de nommage, la profusion de méthode utilitaires, etc. Beaucoup de classes utilitaires n'ont aucun lien avec l'OS donc autant les porter telles quelles (NSString, NSSNumber, les collections, ...)
Porter AppKit est plus difficile car Windows ne fonctionne pas comme le Mac : le système de fenêtre, la base de registre, les raccourcis, les mécanismes de communication inter-apps, la gestion de l'environnement (Shell32 vs NSWorkspace), tout est différent.
Faire de la cross-compilation d'apps entre Windows et Mac est un deuxième objectif, plus ambitieux, et un peu utopique si Apple n'est pas le moteur derrière le projet.
En quelques sortes, tu illustres mon propos. Objective-C, sans tout ses apports était moins efficace qu'actuellement. Je n'en disconviens pas.
Mais quid du futur ? Manque-t-il encore des améliorations clés ?
Pour utiliser une vision mathématique : y a-t-il une asymptote horizontale (ou une succession d'extrêmas, sorte d'ilots de stabilité), oblique ou au contraire est-ce "définitivement" divergent ?
Pour rappel, avant le C qu'on utilise aujourd'hui connu sous le nom C99, il y avait le C ANSI qui avait bien moins de trucs que le C99 (d'ailleurs il y a eu des extensions optionnelles au C ANSI faites au fur et à mesure avant leurs standardisation pour combler ses lacunes avant que ce soit officialisé dans le C99). Sans parler qu'avant le C ANSI c'était encore plus la galère car rien n'était uniformisé. Tu as sans doute l'impression que le C fait partie de ces langages "stables" et qui se sont imposés sur toutes les plateformes, mais la réalité est que le C continue d'évoluer encore aujourd'hui, et a vécu pas mal d'extensions. J'espère bien qu'il en sera de même pour l'Objective-C, pour pas que ce langage stagne mais profite bien des nouveaux concepts disponibles dans le monde de la programmation.
Aujourd'hui pour moi il ne manque pas beaucoup d'améliorations clés (j'ai bien 2-3 idées comme les Class Templates mais pas bcp), mais dans 2 ans si tu me reposes la question je trouverais sans doute qu'avec les nouveautés qui seront sorties d'ici là , il sera appréciable d'ajouter d'autres choses au langage pour inclure ces nouveaux concepts futurs.
Je pense donc qu'on est sur une asymptote horizontale dans le sens où aujourd'hui on en est à une version d'ObjC 2.0 où je ne vois rien de capital à rajouter, mais j'espère pas qu'on soit à une dérivée totalement nulle non plus car j'espère bien que ça va continuer à évoluer quand de nouveaux petterns ou concepts arriveront, même s'il y a de moins en moins de choses à rajouter.
Bonjour
J'aimerais revenir sur les blocks, très présents ici.
Il paraà®t que c'est la grande innovation de cocoa, avec les Objects literal.
Pour ces derniers, OK car ça les intègre dans la logique cocoa (cf NSInteger, si c'est bien de cela dont il s'agit).
Pour les blocks, je ne comprends pas bien.
J'aimerais comprendre ce que cela change ?
J'ai cherché "blocks" sur CocoaCafé.
J'ai retenu
1 - http://forum.cocoacafe.fr/topic/2963-debat-objective-c-20/?hl=blocks#entry29186, de 2008
Dans la plupart des autres cas, rien de plus concret que, pour résumer, "ça m'a changé la vie..." ou des discours compréhensibles pour ceux qui savent.
Au delà des éternelles additions de deux entiers de la doc cocoa qui n'ont aucun intérêt démonstratif, un exemple est donc celui de 1 post #8 de psychoh13.
Seule différence, toujours pour moi : je n'y vois qu'une autre forme d'écriture du code. Un peu comme un if ou un ?: (débat sur le forum, me semble-t-il ?)
Quand à la merveille de l'optimisation à l'exécution, ça me rappelle le temps où on optimisait l'espace en mémoire d'une chaà®ne de caractères. C'était du temps où un disque amovible de 1.2Mo (oui vous avez bien lu : Mo) avait la taille d'une poêle à frire.
En fait, l'optimisation me laisse totalement indifférent aujourd'hui. Il y a sans doute être certaines applications qui demandent cette optimisation, comme Photoshop ou certains jeux, mais qui ne concernent pas le développeur moyen, me semble-t-il ?
Je pense qu'aujourd'hui la gestion de la mémoire relève d'une vie antérieure, compte tenu de la puissance des machines actuelles.
Merci à Apple pour ARC qui permet à Objective-C d'ignorer la gestion de la mémoire et d'en faire un langage quasiment de "haut-niveau".
En tout cas, je n'ai encore vu nulle part d'exemple concret me montrant, en dehors d'une écriture différente liée à des fonctions proposées par les frameworks cocoa, l'intérêt des blocks créés par un utilisateur :
- réduction significative du nombre de lignes de code, par exemple de 1 à 10
- réduction significative du nombre de classes ou de méthodes
- résolution d'un problème autrement insoluble
- autre
Il y eut jadis un Saint Thomas... qui aujourd'hui ne demande pas mieux que de devenir un adepte des blocks si on lui en montre concrètement l'intérêt.
J'ai à peu près compris ce que sont les blocs. Essentiellement cela économise les doigts des programmeurs et cela augmente la lisibilité du code en rassemblant la fonction et ses conditions qui avant étaient ventilées dans des delegates.
Aligator en a parlé ici et il existe une séquence de cocoaheads à Rennes qui est sur ce sujet.
En bref, les blocks permettent plusieurs choses (notamment les patterns de "fonction anonyme" et de "closure", voir Wikipedia & co). En pratique :
1) Cela te permet de passer du code en paramètre, comme si c'était un objet. C'est pratique par exemple pour des méthodes où algos qui sont tout le temps pareil, sauf pour un petit bout de code en plein milieu. Du coup tu peux passer ce bout de code en paramètre (sous la forme d'un block).
Par exemple pour une fonction de tri, tu as toujours le même algo de tri mais selon ce que tu veux trier tu ne vas pas utiliser forcément le même code pour déterminer si un objet A est à trier avant ou après un objet B. Par exemple si ce sont des classes Personne, peut-être que dans le cas qui t'intéresse tu veux trier par nom de famille. Ou peut-être par age. Ou peut-être par couleur de cheveux. Ca dépend du contexte.
Bah avec Cocoa tu as une méthode sur NSArray "sortedArrayUsingComparator" où tu lui passes un block (donc un bout de code) qu'il va utiliser à chaque fois qu'il a besoin de comparer 2 éléments du tableau 2 à 2 lors de son algo de tri, pour trier les éléments dans le bon ordre. Si tu n'avais pas ça, il aurait fallu dupliquer tout l'algo pour tous les cas possibles. Ou alors passer un @selector à la méthode pour dire quelle méthode appeler sur chacun des objets Personne pour le comparer à une autre Personne, et du coup il faudrait dans la classe Personne implémenter toutes les méthodes de comparaison possibles et imaginables, compareByAge, compareByHairColor, compareByLastname, ...
----
2) Autre utilisation souvent rencontrée des blocks : pour gérer plus proprement l'asynchronisme.
En général, avant les Blocks, on utilisait des delegates pour gérer l'asynchronisme. Par exemple si on envoie une requête réseau, ou affiche une UIAlertView... comme forcément ça ne va pas répondre tout de suite, on rend tout de suite la main au code et on demande à ce qu'une méthode de delegate soit appelée quand on a la réponse plus tard.
- Inconvénient numéro 1 de cette approche, c'est que le code qui demande les données et celui qui traite le retour sont à 2 endroits totalement différents dans le code. Pas très lisible.
- Inconvénient numéro 2, c'est que si tu as plusieurs objets qui lancent cette méthode asynchrone, tu vas avoir le même délégate pour tout le monde. Du coup c'est vite le boxon pour ne pas confondre si la réponse que tu as reçu vient de ta requête 1 ou 2 vu qu'elles appellent la même méthode pour signaler qu'elles ont fini.
Alors que depuis qu'on a les blocks, en général on préfère de loin pour ce genre de Use Case passer un block en paramètre, qui sera appelé quand la méthode asynchrone aura fini.
Pour ça mes composant OHAlertView ou OHActionSheet sont de parfaits exemples. Si dans une UIViewController tu as 5 UIAlertViews (à différents endroits dans ton VC), c'est la galère car ils partagent tous le même delegate (ton VC) et la même méthode pour gérer le cas de retour (la méthode "-alertView:clickedButtonAtIndex:"). Du coup déjà quand cette méthode est exécutée tu ne sais pas à quelle AlertView l'utilisateur vient de répondre, est-ce la 1, la 2, la 5 ? En plus tu ne sais pas quelles étaient les options de cette AlertView (OK/Cancel ? Oui/Non/Peut-être ? A/B/C/D ?, donc avec l'index du bouton t'es bien avancé...
Au final :
- non seulement tu es obligé de mettre le code de traitement des réponses de TOUTES tes UIAlertView dans la même méthode (bonjour la lisibilité)
- tu n'as plus le contexte pour savoir de quelle alertView on parle, ni possibilité d'utiliser des variables que tu avais déclarées lors de l'appel à la méthode "show" de ton UIAlertView
- tu ne sais du coup pas forcément quoi faire comme enchaà®nement pour la suite
- et en plus ce code est à l'autre bout, pas du tout lié avec le code qui a demandé d'afficher l'alertView, bonjour les scrolls d'un bout à l'autre du code
Alors qu'en utilisant les blocks, on passe directement le code à exécuter en paramètre, pour directement dire "voilà quand l'utilisateur aura fini par cliquer sur un bouton de l'UIAlertView, c'est ce bout de code qu'il faut utiliser".
Avantage :
- le code est propre à chaque AlertView, tu le passes en paramètre à chaque alertView à qui tu demandes show
- il est groupé au même endroit
- grace au mécanisme de "closure" des blocks (capture des variables) tu peux utiliser des variables qui étaient dans le contexte appelant (ça n'a pas l'air comme ça car c'est tellement naturel quand on l'utilise qu'on pense que c'est normal que ça marche, mais quand on réalise que depuis la méthode qui a appelé le "show" est finie depuis des lustres et que les variables ont normalement disparues, c'est puissant comme possibilité... et en plus tellement bien intégré que ça en devient transparent et on se rend même pas compte que ça fait tout ça)
Et en plus si tu as 3 ou 4 OHAlertViews ça ne pose pas de problème tu peux leur donner chacune le block de code à exécuter de façon indépendantes les unes des autres, pas besoin de tout regrouper dans une même méthode de delegate, pas besoin de scroller à fond pour retrouver le code à exécuter quand c'est fini...
Bref, que des avantages.
Je vais compléter ma réponse. Même si j'ai compris, j'ai toujours du mal à utiliser les blocs de même que les notations avec des points. C'est dû à une non formation en informatique qui fait que j'ai tendance à utiliser ce dont j'ai l'habitude. Je sais Aligator, c'est dommage (ne pas taper sur la tête, merci).
Voilà un raccourci bien dangereux qu'on lit un peu trop souvent ici et là . Pour moi, c'est le plus gros problème d'ARC: infantiliser le développeur lambda qui ne se pose même plus de question. C'est pas grave y a ARC...
Tu veux que je te montre comment faire exploser l'usage mémoire d'une appli écrite avec ARC?
Le nombre de personne qui confondent ARC avec "on n'a plus à réfléchir sur la gestion de la mémoire"...
Déjà ça n'empêche en rien de réfléchir sur l'ownership de nos objet (d'autant que si on le fait pas en effet on peut avoir des retain cycle ou autre et on peut sans problème faire exploser le memory footprint quand même).
En plus je suis assez d'accord que si ARC c'est quand même magnifique, ceux qui ont débuté directement avec ARC sans avoir un peu expérimenté sans, et sans comprendre du coup les tenants et aboutissants que ça implique sous le capot, n'ont pas conscience que ce n'est pas magique tout seul et qu'en aucun cas ça autorise à ignorer la gestion mémoire !
J'suis passé à ARC (pratiquement, un project actuel ne l'est pas), et j'aime bien et j'aime pas à la fois...
J'aime bien ne pas avoir à m'en occuper, et parfois ça me démanger de foutre quelques (auto)release, parce que j'ai l'habitude et que je me dis que mon object HAS TO DIE.
J'étais très réticent à ARC mais l'essayer c'est l'adopter. Quel confort bordel !!!
Arrête de parler d'argent!
Pour #22.
Aà¯e ! Aà¯e !
Les points 1 et 2 commencent à me titiller : je soupçonne que je pourrais les mettre en oeuvre avec profit.
Donc, comme je suis curieux, je vais essayer de le faire.
Mais ça ne va pas être simple et ça va me demander du temps.
Et pendant ce temps, mes applications (basiques) ne vont pas beaucoup avancer ...
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.
J'ai toujours trouvé idiot d'avoir à perdre son temps et à générer des bugs en devant gérer soi-même la mémoire.
Mala, en tant que développer aguerri et compétent sachant maitriser la gestion de la mémoire, pendant cette période de transition tu as ton épingle à tirer mais bientôt, cette compétence sera devenue obsolète.
à‰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 :-*
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.
je ne suis pas tout à fait d'accord. Ce qui caractérise une bonne application c'est d'abord qu'elle correspond à un besoin ou à un désir d'un groupe d'utilisateurs et qu'elle satisfait ce groupe. Vient en deuxième point sa qualité technique: pas de plantage, pas de blocage de l'appareil, pas d'incompatibilité avec d'autres applications, vitesse satisfaisante .... etc.
Si pour arriver au même résultat, tu écris 10% de lignes de plus qu'Ali et que ton application occupe 10% de mémoire de plus, ce n'est pas grave. Les quidams qui l'utilisent s'en tamponneront le coquillard avec une patte d'escargot.
Ceci étant dit, il faut quand même suivre un peu les évolutions de la technique.