Après toutes les évolutions des IDE (toutes les plates-formes sur le sujet sont modifiées) de cette année, je suis à la recherche pour comprendre quel est l’état de la technologie pour ces plates-formes.
Quelles sont les forces et les faiblesses de chaque ones ? Il existe certaines limitations de l’un de ces approche ?
J’ai une bonne expérience sur c# et Javascript, qu’il n’y a aucune influence de langage de programmation qui puisse se pencher d’un côté.
Je n'ai pas beaucoup travaillé avec Appcelerator Titanium, mais je vais mettre ma compréhension de celui-ci à la fin.
Je peux parler un peu plus sur les différences entre PhoneGap et Xamarin, que je travaille avec ces deux 5 (ou plus) les jours de la semaine.
Si vous êtes déjà familier avec le C# et JavaScript, alors la question que je conjecture est, la logique d'entreprise se situe dans une zone plus adapté à JavaScript ou C#?
PhoneGap est conçu pour vous permettre d'écrire vos applications à l'aide de JavaScript et HTML, et de nombreuses fonctionnalités qu'ils offrent est conçu pour imiter la proposition de spécifications pour la fonctionnalité qui sera éventuellement disponible avec HTML5. Le gros avantage de PhoneGap, à mon avis, c'est que depuis que vous faites l'INTERFACE avec le HTML, il peut facilement être transférés entre des plates-formes. Le revers de la médaille, parce que vous portez la même INTERFACE entre les plates-formes, il ne se sentent pas tout à fait comme à la maison dans l'un d'eux. Ce qui signifie que, sans plus de peaufinage, vous ne pouvez pas avoir une application qui se sent entièrement à l'aise dans iOS et Android, ce qui signifie qu'il a le iOS et Android dans le style. La majorité de votre logique peut être écrite à l'aide de JavaScript, ce qui signifie qu'il peut aussi être transférés entre des plates-formes. Si le courant PhoneGap API n'est plus de ce que vous voulez, alors il est assez facile de se lever et courir. Si toutefois, il y a des choses que vous avez besoin de l'appareil qui ne sont pas dans l'API, puis vous entrez dans le plaisir de Développement d'un Plugin, qui sera dans les natifs des dispositifs de développement de la langue de son choix (avec une mise en garde, mais j'y reviendrai), ce qui signifie que vous aurait probablement besoin d'obtenir rapidement en Objective-C, Java, etc. La bonne chose à propos de ce modèle, si vous pouvez généralement s'adapter beaucoup de différentes bibliothèques natives pour servir vos fins, et de nombreuses bibliothèques ont déjà PhoneGap Plugins. Bien que vous pourriez ne pas avoir beaucoup d'expérience avec ces langues, il y aura au moins une pléthore d'exemples de notre travail.
Xamarin.iOS et Xamarin.Android (aussi connu comme MonoTouch et MonoDroid), sont conçues pour vous permettre d'avoir une bibliothèque d'une logique d'entreprise, et de l'utiliser au sein de votre application, et de le brancher dans votre INTERFACE utilisateur. Car il est basé sur .NET 4.5, vous obtenez certains génial lambda notations, LINQ, et tout un tas d'autres C# awesomeness, ce qui peut rendre la rédaction de votre logique métier moins pénible. L'inconvénient ici est que Xamarin s'attend à ce que vous voulez faire de vos applications vraiment l'impression native sur l'appareil, ce qui signifie que vous allez probablement finir par la réécriture de votre INTERFACE utilisateur pour chaque plate-forme, avant de les brancher avec la logique d'entreprise. J'ai entendu parler de MvvmCross, qui est conçu pour rendre cela plus facile pour vous, mais je n'ai pas vraiment eu l'occasion de le regarder encore. Si vous êtes familier avec le MVVM système en C#, vous voudrez peut-être avoir un coup d'oeil à ce. Quand il s'agit de bibliothèques natives, MonoTouch devient intéressant. MonoTouch nécessite une Liaison de la bibliothèque de dire à votre code C# comment faire un lien dans le sous-jacent Objective-C et Java code. Certaines de ces bibliothèques ont déjà des liaisons, mais si le vôtre n'en a pas, la création d'un peut-être, intéressant. Xamarin a fait un outil appelé Objectif Sharpie pour aider à ce processus, et pour la plupart, vous permettra de 95% du chemin. Les 5% restants seront probablement 80% de votre temps à tenter de lier une bibliothèque.
Mise à jour
Comme indiqué dans les commentaires ci-dessous, Xamarin a publié Xamarin Forms qui est une croix-plate-forme de l'abstraction autour de la plate-forme spécifique des composants de l'INTERFACE utilisateur. Vaut vraiment le coup d'oeil.
Maintenant, parce que je l'ai dit, je voudrais obtenir à elle, la mise en garde mentionnées dans PhoneGap ci-dessus, est une approche Hybride, où vous pouvez utiliser PhoneGap pour une partie, et Xamarin pour la partie. J'ai un peu d'expérience, et je vous mets en garde contre elle. Hautement. Le problème avec cela, c'est un no mans land que si vous lancez jamais dans les questions, presque personne n'aura parcouru près de ce que vous faites, et posent la question de ce que vous essayez de faire beaucoup. C'est faisable, mais ce n'est certainement pas amusant.
Comme je l'ai mentionné avant, je n'ai pas beaucoup travaillé avec Appcelerator Titanium, de Sorte que les différences entre eux, je vous suggère de regarder la Comparaison de Titane et de Phonegap ou de Comparaison entre Corona, Phonegap, Titanium car il a une très bonne description des différences. Fondamentalement, il semble qu' ils ont tous deux l'utilisation de JavaScript, de façon que le JavaScript est interprété, c'est légèrement différent. Avec du Titane, vous serez la rédaction de votre JavaScript pour le Titane SDK, où, comme PhoneGap, vous allez écrire votre application à l'aide de l' API PhoneGap. Comme PhoneGap est très HTML5 et JavaScript conformes aux normes, vous pouvez utiliser à peu près toutes les bibliothèques JavaScript que vous voulez, tels que JQuery. Avec PhoneGap votre interface utilisateur sera composé de HTML et de CSS. Avec du Titane, vous bénéficierez de leurs Croix-plate-forme XML qui semble générer des composants Natifs. Cela signifie qu'il va certainement avoir une meilleure interface native.
J'ai travaillé avec Xamarin . J'ai noté quelques bons points et les mauvais points.
+ve côté
Facile à code, c# rend la tâche plus facile
La Performance ne sera pas un souci
Natif de regarder dans la maison du sol
Bonne IDE , un peu comme Xcode et visual Studio.
Xamarin Débogueur
-cinq à Côté
Xamarin ne partage que peu de choses à travers platofrms, Seulement quelques petites choses comme des bases de données et web services, etc.
Besoin de connaissances sur chacune des plateformes comme iOS, Android, WP8, etc. Vous n'avez pas besoin de savoir objective C, mais vous avez besoin de quelques connaissances sur iOS et sur les classes et l'architecture MVC. Dans le cas d'Android, vous n'avez pas besoin de Java connaissances, mais vous devez savoir à propos de Android Activités, des Cycles de Vie, les Classes etc.
A la conception de l'INTERFACE utilisateur de chaque plate-forme séparément, cette chose est une malédiction et une bénédiction
si votre projet a un grand nombre de pages que vous avez à la conception de l'INTERFACE utilisateur de chaque plate-forme indépendante qui serait peut-être temps de prendre. Si vous avez le moindre nombre d'écrans et plus de travail à faire avec le noyau comme les bases de données et des services web puis xamarin sera un bon choix.
C# connaissances,Si vous avez d'autres plates-formes.
Xamarin est sous licence.
PhoneGap est assez lente : en cliquant sur un bouton peut prendre jusqu'à 3 secondes pour afficher l’écran suivant. iscroll est lente et jumpy.
Il autres funny bugs et des problèmes que j’ai a été en mesure de surmonter, mais en total - pas complètement mûri.
EDIT : Par commentaire grincheux, il n’est pas Phonegap qui est vraiment lent, c’est le moteur natif de JS/navigateur
Voici un excellent article sur le sujet-un aperçu très complet : http://blog.mercdev.com/?p=200
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
