J'ai déjà donné mon opinion sur le Nexus One de matériel. Maintenant il est temps de regarder la programmation côté des choses. Il est temps pour mon opinion sur le SDK Android.
Laissez-moi commencer par énoncer une évidence, parce que je connais quelques personnes vont oublier ceci: je suis sur mon propre état de ses opinions personnelles et très subjectives sur le SDK Android. Cette opinion peut être différente de la vôtre, et c'est correct. Vraiment. Il est. La Terre va continuer à tourner même si vous pensez que je suis 100% faux.
Permettez-moi aussi mettre mes préjugés juste devant: je n'aime pas Java. En fait, j'ai été en utilisant Java plus long que l'Objective-C et ont effectivement enregistré plus d'heures et fait plus d'argent en utilisant Java que j'ai avec Objective-C, mais dès l'instant que j'ai lu Programmation Orientée Objet et le langage Objective-C en 1997 ou 1998, je me sentais comme Java a été fait beaucoup de choses erronées. Chaque étape dans l'évolution de Java a renforcé et renforcé ce sentiment. L'approche utilisée dans NeXTSTEP (qui a évolué en Cocoa et Cocoa Touch, puis) correspond à ma façon de penser. Je crois que dans l'approche. J'aime l'approche et le langage tellement, en fait, que j'ai pris une réduction substantielle des revenus pour être en mesure de travailler avec elle à temps plein. Donc, sur cette base, vous devriez être capable de voir que Android a déjà eu une grève contre elle, de mon point de vue.
J'ai été intentionnellement mettre hors la rédaction de ce blog, toutefois, parce que je ne voulais pas faire ce que j'ai vu beaucoup de gens font avec l'iPhone SDK et Xcode, qui est d'écrire un blog sur la façon dont il doesn 't travail comme je l'ai attendu, et donc c'est mauvais. Étant donné que j'ai déjà un peu d'expérience avec la langue et IDE et ont maintenant eu plusieurs semaines avec le SDK Android, je sens que je peux donner une opinion qui n'est pas seulement moi se plaindre que ce n'est pas ce que je connais déjà, et comme, bien le fait qu'il fait beaucoup de choses d'une manière que je n'aime pas, c'est certainement un facteur à mon avis.
Ainsi, après avoir passé quelques semaines avec Android, qu'est-ce que je pense?
C'est quand même pas mal. C'est un SDK assez capable. Il possède la plupart de ce que vous avez besoin et, étant basé sur Java, il ya énormément de code et les bibliothèques vous pouvez puiser. La conception du SDK est un peu incohérent (tout comme l'expérience utilisateur Android, en fait). Il ya des parties qui sont presque aussi proche d'une copie de l'iPhone SDK sont très similaires dans la conception et se sentir à l'iPhone, et il ya des pièces qui semblent carrément extraterrestre1.
Il ya certainement un manque de cohérence dans la conception par rapport à l'iPhone SDK. Différentes parties du SDK Android se sentent comme ils ont été écrits par des équipes totalement différentes qui ne communiquent pas nécessairement ou même d'accord sur la meilleure façon de faire les choses. Il ya quelques petites incohérences dans le SDK de l'iPhone, mais il ya de fortes principes directeurs et les modèles de conception dominante tout au long du SDK de l'iPhone qui n'ont pas d'équivalent dans le SDK Android. L'effet global est que Android est un peu chaotique et décousu, mais toujours compétent.
Android a également une tâche difficile en ce sens qu'il est conçu pour fonctionner sur un tel éventail de matériels et vous pouvez développé sur une large gamme de systèmes d'exploitation et le matériel. Google a effectivement fait tout un travail admirable donné combien plus difficile le problème c'est quand vous n'avez pas d'options matérielles limitées, qui tous vous contrôler.
Un des moyens qu'ils ont abordé ce n'est dans la conception de l'émulateur. Vous pouvez configurer l'émulateur pour simuler un matériel différent avec des caractéristiques différentes et différentes tailles d'écran, et vous pouvez avoir plusieurs setup virtuels appareils. Cela signifie que vous pouvez tester votre application sur un "Nexus One virtuels", puis passer à un nouveau périphérique virtuel et tester sur une "Droid Motorola virtuels". Travailler avec l'émulateur est lisse, mais pas aussi lisse d'une expérience que l'iPhone Simulator. Par exemple, lorsque vous lancez une application dans l'émulateur, l'émulateur ne devienne pas l'application front-plus, et l'émulateur ne se déverrouillent automatiquement. Mais, l'expérience est encore tout à fait décent, surtout à la lumière des défis supplémentaires présentées par étant une plateforme ouverte.
Fonctionnant sur le périphérique fonctionne bien, aussi. Etonnamment bien, en fait. Encore une fois, il n'est pas aussi lisse d'une expérience en tant que tournant sur l'iPhone. Il y avait des petits désagréments, comme lorsque vous exécutez un programme sur l'appareil, le téléphone ne se réveille pas ou déverrouiller la manière de l'iPhone ne. Mais, globalement, cela fonctionne assez bien et sans les tracas de profils d'approvisionnement ou de certificats développeur.
J'ai trouvé le débogage d'être quelque peu douloureux sur Android, mais cela peut être simplement que je sais GDB tellement mieux que JDB / BAD (l'Android débogage Bridge) et je sais aussi le débogage de Xcode fonctions beaucoup mieux que d'Eclipse.
Bien que vous n'avez pas à utiliser Eclipse pour programmer pour Android, il ne semble pas être le choix par défaut. Au moins, il semblait que le choix avec le moins d'obstacles quand je me configuration tout. Eclipse a vraiment bien avec l'intégration du SDK Android et les outils. Exécution et le débogage sur le périphérique ou sur l'émulateur sont un morceau de gâteau, et il ya même des outils pour pousser des données à l'appareil exécutant virtuels tels que les données de localisation.
Mais je déteste Eclipse avec une passion. Il a complètement et totalement ne jive avec la façon dont je pense ou au travail. Je trouve l'interface impénétrables et ses performances sur le Mac est moins que stellaire. Si je devais faire beaucoup de développement d'Android, je serais probablement investir un certain temps à trouver une alternative avec Android IDE bonne intégration, ou tout simplement travailler avec TextMate et la ligne de commande.
Je ne sens que je peux le code n'importe quelle application je dois utiliser Android. Rendre belle apparence peut être un défi, et je passe beaucoup plus de documentation de temps référencement que je n'ai jamais fait avec le SDK iPhone. Sachant qu'une partie du SDK Android ne vous donnent pas nécessairement des indices sur la façon dont une autre partie qui fonctionne et même d'être un développeur Java expérimenté ne vous donne pas que beaucoup d'avantage à cet égard.
Conception de vues dans le SDK Android est l'un des domaines que je peux dire sans équivoque est pire que l'iPhone à tous égards unique. L'approche d'Android à la création de points de vue n'a absolument aucune valeur rédemptrice que ce soit. Concevoir votre interface sur l'iPhone, c'est facile. C'est amusant. Il est intuitif. Sur Android, c'est putain enfer. C'est comme travailler avec les enfants du mal de GridBagLayout et XML. C'est tout à fait horrible. Mais, Java n'a jamais fait l'interface utilisateur bien et n'a jamais fait particulièrement fun donc je ne peux dire que j'ai été surpris par cela, si elle ne dépasse mes attentes en étant encore pire que je pensais était humainement possible. Le processus entier est contre-intuitif et fastidieuse, et c'est juste pour faire quelque chose qui fonctionne. Il est encore plus fastidieux et douloureux de faire une interface qui ne ressemble pas à cul.
Mais, c'est le seul domaine à ce jour en Android que j'ai trouvé vraiment horrible. Globalement, c'est un SDK capable. Qu'est-ce qu'il n'est pas, toutefois (du moins pour moi), c'est amusant. C'est complètement à côté de tout autre facteur amusant que ce soit. Le SDK ne pas sortir de mon chemin quand je veux créer. C'est un obstacle constant. Pas un gros obstacle ou insurmontable, mais une constante. Le SDK iPhone, d'autre part, est assez amusant. Une fois que j'ai compris sa démarche à faire les choses, il est devenu très facile d'oublier le SDK et il suffit de créer mes applications.
J'ai essayé de comprendre exactement quelle est la différence, quelle qu'elle soit qui fait un plaisir pour moi et l'autre pas, et je pense que je l'ai. Le SDK Android échoue généralement à suivre un principe de conception que Apple ne sacrément bien, qui est:
Exemple: En raison de la taille de l'écran relativement petit, l'une des choses que tu fais tout le temps dans des applications mobiles est le commutateur de nouveaux écrans de données. Sur l'iPhone, nous réalisons que de cette manière:
Maintenant, les gens qui aiment Android fera valoir que les intentions sont puissants - plus puissant que l'approche de l'iPhone, car intentions peuvent être utilisés pour laisser d'autres programmes et la fonctionnalité levier OS à partir de votre programme.
En effet. Intentions sont puissants. Le problème est qu'ils vous donnent le pouvoir que vous n'avez pas besoin de la grande majorité du temps dans la grande majorité des applications. Et ils font ça au détriment de faire quelque chose que vous devez faire tout le temps plus impliqués et plus complexe que ce qu'elle devrait être (et, par conséquent, plus susceptibles de contenir des bogues). C'est la complexité sans discernement, ce qui n'est pas une vertu. Comme OpenDoc et Cyberdog volontiers attestent, des concepts apparemment bonnes ne font pas toujours pour les bonnes implémentations ou de l'expérience utilisateur, et l'iPhone n'a pas beaucoup souffert pour son manque d'un moyen de partager les fonctionnalités entre les applications.
Pour moi, une grande partie du SDK Android (assez bien les parties qui n'ont pas été fortement influencé par le SDK iPhone) semblent être trop complexe. Une grande partie des caractéristiques du SDK Android complexité apparemment à cause de la complexité du. Il ya quinze ans, je l'aurais aimé parce que j'étais dans mon cours d'ingénierie macho-programmeur phase de2 et que la complexité et la puissance théorique, il m'a donné aurait semblé vraiment cool.
Aujourd'hui, il fait juste me secouer ma tête et penser les ingénieurs de Google devrait arrêter montrer comment futé ils pensent qu'ils sont et de commencer à écrire du code élégante que c'est exactement comme complexe car il doit être. Ils devraient concevoir l'architecture de leur SDK avec une prise de conscience du fait que ce n'est pas toutes les tâches sont créés égaux, et la simplicité est, à certains moments, le meilleur choix absolu.
Mais, malgré mes sentiments sur l'élégance d'Android, il est absolument is un SDK décente mobiles. Il ya beaucoup de fonctionnalités là, et un très grand nombre de bibliothèques et des exemples de code que vous pouvez faire appel pour éviter de réinventer la roue dans vos applications.
Je ne me vois pas faire jamais le temps de travail Android complet. Je ne me vois pas toujours activement à la recherche d'Android SDK de travail qui ne fait pas partie intégrante d'un projet plus vaste qui inclut une application iPhone. Mais, au fond, c'est pas mal. Il est, à certains moments, inélégante, inutilement complexes et alambiquées, mais il est jeune et il a encore le potentiel de devenir une grande SDK.
Est-ce que Android décoller? Probablement. Il ya beaucoup de téléphones Android arrivent sur le marché. Les compagnies de téléphone sans fil et l'amour des OS libres, car ils augmentent leurs marges bénéficiaires. Et, une fois suffisamment de gens commencent à posséder des téléphones Android, les gens vont vraiment commencer à écrire des applications pour les téléphones Android. Je ne pense pas que vous verrez jamais la vague de la façon dont vous avez avec le SDK de l'iPhone où les gens de tous les horizons de la vie sans aucune expérience de programmation développé un désir d'apprendre à écrire des logiciels, mais je ne pense qu'il y aura éventuellement une bon marché pour les applications Android et, par conséquent, pour les développeurs Android.
Je suis heureux de quitter ce marché à d'autres.
1 Mes excuses. Mon texte original ici auraient pu être interprété comme impliquant que l'équipe Android copié le SDK de l'iPhone, ce qui n'était pas vraiment mon intention. Je voulais dire que certaines parties ont un sens très similaires et l'utilisation des design patterns couramment utilisés dans le SDK de l'iPhone. Il est assez évident si vous avez passé du temps avec le SDK Android, qu'ils font leur propre chose et ne sont pas simplement copier l'iPhone
2 Chaque programmeur passe par cette phase, si elles collent avec la programmation assez longtemps. Si vous avez été la programmation pendant un moment et ne pense pas que vous êtes allé à travers elle, il ya une très bonne chance que vous êtes encore en elle.
Laissez-moi commencer par énoncer une évidence, parce que je connais quelques personnes vont oublier ceci: je suis sur mon propre état de ses opinions personnelles et très subjectives sur le SDK Android. Cette opinion peut être différente de la vôtre, et c'est correct. Vraiment. Il est. La Terre va continuer à tourner même si vous pensez que je suis 100% faux.
Permettez-moi aussi mettre mes préjugés juste devant: je n'aime pas Java. En fait, j'ai été en utilisant Java plus long que l'Objective-C et ont effectivement enregistré plus d'heures et fait plus d'argent en utilisant Java que j'ai avec Objective-C, mais dès l'instant que j'ai lu Programmation Orientée Objet et le langage Objective-C en 1997 ou 1998, je me sentais comme Java a été fait beaucoup de choses erronées. Chaque étape dans l'évolution de Java a renforcé et renforcé ce sentiment. L'approche utilisée dans NeXTSTEP (qui a évolué en Cocoa et Cocoa Touch, puis) correspond à ma façon de penser. Je crois que dans l'approche. J'aime l'approche et le langage tellement, en fait, que j'ai pris une réduction substantielle des revenus pour être en mesure de travailler avec elle à temps plein. Donc, sur cette base, vous devriez être capable de voir que Android a déjà eu une grève contre elle, de mon point de vue.
J'ai été intentionnellement mettre hors la rédaction de ce blog, toutefois, parce que je ne voulais pas faire ce que j'ai vu beaucoup de gens font avec l'iPhone SDK et Xcode, qui est d'écrire un blog sur la façon dont il doesn 't travail comme je l'ai attendu, et donc c'est mauvais. Étant donné que j'ai déjà un peu d'expérience avec la langue et IDE et ont maintenant eu plusieurs semaines avec le SDK Android, je sens que je peux donner une opinion qui n'est pas seulement moi se plaindre que ce n'est pas ce que je connais déjà, et comme, bien le fait qu'il fait beaucoup de choses d'une manière que je n'aime pas, c'est certainement un facteur à mon avis.
Ainsi, après avoir passé quelques semaines avec Android, qu'est-ce que je pense?
C'est quand même pas mal. C'est un SDK assez capable. Il possède la plupart de ce que vous avez besoin et, étant basé sur Java, il ya énormément de code et les bibliothèques vous pouvez puiser. La conception du SDK est un peu incohérent (tout comme l'expérience utilisateur Android, en fait). Il ya des parties qui sont presque aussi proche d'une copie de l'iPhone SDK sont très similaires dans la conception et se sentir à l'iPhone, et il ya des pièces qui semblent carrément extraterrestre1.
Il ya certainement un manque de cohérence dans la conception par rapport à l'iPhone SDK. Différentes parties du SDK Android se sentent comme ils ont été écrits par des équipes totalement différentes qui ne communiquent pas nécessairement ou même d'accord sur la meilleure façon de faire les choses. Il ya quelques petites incohérences dans le SDK de l'iPhone, mais il ya de fortes principes directeurs et les modèles de conception dominante tout au long du SDK de l'iPhone qui n'ont pas d'équivalent dans le SDK Android. L'effet global est que Android est un peu chaotique et décousu, mais toujours compétent.
Android a également une tâche difficile en ce sens qu'il est conçu pour fonctionner sur un tel éventail de matériels et vous pouvez développé sur une large gamme de systèmes d'exploitation et le matériel. Google a effectivement fait tout un travail admirable donné combien plus difficile le problème c'est quand vous n'avez pas d'options matérielles limitées, qui tous vous contrôler.
Un des moyens qu'ils ont abordé ce n'est dans la conception de l'émulateur. Vous pouvez configurer l'émulateur pour simuler un matériel différent avec des caractéristiques différentes et différentes tailles d'écran, et vous pouvez avoir plusieurs setup virtuels appareils. Cela signifie que vous pouvez tester votre application sur un "Nexus One virtuels", puis passer à un nouveau périphérique virtuel et tester sur une "Droid Motorola virtuels". Travailler avec l'émulateur est lisse, mais pas aussi lisse d'une expérience que l'iPhone Simulator. Par exemple, lorsque vous lancez une application dans l'émulateur, l'émulateur ne devienne pas l'application front-plus, et l'émulateur ne se déverrouillent automatiquement. Mais, l'expérience est encore tout à fait décent, surtout à la lumière des défis supplémentaires présentées par étant une plateforme ouverte.
Fonctionnant sur le périphérique fonctionne bien, aussi. Etonnamment bien, en fait. Encore une fois, il n'est pas aussi lisse d'une expérience en tant que tournant sur l'iPhone. Il y avait des petits désagréments, comme lorsque vous exécutez un programme sur l'appareil, le téléphone ne se réveille pas ou déverrouiller la manière de l'iPhone ne. Mais, globalement, cela fonctionne assez bien et sans les tracas de profils d'approvisionnement ou de certificats développeur.
J'ai trouvé le débogage d'être quelque peu douloureux sur Android, mais cela peut être simplement que je sais GDB tellement mieux que JDB / BAD (l'Android débogage Bridge) et je sais aussi le débogage de Xcode fonctions beaucoup mieux que d'Eclipse.
Bien que vous n'avez pas à utiliser Eclipse pour programmer pour Android, il ne semble pas être le choix par défaut. Au moins, il semblait que le choix avec le moins d'obstacles quand je me configuration tout. Eclipse a vraiment bien avec l'intégration du SDK Android et les outils. Exécution et le débogage sur le périphérique ou sur l'émulateur sont un morceau de gâteau, et il ya même des outils pour pousser des données à l'appareil exécutant virtuels tels que les données de localisation.
Mais je déteste Eclipse avec une passion. Il a complètement et totalement ne jive avec la façon dont je pense ou au travail. Je trouve l'interface impénétrables et ses performances sur le Mac est moins que stellaire. Si je devais faire beaucoup de développement d'Android, je serais probablement investir un certain temps à trouver une alternative avec Android IDE bonne intégration, ou tout simplement travailler avec TextMate et la ligne de commande.
Je ne sens que je peux le code n'importe quelle application je dois utiliser Android. Rendre belle apparence peut être un défi, et je passe beaucoup plus de documentation de temps référencement que je n'ai jamais fait avec le SDK iPhone. Sachant qu'une partie du SDK Android ne vous donnent pas nécessairement des indices sur la façon dont une autre partie qui fonctionne et même d'être un développeur Java expérimenté ne vous donne pas que beaucoup d'avantage à cet égard.
Conception de vues dans le SDK Android est l'un des domaines que je peux dire sans équivoque est pire que l'iPhone à tous égards unique. L'approche d'Android à la création de points de vue n'a absolument aucune valeur rédemptrice que ce soit. Concevoir votre interface sur l'iPhone, c'est facile. C'est amusant. Il est intuitif. Sur Android, c'est putain enfer. C'est comme travailler avec les enfants du mal de GridBagLayout et XML. C'est tout à fait horrible. Mais, Java n'a jamais fait l'interface utilisateur bien et n'a jamais fait particulièrement fun donc je ne peux dire que j'ai été surpris par cela, si elle ne dépasse mes attentes en étant encore pire que je pensais était humainement possible. Le processus entier est contre-intuitif et fastidieuse, et c'est juste pour faire quelque chose qui fonctionne. Il est encore plus fastidieux et douloureux de faire une interface qui ne ressemble pas à cul.
Mais, c'est le seul domaine à ce jour en Android que j'ai trouvé vraiment horrible. Globalement, c'est un SDK capable. Qu'est-ce qu'il n'est pas, toutefois (du moins pour moi), c'est amusant. C'est complètement à côté de tout autre facteur amusant que ce soit. Le SDK ne pas sortir de mon chemin quand je veux créer. C'est un obstacle constant. Pas un gros obstacle ou insurmontable, mais une constante. Le SDK iPhone, d'autre part, est assez amusant. Une fois que j'ai compris sa démarche à faire les choses, il est devenu très facile d'oublier le SDK et il suffit de créer mes applications.
J'ai essayé de comprendre exactement quelle est la différence, quelle qu'elle soit qui fait un plaisir pour moi et l'autre pas, et je pense que je l'ai. Le SDK Android échoue généralement à suivre un principe de conception que Apple ne sacrément bien, qui est:
Faire les choses que vous faire tout le temps facile.En conséquence, sur Android, des choses que vous ne presque jamais semblent être à peu près aussi dur et consomme du temps comme ceux que vous n'avez tout le temps.
Exemple: En raison de la taille de l'écran relativement petit, l'une des choses que tu fais tout le temps dans des applications mobiles est le commutateur de nouveaux écrans de données. Sur l'iPhone, nous réalisons que de cette manière:
- Créer une instance de la classe du contrôleur d'affichage de la vue, nous voulons montrer
- Définir les propriétés de ce contrôleur en vue de lui fournir les données dont il a besoin pour fonctionner
- Présent afficher le contrôleur de vue de l'ajoutant à la hiérarchie d'affichage, en le poussant vers la pile d'un contrôleur de la navigation, ou de le présenter sous forme modale, dont chacun nécessite généralement une seule ligne de code
- Ajoutez une entrée pour l'activité (ce qui est similaire à UIViewController, mais pas exactement les mêmes) pour manifester votre application Android pour laisser Android connaître la classe peut être lancé
- Créer une intention basé sur le Activity«Classe S
- Assurez-vous que toutes les données que vous voulez passer à l'autre Activity est sérialisable ou en forme de types de données brutes
- Poussez les informations que vous voulez passer à l'autre activité comme un «extra» à l'intention, la sérialisation ceux qui sont des objets
- Commencez l'activité
- Dans la classe d'activité, remplacer onActivityResult et récupérer les extras dont vous avez besoin, désérialisation ceux qui ne sont pas des types de données natifs.
- Dans l'Activité remplacer le onCreate () pour spécifier la vue à utiliser (et ne me lancez sur la conception de vues dans Android ...)
Maintenant, les gens qui aiment Android fera valoir que les intentions sont puissants - plus puissant que l'approche de l'iPhone, car intentions peuvent être utilisés pour laisser d'autres programmes et la fonctionnalité levier OS à partir de votre programme.
En effet. Intentions sont puissants. Le problème est qu'ils vous donnent le pouvoir que vous n'avez pas besoin de la grande majorité du temps dans la grande majorité des applications. Et ils font ça au détriment de faire quelque chose que vous devez faire tout le temps plus impliqués et plus complexe que ce qu'elle devrait être (et, par conséquent, plus susceptibles de contenir des bogues). C'est la complexité sans discernement, ce qui n'est pas une vertu. Comme OpenDoc et Cyberdog volontiers attestent, des concepts apparemment bonnes ne font pas toujours pour les bonnes implémentations ou de l'expérience utilisateur, et l'iPhone n'a pas beaucoup souffert pour son manque d'un moyen de partager les fonctionnalités entre les applications.
Pour moi, une grande partie du SDK Android (assez bien les parties qui n'ont pas été fortement influencé par le SDK iPhone) semblent être trop complexe. Une grande partie des caractéristiques du SDK Android complexité apparemment à cause de la complexité du. Il ya quinze ans, je l'aurais aimé parce que j'étais dans mon cours d'ingénierie macho-programmeur phase de2 et que la complexité et la puissance théorique, il m'a donné aurait semblé vraiment cool.
Aujourd'hui, il fait juste me secouer ma tête et penser les ingénieurs de Google devrait arrêter montrer comment futé ils pensent qu'ils sont et de commencer à écrire du code élégante que c'est exactement comme complexe car il doit être. Ils devraient concevoir l'architecture de leur SDK avec une prise de conscience du fait que ce n'est pas toutes les tâches sont créés égaux, et la simplicité est, à certains moments, le meilleur choix absolu.
Mais, malgré mes sentiments sur l'élégance d'Android, il est absolument is un SDK décente mobiles. Il ya beaucoup de fonctionnalités là, et un très grand nombre de bibliothèques et des exemples de code que vous pouvez faire appel pour éviter de réinventer la roue dans vos applications.
Je ne me vois pas faire jamais le temps de travail Android complet. Je ne me vois pas toujours activement à la recherche d'Android SDK de travail qui ne fait pas partie intégrante d'un projet plus vaste qui inclut une application iPhone. Mais, au fond, c'est pas mal. Il est, à certains moments, inélégante, inutilement complexes et alambiquées, mais il est jeune et il a encore le potentiel de devenir une grande SDK.
Est-ce que Android décoller? Probablement. Il ya beaucoup de téléphones Android arrivent sur le marché. Les compagnies de téléphone sans fil et l'amour des OS libres, car ils augmentent leurs marges bénéficiaires. Et, une fois suffisamment de gens commencent à posséder des téléphones Android, les gens vont vraiment commencer à écrire des applications pour les téléphones Android. Je ne pense pas que vous verrez jamais la vague de la façon dont vous avez avec le SDK de l'iPhone où les gens de tous les horizons de la vie sans aucune expérience de programmation développé un désir d'apprendre à écrire des logiciels, mais je ne pense qu'il y aura éventuellement une bon marché pour les applications Android et, par conséquent, pour les développeurs Android.
Je suis heureux de quitter ce marché à d'autres.
1 Mes excuses. Mon texte original ici auraient pu être interprété comme impliquant que l'équipe Android copié le SDK de l'iPhone, ce qui n'était pas vraiment mon intention. Je voulais dire que certaines parties ont un sens très similaires et l'utilisation des design patterns couramment utilisés dans le SDK de l'iPhone. Il est assez évident si vous avez passé du temps avec le SDK Android, qu'ils font leur propre chose et ne sont pas simplement copier l'iPhone
2 Chaque programmeur passe par cette phase, si elles collent avec la programmation assez longtemps. Si vous avez été la programmation pendant un moment et ne pense pas que vous êtes allé à travers elle, il ya une très bonne chance que vous êtes encore en elle.
Aucun commentaire:
Enregistrer un commentaire