Je suis tombé sur une blog d'aujourd'hui intéressante qui prétend être une comparaison d'Android et de développement iPhone. Et c'est une comparaison. Bien que l'auteur ne fait absolument aucune allégation selon laquelle il est sans parti pris, un titre plus approprié et moins trompeuse aurait été Une comparaison de l'iPhone et Android de développement par quelqu'un qui a vraiment, vraiment, vraiment, aime vraiment de Java et ne veut pas être dérangé fait d'apprendre à utiliser le langage et les outils utilisés dans le développement iPhone. Bon, j'avoue que ce serait un peu un titre difficile à manier, mais je peux imaginer que beaucoup de gens viennent à cette entrée de blog et d'obtenir une vision biaisée des choses, alors je veux offrir un contre-avis. Je ne veux pas entrer dans un match de pisser, mais quelques-unes des accusations dans cette annonce sont mauvais et inexcusable nous en dire plus sur l'auteur que les choses qu'il compare.
Permettez-moi d'emblée que je sais que certaines personnes vont interpréter ma réponse comme une tentative de dire que Xcode est «mieux» que d'autres environnements de développement. Ce n'est absolument pas ce que j'essaie de dire. "Better" est une question subjective. Mon but est simplement de contrer la notion présentées dans ce blog que Xcode est "scandaleusement mauvais» ou que Xcode "éloigne de l'écoulement d'un développeur". Il ne prendra loin de l'écoulement d'un développeur qui insiste pour l'utiliser comme s'il s'agissait d'Eclipse ou Visual Studio, mais c'est une faille dans le révélateur, non pas l'en IDE.
Mais tout comme l'affichage d'origine, ceci est un message biaisé basé sur mes propres goûts et aime, mais contrairement à l'auteur original, fait, j'ai une quantité comparable de l'expérience à la fois avec des choses que je ne suis comparer.
Je pense qu'il était Jeff Atwood qui a dit "la seule interface intuitive est le mamelon», et qui ne pouvait pas être plus vrai. Tout ce que nous sommes habitués à faire dans les programmes d'ordinateur - tout le paradigme qui est appris. C'est complètement vrai pour les IDE et les langages de programmation ainsi. Nous apprenons à les utiliser, et beaucoup d'entre nous codeurs passent beaucoup de temps dans notre IDE qu'ils deviennent une seconde nature pour nous au point où nous voyons la façon dont nous travaillons aussi naturel.
Une des plaintes les plus courantes que je vois partir nouvel iPhone et les développeurs Mac, en particulier ceux provenant de Visual Studio ou Eclipse (comme l'auteur du post lié ci-dessus), c'est qu'ils détestent Xcode parce qu'il manque telle ou telle fonctionnalité ou «se sent daté ". Seuls les plus obstinés et coincé dans-leur-moyens aux développeurs de continuer à faire ces revendications après avoir travaillé avec elle à temps plein pendant un an ou plus, toutefois, car le problème n'est pas avec Xcode, le problème est qu'ils essayaient de faire les choses dans Xcode la façon dont ils ont été utilisés pour les faire dans certains autres IDE. Ils essayaient de mettre à profit toutes leurs connaissances acquises sur la façon de programmer en Java ou C # ou de base dans un autre IDE avec les différentes conventions visuelle que sont utilisés dans le codage d'Objective-C en utilisant Xcode.
Maintenant, je n'essaie pas de dire que Xcode est parfait. Pas IDE est parfait, et ils sont constamment emprunter des idées les uns des autres. Une des vertus de Xcode, dans mon esprit, c'est qu'ils n'ont pas adopté l'approche d'un évier d'essayer de mettre en œuvre toute fonction que quiconque croit en place. Ils ont toujours eu relativement un petit nombre d'utilisateurs ciblés, et l'équipe Xcode a créé un scalpel, pas une tronçonneuse. Xcode est écrit par certains ingénieurs qui ont vraiment intelligent de l'utiliser chaque jour pour écrire C, Objective-C, et C + +. Ils ne sont pas à l'utiliser pour écrire VB ou C # et seulement rarement d'écrire Java. Ils ont des besoins différents et des priorités différentes de l'équipe Eclipse ou l'équipe de Visual Studio. Mais de prétendre que Xcode est «manquant» ou «mauvais» ne les développeurs un très mauvais service. Il ne cherche pas à être tout pour tout le monde, c'est vrai, mais il n'en est pas moins une grande IDE pour les types de développement que sa base utilisateur ne sur une base quotidienne.
Voici la chose. Si vous êtes constamment manque certaines fonctionnalités d'Eclipse de Visual Studio, il ya une chance vraiment, vraiment bon vous travaillez à l'encontre, en essayant de faire quelque chose basé sur ce que vous pensez que vous savez d'une autre langue ou un cadre d'application, ou que vous simplement Haven 't découvert quelques morceau de fonctionnalité dans Xcode.
David Green, l'auteur de ce blog, faire l'affirmation que Xcode (où il a travaillé avec de "quelques mois") entrave la productivité des développeurs et qu'elle est donc «inférieure» à Eclipse, un programme, il a travaillé avec le jour- dans les jour-out pendant douze ans. Oui, cela ressemble à une base juste pour comparaison. «Cette chose je viens de commencer à utiliser n'est pas n'importe où près aussi bon que cette chose que j'ai utilisé pendant des années et savent l'intérieur et dehors."
Vous pouvez obtenir un aperçu du processus de pensée derrière cette revendication à partir de cette citation:
Maintenant laissez-moi mettre là-bas que j'ai travaillé avec Java depuis 1997 environ, ce qui serait, quoi, dire ... douze ans? Il a été mon pain et le beurre pendant près de dix de ces années. J'ai aussi une dizaine d'années d'expérience avec Cocoa, Objective-C et Xcode (si vous incluez le Project Builder prédécesseur). Alors, j'ai une base de comparaison et laissez-moi préciser que mon opinion sur les langues et l'IDE est presque exactement le contraire de M. Green quand il s'agit de développement mobile d'applications GUI.
Pour commencer, Java n'est absolument pas une évidence. En fait, Java est un choix vraiment, vraiment mauvais pour le développement embarqué. Oh, je sais de Java a été poussé comme un excellent choix pour les périphériques embarqués depuis des années, mais ce n'est tout simplement pas.
Les appareils mobiles sont contraints appareils ressource. La surcharge de la mémoire d'exécution Java et surcharge du processeur est non-trivial sur un tel dispositif. Et "skillsets existants» peut ne pas venir facile, mais la réutilisation de l'expertise n'est pas bon si le coût pour le faire est de faire de mauvais choix. Vous avez certainement entendu le clich'e "si votre seul outil est un marteau, chaque problème ressemble à un clou"? Eh bien, relire la citation ci-dessus et me dire que ce n'est pas simplement une réaffirmation de ce clich'e comme un axiome. Il déclarant "Java est mieux parce que je la connais mieux», rien de plus. Je sais que les deux langues, et Java est un meilleur choix pour de nombreuses tâches, mais il n'y a vraiment aucun moyen vous pouvez prétendre que c'est mieux pour écrire une application GUI sur un appareil embarqué. Ou, d'ailleurs, pour l'écriture de toute période d'application GUI.
D'autre part, Objective-C est un excellent choix pour écrire des applications GUI pour un appareil embarqué. Il a un runtime qui fournit un grand nombre de fonctionnalités dynamiques avec des frais généraux beaucoup moins. Objective-C a beaucoup mieux que l'introspection Java et une plus grande flexibilité en termes de passage des objets de types différents à travers une chaîne répondeur sans remplir votre code avec des transtypages ou l'utilisation constante des génériques godawful (un hack tant vanté pour contourner une faille fondamentale avec fortement typé des langages statiques comme Java quand il s'agit de concevoir des applications GUI).
Quelques autres joyaux de ce blog:
Honnêtement, je la plainte avait opposés à propos de Java. Je détestais qu'il y avait seulement un seul fichier par classe. Je détestais que Java m'a privé de la possibilité de faire beaucoup de choses cool en séparant la mise en œuvre de ce qui est annoncé pour les autres classes. Je détestais, par exemple, avoir à utiliser des variables statiques finales et détesté avoir à supporter les frais généraux d'un appel de méthode pour de petits morceaux de fonctionnalité qui aurait pu être exprimée dans une macro ou une fonction inline précompilateur statique dans une autre langue. Cela ne veut pas dire que l'approche de Java est mauvais, juste pour dire que juste parce qu'il a pensé de suite ne le rend pas intrinsèquement meilleurs. Son sauve un peu et taper une petite quantité de l'encombrement du projet, mais elle arrive à un prix. Personnellement, je préfère avoir plus de flexibilité et de fichiers un peu plus dans mon projet.
Tête de Split et les fichiers d'implémentation fournissent des fonctionnalités supplémentaires et le coût est relativement trivial. Navigation entre les fichiers en-tête et la mise en œuvre peut être accompli avec un raccourci clavier configurables. J'ai basculer régulièrement entre-tête et les fichiers d'implémentation. La touche de commande devient une seconde nature après un petit moment et il devient complètement un non-problème. Je ne peux même pas voir comment cela pourrait être un problème important de mentionner si vous aviez passé quelques minutes pour lire sur les liaisons principales de Xcode.
ZOMG! Je dois libérer de la mémoire! Et le type à plus d'un endroit! Courir pour les collines!
Pour la petite histoire, je peux mettre en œuvre une propriété unique en environ 20 secondes en utilisant Xcode codesense et les raccourcis clavier pour naviguer entre les fichiers en-tête et la mise en œuvre. Pour ceux qui ne tapez plus vite, consultez l'excellent Accessorizer. Personnellement, je ne peux pas créer des getters et setters Java en Java avec Eclipse sensiblement plus rapide.
Une autre chose à réaliser est que Objective-C a un garbage collector, et c'est assez un bon à ce point, mais Apple a volontairement choisi de ne pas le soutenir sur l'iPhone. Il ne s'agit pas d'une lacune dans la langue, il s'agit d'une décision consciente de fournir une meilleure expérience utilisateur. Forcer les développeurs à prendre la responsabilité de la mémoire signifie que les applications bien écrites seront plus efficaces et utiliser moins de mémoire. Bien sûr, il ya un risque de fuites de mémoire, mais il existe des moyens pour suivre ces bas, et la collecte des ordures vient avec un prix. Sur un appareil comme un téléphone portable, qui est un prix non négligeable, même si le garbage collector est intacte et n'a pas de fuites de mémoire lui-même.
Gosh, il est trop mauvais, nous n'avons pas quelque chose comme ça dans Xcode. Ce serait bien si nous avions peut-être un menu Création, ou peut-être quelques macros de texte pour Objective-C. Ou à tout le moins, une architecture extensible de scripts avec les scripts fournis pour nous aider à écrire nos accesseurs et manipulateurs. Il serait encore mieux si nous avions un framework de persistance qui a complètement éliminé la nécessité pour les classes de modèle de données du tout.
Et pour ceux qui n'ont pas attraper à mon sarcasme dans ce dernier paragraphe, nous avons tous ceux avec Xcode. Il ya un menu de conception avec des outils qui vous aident à concevoir des classes de données modèle. Dans le menu Edition, il est élément de menu appelé «macro Insérer texte", avec plusieurs macros communs pour toutes les langues Xcode supporte, et il ya aussi un menu AppleScript avec des perles telles que "Defs Accesseur Placer sur Presse-papiers".
Mais, dans la grande majorité des situations, vous n'avez pas besoin d'y écrire vos setters et getters. Je ne m'inquiète pas si votre IDE les crée pour vous, 95% du temps, ceux qui sont encore l'encombrement de code. Je préfère avoir une propriété avec une déclaration de synthétiser et éventuellement un appel communiqué que des tonnes de cochonneries dans mon code.
Nous avons aussi des données de base, qui vous permet de concevoir des classes du modèle de données visuelles sans jamais créer une classe Objective-C. Ou vous pouvez créer une sous-classe personnalisée, mais vous ne devez mettre dans votre fonctionnalités personnalisées - pas setters ou des getters moins ils font quelque chose non standard.
Permettez-moi de traduire cela: "Objective-C qui me gêne, car il n'utilise pas les mêmes modèles qui utilise Java et il est donc mauvais". La mise en œuvre correcte des méthodes init et dealloc est non-trivial? Comment dans le monde pourriez-vous dire? Si vous comprenez les contrat de gestion de la mémoire (Pas moins de quatre règles entière), c'est à la fois trivial et intuitive. Il semble que déroutant si vous n'avez pas pris la peine d'apprendre l'un des aspects fondamentaux de la langue que vous utilisez, et si vous n'avez pas, eh bien, ce n'est vraiment pas la faute de Xcode, c'est le vôtre.
Ce qu'il appelle une «douleur», que j'appelle «plus souples». Déclarations avant et les importations en-tête sont plus puissants et plus flexibles que mécanisme d'importation de Java, et si vous comprenez ce qu'ils font, ils sont vraiment pas difficile ou fastidieuse.
Une autre traduction: j'ai continué à regarder pour des fonctionnalités comme si je travaillais en Java et n'a pas trouvé des choses où je les ai attendus. Personnellement, je trouve le navigateur de documentation de Xcode (surtout la nouvelle venue dans Xcode 3.2 sous Snow Leopard) pour être plus intuitive et se sentir comme il est parfaitement conçu pour les besoins d'un programmeur Cocoa Touch informés. Il n'est pas surprenant que ce n'est pas conçue pour répondre aux attentes d'un programmeur tirés de l'utilisation d'une autre langue, d'autres cadres, et un IDE différent.
Et voici les plaintes plus sur le "scandaleusement mauvais" Xcode:
Bon point. C'est juste dommage qu'il n'y a pas de préférence pour le passage à un guichet unique, ou limité fenêtre de présentation, hein? Oh, attendez ... il ya, n'est pas là?
Oh, mon dieu, non. S'il vous plaît non. Vous essayez d'utiliser l'arborescence du projet pour faire le travail du panneau de détails. Cliquez simplement sur le nœud de l'arbre que vous voulez, puis dans le panneau de détails, en quelque sorte de la part de l'arbre que vous avez sélectionné comme vous le voulez, par ordre alphabétique, par la taille du code, que ce soit. Cela vous donne toute la puissance de l'arbre Eclipse horrible projet, mais nous allons vous travaillez uniquement avec la section de la hiérarchie vous êtes actuellement intéresser Croyez-moi, ce n'est pas une lacune dans Xcode, c'est une lacune dans la façon dont vous êtes de travail.
Oh non - il avait à lire la documentation! Aucun développeur ne devrait jamais avoir à faire cela. N'importe qui condamne Interface Builder avec l'éloge s'évanouir ainsi ne pas entièrement comprendre et pense que c'est juste un générateur de formulaire comme ils ont utilisé dans Eclipse ou VS.
Bon, je suis fait. Maintenant, je suis un peu rugueux sur le gars. Il donne un avis honnête pensant qu'il est d'aider les autres, et qui doit être salué. Le problème, c'est qu'il est des réclamations qui ne sont pas seulement un peu partial, ils sont carrément insupportables. Appel Xcode "scandaleusement mauvais" parce que vous n'avez pas pris le temps d'apprendre comment cela fonctionne est simplement ignorants.
Okay, peut-être quelques citations plus, car il ya tellement de bons.
L'iPhone "restera un leader du marché" jusqu'à "18 nouveaux téléphones Android» sont libérés? Avez-vous sérieusement écrire que sans rire? Vous pensez honnêtement que c'est le nombre de combinés qui tient Android dos? Sérieusement?
Mais au moins il a terminé avec un grande citation:
Et la réponse est, en réalité, yes. Mais qui dans leur bon esprit voudrait? Linux fanatisme nonobstant, le noyau Mach est meilleure, et à vrai dire, la plupart des gens - même la plupart des développeurs - ne veulent pas perdre de temps à avoir à compiler et installer de nouveaux noyaux de toute façon.
Permettez-moi d'emblée que je sais que certaines personnes vont interpréter ma réponse comme une tentative de dire que Xcode est «mieux» que d'autres environnements de développement. Ce n'est absolument pas ce que j'essaie de dire. "Better" est une question subjective. Mon but est simplement de contrer la notion présentées dans ce blog que Xcode est "scandaleusement mauvais» ou que Xcode "éloigne de l'écoulement d'un développeur". Il ne prendra loin de l'écoulement d'un développeur qui insiste pour l'utiliser comme s'il s'agissait d'Eclipse ou Visual Studio, mais c'est une faille dans le révélateur, non pas l'en IDE.
Mais tout comme l'affichage d'origine, ceci est un message biaisé basé sur mes propres goûts et aime, mais contrairement à l'auteur original, fait, j'ai une quantité comparable de l'expérience à la fois avec des choses que je ne suis comparer.
Je pense qu'il était Jeff Atwood qui a dit "la seule interface intuitive est le mamelon», et qui ne pouvait pas être plus vrai. Tout ce que nous sommes habitués à faire dans les programmes d'ordinateur - tout le paradigme qui est appris. C'est complètement vrai pour les IDE et les langages de programmation ainsi. Nous apprenons à les utiliser, et beaucoup d'entre nous codeurs passent beaucoup de temps dans notre IDE qu'ils deviennent une seconde nature pour nous au point où nous voyons la façon dont nous travaillons aussi naturel.
Une des plaintes les plus courantes que je vois partir nouvel iPhone et les développeurs Mac, en particulier ceux provenant de Visual Studio ou Eclipse (comme l'auteur du post lié ci-dessus), c'est qu'ils détestent Xcode parce qu'il manque telle ou telle fonctionnalité ou «se sent daté ". Seuls les plus obstinés et coincé dans-leur-moyens aux développeurs de continuer à faire ces revendications après avoir travaillé avec elle à temps plein pendant un an ou plus, toutefois, car le problème n'est pas avec Xcode, le problème est qu'ils essayaient de faire les choses dans Xcode la façon dont ils ont été utilisés pour les faire dans certains autres IDE. Ils essayaient de mettre à profit toutes leurs connaissances acquises sur la façon de programmer en Java ou C # ou de base dans un autre IDE avec les différentes conventions visuelle que sont utilisés dans le codage d'Objective-C en utilisant Xcode.
Maintenant, je n'essaie pas de dire que Xcode est parfait. Pas IDE est parfait, et ils sont constamment emprunter des idées les uns des autres. Une des vertus de Xcode, dans mon esprit, c'est qu'ils n'ont pas adopté l'approche d'un évier d'essayer de mettre en œuvre toute fonction que quiconque croit en place. Ils ont toujours eu relativement un petit nombre d'utilisateurs ciblés, et l'équipe Xcode a créé un scalpel, pas une tronçonneuse. Xcode est écrit par certains ingénieurs qui ont vraiment intelligent de l'utiliser chaque jour pour écrire C, Objective-C, et C + +. Ils ne sont pas à l'utiliser pour écrire VB ou C # et seulement rarement d'écrire Java. Ils ont des besoins différents et des priorités différentes de l'équipe Eclipse ou l'équipe de Visual Studio. Mais de prétendre que Xcode est «manquant» ou «mauvais» ne les développeurs un très mauvais service. Il ne cherche pas à être tout pour tout le monde, c'est vrai, mais il n'en est pas moins une grande IDE pour les types de développement que sa base utilisateur ne sur une base quotidienne.
Voici la chose. Si vous êtes constamment manque certaines fonctionnalités d'Eclipse de Visual Studio, il ya une chance vraiment, vraiment bon vous travaillez à l'encontre, en essayant de faire quelque chose basé sur ce que vous pensez que vous savez d'une autre langue ou un cadre d'application, ou que vous simplement Haven 't découvert quelques morceau de fonctionnalité dans Xcode.
David Green, l'auteur de ce blog, faire l'affirmation que Xcode (où il a travaillé avec de "quelques mois") entrave la productivité des développeurs et qu'elle est donc «inférieure» à Eclipse, un programme, il a travaillé avec le jour- dans les jour-out pendant douze ans. Oui, cela ressemble à une base juste pour comparaison. «Cette chose je viens de commencer à utiliser n'est pas n'importe où près aussi bon que cette chose que j'ai utilisé pendant des années et savent l'intérieur et dehors."
Vous pouvez obtenir un aperçu du processus de pensée derrière cette revendication à partir de cette citation:
Java est un doux euphémisme. Je dois dire que c'est agréable de ne pas avoir à apprendre une nouvelle langue à la cible mobile. Skillsets existantes ne viennent pas facile - la réutilisation afin d'expertise vaut beaucoup.
Maintenant laissez-moi mettre là-bas que j'ai travaillé avec Java depuis 1997 environ, ce qui serait, quoi, dire ... douze ans? Il a été mon pain et le beurre pendant près de dix de ces années. J'ai aussi une dizaine d'années d'expérience avec Cocoa, Objective-C et Xcode (si vous incluez le Project Builder prédécesseur). Alors, j'ai une base de comparaison et laissez-moi préciser que mon opinion sur les langues et l'IDE est presque exactement le contraire de M. Green quand il s'agit de développement mobile d'applications GUI.
Pour commencer, Java n'est absolument pas une évidence. En fait, Java est un choix vraiment, vraiment mauvais pour le développement embarqué. Oh, je sais de Java a été poussé comme un excellent choix pour les périphériques embarqués depuis des années, mais ce n'est tout simplement pas.
Les appareils mobiles sont contraints appareils ressource. La surcharge de la mémoire d'exécution Java et surcharge du processeur est non-trivial sur un tel dispositif. Et "skillsets existants» peut ne pas venir facile, mais la réutilisation de l'expertise n'est pas bon si le coût pour le faire est de faire de mauvais choix. Vous avez certainement entendu le clich'e "si votre seul outil est un marteau, chaque problème ressemble à un clou"? Eh bien, relire la citation ci-dessus et me dire que ce n'est pas simplement une réaffirmation de ce clich'e comme un axiome. Il déclarant "Java est mieux parce que je la connais mieux», rien de plus. Je sais que les deux langues, et Java est un meilleur choix pour de nombreuses tâches, mais il n'y a vraiment aucun moyen vous pouvez prétendre que c'est mieux pour écrire une application GUI sur un appareil embarqué. Ou, d'ailleurs, pour l'écriture de toute période d'application GUI.
D'autre part, Objective-C est un excellent choix pour écrire des applications GUI pour un appareil embarqué. Il a un runtime qui fournit un grand nombre de fonctionnalités dynamiques avec des frais généraux beaucoup moins. Objective-C a beaucoup mieux que l'introspection Java et une plus grande flexibilité en termes de passage des objets de types différents à travers une chaîne répondeur sans remplir votre code avec des transtypages ou l'utilisation constante des génériques godawful (un hack tant vanté pour contourner une faille fondamentale avec fortement typé des langages statiques comme Java quand il s'agit de concevoir des applications GUI).
Quelques autres joyaux de ce blog:
Une chose qui est vraiment devenu clair pour moi est que l'Objective-C, si elle peut avoir été visionnaire pour son époque, est vraiment une langue des années 80. Certaines questions telles que les fichiers d'en-tête fendue et la mise en œuvre et la violation de DRY sont vraiment temps-gaspilleurs, et pas les petits à cela.
Honnêtement, je la plainte avait opposés à propos de Java. Je détestais qu'il y avait seulement un seul fichier par classe. Je détestais que Java m'a privé de la possibilité de faire beaucoup de choses cool en séparant la mise en œuvre de ce qui est annoncé pour les autres classes. Je détestais, par exemple, avoir à utiliser des variables statiques finales et détesté avoir à supporter les frais généraux d'un appel de méthode pour de petits morceaux de fonctionnalité qui aurait pu être exprimée dans une macro ou une fonction inline précompilateur statique dans une autre langue. Cela ne veut pas dire que l'approche de Java est mauvais, juste pour dire que juste parce qu'il a pensé de suite ne le rend pas intrinsèquement meilleurs. Son sauve un peu et taper une petite quantité de l'encombrement du projet, mais elle arrive à un prix. Personnellement, je préfère avoir plus de flexibilité et de fichiers un peu plus dans mon projet.
Tête de Split et les fichiers d'implémentation fournissent des fonctionnalités supplémentaires et le coût est relativement trivial. Navigation entre les fichiers en-tête et la mise en œuvre peut être accompli avec un raccourci clavier configurables. J'ai basculer régulièrement entre-tête et les fichiers d'implémentation. La touche de commande devient une seconde nature après un petit moment et il devient complètement un non-problème. Je ne peux même pas voir comment cela pourrait être un problème important de mentionner si vous aviez passé quelques minutes pour lire sur les liaisons principales de Xcode.
Dans la mesure du SEC, dois-je vraiment faire 5 choses à déclarer une propriété?
ZOMG! Je dois libérer de la mémoire! Et le type à plus d'un endroit! Courir pour les collines!
Pour la petite histoire, je peux mettre en œuvre une propriété unique en environ 20 secondes en utilisant Xcode codesense et les raccourcis clavier pour naviguer entre les fichiers en-tête et la mise en œuvre. Pour ceux qui ne tapez plus vite, consultez l'excellent Accessorizer. Personnellement, je ne peux pas créer des getters et setters Java en Java avec Eclipse sensiblement plus rapide.
Une autre chose à réaliser est que Objective-C a un garbage collector, et c'est assez un bon à ce point, mais Apple a volontairement choisi de ne pas le soutenir sur l'iPhone. Il ne s'agit pas d'une lacune dans la langue, il s'agit d'une décision consciente de fournir une meilleure expérience utilisateur. Forcer les développeurs à prendre la responsabilité de la mémoire signifie que les applications bien écrites seront plus efficaces et utiliser moins de mémoire. Bien sûr, il ya un risque de fuites de mémoire, mais il existe des moyens pour suivre ces bas, et la collecte des ordures vient avec un prix. Sur un appareil comme un téléphone portable, qui est un prix non négligeable, même si le garbage collector est intacte et n'a pas de fuites de mémoire lui-même.
Java a un problème similaire avec des propriétés, mais pas si mal - et l'EDI vous aide à rédiger votre getter / setter.
Gosh, il est trop mauvais, nous n'avons pas quelque chose comme ça dans Xcode. Ce serait bien si nous avions peut-être un menu Création, ou peut-être quelques macros de texte pour Objective-C. Ou à tout le moins, une architecture extensible de scripts avec les scripts fournis pour nous aider à écrire nos accesseurs et manipulateurs. Il serait encore mieux si nous avions un framework de persistance qui a complètement éliminé la nécessité pour les classes de modèle de données du tout.
Et pour ceux qui n'ont pas attraper à mon sarcasme dans ce dernier paragraphe, nous avons tous ceux avec Xcode. Il ya un menu de conception avec des outils qui vous aident à concevoir des classes de données modèle. Dans le menu Edition, il est élément de menu appelé «macro Insérer texte", avec plusieurs macros communs pour toutes les langues Xcode supporte, et il ya aussi un menu AppleScript avec des perles telles que "Defs Accesseur Placer sur Presse-papiers".
Mais, dans la grande majorité des situations, vous n'avez pas besoin d'y écrire vos setters et getters. Je ne m'inquiète pas si votre IDE les crée pour vous, 95% du temps, ceux qui sont encore l'encombrement de code. Je préfère avoir une propriété avec une déclaration de synthétiser et éventuellement un appel communiqué que des tonnes de cochonneries dans mon code.
Nous avons aussi des données de base, qui vous permet de concevoir des classes du modèle de données visuelles sans jamais créer une classe Objective-C. Ou vous pouvez créer une sous-classe personnalisée, mais vous ne devez mettre dans votre fonctionnalités personnalisées - pas setters ou des getters moins ils font quelque chose non standard.
Un autre désagrément de l'Objective-C est le modèles qui doivent être suivies: la mise en œuvre correcte des méthodes init et dealloc n'est pas trivial. Getters et setters @ synthétisés pour les propriétés avec retenue ne doit pas être appelé à ces méthodes. Ainsi de nombreuses conventions et les règles à se rappeler!
Permettez-moi de traduire cela: "Objective-C qui me gêne, car il n'utilise pas les mêmes modèles qui utilise Java et il est donc mauvais". La mise en œuvre correcte des méthodes init et dealloc est non-trivial? Comment dans le monde pourriez-vous dire? Si vous comprenez les contrat de gestion de la mémoire (Pas moins de quatre règles entière), c'est à la fois trivial et intuitive. Il semble que déroutant si vous n'avez pas pris la peine d'apprendre l'un des aspects fondamentaux de la langue que vous utilisez, et si vous n'avez pas, eh bien, ce n'est vraiment pas la faute de Xcode, c'est le vôtre.
Les importations en Objective-C et le transmet-déclarations (classe @) sont une douleur
Ce qu'il appelle une «douleur», que j'appelle «plus souples». Déclarations avant et les importations en-tête sont plus puissants et plus flexibles que mécanisme d'importation de Java, et si vous comprenez ce qu'ils font, ils sont vraiment pas difficile ou fastidieuse.
Avec l'iPhone, d'autre part, de trouver les fonctionnalités dont j'avais besoin était douloureux. Les classes et les méthodes sont mal organisés
Une autre traduction: j'ai continué à regarder pour des fonctionnalités comme si je travaillais en Java et n'a pas trouvé des choses où je les ai attendus. Personnellement, je trouve le navigateur de documentation de Xcode (surtout la nouvelle venue dans Xcode 3.2 sous Snow Leopard) pour être plus intuitive et se sentir comme il est parfaitement conçu pour les besoins d'un programmeur Cocoa Touch informés. Il n'est pas surprenant que ce n'est pas conçue pour répondre aux attentes d'un programmeur tirés de l'utilisation d'une autre langue, d'autres cadres, et un IDE différent.
Et voici les plaintes plus sur le "scandaleusement mauvais" Xcode:
Une fenêtre décent / système de gestion de l'éditeur. XCode et il est associé (débogueur) souhaite ouvrir de nombreuses fenêtres. Vous voulez ouvrir un fichier? Que diriez-vous dans une nouvelle fenêtre pour vous! Très vite je me suis retrouvé en plein-window-enfer. La gestion des fenêtres du système d'exploitation est conçu pour gérer de multiples applications, et non pas plusieurs éditeurs au sein d'un IDE. Il n'est tout simplement pas capable de fournir la gestion des éditeurs dans un environnement aussi complexe que d'un IDE.
Bon point. C'est juste dommage qu'il n'y a pas de préférence pour le passage à un guichet unique, ou limité fenêtre de présentation, hein? Oh, attendez ... il ya, n'est pas là?
Une arborescence de projet qui trie les fichiers par ordre alphabétique. Vraiment!
Oh, mon dieu, non. S'il vous plaît non. Vous essayez d'utiliser l'arborescence du projet pour faire le travail du panneau de détails. Cliquez simplement sur le nœud de l'arbre que vous voulez, puis dans le panneau de détails, en quelque sorte de la part de l'arbre que vous avez sélectionné comme vous le voulez, par ordre alphabétique, par la taille du code, que ce soit. Cela vous donne toute la puissance de l'arbre Eclipse horrible projet, mais nous allons vous travaillez uniquement avec la section de la hiérarchie vous êtes actuellement intéresser Croyez-moi, ce n'est pas une lacune dans Xcode, c'est une lacune dans la façon dont vous êtes de travail.
les développeurs d'applications iPhone sont donnés un constructeur UI assez bonne. Il fait un excellent travail de montrer l'interface utilisateur comme il apparaîtra effectivement. Il est souple et permet de modéliser des interfaces assez sophistiquée, donc j'ai été impressionné. J'ai trouvé qu'il était en utilisant un peu délicat - je devais lire la documentation deux ou trois fois avant que je puisse vraiment comprendre comment l'utiliser correctement.
Oh non - il avait à lire la documentation! Aucun développeur ne devrait jamais avoir à faire cela. N'importe qui condamne Interface Builder avec l'éloge s'évanouir ainsi ne pas entièrement comprendre et pense que c'est juste un générateur de formulaire comme ils ont utilisé dans Eclipse ou VS.
Bon, je suis fait. Maintenant, je suis un peu rugueux sur le gars. Il donne un avis honnête pensant qu'il est d'aider les autres, et qui doit être salué. Le problème, c'est qu'il est des réclamations qui ne sont pas seulement un peu partial, ils sont carrément insupportables. Appel Xcode "scandaleusement mauvais" parce que vous n'avez pas pris le temps d'apprendre comment cela fonctionne est simplement ignorants.
Okay, peut-être quelques citations plus, car il ya tellement de bons.
Nous pouvons voir un bouleversement dans le marché du mobile, avec au moins 18 nouveaux téléphones Android d'être libéré de cette année. Jusque là, l'iPhone restera un leader sur le marché et les développeurs devront mettre en place avec XCode et Objective-C.
L'iPhone "restera un leader du marché" jusqu'à "18 nouveaux téléphones Android» sont libérés? Avez-vous sérieusement écrire que sans rire? Vous pensez honnêtement que c'est le nombre de combinés qui tient Android dos? Sérieusement?
Mais au moins il a terminé avec un grande citation:
Bien sûr, l'iPhone est grande - mais peut-on installer un nouveau noyau Linux?
Et la réponse est, en réalité, yes. Mais qui dans leur bon esprit voudrait? Linux fanatisme nonobstant, le noyau Mach est meilleure, et à vrai dire, la plupart des gens - même la plupart des développeurs - ne veulent pas perdre de temps à avoir à compiler et installer de nouveaux noyaux de toute façon.
Aucun commentaire:
Enregistrer un commentaire