Je suis tombé sur cet article sur le développement Android aujourd'hui, et ce fut une lecture très intéressante. L'auteur a donné un look très équilibré à la plateforme Android, en disant ce qu'il pensait être bon et mauvais. Il se lit comme une évaluation très honnête. Je n'ai pas de détecter toute spin évident.
Le seul domaine où je ne suis d'accord avec l'auteur est sa déclaration sur Android Intent/Activity modèle. Ce message prétend que Android est "un grand pas en avance sur le modèle de programmation iPhone actuel», mais je ne peux pas m'empêcher d'être rappelé OpenDoc and CyberDog. Cette idée de se "loin de monolithique, les applications isolées» n'est pas nouvelle, elle a été flottant autour d'au moins depuis les années 1990. Si vous regardez théoriques, plutôt que des applications pratiques, il remonte sans doute beaucoup plus loin, même.
Pourtant, nous voici en 2009 encore en utilisant des applications monolithiques.
Oh, attendez, ne nous sont pas. Pas vraiment.
Quand j'écris une application iPhone, la plupart des fonctionnalités que j'utilise n'a pas été écrit par moi et ne fait pas partie de ma demande. Il fait partie d'un cadre qui est déjà sur le téléphone. Je pense que le temps a montré que le contenu axé manière (ou, en intention de concentré, si vous voulez) de diviser le code est au mieux problématique. C'est formidable en théorie, mais difficile en pratique.
Dans l'exemple dans le blogue, comment puis-je savoir si cette application de codes à barres est installé? Que dois-je faire si ce n'est pas? Cette approche ouvre un grand nombre de problèmes avec les tests, l'installation et le développement qui a compensé une partie des gains que vous obtenez de ne pas avoir de code dupliqué. Les problèmes de l'intention / l'activité sont encore plus prononcés sur une plateforme ouverte comme Android où l'utilisateur a beaucoup de flexibilité en termes de comment ils le configurer et d'installer ce qu'ils dessus.
Ce concept a également fait juste pas vraiment correspondre au modèle d'applications mobiles très bien. L'iPhone n'est pas un ordinateur à usage général, et aucun des deux n'est un téléphone Android. Si vous regardez la population générale des consommateurs utilisant des téléphones intelligents, leur façon d'utiliser le téléphone que la grande majorité du temps ne se prête pas vraiment à ce concept à tous. Ils utilisent et s'attendent à de petites applications pour servir une définition, le but fini.
Si vous construisez des applications mégalithiques pour un téléphone intelligent, vous êtes (tout simplement) le fais mal, et si vous n'êtes pas, vous n'allez pas obtenir tout ce que beaucoup bénéficier d'intention / Activité, et vous allez à payer un prix dans la complexité ajoutée au processus de développement et le processus d'installation, pour ne pas mentionner qui augmente considérablement la probabilité de problèmes pour vos clients.
Cela ne veut pas dire que l'iPhone ne pouvait pas utiliser une certaine amélioration dans l'arène de la communication inter-applications. Nous avons actuellement la possibilité d'enregistrer des URL d'application, mais c'est un voyage à sens unique. Je peux lancer une application de codes à barres, mais je ne peux pas dire au programme de codes à barres pour m'envoyer rien en retour sauf si je contrôle les deux applications. En réalité, je ne suis pas sûr quelle taille d'une limitation c'est vraiment, cependant. La plupart du temps, nous n'allons pas à vouloir s'appuyer sur les fonctionnalités d'une autre application pour gérer une tâche importante application à moins que l'autre application est celle que nous avons écrit et contrôle. Si c'est le cas, alors nous avons accès au code source et peut inclure la fonctionnalité dans l'application et la rendre autonome, ce qui réduit considérablement les chances que nos clients ont des problèmes et en colère contre nous.
Le seul domaine où je ne suis d'accord avec l'auteur est sa déclaration sur Android Intent/Activity modèle. Ce message prétend que Android est "un grand pas en avance sur le modèle de programmation iPhone actuel», mais je ne peux pas m'empêcher d'être rappelé OpenDoc and CyberDog. Cette idée de se "loin de monolithique, les applications isolées» n'est pas nouvelle, elle a été flottant autour d'au moins depuis les années 1990. Si vous regardez théoriques, plutôt que des applications pratiques, il remonte sans doute beaucoup plus loin, même.
Pourtant, nous voici en 2009 encore en utilisant des applications monolithiques.
Oh, attendez, ne nous sont pas. Pas vraiment.
Quand j'écris une application iPhone, la plupart des fonctionnalités que j'utilise n'a pas été écrit par moi et ne fait pas partie de ma demande. Il fait partie d'un cadre qui est déjà sur le téléphone. Je pense que le temps a montré que le contenu axé manière (ou, en intention de concentré, si vous voulez) de diviser le code est au mieux problématique. C'est formidable en théorie, mais difficile en pratique.
Dans l'exemple dans le blogue, comment puis-je savoir si cette application de codes à barres est installé? Que dois-je faire si ce n'est pas? Cette approche ouvre un grand nombre de problèmes avec les tests, l'installation et le développement qui a compensé une partie des gains que vous obtenez de ne pas avoir de code dupliqué. Les problèmes de l'intention / l'activité sont encore plus prononcés sur une plateforme ouverte comme Android où l'utilisateur a beaucoup de flexibilité en termes de comment ils le configurer et d'installer ce qu'ils dessus.
Ce concept a également fait juste pas vraiment correspondre au modèle d'applications mobiles très bien. L'iPhone n'est pas un ordinateur à usage général, et aucun des deux n'est un téléphone Android. Si vous regardez la population générale des consommateurs utilisant des téléphones intelligents, leur façon d'utiliser le téléphone que la grande majorité du temps ne se prête pas vraiment à ce concept à tous. Ils utilisent et s'attendent à de petites applications pour servir une définition, le but fini.
Si vous construisez des applications mégalithiques pour un téléphone intelligent, vous êtes (tout simplement) le fais mal, et si vous n'êtes pas, vous n'allez pas obtenir tout ce que beaucoup bénéficier d'intention / Activité, et vous allez à payer un prix dans la complexité ajoutée au processus de développement et le processus d'installation, pour ne pas mentionner qui augmente considérablement la probabilité de problèmes pour vos clients.
Cela ne veut pas dire que l'iPhone ne pouvait pas utiliser une certaine amélioration dans l'arène de la communication inter-applications. Nous avons actuellement la possibilité d'enregistrer des URL d'application, mais c'est un voyage à sens unique. Je peux lancer une application de codes à barres, mais je ne peux pas dire au programme de codes à barres pour m'envoyer rien en retour sauf si je contrôle les deux applications. En réalité, je ne suis pas sûr quelle taille d'une limitation c'est vraiment, cependant. La plupart du temps, nous n'allons pas à vouloir s'appuyer sur les fonctionnalités d'une autre application pour gérer une tâche importante application à moins que l'autre application est celle que nous avons écrit et contrôle. Si c'est le cas, alors nous avons accès au code source et peut inclure la fonctionnalité dans l'application et la rendre autonome, ce qui réduit considérablement les chances que nos clients ont des problèmes et en colère contre nous.
Aucun commentaire:
Enregistrer un commentaire