Comment choisir entre MonoTouch et Objective-C?

Après avoir assisté à une session aujourd’hui sur Mono lors d’un événement local .Net, l’utilisation de MonoTouch a été considérée comme une alternative au développement de l’iPhone. Étant très à l’aise dans C # et .Net, cela semble être une option attrayante, en dépit de la bizarrerie de la stack Mono. Cependant, comme MonoTouch coûte 400 dollars, je suis un peu déchiré si c’est la voie à suivre pour le développement de l’iPhone.

Quelqu’un at-il une expérience de développement avec MonoTouch et Objective-C, et si tel est le cas, développer avec MonoTouch est-il beaucoup plus simple et rapide que d’apprendre Objective-C et vaut à son tour les 400 $?

J’ai vu cette question (et ses variations) beaucoup ces derniers temps. Ce qui m’étonne, c’est la fréquence à laquelle les gens répondent, mais combien peu répondent .

J’ai mes préférences (j’apprécie les deux stacks), mais c’est là que la plupart des “réponses” commencent à mal tourner. Il ne devrait pas s’agir de ce que je veux (ou de ce que quelqu’un d’autre veut).

Voici ce que je ferais pour déterminer la valeur de MonoTouch: je ne peux évidemment pas être objective, mais je pense que c’est sans zèle:

  • Est-ce pour le plaisir ou pour les affaires? Si vous souhaitez vous lancer dans le conseil dans ce domaine, vous pourriez rapidement récupérer votre 399 $.

  • Voulez-vous apprendre la plate-forme à l’intérieur ou voulez-vous simplement écrire des applications pour elle?

  • Aimez-vous assez .Net pour que l’utilisation d’une stack de dev différente vous en prenne? Encore une fois, j’aime les deux stacks (Apple et Mono), mais pour moi, MonoTouch rend l’expérience encore plus amusante. Je n’ai pas cessé d’utiliser les outils d’Apple, mais c’est principalement parce que j’aime vraiment les deux stacks . J’aime l’iPhone et j’aime .Net. Dans ce cas, pour moi, MonoTouch était une évidence.

  • Vous sentez-vous à l’aise de travailler avec C? Je ne parle pas d’Objective-C, mais de C – c’est important car Objective-C est C. C’est une version OO sympa, élégante et sympathique, mais si des pointeurs vous donnent les heebie-jeebies, MonoTouch est votre ami. Et n’écoutez pas les opposants qui pensent que vous êtes un développeur si vous n’aimez pas les pointeurs (ou C, etc.). J’avais l’habitude de me promener avec une copie de l’IBM ROM BIOS Pocket Reference, et quand j’écrivais l’assemblage et forçais mon ordinateur en modes vidéo drôles et que je écrivais mes propres morceaux de rendu de fonts et de systèmes de fenêtrage Je pense que les devs de QuickBasic étaient des wusses. J’étais un développeur QuickBasic (en plus du rest). Ne cédez jamais au machisme. Si vous n’aimez pas C, et si vous n’aimez pas les pointeurs, et si vous voulez restr aussi loin que possible de la gestion manuelle de la mémoire (et, pour être honnête, ce n’est pas mal du tout dans ObjC), alors. .. MonoTouch. Et ne prenez aucune guff pour cela.

  • Voulez-vous cibler des utilisateurs ou des entresockets? Peu importe pour moi, mais il y a encore des gens sur Edge, et le fait est que vous pouvez créer un paquet de téléchargement beaucoup plus petit si vous utilisez la stack d’Apple. J’ai joué avec MonoTouch, et j’ai une petite application décente qui, une fois compressée, passe à environ 2,7 Mo (lorsque vous soumettez votre application pour la dissortingbution, vous la compressez – lorsque les applications sont téléchargées à partir du magasin, elles ‘ zippé – alors, si vous pensez que votre application va entrer dans la limite de 10 Mo OTA, compressez-la en premier – vous serez agréablement surpris par MonoTouch. Mais, mis à part le bonheur MT, un demi-million contre près de trois (par exemple) est quelque chose qui peut être important pour vous si vous ciblez les utilisateurs finaux. Si vous pensez au travail en entreprise, quelques Mo ne seront pas importants du tout. Et pour être clair, je vais bientôt envoyer une application basée sur MT à la boutique et je n’ai aucun problème avec la taille. Ça ne me dérange pas du tout. Mais si cela vous concerne, alors la stack d’Apple remporte celle-ci.

  • Faire du travail XML? MonoTouch. Période.

  • Manipulation de cordes? Manipulation des dates? Un million d’autres petites choses auxquelles nous nous sums habitués avec les frameworks tout-ET-le-lavabo-cuisine de .Net? MonoTouch.

  • Services Web? MonoTouch.

  • Syntactiquement, ils ont tous deux leurs avantages. Objective-C a tendance à être plus verbeux lorsque vous devez l’écrire . Vous vous retrouverez à écrire du code avec C #, vous n’auriez pas à écrire avec ObjC, mais cela va dans les deux sens. Ce sujet particulier pourrait remplir un livre. Je préfère la syntaxe C #, mais après avoir surmonté ma réaction initiale à Objective-C, j’ai appris à l’apprécier un peu. Je me moque un peu des discussions (c’est bizarre pour les développeurs qui sont habitués à C # / Java / etc), mais la vérité est que j’ai un point en forme de C objective qui me rend heureux.

  • Prévoyez-vous d’utiliser Interface Builder? Parce que, même dans cette première version, je travaille beaucoup moins pour construire mes interfaces avec IB et les utiliser ensuite dans le code. Il semble que des étapes entières manquent à la façon de faire d’Objective-C / IB, et je suis presque certain que des étapes entières manquent dans la façon de faire d’Objective-C / IB. Jusqu’à présent, et je ne pense pas avoir suffisamment testé, mais jusqu’ici , MonoTouch est le gagnant ici pour combien moins de travail vous devez faire.

  • Pensez-vous que c’est amusant d’apprendre de nouveaux langages et plates-formes? Si oui, l’iPhone a beaucoup à offrir, et la stack d’Apple va probablement vous sortir de votre zone de confort – ce qui, pour certains développeurs, est amusant (salut – je suis un de ces développeurs – je plaisante à ce sujet et donne Apple a du mal, mais j’ai eu beaucoup de plaisir à apprendre le développement de l’iPhone grâce aux outils d’Apple.

Il y a tellement de choses à considérer. La valeur est tellement abstraite. Si nous parlons de coût et si cela en vaut la peine, la réponse se résume à ma première puce: si c’est pour les affaires et si vous pouvez obtenir le travail, vous récupérerez votre argent.

Donc … c’est à peu près aussi objective que possible. Ceci est une courte liste de ce que vous pourriez vous demander, mais c’est un sharepoint départ.

Personnellement (laissez tomber l’objectivité pour un moment), j’aime et utilise les deux. Et je suis content d’avoir appris la stack Apple en premier. Il était plus facile pour moi de me familiariser avec MonoTouch lorsque je connaissais déjà le monde d’Apple. Comme d’autres l’ont dit, vous allez toujours travailler avec CocoaTouch – ce sera juste dans un environnement .Net.

Mais il y a plus que ça. Les personnes qui n’ont pas utilisé MonoTouch ont tendance à s’arrêter là – “C’est un blah blah blah blah” – ce n’est pas MonoTouch.

MonoTouch vous donne access à ce que CocoaTouch a à offrir tout en vous donnant access à ce que (un sous-ensemble de) .Net offre, un IDE avec lequel certaines personnes se sentent plus à l’aise (je suis l’une d’entre elles), une meilleure intégration avec Interface Builder. , et bien que vous n’oubliiez pas complètement la gestion de la mémoire, vous obtenez une bonne marge de manœuvre.

Si vous n’êtes pas sûr, prenez la stack d’Apple (c’est gratuit) et prenez la stack eval de MonoTouch (c’est gratuit). Jusqu’à ce que vous rejoigniez le programme de développement d’Apple, les deux ne fonctionneront que contre le simulateur, mais cela suffit pour vous aider à déterminer si vous préférez l’un à l’autre, et si MonoTouch vaut, pour vous, les 399 $.

Et n’écoutez pas les fanatiques – ils ont tendance à ne pas avoir utilisé la technologie contre laquelle ils se battent 🙂

Il y a beaucoup de rumeurs dans cet article de développeurs qui n’ont pas essayé MonoTouch et Objective-C. Il semble qu’il s’agisse principalement de développeurs Objective-C qui n’ont jamais essayé MonoTouch.

Je suis évidemment partial, mais vous pouvez vérifier ce que la communauté MonoTouch a fait dans:

http://xamarin.com

Vous y trouverez plusieurs articles de développeurs développés en Objective-C et C #.

Donc, ma réponse à une question précédente est d’apprendre Objective-C. (N’oubliez pas non plus le support du débogage)

Cela choquera probablement certains, mais pour être honnête, si vous envisagez un développement sérieux, vous devriez apprendre Objective-C. Ne pas connaître Objective-C dans le développement de l’iPhone ne sera qu’un obstacle. Vous ne pourrez pas comprendre beaucoup d’exemples; vous devez faire face aux bizarreries de Mono alors que si vous aviez une connaissance pratique d’Objective-C, vous pourriez tirer beaucoup plus de la documentation de la plateforme.

Personnellement, je ne comprends pas la position qui dit augmenter la quantité d’informations dont vous avez besoin en faveur de l’utilisation de Mono sur la langue maternelle de la plateforme. Cela me semble quelque peu contre-productif. Je pense que s’il s’agit d’une proposition très coûteuse (apprendre une nouvelle langue), il peut être utile de passer du temps sur des concepts fondamentaux de programmation, de sorte que l’apprentissage de nouvelles langues soit une proposition relativement peu coûteuse.

Un autre utilisateur a également écrit ceci:


Monotouch est plus facile pour vous maintenant. Mais plus tard plus tard.

Par exemple, que se passe-t-il lorsque de nouvelles semences doivent être testées, mais que MonoTouch se casse pour une raison quelconque?

En restant fidèle à Mono, chaque fois que vous recherchez des ressources pour des frameworks, vous devez traduire mentalement comment vous allez les utiliser avec Mono. Les fichiers binarys de votre application seront plus gros, votre temps de développement beaucoup moins rapide après quelques mois passés dans Objective-C, et les autres développeurs d’applications auront encore plus d’avantage sur vous parce qu’ils utilisent la plate-forme native.

Une autre considération est que vous cherchez à utiliser C # parce que vous êtes plus familier avec Objective-C. Mais la grande majorité de la courbe d’apprentissage de l’iPhone n’est pas Objective-C, ce sont les frameworks – que vous devrez également utiliser avec C #.

Pour toute plate-forme, vous devez utiliser la plate-forme qui exprime directement la philosophie de conception de cette plate-forme – sur l’iPhone, à savoir Objective-C. Pensez à ceci sous l’angle inverse, si un développeur Linux habitué à programmer en GTK voulait écrire des applications Windows, recommanderiez-vous sérieusement de ne pas utiliser C # et de s’en tenir à GTK car il était plus facile de le faire?


Utiliser Mono n’est pas une béquille. Il y a beaucoup de choses qu’il ajoute au système d’exploitation de l’iPhone. LINQ, WCF, code partageable entre une application Silverlight, une page ASP.NET, une application WPF, une application Windows Form, et il y a également mono pour Android et cela fonctionnera également pour Windows Mobile.

Donc, vous pouvez passer beaucoup de temps à écrire Objective-C (vous verrez à partir de nombreuses études où le même exemple de code en C # est beaucoup moins important que OC), puis le dupliquer pour les autres plates-formes. Pour moi, j’ai choisi MonoTouch car l’application Cloud que j’écris aura de nombreuses interfaces, l’iPhone n’étant que l’un d’entre eux. Avoir un stream de données WCF depuis le cloud vers l’application MonoTouch est incroyablement simple. J’ai des bibliothèques centrales qui sont partagées entre les différentes plates-formes et je n’ai besoin que d’écrire une couche de présentation simple pour les déploiements iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET. Tout recréer en Objective-C serait une énorme perte de temps tant pour le développement initial que pour la maintenance, car le produit continue à progresser, car toutes les fonctionnalités devraient être répliquées plutôt que réutilisées.

Les personnes qui insultent MonoTouch ou insinuent que les utilisateurs ont besoin d’une béquille n’ont pas la grande image de ce que signifie avoir le framework .NET à scope de main et peut-être ne comprennent pas la séparation correcte de la logique avec la présentation peut être réutilisé sur les plates-formes et les périphériques.

Objective-C est intéressant et très différent de beaucoup de langages communs. J’aime relever un défi et apprendre différentes approches … mais pas lorsque cela entrave mes progrès ou crée des recodages inutiles. Il y a de très bonnes choses sur le framework SDK iPhone, mais toute cette qualité est entièrement prise en charge avec MonoTouch et supprime toute la gestion manuelle de la mémoire, réduit la quantité de code nécessaire pour effectuer les mêmes tâches et me permet de réutiliser mes assemblages. garde mes options ouvertes pour pouvoir passer à d’autres appareils et plates-formes.

J’ai changé Monotouch me permet d’écrire des applications au moins 3 à 4 fois plus rapidement (4 applications par mois par rapport à mon ancien 1 par mois dans Obj C)

Beaucoup moins de frappe.

Juste mon expérience

S’il s’agit de la seule application iPhone que vous développerez jamais, et que vous n’avez aucun intérêt à développer des applications Mac, MonoTouch en vaut probablement la peine.

Si vous pensez que vous développerez de nouvelles applications pour iPhone, ou voudrez un jour faire du développement natif sur Mac, cela vaut probablement la peine d’apprendre Objective-C et les frameworks associés. De plus, si vous êtes le type de programmeur qui aime apprendre de nouvelles choses, c’est un nouveau paradigme amusant à étudier.

Personnellement, je pense que vous aurez un meilleur moment pour apprendre Objective-C.

En bref:

  • “Learning Objective-C” n’est pas une tâche décourageante, vous pourriez même en profiter après les premières semaines
  • Vous connaissez déjà la syntaxe “C style” avec beaucoup de * & () {}; partout
  • Apple a fait un très bon travail de documentation
  • Vous interagirez avec l’iPhone comme le voulait Apple, ce qui signifie que vous tirerez directement profit de la source et non d’un filtre.

J’ai constaté que les projets comme Unity et MonoTouch étaient censés vous faire gagner du temps, mais vous aurez finalement besoin d’apprendre le langage spécifique à un domaine et vous devrez parfois suivre les étapes. Tout cela va probablement vous prendre tout le temps nécessaire pour apprendre la langue que vous essayez d’éviter d’apprendre (dans le temps du calendrier). En fin de compte, vous n’avez économisé aucun temps et vous êtes étroitement lié à certains produits.

EDIT: Je n’ai jamais voulu dire quelque chose de négatif à propos de .NET J’en suis un grand fan. Ce que je veux dire, c’est que l’ajout de couches de complexité simplement parce que vous n’êtes pas encore à l’aise avec la notation des supports obsolètes n’est pas vraiment logique pour moi.

Pour append à ce que d’autres ont déjà dit (bon!): J’ai le sentiment que vous doublez le nombre de bogues dont vous avez besoin, en ajoutant ceux de MonoTouch à ceux d’iPhone OS. La mise à jour des nouvelles versions du système d’exploitation sera encore plus pénible que la normale. Beurk, tout autour.

Le seul cas convaincant que je peux voir pour MonoTouch est celui des organisations qui ont beaucoup de programmeurs C # et de code C # à exploiter sur iPhone. (Le genre de magasin qui ne clignote même pas à 3500 $.)

Mais pour quiconque partant de zéro, je ne peux vraiment pas le voir comme utile ou sage.

Trois mots: Linq to SQL

Oui ça vaut bien le $.

Quelque chose que j’aimerais append, même s’il y a une réponse acceptée – qui peut dire qu’Apple ne rejettera pas seulement les applications qui semblent être construites avec Mono Touch?

J’investirais le temps dans Objective-C principalement grâce à toute l’aide que vous pouvez obtenir de sites comme celui-ci. Une des forces d’Objective-C est que vous pouvez utiliser du code C et C ++, et que de nombreux projets sont bien testés .

Une autre chose est que votre code (langue de choix) sera pris en charge par Apple. Qu’est-ce que iOS 5.x par exemple supprime la prise en charge d’une solution tierce telle que MonoTouch? Que direz-vous à vos clients alors?

Peut-être est-il préférable d’utiliser une solution indépendante de la plate-forme comme HTML5 si vous n’êtes pas prêt à passer à Objective-C?

J’utilise MonoTouch depuis quelques mois maintenant, j’ai porté mon application à moitié terminée depuis ObjectiveC pour pouvoir supporter Android à un moment donné.

Voici mon expérience:

Mauvais bits:

  • Xamarin Studio. Les développeurs indépendants tels que moi-même sont contraints d’utiliser Xamarin Studio. Il s’améliore chaque semaine, les développeurs sont très actifs sur les forums pour identifier et corriger les bugs, mais il est toujours très lent, se bloque fréquemment, contient beaucoup de bogues et le débogage est également très lent.

  • Temps de construction Construire ma grande application (liée) pour déboguer sur un périphérique peut prendre quelques minutes, comparé à XCode qui se déploie presque immédiatement. Construire pour le simulateur (non lié) est un peu plus rapide.

  • Problèmes MonoTouch. J’ai rencontré des problèmes de fuite de mémoire causés par la gestion des événements, et j’ai dû mettre au sharepoints solutions de contournement assez moche pour éviter les fuites, comme attacher et détacher des événements lors de l’entrée et de la sortie des vues. Les développeurs de Xamarin étudient activement des problèmes de ce type.

  • Bibliothèques tierces. J’ai passé pas mal de temps à convertir / relier des bibliothèques ObjectiveC à utiliser dans mon application, même si cela s’améliore avec des logiciels automatisés tels que Objective Sharpie.

  • Des binarys plus grands. Cela ne me dérange pas vraiment mais je pensais le mentionner. À mon avis, quelques Mb supplémentaires ne sont rien de nos jours.

Bons morceaux:

  • Multi plateforme. Mon ami crée avec plaisir une version Android de mon application à partir de mon code de base, nous développons en parallèle et nous nous engageons dans un repository Git distant sur Dropbox, ça marche bien.

  • .Net. Travailler en C # .Net est beaucoup plus intéressant que l’Objectif C IMO.

  • MonoTouch. À peu près tout dans iOS est reflété dans .Net et il est assez simple de faire avancer les choses.

  • Xamarin. Vous pouvez voir que ces gars-là travaillent vraiment à tout améliorer, rendant le développement plus facile et plus facile.

Je recommande définitivement Xamarin pour le développement multiplateforme, surtout si vous avez les moyens d’utiliser les éditions Business ou Enterprise qui fonctionnent avec Visual Studio.

Si vous créez uniquement une application iPhone qui ne sera jamais nécessaire sur une autre plate-forme et que vous êtes un développeur indépendant, je m’en tiendrai à XCode et à Objective C pour le moment.

En tant que personne ayant une expérience à la fois de C # et d’Objective-C, je dirais que pour la plupart des gens, Xamarin vaudra le coup.

C # est un très bon langage conçu et les API C # sont également bien conçues. Bien sûr, les API de Cocoa Touch (y compris UIKit) ont également un excellent design, mais le langage peut être amélioré de plusieurs manières. Lorsque vous écrivez en C #, vous serez probablement plus productif que d’écrire le même code dans Objective-C. Cela est dû à plusieurs raisons, mais certaines raisons pourraient être:

  • C # a une inférence de type . L’inférence de type rend l’écriture de code plus rapide, puisque vous n’avez pas à “connaître” le type à gauche d’une affectation. Cela rend également le refactoring plus facile et plus économique.

  • C # a des génériques , ce qui réduira les erreurs par rapport au code Objective-C équivalent (bien qu’il y ait quelques solutions dans Objective-C, dans la plupart des cas, les développeurs les éviteront).

  • Récemment, Xamarin a ajouté un support pour Async / Await , ce qui rend l’écriture asynchrone très facile.

  • Vous pourrez réutiliser une partie de la base de code sur iOS, Android et Windows Phone.

  • MonoTouch implémente largement les API CocoaTouch de manière très simple. Par exemple: si vous avez de l’expérience avec CocoaTouch, vous saurez où trouver des classes pour les contrôles dans MonoTouch (MonoTouch.UIKit contient des classes pour UIButton, UIView, UINavigationController, etc., ainsi que MonoTouch.Foundation pour les classes NSSsortingng, NSData, etc …).

  • Xamarin offrira aux utilisateurs une expérience native, contrairement aux solutions telles que PhoneGap ou Titanium.

Maintenant, Objective-C présente certains avantages par rapport à C #, mais dans la plupart des cas, l’écriture d’applications en C # se traduira généralement par une réduction du temps de développement et du code plus propre. Une exception notable pourrait être les jeux à haute performance basés sur OpenGL.

Le coût de la bibliothèque MonoTouch est totalement hors de propos. La raison pour laquelle vous ne devriez pas utiliser Mono pour vos applications iPhone, c’est que c’est une béquille. Si vous ne pouvez pas prendre la peine d’apprendre les outils natifs, je n’ai aucune raison de croire que votre produit mérite d’être téléchargé.

Edit: 14/04/2010 Les applications écrites avec MonoTouch ne sont pas éligibles pour iTunes Store. C’est comme il se doit. Apple a vu beaucoup de ports peu profonds sur Mac, utilisant des toolkits multi-plateformes comme Qt, ou la ré-implémentation partielle de la boîte à outils System 7 d’Adobe.