Le Titanium affirme qu'il peut faire la même application en moyenne 70% plus rapide que Xcode natif.
Quelle est l'expérience de tous les autres en termes de différence de vitesse de développement (entre xcode natif et téléphones ou titane)?
Disons une application comme Kik Messenger ou Badoo ....
Typiquement, un bon développeur Xcode peut le faire en 4-5 semaines, en supposant que les graphiques et le backend soient en place.
Que faudrait-il pour une personne expérimentée de titane (HTML5) pour y parvenir? (grossièrement)
5 Réponses :
Si vous êtes un développeur iOS et que vous ne le développez que pour iOS Device, il est préférable de coder en utilisant Xcode. Si vous êtes plus en JavaScript et que vous développez pour Android et IOS, vous devez utiliser Titanium ou PhoneGap. Entre Titanium et PhoneGap, j'ai trouvé plus facile de coder à l'aide de titane (et oui rapidement). Mais je ne suis pas sûr de combien de valeur utilise du titane. http: // à l'aide de l'utilisation. wordpress.com/2011/06/14/whay-You-should-stay-away-de-Appelerators-titanium/
Bon lien. Je n'ai pas encore été convaincu que si vous souhaitez construire une application de haut niveau que vous bénéficiez beaucoup d'avantages des frameworks inter-plate-forme. En tout le temps que vous passez à la poursuite des petits problèmes pour obtenir une solution de dénominateur la plus bas, vous auriez pu simplement écrire deux applications indigènes à la place et elles auraient beaucoup mieux dans leurs plates-formes.
Rob, que pensez-vous d'utiliser des modèles et des bibliothèques vs natif? Stackoverflow.com/Questions/8756/...
Il y a des choses à savoir sur le titane, comme tous les autres cadres.
@ XRave3, si par "Modèles et bibliothèques" Vous voulez dire des applications Web, il n'est pas différent. Si vous ne pouvez pas accéder à l'animation de base, iCloud, la protection des données, etc., etc., vous commencez par une seule main attachée derrière votre dos sur le chemin d'une application debout.
Oui Rob, je veux dire des choses comme dans ce lien: Stackoverflow.com/Questtions/215390/...
Le temps de marché dépend de la qualité des spécifications, des processus et des personnes, bien plus que la technologie ou le cadre sous-jacent.
Codage d'une application réelle avec Appelerator Titanium n'est pas si facile et les performances d'exécution sont plus lentes que le code natif car il utilise un moteur JavaScript comme pont. Surtout avec une grande vision de la table, il est beaucoup plus plus lent et le sentiment n'est tout simplement pas pareil. Mais une fois que vous avez purgé les fuites de mémoire, le sentiment est néanmoins incroyablement meilleur qu'avec HTML5.
Vous devriez être intéressé par Titanium ou PhoneGap (maintenant connu comme Cordoue) si vous envisagez de distribuer votre application sur d'autres appareils ou si vous n'aimez vraiment pas l'objectif c.
Sinon, conservez-le avec le XCode natif.
J'ajouterais que Cordoue ne fera aucune interface utilisateur, mais vous permettra d'accéder à la caméra, à l'accéléromètre ou au GPS avec JavaScript dans le code HTML5. Vous utiliseriez probablement Sencha Touch ou Jquerymobile avec Cordoue.
Pour ajouter à cela, Titanium a récemment inclus un composant ListView qui devrait corriger la plupart des problèmes de performance liés à la composante TableView.
Vous avez dit: << Les performances d'exécution sont plus lentes que le code natif car il utilise un moteur JavaScript comme pont. >> Je pense que l'application n'utilisera pas de JavaScript sur le temps d'exécution, car JavaScript n'est utilisé que sur la phase de développement, puis L'application sera générée sur le code natif afin qu'il soit aussi rapide qu'une application développée directement avec le code natif. S'il vous plaît, quelqu'un me dit si c'est faux ou vrai.
C'est faux. JavaScript est exécuté sur les appareils. Votre application est expédiée avec un moteur JavaScript.
Dans mon expérience, si l'application n'est pas une application de modèle simple, vous serez mieux conseillé de créer une application native pour chaque plate-forme.
Comme Rob dit, essayant de surmonter la situation de dénominateur la plus faible et de surmonter les limitations dans les "solutions" de la plate-forme inter-plate-forme signifie généralement qu'il faut plus de temps que de le faire de manière native.
Vous pourriez même frapper un problème qui vous permet d'abandonner le navire et de commencer à partir de zéro comme des applications indigènes. Donc, si vous décidez d'aller un itinéraire téléphonique ou Titanium, assurez-vous de rechercher pleinement avant de commencer et que vous n'aurez pas d'exigences futures non couvertes par elles.
J'accepte vraiment: "Vous pourriez même frapper un problème qui vous entraîne d'abandonner le navire et de commencer à partir de zéro comme des applications indigènes" ..
Je suis en fait d'effectuer une enquête assez intensive de tous les grands kits de développement mobiles multi-plateformes en ce moment. J'ai commencé en faisant un exemple d'application à partir de zéro dans l'IOS qui utilise quelques fonctionnalités de l'appareil de simple, puis réimplémentées que comme une application Adroid. Ces deux ont pris environ une journée pour terminer (l'androïde a peut-être une demi-journée plus). Depuis que je ne l'ai jamais écrit une application Android avant, je pense que c'est une bonne base en termes de comparaison du temps de développement entre les divers autres cadres je tester.
Je mettrai à jour ce commentaire dans quelques semaines avec un billet de blog quand je suis fait, mais pour le moment je l'ai été de trouver que ces kits multi-plateformes sont largement plus difficile à utiliser et prendre beaucoup plus de temps, même pour les applications les plus simples. et malgré cela, il y a encore un peu de code personnalisé par périphérique qui doit être écrit pour l'interface utilisateur et les différences idiosyncrasiques fondamentales entre la façon dont fonctionnent les services de l'appareil, de sorte que vous ne vraiment pas obtenir la valeur d'une véritable « base de code unique » vous avez peut-être attendiez.
Je pense que la valeur principale de ceux-ci peuvent se révéler ne pas être tout ce qui concerne le temps de développement ou la réutilisation du code, mais seulement comme un moyen pour les non-app-développeurs de créer des prototypes simples qui peuvent ensuite être remis à la " vrais » développeurs d'applications mobiles à construire des applications en véritables autochtones après ... Pas vraiment si utile que ça, à mon avis, mais peut-être mes pensées vont changer de plonger dans cet autre.
AppCelerator n'est pas HTML5, il s'agit d'une application native intégrée dans une langue de niveau supérieur de JavaScript. Il résume la complexité des éléments communs et offre une valeur énorme, ping-moi hors ligne pour en savoir plus. Je gère notre entreprise de Californie.
Où avez-vous reçu le point de données que ces applications ont été construites en 4-5 semaines? Cela peut également valoir la peine de discuter de vos objectifs de qualité. Voulez-vous juste quelque chose qui est "ok" ou quelque chose qui est vraiment excellent et se distingue? Un grand nombre des avantages de JavaScript s'évaporent lorsque vous essayez d'aller de «assez bon si vous ne vous moquez pas trop».
Rob, je veux certainement quelque chose qui se démarque lorsqu'il est enfoncé d'un point de vue UI / UX et d'efficacité (performance de la vitesse). En ce sens, je suppose que je suppose en ce qui concerne la rapidité de développement, mais j'essaie simplement d'essayer de jauger combien de temps est en train de le faire dans Native VS ayant un codeur HTML5 expérimenté via les solutions multiples plateformes.
Pour arriver à quelque chose qui se démarque, le natif sera généralement plus rapide de vous y arriver (en supposant des compétences similaires). Ce n'est pas un revers. Native peut vous prendre légèrement plus longtemps pour arriver à V0.1, mais il est beaucoup plus rapide d'arriver à V1.0 (si v1.0 devrait être très bon). Prenant un "codeur HTML5" qui n'est pas expérimenté avec la programmation HTML5 spécifiquement pour la plate-forme mobile en question serait un revers dramatique. Le développement HTML5 de bureau n'est pas la même chose. Si tout ce que vous avez sont des développeurs HTML5, ils se développeront évidemment dans HTML5 plus rapidement qu'ils ne leur développeraient.
BTW, tout développement multiplateforme a ce problème. C'est très difficile et prend du temps pour construire une application Web qui fonctionne vraiment bien sur tous les navigateurs. Juste parce que c'est HTML5 ne fait pas de plate-forme croisée facile. Il y a toujours beaucoup de hacks par plate-forme requis. Même sans plate-forme X, il est difficile de rendre les applications Web aussi bonnes que natif sur n'importe quelle plate-forme. Comparez le mot natif à la version Web sur Live.com. Même lorsque OWA était seulement - seulement, le meilleur qu'il pourrait faire était "bon pour une application Web" par rapport aux perspectives autochtones. Il y a des raisons de faire des applications Web bien sûr, mais il ne s'agit pas d'obtenir le meilleur UX possible.
@ Rob - juste hors de curiosité, qu'est-ce que le titane signifie qu'il en fait une moyenne de 70% de développement rapide que le codage natif? (En plus de l'intention des relations publiques) Y a-t-il une légitimité derrière cela? Peut-être juste pour v0.1 comme vous l'avez mentionné ci-dessus
Je n'ai aucune idée d'où ils obtiennent cela. Je soupçonne qu'ils veulent dire "pour une application qui veut un UX qui correspond exactement à ce que le titane fait bien." Vous pouvez construire probablement une vue simple de la table de forage avec le backend de repos très rapidement dans Titanium; Mais je devine. Il est toujours difficile de deviner quelle copie annonce signifie réellement: D