Comparaison entre Corona, Phonegap, Titanium
Je suis un développeur Web et je souhaite transférer mes produits Web sur iPhone. L'un des produits ressemble à Google Maps: affichez la carte sur l'écran du téléphone, vous pouvez faire glisser ou redimensionner la carte et afficher certaines informations que nous ajoutons à la carte.
Je sais que certaines technologies vous permettent d’utiliser HTML, CSS et Javascript pour développer des applications iPhone natives. J'ai identifié quelques-uns:
Existe-t-il d'autres produits similaires? Quelles sont les différences entre eux? Lequel devrais-je choisir?
Je me suis inscrit à stackoverflow uniquement dans le but de commenter la réponse majoritairement votée. Le problème, c'est que stackoverflow ne permet pas aux nouveaux membres de poster des commentaires. Je dois donc faire en sorte que ce commentaire ressemble davantage à une réponse.
La réponse de Rory Blyth contient des points valables sur les deux frameworks mobiles javascript. Cependant, ses points clés sont incorrects. La vérité est que Titanium et PhoneGap sont plus similaires que différents. Ils exposent tous les deux les fonctions du téléphone mobile via un ensemble d’API javascript. La logique de l’application (html, css, javascript) s’exécute dans un contrôle WebView natif.
PhoneGap n'est pas simplement un wrapper natif d'une application Web. Grâce aux API javascript de PhoneGap, "l'application Web" a accès aux fonctions du téléphone mobile telles que la géolocalisation, l'appareil photo accéléromètre, les contacts, la base de données, le système de fichiers, etc. En gros, toute fonction fournie par le SDK du téléphone monde javascript. D'autre part, une application Web normale qui s'exécute sur le navigateur Web mobile n'a pas accès à la plupart de ces fonctions (la sécurité étant la raison principale). Par conséquent, une application PhoneGap est davantage une application mobile qu'une application Web. Vous pouvez certainement utiliser PhoneGap pour envelopper une application Web qui n’utilise aucune API PhoneGap, mais ce n’est pas la raison pour laquelle PhoneGap a été créé.
Titanium NE compile PAS votre code html, css ou javascript en "bits natifs". Ils sont regroupés en tant que ressources dans le groupe d'exécutables, un peu comme un fichier image incorporé. Lorsque l'application est exécutée, ces ressources sont chargées dans un contrôle UIWebView et y sont exécutées (en javascript, pas en bits natifs, bien sûr). Il n'existe pas de compilateur javascript-native-code (ou to-objective-c). Cela se fait de la même manière dans PhoneGap. Du point de vue architectural, ces deux cadres sont très similaires.
Maintenant, sont-ils différents? Oui. Premièrement, Titanium semble être plus riche en fonctionnalités que PhoneGap, car il relie davantage de fonctions de téléphonie mobile à javascript. Surtout, PhoneGap n'expose pas beaucoup (le cas échéant) de composants d'interface utilisateur natifs à javascript. Titanium, quant à lui, dispose d'une API d'interface utilisateur complète qui peut être appelée en javascript pour créer et contrôler tous types de contrôles d'interface utilisateur natifs. En utilisant ces API d'interface utilisateur, une application Titanium peut sembler plus "native" qu'une application PhoneGap. Deuxièmement, PhoneGap prend en charge davantage de plateformes de téléphonie mobile que Titanium. Les API PhoneGap sont plus génériques et peuvent être utilisées sur différentes plates-formes telles que iPhone, Android, Blackberry, Symbian, etc. Titanium cible principalement l'iPhone et Android au moins pour le moment. Certaines de ses API sont spécifiques à la plate-forme (comme les API d'interface utilisateur iPhone). L'utilisation de ces API réduira la capacité multiplate-forme de votre application.
Donc, si votre préoccupation pour votre application est de la rendre plus "native", Titanium est un meilleur choix. Si vous souhaitez "transférer" votre application sur une autre plate-forme plus facilement, PhoneGap sera meilleur.
Mise à jour le 13/08/2010: Lien vers la réponse d'un employé de Titanium à la question de Mickey.
Mise à jour le 12/04/2010: J'ai décidé de donner à cette publication une revue annuelle pour tenir ses informations à jour. Beaucoup de choses ont changé en une année, ce qui a rendu certaines informations du post initial obsolètes.
Le plus gros changement est venu de Titanium. Plus tôt cette année, Appcelerator a publié Titanium 1.0, qui s’est radicalement écarté de ses versions précédentes du point de vue de l’architecture. Dans la version 1.0, le contrôle UIWebView n'est plus utilisé. Au lieu de cela, vous appelez les API Titanium pour toutes les fonctions de l'interface utilisateur. Ce changement a deux conséquences:
Votre interface utilisateur devient complètement native. Il n'y a plus d'interface utilisateur Web dans votre application, car les API natives Titanium prennent le contrôle de tous vos besoins d'interface utilisateur. Titanium mérite beaucoup de crédit pour avoir été un pionnier dans le domaine des "interfaces utilisateur natives multi-plateformes". Cela donne aux programmeurs qui préfèrent l'aspect et la convivialité de l'interface utilisateur native mais qui n'aiment pas le langage de programmation officiel une alternative.
Vous ne pourrez pas utiliser HTML ou CSS dans votre application, la vue Web ayant disparu. (Remarque: vous pouvez toujours créer une vue Web dans Titanium. Toutefois, il existe quelques fonctionnalités de Titanium dont vous pouvez tirer parti dans la vue Web.) Questions et réponses sur Titanium: que sont devenues HTML et CSS?
Vous ne pourrez pas utiliser les bibliothèques JS populaires telles que JQuery qui supposent l'existence d'un objet DOM. Vous continuez à utiliser JavaScript comme langage de programmation. Mais c’est à peu près la seule technologie Web que vous pouvez utiliser si vous venez à Titanium 1.0 en tant que programmeur Web.
Vidéo Titanium: Quoi de neuf dans Titanium 1.0.
Maintenant, Titanium 1.0 compile-t-il votre JavaScript en "bits natifs"? Non. Appcelerator a enfin réglé ce problème en publiant ce blog de développeur: Projet Titanium Guides: JS Environment. Nous, programmeurs, sommes plus authentiques que ceux du service Marketing, n'est-ce pas? :-)
Passez à PhoneGap. Il n'y a pas beaucoup de nouvelles choses à dire sur PhoneGap. Ma perception est que le développement de PhoneGap n’était pas très actif jusqu’à ce que IBM se lance plus tard cette année. Certaines personnes ont même soutenu qu'IBM fournissait plus de code à PhoneGap que Nitobi. Que cela soit vrai ou non, il est bon de savoir que PhoneGap est en cours de développement.
PhoneGap continue de se baser sur les technologies Web, à savoir HTML, CSS et JavaScript. Il ne semble pas que PhoneGap ait l'intention de relier les fonctionnalités de l'interface utilisateur native à JavaScript, comme le fait Titanium. Bien que l'interface utilisateur Web soit toujours à la traîne par rapport à l'interface utilisateur native en termes de performances et d'apparence native, cet écart est en train d'être rapidement comblé. Les technologies Web offrent deux tendances en termes de performances:
Moteur JavaScript passant d'un interprète à une machine virtuelle. JavaScript est compilé JIT en code natif pour une exécution plus rapide. moteur Safari JS: SquirrelFish Extreme
Le rendu des pages Web est passé de l'utilisation du processeur à l'utilisation de l'accélération GPU. Les tâches graphiques intensives telles que la transition de page et l'animation 3D deviennent beaucoup plus fluides avec l'aide de l'accélération matérielle. composition accélérée par GPU dans Chrome
Les améliorations apportées par les navigateurs de bureau sont rapidement transmises aux navigateurs mobiles. En fait, depuis iOS 3.2 et Android 2.0, le contrôle de la vue sur le Web mobile est devenu beaucoup plus performant et plus convivial avec HTML5. L’avenir du Web mobile est tellement prometteur qu’il a attiré un grand enfant en ville: JQuery a récemment annoncé son infrastructure Web mobile. Avec JQuery Mobile fournissant des gadgets d’interface utilisateur et PhoneGap fournissant des fonctionnalités de téléphonie, crée une plate-forme Web mobile parfaite à mon avis.
Je devrais également mentionner Sencha Touch comme un autre cadre de gadget d’interface utilisateur Web mobile. La version 1.0 de Sencha Touch a récemment été publiée sous un modèle de double licence incluant la GPLv3. Tout comme JQuery Mobile, Sencha Touch fonctionne bien avec PhoneGap.
Si vous êtes un GWT programmeur (comme moi), vous pouvez consulter GWT Mobile , un projet open source permettant de créer des applications Web mobiles avec GWT. Il comprend un wrapper PhoneGap GWT qui permet d’utiliser PhoneGap dans GWT.
D'après ce que j'ai recueilli, voici quelques différences entre les deux:
PhoneGap génère essentiellement des wrappers natifs pour ce qui reste des applications Web . Il crache un projet WhateverYourPlatformIs, vous le construisez et le déployez. Si nous parlons de l’iPhone (c’est là que je passe mon temps), cela ne semble pas très différent de créer un lanceur d’applications Web (un raccourci qui a sa propre icône Springboard, vous pouvez donc le lancer comme comme une application native). L '"application" elle-même est toujours HTML/JS/etc. Et s'exécute dans un contrôle de navigateur hébergé. Ce que PhoneGap propose au-delà, c'est un pont entre JavaScript et les API de périphérique natif. Donc, vous écrivez JavaScript contre les API PhoneGap, puis PhoneGap effectue l'appel natif correspondant. À cet égard, est différent du déploiement d'une vieille application Web ordinaire.
Les sources Titanium sont compilées en bits natifs. C’est-à-dire, votre html/js/etc. ne sont pas simplement attachés à un projet puis hébergés dans un contrôle de navigateur Web - ils sont transformés en applications natives. Cela signifie, par exemple, que l'interface de votre application sera composée de composants de l'interface utilisateur natifs . Il existe des moyens d'obtenir une apparence et une sensation natives sans avoir une application native, mais ... eh bien ... quel cauchemar qui se révèle généralement être.
Les deux sont similaires en ce sens que vous écrivez tous vos documents en utilisant les technologies Web classiques (html/js/css/blah blah blah) et que vous avez accès à des fonctionnalités natives via des API JavaScript personnalisées.
Mais, encore une fois, les applications PhoneGap (PhonGapps? Je ne sais pas ... est-ce un nom stupide? C'est plus facile à dire - je le sais très bien) commencent leur vie en tant qu'applications Web et finissent leur vie en tant qu'applications Web. Sur l'iPhone, votre html/js/etc. est simplement exécuté dans un contrôle UIWebView et les API PhoneGap JavaScript que vos appels js sont routées vers des API natives.
Les applications Titanium deviennent des applications natives. Elles sont simplement développées à l'aide de la technologie de développement Web.
Qu'est-ce que cela signifie réellement ?
Une application Titanium ressemblera à une "vraie" application car, finalement, elle est une "vraie" application.
Une application PhoneGap ressemblera à une application Web hébergée dans un contrôle de navigateur car, en fin de compte, elle est une application Web hébergée dans un contrôle de navigateur.
Lequel est exact pour toi?
Si vous souhaitez écrire des applications natives à l'aide de compétences en développement Web, Titanium est votre meilleur choix.
Si vous souhaitez créer une application utilisant des compétences en développement Web que vous pouvez déployer de manière réaliste sur plusieurs plates-formes (iPhone, Android, Blackberry et tout ce qu’elles décident d’inclure), et si vous souhaitez accéder à un sous-ensemble de fonctionnalités de plate-forme native (GPS, accéléromètre, etc.) via une API JavaScript unifiée, PhoneGap est probablement ce que vous voulez.
Vous vous demandez peut-être pourquoi je voudrais écrire un PhoneGapp (j'ai décidé d'utiliser le nom) plutôt qu'une application Web hébergée sur le Web. Ne puis-je toujours pas accéder à certaines fonctionnalités de l'appareil natif de cette manière, mais aussi bénéficier du vrai déploiement Web plutôt que d'obliger l'utilisateur à télécharger mon application "native" et à l'installer?
La réponse est: Parce que vous pouvez soumettre votre PhoneGapp à l'App Store et le facturer. Vous obtenez également cette icône de lanceur, ce qui empêche l’utilisateur d’oublier votre application (il est beaucoup plus probable que j’oublie un signet qu’une icône de l’application).
Vous pourriez certainement faire payer l'accès à votre application Web hébergée sur le Web, mais combien de personnes vont vraiment suivre le processus pour le faire? Avec l'App Store, je choisis une application, touchez le bouton "Acheter", entrez un mot de passe et tout est fait. Il installe. Quelques secondes plus tard, je l'utilise. Si je devais utiliser l'interface unique de transaction Web mobile de quelqu'un d'autre, ce qui impliquerait probablement de saisir mon nom, mon adresse, mon numéro de téléphone, mon numéro de téléphone et d'autres éléments que je ne souhaite pas utiliser, je ne voudrais certainement pas. pas passer par là. En outre, j’ai confiance en Apple - Je suis persuadé que Steve Jobs ne va pas enregistrer mes informations et ne pas facturer une série d’abonnements de magazines coquins à mon CC pour des coups de pied.
Quoi qu'il en soit, hormis le fait que la technologie de développement Web est impliquée, PhoneGap et Titanium sont très différents, au point de n'être que superficiellement comparables.
Je déteste les applications Web, à propos, et si vous lisez les critiques iTunes App Store, les utilisateurs sont plutôt doués pour les repérer. Je ne nommerai aucun nom, mais j'ai plusieurs "applications" sur mon téléphone qui ressemblent et fonctionnent à la poubelle, et ce parce qu'elles sont hébergées dans des instances UIWebView. Si je voulais utiliser une application Web, j'ouvrirais Safari et, vous le savez, j'allais y accéder. J'ai acheté un iPhone parce que je veux des choses qui sont iPhone-y. Je n'ai aucun problème à utiliser, par exemple, une application Web Google élégante dans Safari, mais je me sentirais trompé si Google insérait un signet dans Springboard en présentant une application Web en tant que application native.
Dois y aller maintenant. Ma copine a ce visage qui pourrait, s'il vous plaît, cesser d'utiliser son ordinateur pendant trois secondes.
Je suis un cours sur le développement Android/iPhone et nous avons passé 8 semaines avec Titanium (pas à temps plein) (la version était Titanium 1.4.2 et le temps tournait autour de novembre 2010). Voici mon expérience.
iPhone Android double ciblage
Même si les guides de l'API affirment que la fonctionnalité est disponible pour Android et pour iPhone, ce n'est pas le cas. Une grande partie du matériel ne fonctionne tout simplement pas sur l'une des plates-formes. Certaines choses fonctionnent différemment.
Un grand nombre de personnes de la classe ont déjà créé des applications iPhone et ne peuvent pas les faire fonctionner sur Android sans réécriture majeure. J'ai développé une application simple pour enfants appelée Animap (voir Android market/Appstore en Suède) et j'ai commencé à développer des logiciels sous Windows. Une fois que la cible Android fonctionnait, j'ai ouvert le projet sous OS X. Il ne montre aucun élément de construction pour iPhone, uniquement pour Android. Vous devez démarrer un projet à double cible sous OS X. (D'accord, j'ai copié les fichiers pertinents dans un nouveau projet). Problème suivant - les animations ne fonctionnent pas sur iPhone (elles fonctionnent sur Android). Les événements de défilement ne fonctionnent pas de la même façon sur l'iPhone. (c.-à-d. sur Android, vous obtenez l'événement d'annulation lorsque l'utilisateur arrête de faire défiler l'écran et libère son doigt de l'écran, cela ne se produit pas sur l'iPhone).
Comme cela n’est pas mentionné quelque part, vous devez en principe faire de la programmation par essais et erreurs sur une première plate-forme, puis sur l’autre. Par essais et erreurs, je veux dire qu’il faudra environ deux jours pour obtenir une application aussi simple que Animap fonctionnant sur l’autre plate-forme. Vous devrez également avoir si (Android) alors ... ou si (iphone) ... dans tout votre code ...
Télécharger et configurer
Vous devez suivre les instructions à la lettre. N'essayez pas d'utiliser Java 64 bits. Il ne compilera pas l'application de démonstration KitchenSink 1.4.0. (1.3 fonctionne correctement!) Vous devez placer les fichiers directement sur le lecteur C, car les noms de chemin longs feront que le programme externe ne recevra pas tous les paramètres de ligne de commande s’ils deviennent trop longs. (Très bien pour les petits programmes) 1/3 des fois, la chaîne d’outils s’arrête tout simplement et vous devez appuyer à nouveau sur 'lancer'. Ensuite, cela fonctionnera probablement… très peu fiable. Le simulateur ne sera pas trouvé au démarrage et vous devrez alors simplement tuer adb.exe avec Ctrl + Alt + Suppr et réessayer.
Connexion réseau
Sur un réseau Wi-Fi, la connexion en direct est parfois perdue et Titanium se bloque (interface de compilation/déploiement). Si vous ne disposez pas d'une connexion Internet fonctionnelle, elle ne démarrera pas car elle ne peut pas vous connecter à leurs serveurs.
API
CSS, HTML et jQuery est un jeu d'enfant par rapport à cela. Titanium ressemble à n'importe quelle ancienne API graphique et vous devez définir des propriétés pour chaque bouton/champ/etc. Se tromper de terrain est trop facile, vous vous souvenez de toutes les propriétés à définir? Avez-vous épelé avec des lettres majuscules au bon endroit? (comme ceci n'est pas attrapé par le compilateur, mais sera vu comme une erreur d'exécution si vous avez la chance de tester cette partie)
Dans Titanium, les choses se cassent tout simplement lorsque vous ajoutez une autre vue au-dessus d'un contrôle ou que vous cliquez ailleurs dans l'interface graphique.
Documentation
Plusieurs pages de l'API portent le symbole Android, mais ne renverront un null que lorsque vous essayez de créer le contrôle. Ils ne sont pas simplement disponibles sur la plate-forme Android malgré les symboles. Parfois, Android mentionne de ne pas prendre en charge une méthode particulière, mais alors l’API complète est manquante.
Évier de cuisine
L'application de démonstration. Ai-je mentionné qu'il ne compile pas si vous le mettez dans votre dossier de projet Eclipse parce que le chemin devient trop long? Doit être mis sur votre lecteur C dans le dossier racine. J'utilise actuellement un lien symbolik (mklink/J ...)
Méthodes non documentées
Vous devez utiliser probablement des éléments tels que label.setText ('Hello World') pour modifier une étiquette fiable, mais cela n’est pas du tout documenté.
Débogage
Titanium.API.info ('Les impressions sont le seul moyen de déboguer');
Édition
Les API ne sont pas disponibles dans un format correct. Vous ne pouvez donc pas obtenir une complétion de code ordinaire avec de l’aide, etc. dans Eclipse. Aptana s'il vous plaît aider!
Matériel
Il semble que le compilateur/les outils ne soient pas multithreads, donc un ordinateur rapide avec un disque dur rapide est indispensable, car vous devez faire beaucoup d'essais et d'erreurs. Ai-je mentionné la mauvaise documentation? Vous devez tout essayer, vous ne pouvez pas vous y fier!
Des choses positives
- Open source
Des projets précédents, je me suis promis de ne plus jamais utiliser une source fermée, car il est impossible de réparer les choses simplement en consacrant des heures et de la main-d'œuvre. Important lorsque vous êtes en retard dans le projet et que vous devez livrer dans des délais serrés. Ceci est open source et j'ai pu voir pourquoi la chaîne d'outils se casse et le réparer également.
Bugdatabase
C'est aussi ouvert. Vous pouvez simplement voir que vous n'êtes pas seul et faire une solution de contournement au lieu de 4 heures supplémentaires d'essais et d'erreurs.
Communauté
- Semble être actif sur leurs forums.
Bogues
- Titanium 1.4 n'est pas threadsafe. Cela signifie que si vous utilisez des threads (utilisez la propriété url: dans un appel de createWindow) et que vous programmez comme si les threads fonctionnaient et que vous envoyiez des événements avec des données dans les deux sens, vous rencontriez de nombreux problèmes très étranges - gestionnaires perdus, perdus fenêtres, trop d’événements, trop peu d’événements, etc., etc. Tout dépend du timing, le fait de placer les lignes de code dans un ordre différent peut planter ou guérir votre application. L'ajout d'une fenêtre dans un autre fichier.js interrompt l'exécution de votre application.js ... Cela supprime également les infrastructures de données internes dans Titanium, car ils peuvent parfois mettre à jour les infrastructures de données internes de manière parallèle, écrasant ainsi une valeur modifiée.
Une grande partie des problèmes que j'ai rencontrés avec Titanium provient de mon expérience de systèmes en temps réel comme OSE, qui prennent en charge des centaines de threads, d'événements et de messages. Ceci est supposé fonctionner dans Titanium 1.4 mais ne le fait tout simplement pas de manière fiable.
Javascript (ce qui est nouveau pour moi) meurt en silence suite à des erreurs d'exécution. Cela signifie également que les petits bugs courants, tels que l'orthographe d'un nom de variable ou la lecture dans un pointeur nul, ne se bloque pas lorsqu'il le devrait, vous pouvez donc le déboguer. Certaines parties de votre programme cessent simplement de fonctionner, par exemple un gestionnaire d’événements, car vous avez mal placé/mal saisi un caractère.
Ensuite, nous avons plus de bogues simples dans Titanium, comme certains paramètres ne fonctionnant pas dans les fonctions (ce qui est assez courant sur la plate-forme Android au moins).
Vitesse du cycle de débogage d'essai et d'erreur Après avoir exécuté Titnium Developer sur plusieurs ordinateurs, j'ai remarqué que le goulot d'étranglement est le disque dur. Un disque SSD sur un ordinateur portable rend le cycle de construction environ 3 à 5 fois plus rapide que sur un disque à 4200 tr/min. Sur un ordinateur de bureau, le fait de disposer de deux disques en RAID 1 (mode de répartition) accélère la construction d’environ 25 pour cent par rapport à un disque unique doté d’un processeur un peu plus rapide, et bat également le portable SSD.
Sommaire
- D'après les commentaires dans ce fil, il semble y avoir une bataille pour le nombre de plates-formes qu'un outil comme celui-ci peut fournir des applications. Le nombre d’API semble être le principal argument de vente.
Cela brille beaucoup lorsque vous commencez à l'utiliser. Si vous regardez le bugtracker ouvert, vous voyez que le nombre de bogues continue à augmenter plus rapidement que le nombre de bogues corrigés. C'est généralement un signe que les développeurs continuent d'ajouter de nouvelles fonctionnalités plutôt que de se concentrer sur la réduction du nombre de bogues.
En tant que consultant essayant de fournir des applications plutôt simples pour multiplier les plates-formes pour un client, je ne suis pas sûr que ce soit en fait plus rapide que de développer des applications natives sur deux plates-formes. Cela est dû au fait que lorsque vous êtes au courant, vous êtes rapide avec Titanium, mais soudainement, vous regardez en bas et vous vous retrouvez dans un trou si profond que vous ne savez pas combien d'heures doivent être consacrées à une solution de contournement. Vous pouvez simplement NE PAS promettre une certaine fonctionnalité pour une certaine date/heure/coût.
À propos de moi: J'utilise Python depuis deux ans avec wxPython. (Cette interface graphique est inconsciente, mais ne casse jamais comme ça. Cela pourrait être moi qui n'ai pas compris le modèle de thread utilisé par Javascript et Titanium, mais je ne suis pas seul en raison de leurs forums de discussion ouverts, les objets de l'interface graphique utilisent soudainement le mauvais contexte/pas de mise à jour .. ???) Avant cela, j'ai une formation en programmation C et ASM pour appareils mobiles.
[modifier - ajouté une partie avec des bugs et ne pas être thread-safe] [Modifier - maintenant avoir travaillé avec elle pendant un mois +, principalement sur PC mais aussi sur OS X également. Ajout du ciblage iPhone et Android. Vitesse du cycle de débogage d'essai et d'erreur ajoutée.]
Corona SDK (Ansca Mobile) utilise Lua comme langage de codage. Voir lua.org pour plus d'informations sur Lua.
Bien que nous prévoyions d’intégrer davantage d’intégration Web et d’éléments d’interface utilisateur native, nous nous intéresserons généralement aux applications gourmandes en ressources graphiques, telles que le développement de jeux, par opposition aux technologies basées sur le Web. En d'autres termes, nous n'envisageons pas que les utilisateurs écrivent entièrement les applications Corona en Javascript/HTML/CSS.
Je travaille avec Titanium depuis plus d’une semaine maintenant et j’ai une bonne impression de ses faiblesses.
1) Si vous espérez utiliser le même code sur plusieurs plates-formes, bonne chance! Vous verrez quelque chose comme backgroundGradient et serez émerveillé jusqu'à ce que vous découvriez que la version de Android ne le prend pas en charge. Il faut ensuite revenir à l’utilisation d’une image en dégradé, mais aussi bien l’utiliser pour les deux versions afin de rendre le code plus simple, non?
2) De nombreux comportements étranges, sur le Titanium Android sdk, vous devez comprendre ce qu’est une fenêtre "lourde" qui sert simplement à faire fonctionner le bouton Précédent, voire à un meilleur suivi des événements d’orientation. Ce n'est pas ainsi que la plate-forme Android, mais comment Titanium essaie de faire fonctionner leur API.
3) votre jeté dans le noir, les choses vont planter et vous devez commencer à commenter le code et puis quand vous le trouvez, ne l'utilisez jamais. Certains bugs évidents, tels que l'orientation et les pourcentages sur Android, posent problème depuis plus de six mois.
4) Bugs .... il y a beaucoup de bugs et ils seront rapportés, rester assis pendant des mois, être corrigés dans quelques jours. Je suis surpris qu'ils envisagent même de sortir un sdk pour mobile black berry alors qu'il y a tant d'autres problèmes avec Android.
5) Titanium Iphone et Titanium Android les moteurs javascript sont complètement différents. Sur la version Android, vous pouvez télécharger des fichiers JavaScript à distance, inclure et utiliser des bibliothèques telles que mootools, jquery, etc. J'étais au paradis quand j'ai découvert cela parce que je n'avais pas besoin de continuer à compiler mon application Android. Le processus d'installation de Android apk prend si longtemps! Iphone rien de tout cela n'est possible, la version iphone a aussi un moteur javascript bien plus rapide.
Si vous restez loin de nombreuses parties de l'interface utilisateur native, utilisez plutôt setInterval pour détecter les changements d'orientation, coller aux images en dégradé, oublier le bouton Précédent, créer vos propres animations, oublier l'en-tête de fenêtre, les barres d'outils et le tableau de bord. Vous pouvez vraiment faire une API qui fonctionne sur les deux qui ne nécessite pas beaucoup de réécriture. Mais sur ce point, il est tout aussi lent qu'une webapp.
Alors ça vaut le coup? Après toute la douleur, ça vaut chaque minute. Vous pouvez faire abstraction de la logique et créer simplement une interface utilisateur différente pour chacun plutôt que si vous le souhaitez partout. Le titane vous permet de faire des applications fluides et rapides. Vous perdez les puissantes capacités de mise en page de chaque plate-forme, mais si vous pensez simple, les choses peuvent être faites dans une seule langue.
Pourquoi pas une application web? Sur le marché des ordinateurs d'entrée de gamme Android, il est extrêmement lent à générer une vue Web et consomme beaucoup de mémoire que vous pourriez utiliser pour effectuer une logique plus complexe.
Voici une analyse plus récente et plus approfondie d’Appcelerator et de PhoneGap: http://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap
Et voici encore plus de détails sur la façon dont ils diffèrent par programme: http://savagelook.com/blog/portfolio/phonegap-is-web-based-appcelerator-is-pure-javascript
mapkit natif est supporté dans Titanium
Faire des widgets HTML5 qui ressemblent à des widgets iphone est une chose, mais les faire fonctionner aussi bien est un autre problème. Performances des animations html5 (même les transitions entre vues), défilement de longues listes, réactivité aux gestes, sensation collante et saccadée. Un utilisateur d'iPhone remarquera la différence.
Il existe également des différences dans les types de gestes pris en charge par différents périphériques, ce qui entraîne également des problèmes de code et d'ergonomie spécifiques à la plate-forme.
Je vais rester avec les applications natives pour le moment je suppose.
Rhomobile Rhodes ( http://rhomobile.com/products/rhodes ) a une approche très similaire de PhoneGap, mais constitue le seul cadre avec:
- un modèle de contrôleur de vue de modèle (comme le prévoient la plupart des frameworks Web)
- un gestionnaire relationnel d'objet
- support pour tous les smartphones populaires (y compris Windows Phone 7)
- un service de développement hébergé (pas seulement une version hébergée): http://rhohub.com
- un débogueur complet et un émulateur sans SDK dans l'IDE RhoStudio
- prise en charge des données hors ligne synchronisées
Pour tous ceux qui s'intéressent à Titanium, je dois dire qu’ils n’ont pas une très bonne documentation. Certaines classes, propriétés et méthodes manquent. Mais beaucoup est "documenté" dans leur exemple d'application, le KitchenSink, donc ce n'est pas si mal que ça.
D'après ma compréhension de PhoneGap, ils fournissent des API Javascript à la plupart des API iPhone.
Titanium semble plus facile pour un contexte de développeur Web. C'est un simple fichier XML pour créer une application TabView de base, puis tout dans la zone de contenu est contrôlé par HTML/JS. Je sais également que Titanium fournit un accès javascript à certains des frameworks (en particulier l’accès aux informations de localisation, à l’identifiant du téléphone, etc.).
MISE À JOUR: Titanium a ajouté Maps API dans la version 0.8 de son framework.
Vous devriez apprendre Objective C et programmer des applications natives. Ne comptez pas sur ces choses qui, à votre avis, faciliteront la vie. Apple s'est assuré que le moyen le plus simple consiste à utiliser ses outils et son langage natifs. Pour vos 100 lignes de javascript, je peux faire la même chose en 3 lignes de code ou pas de code du tout en fonction de l'élément. Regardez des tutoriels - si vous comprenez le javascript, alors Objective C n’est pas difficile. Les solutions de contournement sont misérables et Apple peut vous débrancher à tout moment.
Parmi les solutions que vous avez mentionnées, aucune ne semble vous donner un accès direct au framework MapKit introduit dans OS 3.0.
Comme les widgets HTML de Google Maps ne sont pas aussi performants que MapKit (voir Google Latitude pour un exemple), il est probablement préférable de développer une application native Cocoa Touch ou de choisir une solution que vous pouvez étendre pour ajouter l’intégration MapKit. PhoneGap est extensible de cette manière (il est open-source, donc c'est par défaut), et certaines des autres solutions pourraient l'être également.
edit: Titanium supporte maintenant MapKit
J'ai essayé la couronne. C'était bien jusqu'à ce que je découvre qu'il ne supporte pas le streaming audio MP3. Alors je me suis arrêté là. Je pense que si je veux vraiment être développeur d'applications pour iPhone, je devrais apprendre obj c. Tout ce que je voulais faire une application qui a une liste de stations de radio et vous cliquez dessus, il commence à jouer.