Comparaison entre Corona, Phonegap, Titanium

Je suis développeur Web et je souhaite transférer mes produits Web sur iPhone. L'un des produits est comme Google Maps: afficher 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 qu'il existe des technologies qui vous permettent d'utiliser HTML, CSS et Javascript pour développer des applications iPhone natives. J'en ai identifié quelques-uns:

• Ansca Mobile
• PhoneGap
• Appcelerator

Existe-t-il d'autres produits similaires? Quelles sont les différences entre eux? Lequel devrais-je choisir?

Je me suis inscrit sur stackoverflow juste pour commenter la réponse la plus votée en haut. La mauvaise chose 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 deux les fonctions du téléphone mobile via un ensemble d'API javascript, et la logique de l'application (html, css, javascript) s'exécute dans un contrôle WebView natif.

1. PhoneGap n'est pas seulement 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, la caméra accélérométrique, les contacts, la base de données, le système de fichiers, etc. monde javascript. D'un autre côté, 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 plus 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 pour cela que PhoneGap a été créé.

2. Titanium ne compile PAS votre code html, css ou javascript en "bits natifs". Ils sont regroupés en tant que ressources du bundle exécutable, un peu comme un fichier image incorporé. Lorsque l'application s'exécute, 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-to-native-code (ou to-objective-c). Cela se fait également 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. Tout d'abord, Titanium semble être plus riche en fonctionnalités que PhoneGap en reliant plus de fonctions de téléphone mobile à javascript. Plus particulièrement, PhoneGap n'expose pas de nombreux composants d'interface utilisateur natifs (le cas échéant) au javascript. Titanium, d'autre part, dispose d'une API d'interface utilisateur complète qui peut être appelée en javascript pour créer et contrôler toutes sortes 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 plus 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 plateformes telles que iPhone, Android, Blackberry, Symbian, etc. Titanium cible principalement iPhone et Android au moins pour l'instant. Certaines de ses API sont spécifiques à la plate-forme (comme les API de l'interface utilisateur de l'iPhone).

Donc, si votre souci pour votre application est de la rendre plus "native", le titane est un meilleur choix. Si vous voulez pouvoir "porter" votre application vers une autre plate-forme plus facilement, PhoneGap sera mieux.

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 à ce poste une revue annuelle pour garder ses informations à jour. Beaucoup de choses ont changé en un an, ce qui a rendu certaines informations du post initial obsolètes.

Le plus grand changement est venu du titane. Plus tôt cette année, Appcelerator a publié Titanium 1.0, qui s'écartait radicalement de ses versions précédentes du point de vue architectural. Dans 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 signifie deux choses:

1. L'interface utilisateur de votre application devient complètement native. Il n'y a plus d'interface utilisateur Web dans votre application, car les API Titanium natives prennent le contrôle de tous vos besoins en matière d'interface utilisateur. Le titane mérite beaucoup de crédit en étant pionnier sur la frontière de "l'interface utilisateur native multiplateforme". Il offre aux programmeurs qui préfèrent l'apparence de l'interface utilisateur native mais n'aiment pas le langage de programmation officiel une alternative.

2. Vous ne pourrez pas utiliser HTML ou CSS dans votre application, car la vue Web a disparu. (Remarque: vous pouvez toujours créer une vue Web dans Titanium. Mais il y a peu de fonctionnalités Titanium dont vous pouvez profiter dans la vue Web.) Q&R Titanium: Qu'est-il arrivé à HTML et CSS?

3. 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 codage. 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 est enfin revenu sur ce problème avec ce blog de développeur: Titanium Guides Project: JS Environment. Nous, les programmeurs, sommes des gens plus authentiques que ceux du département 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'a pas été très actif jusqu'à ce qu'IBM monte à bord plus tard cette année. Certaines personnes ont même fait valoir qu'IBM fournit plus de code à PhoneGap que Nitobi. Cela étant vrai ou non, il est bon de savoir que PhoneGap est en cours de développement actif.

PhoneGap continue de se baser sur les technologies Web, à savoir HTML, CSS et JavaScript. Il ne semble pas que PhoneGap ait prévu de relier les fonctionnalités natives de l'interface utilisateur à JavaScript comme le fait Titanium. Bien que l'interface utilisateur Web soit toujours à la traîne de l'interface utilisateur native en termes de performances et d'aspect natif, cet écart se réduit rapidement. Il existe deux tendances dans les technologies Web qui assurent une fonctionnalité brillante à l'interface utilisateur Web mobile en termes de performances:

1. Moteur JavaScript passant d'un interprète à une machine virtuelle. JavaScript est JIT compilé en code natif pour une exécution plus rapide. Moteur Safari JS: SquirrelFish Extreme

2. Rendu de page Web passant de la dépendance au 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 grâce à l'accélération matérielle. Compositing accéléré par GPU dans Chrome

Ces améliorations provenant des navigateurs de bureau sont rapidement mises à disposition des navigateurs mobiles. En fait, depuis iOS 3.2 et Android 2.0, le contrôle d'affichage Web mobile est devenu beaucoup plus performant et convivial HTML5. L'avenir du web mobile est si prometteur qu'il a attiré un grand enfant en ville: JQuery a récemment annoncé son framework web mobile. Avec JQuery Mobile fournissant des gadgets d'interface utilisateur et PhoneGap fournissant des fonctionnalités de téléphone, les deux combinés créent une plateforme Web mobile parfaite à mon avis.

Je devrais également mentionner Sencha Touch comme un autre cadre de gadget pour l'interface utilisateur Web mobile. La version 1.0 de Sencha Touch a été récemment publiée sous un modèle de licence double qui inclut la GPLv3. Sencha Touch fonctionne bien avec PhoneGap, tout comme JQuery Mobile.

Si vous êtes un programmeur GWT (comme moi), vous voudrez peut-être consulter GWT Mobile , un projet open source pour créer des applications Web mobiles avec GWT. Il comprend un wrapper PhoneGap GWT qui permet l'utilisation de PhoneGap dans GWT.

D'après ce que j'ai rassemblé, voici quelques différences entre les deux:

• PhoneGap génère essentiellement des wrappers natifs pour ce qui est encore des applications Web . Il crache un projet WhatsYourPlatformIs, vous le construisez et le déployez. Si nous parlons de l'iPhone (où je passe mon temps), cela ne semble pas très différent de la création d'un lanceur d'applications Web (un raccourci qui obtient 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 à l'intérieur d'un contrôle de navigateur hébergé. Ce que PhoneGap fournit au-delà de cela, c'est un pont entre JavaScript et les API des appareils natifs. Ainsi, vous écrivez JavaScript contre les API PhoneGap, et PhoneGap effectue ensuite l'appel natif correspondant approprié. À cet égard, il est différent de déployer une application web ancienne plaine.

• La source de titane est compilée en bits natifs. Autrement dit, 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 d'interface utilisateur natifs . Il existe des moyens d'obtenir une apparence native sans avoir d'application native, mais ... eh bien ... quel cauchemar qui se révèle être.

Les deux sont similaires en ce que vous écrivez tous vos trucs en utilisant des technologies Web typiques (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 - j'en sais beaucoup) 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é à l'intérieur d'un contrôle UIWebView, et les API JavaScript PhoneGap vos appels js sont routés vers les 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 ?

1. Une application Titanium ressemblera à une "vraie" application car, en fin de compte, il s'agit d' une "vraie" application.

2. Une application PhoneGap ressemblera à une application Web hébergée dans un contrôle de navigateur car, en fin de compte, il s'agit d' une application Web hébergée dans un contrôle de navigateur.

Qu'est-ce qui vous convient?

• Si vous souhaitez écrire des applications natives en utilisant les compétences de développement Web, Titanium est votre meilleur choix.

• Si vous souhaitez écrire une application en utilisant des compétences de développement Web que vous pouvez déployer de manière réaliste sur plusieurs plates-formes (iPhone, Android, Blackberry et tout ce qu'ils décident d'inclure), et si vous souhaitez accéder à un sous-ensemble de fonctionnalités de plate-forme natives (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 voudrais-je écrire un PhoneGapp (j'ai décidé d'utiliser le nom) plutôt qu'une application Web hébergée sur le Web? Est-ce que je ne peux toujours pas accéder à certaines fonctionnalités de l'appareil natif de cette façon, mais aussi avoir la commodité d'un véritable déploiement Web plutôt que de forcer 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 rend plus difficile pour l'utilisateur d'oublier votre application (je suis beaucoup plus susceptible d'oublier un signet qu'une icône d'application).

Vous pourriez certainement facturer l'accès à votre application Web hébergée sur le Web, mais combien de personnes vont vraiment passer par le processus pour le faire? Avec l'App Store, je choisis une application, j'appuie sur le bouton "Acheter", je saisis un mot de passe et j'ai terminé. Il s'installe. Quelques secondes plus tard, je l'utilise. Si je devais utiliser l'interface de transaction Web mobile unique de quelqu'un d'autre, ce qui signifie probablement avoir à taper mon nom, mon adresse, mon numéro de téléphone, mon numéro de CC et d'autres choses que je ne veux pas taper, je ne le ferais certainement pas. t passer avec elle. En outre, je fais confiance à Apple - je suis convaincu que Steve Jobs ne va pas enregistrer mes informations, puis facturer un tas d'abonnements coquins à mon CC pour les coups de pied.

Quoi qu'il en soit, à l'exception du fait que la technologie de développement Web est impliquée, PhoneGap et Titanium sont très différents - au point d'être uniquement superficiellement comparables.

Je déteste les applications Web, et si vous lisez les critiques de l'iTunes App Store, les utilisateurs sont assez bons pour les repérer. Je ne nommerai aucun nom, mais j'ai quelques "applications" sur mon téléphone qui ressemblent et fonctionnent comme des ordures, et c'est parce que ce sont des applications Web qui sont hébergées dans des instances UIWebView. Si je voulais utiliser une application Web, j'ouvrirais Safari et, vous savez, j'irais vers celle-ci. J'ai acheté un iPhone parce que je veux des choses qui sont iPhone-y. Je n'ai aucun problème à utiliser, disons, une application Web Google élégante dans Safari, mais je me sentirais trompé si Google glissait simplement un signet sur Springboard en présentant une application Web comme native.

Dois y aller maintenant. Ma copine a ce regard qui pourrait-vous-s'il vous plait-arrêter d'utiliser cet ordinateur pendant trois secondes.

Je suis en cours de 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 était vers novembre 2010). Voici mon expérience.

Double ciblage iPhone Android

Même si les guides API affirment que la fonctionnalité est disponible à la fois pour Android et iPhone, ce n'est pas le cas. La plupart des choses ne fonctionnent tout simplement pas sur l'une des plates-formes. Certaines choses fonctionnent différemment.

Beaucoup de gens dans la classe ont fait des applications iPhone, et ils ne peuvent pas les faire fonctionner sur Android sans réécriture majeure. J'ai développé une application pour enfants simple appelée Animap (voir Android Market / Appstore en Suède) et j'ai commencé à développer sous Windows. Une fois que la cible Android fonctionnait, j'ai ouvert le projet sur OS X. Il ne montre aucun élément de construction pour iPhone, juste pour Android. Vous devez démarrer un projet à double cible sous OS X. (Ok, j'ai copié les fichiers appropriés 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 manière sur l'iPhone. (Par exemple, sur Android, vous obtenez l'événement Untouch lorsque l'utilisateur arrête de faire défiler et libère son doigt de l'écran, cela ne se produit pas sur l'iPhone).

Étant donné que cela n'est pas mentionné quelque part, vous devez essentiellement faire une programmation d'essai et d'erreur sur une première plate-forme, puis sur l'autre plate-forme. Par essais et erreurs, je veux dire qu'il faudra environ deux jours pour qu'une application aussi simple qu'Animap fonctionne sur l'autre plate-forme. Vous devrez également avoir if (android) puis ... ou if (iphone) ... partout dans votre code ...

Téléchargement et configuration

Vous devez suivre les instructions à la lettre. N'essayez pas d'utiliser Java 64 bits. Il ne compilera pas l'application de démonstration de KitchenSink 1.4.0. (1.3 fonctionne bien!) Vous devez placer les fichiers directement sur le lecteur C car les chemins d'accès longs empêcheront le programme externe de recevoir tous les paramètres de ligne de commande s'ils deviennent trop longs. (Bien pour les petits programmes cependant) 1/3 des fois, la chaîne d'outils s'arrête 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 devez simplement tuer adb.exe avec Ctrl + Alt + Suppr et réessayer.

Connexion réseau

Sur un réseau wifi, vous perdez parfois la connexion en direct et Titanium se bloque sur vous (l'interface de compilation / déploiement) Si vous n'avez pas de connexion Internet fonctionnelle, elle ne démarre 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 autre ancienne API GUI, et vous devez définir certaines propriétés pour chaque bouton / champ / etc. Il est trop facile de se tromper sur un champ, en se souvenant de toutes les propriétés qui doivent être définies? L'avez-vous épelé avec des majuscules au bon endroit? (car cela n'est pas détecté par le compilateur, mais sera considéré comme une erreur d'exécution si vous avez la chance de tester cette partie)

Dans Titanium, les choses se cassent simplement lorsque vous ajoutez une autre vue au-dessus d'un contrôle ou cliquez ailleurs dans l'interface graphique.

Documentation

Plusieurs pages d'API portent le symbole Android, mais ne renvoient une valeur nulle que lorsque vous essayez de créer le contrôle. Ils ne sont pas simplement disponibles sur la plateforme Android malgré les symboles. Parfois, Android est mentionné pour ne pas prendre en charge une méthode particulière, mais alors l'API entière est manquante.

Évier

L'application de démonstration. Ai-je mentionné qu'il ne se compile pas si vous le mettez dans votre dossier de projet Eclipse parce que le chemin devient trop long? Doit être placé sur votre lecteur C dans le dossier racine. J'utilise actuellement un lien symbolik (mklink / J ...)

Méthodes non documentées

Vous devez utiliser correctement les choses comme label.setText ('Hello World') pour changer une étiquette fiable mais cela n'est pas documenté du tout.

Débogage

Titanium.API.info ('Les impressions sont le seul moyen de déboguer');

Édition

Les API ne sont disponibles dans aucun bon format, vous ne pouvez donc pas obtenir de complétion de code ordinaire avec de l'aide, etc. dans Eclipse. Aptana s'il vous plaît, aidez-moi!

Matériel

Il semble que le compilateur / les outils ne soient pas multithread donc un ordinateur rapide avec un disque dur rapide est un must, car vous devez faire beaucoup d'essais et d'erreurs. Ai-je mentionné la mauvaise documentation? Vous devez tout essayer car vous ne pouvez pas lui faire confiance!

Quelques choses positives

• Open source

• De projets précédents, je me suis promis de ne plus jamais utiliser la source fermée car vous ne pouvez pas simplement réparer les choses simplement en y consacrant des heures et de la main-d'œuvre. Important lorsque vous êtes en retard dans le projet et que vous devez livrer dans un délai difficile. C'est open source et j'ai pu voir pourquoi la chaîne d'outils se brise et le réparer aussi.

• Base de données de bogues

• 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 passées en essais et erreurs.

• Communauté

• Semble être actif sur leurs forums.

Bugs

• Le titane 1.4 n'est pas threadsafe . Cela signifie que si vous utilisez des threads (utilisez la propriété url: dans un appel createWindow) et que des programmes tels que les threads fonctionnent et envoient des événements avec des données dans les deux sens, vous rencontrez beaucoup de choses très, très étranges - des gestionnaires perdus, perdus fenêtres, trop d'événements, trop peu d'événements, etc. etc. Tout cela dépend du timing, mettre les lignes de code dans un ordre différent peut planter ou soigner votre application. L'ajout d'une fenêtre dans un autre fichier.js interrompt l'exécution de votre app.js ... Cela supprime également les infrastructures de données internes dans Titanium, car elles peuvent parfois mettre à jour les infrastructures de données internes en parallèle, écrasant une valeur qui vient d'être modifiée avec autre chose.

Une grande partie des problèmes que j'ai rencontrés avec Titanium vient de mon expérience des systèmes en temps réel comme OSE qui prennent en charge des centaines de threads, d'événements et de messages. Cela est censé fonctionner dans Titanium 1.4, mais cela ne le fait tout simplement pas de manière fiable.

• Javascript (qui est nouveau pour moi) meurt en silence sur les erreurs d'exécution. Cela signifie également que les petits bogues courants, comme la faute d'orthographe d'un nom de variable ou la lecture d'un pointeur nul, ne se bloquent pas quand il le faut pour que vous puissiez le déboguer. Au lieu de cela, certaines parties de votre programme cessent de fonctionner, par exemple un gestionnaire d'événements, parce que vous avez égaré / mal tapé un caractère.

• Ensuite, nous avons des bogues plus simples dans Titanium, comme certains paramètres qui ne fonctionnent 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 d'avoir deux disques en RAID 1 (mode entrelacement) rend la construction environ 25% plus rapide que sur un seul disque avec un processeur un peu plus rapide et bat également l'ordinateur portable du disque SSD.

Résumé

• D'après les commentaires de ce fil, il semble y avoir une lutte pour le nombre de plateformes pour lesquelles un outil comme celui-ci peut fournir des applications. Le nombre d'API semble être le principal argument de vente.

Cela transparaît beaucoup lorsque vous commencez à l'utiliser. Si vous regardez le bugtracker ouvert, vous voyez que le nombre de bogues continue d'augmenter plus rapidement que le nombre de bogues corrigés. C'est généralement un signe que les développeurs continuent d'ajouter plus de 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 aux multiplates-formes pour un client - je ne suis pas sûr que cela soit en fait plus rapide que de faire du développement d'applications natives sur deux plateformes. Cela est dû au fait que lorsque vous êtes à la vitesse, vous êtes rapide avec Titanium, mais soudain, 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 ne pouvez tout simplement PAS promettre une certaine fonctionnalité pour un certain délai / temps / coût.

À propos de moi: J'utilise Python depuis deux ans avec wxPython. (cette interface graphique est incohérente, mais ne se casse jamais comme ça. Il se peut que ce soit moi qui n'ait pas compris le modèle de thread utilisé par Javascript et Titanium, mais je ne suis pas seul selon leurs forums de discussion ouverts, les objets GUI utilisent soudainement le mauvais contexte / pas de mise à jour .. ???) avant cela, j'ai une formation en programmation C et ASM pour les appareils mobiles.

[edit - ajouté une partie avec des bugs et ne pas être thread-safe] [Edit - ayant maintenant travaillé avec elle pendant un mois +, principalement sur PC mais aussi sur OS X aussi. Ajout d'une double cible pour iPhone et Android. Ajout de la vitesse du cycle de débogage d'essai et d'erreur.]

Le SDK Corona (Ansca Mobile) utilise Lua comme langage de codage. Voir lua.org pour en savoir plus sur Lua.

Bien que nous prévoyions d'ajouter d'autres éléments d'intégration Web et d'interface utilisateur native, nous nous concentrerons généralement sur les applications à forte intensité graphique, telles que le développement de jeux, par opposition aux technologies Web. En d'autres termes, nous n'envisageons pas que les gens écrivent des applications Corona entièrement en Javascript / HTML / CSS.

Je travaille avec Titanium depuis plus d'une semaine maintenant et j'ai l'impression d'avoir une bonne idée de sa faiblesse.

1) Si vous espérez utiliser le même code sur plusieurs plateformes, bonne chance! Vous verrez quelque chose comme backgroundGradient et serez étonné jusqu'à ce que vous découvriez que la version Android ne la prend pas en charge. Vous devez ensuite revenir à l'utilisation d'une image en dégradé, pourrait-il aussi bien l'utiliser pour les deux versions pour rendre le code plus facile non?

2) Beaucoup de comportements étranges, sur le sdk Android Titanium, vous devez comprendre ce qu'est une fenêtre "lourde" juste pour que le bouton de retour fonctionne, ou encore mieux le suivi des événements d'orientation. Ce n'est pas vraiment la plate-forme Android, c'est juste la façon dont Titanium essaie de faire fonctionner son API.

3) Votre jeté dans le noir, les choses vont planter et vous devez commencer à commenter le code, puis quand vous le trouverez, ne jamais l'utiliser. Il y a certains bugs évidents, comme l'orientation et les pourcentages sur Android, qui posent problème depuis plus de six mois.

4) Bugs .... il y a beaucoup de bugs et ils seront signalés, restez assis pendant des mois, corrigez-les en quelques jours. Je suis surpris qu'ils envisagent même de sortir un SDK mobile Black Berry alors qu'il y a tellement d'autres problèmes avec Android.

5) Les moteurs javascript Titanium Iphone et Titanium Android sont complètement différents. Sur la version Android, vous pouvez télécharger des fichiers javascript à distance, inclure et utiliser des bibliothèques comme mootools, jquery, etc. J'étais au paradis lorsque j'ai découvert cela parce que je n'avais pas à continuer de compiler mon application Android. Le processus d'installation d'apk Android prend tellement de temps! Iphone rien de tout cela n'est possible, la version iphone a également un moteur javascript beaucoup plus rapide.

Si vous vous éloignez de la plupart des parties natives de l'interface utilisateur, c'est-à-dire utilisez plutôt setInterval pour détecter les changements d'orientation, restez avec des images de dégradé, oubliez le bouton de retour, créez vos propres animations, oubliez l'en-tête de la fenêtre, les barres d'outils et le tableau de bord. Vous pouvez vraiment créer une API qui fonctionne sur les deux sans nécessiter beaucoup de réécriture. Mais à ce stade, c'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 simplement créer une interface utilisateur différente pour chacun plutôt que si vous utilisez ailleurs. Le titane vous permet de réaliser 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 se faire sous une seule langue.

Pourquoi pas une application web? Sur le marché d'entrée de gamme, les téléphones Android sont horriblement lents à générer une vue Web et consomment beaucoup de mémoire que vous pourriez utiliser pour faire une logique plus complexe.

Voici une analyse plus récente et approfondie d'Appcelerator et 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 pris en charge dans Titanium

Faire des widgets HTML5 qui ressemblent à des widgets iphone est une chose, mais les faire fonctionner aussi bien est une autre affaire. Les performances des animations html5 (même les transitions d'affichage simples), le défilement de longues listes, la réactivité aux gestes sont collants et saccadés. 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 appareils, ce qui entraîne également des problèmes de code et d'utilisation spécifiques à la plate-forme.

Je vais rester avec des applications natives pour l'instant je suppose.

Rhomobile Rhodes ( http://rhomobile.com/products/rhodes ) est très similaire dans l'approche de PhoneGap, mais est le seul framework avec:

1. un modèle de contrôleur de vue du modèle (comme le fournissent la plupart des frameworks Web)
2. un gestionnaire relationnel objet
3. prise en charge de tous les smartphones populaires (y compris Windows Phone 7)
4. un service de développement hébergé (pas seulement une version hébergée): http://rhohub.com
5. un débogueur complet et un émulateur sans SDK dans l'IDE RhoStudio
6. prise en charge des données hors ligne synchronisées

Pour toute personne intéressée par Titanium, je dois dire qu'ils n'ont pas une très bonne documentation, certaines classes, propriétés, méthodes manquent. Mais beaucoup est "documenté" dans leur exemple d'application, le KitchenSink, donc ce n'est pas si mal.

Ma compréhension de PhoneGap est qu'ils fournissent des API Javascript à la plupart des API iPhone.

Le titane semble plus facile pour un développeur Web. Il s'agit d'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 frameworks (en particulier l'accès aux informations de localisation, l'identifiant du téléphone, etc.).

MISE À JOUR: Titanium a ajouté l'API Maps dans la version 0.8 de son framework.

Vous devez apprendre l'objectif c et programmer des applications natives. Ne comptez pas sur ces choses qui, selon vous, vous faciliteront la vie. Apple s'est assuré que le moyen le plus simple consiste à utiliser ses outils et sa langue natifs. Pour vos 100 lignes de javascript, je peux faire de même en 3 lignes de code ou pas de code du tout selon l'élément. Regardez quelques tutoriels - si vous comprenez javascript, l'objectif 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.

Étant donné que les widgets HTML de Google Maps ne sont pas aussi bons 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 de MapKit. PhoneGap est extensible de cette manière (c'est open-source donc c'est par défaut), et certaines des autres solutions pourraient l'être aussi.

edit: Titanium prend désormais en charge MapKit

J'ai essayé corona. C'était bon jusqu'à ce que je découvre qu'il ne prend pas en charge le streaming audio mp3. Alors, je me suis arrêté juste là. Je pense que si je veux vraiment être un développeur d'applications iphone, je devrais apprendre obj c. Tout ce que je voulais, c'était faire une application qui a une liste de stations de radio et vous cliquez dessus pour commencer à jouer.