Comment choisir entre MonoTouch et Objective-C? [fermé]

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

Quelqu'un a-t-il une expérience de développement avec MonoTouch et Objective-C, et si tel est le cas avec MonoTouch, c'est beaucoup plus simple et plus rapide que d'apprendre Objective-C, et en retour vaut 400 $?

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

J'ai mes préférences (j'aime les deux piles), mais c'est là que la plupart des «réponses» commencent à mal tourner. Cela ne devrait pas concerner ce que je veux (ou ce que quelqu'un d'autre veut).

Voici comment je procéderais pour déterminer la valeur de MonoTouch - je ne peux pas être objectif, évidemment, mais je pense que c'est assez sans fanatisme:

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

• Voulez-vous apprendre la plate-forme à l'envers, ou voulez-vous "simplement" écrire des applications pour elle?

• Aimez-vous suffisamment .Net pour que l'utilisation d'une pile de développement différente vous enlève le plaisir? Encore une fois, j'aime les deux piles (Apple et Mono), mais pour moi, MonoTouch rend l'expérience beaucoup plus amusante. Je n'ai pas cessé d'utiliser les outils d'Apple, mais c'est principalement parce que j'aime vraiment les deux piles . J'adore 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 veux pas dire Objective-C, mais C - c'est important parce que Objective-C est C. C'est une version OO sympa, élégante et conviviale, mais si les pointeurs vous donnent les heebie-jeebies, MonoTouch est votre ami. Et n'écoutez pas les opposants qui pensent que vous êtes un witch dev s'il arrive que vous n'aimez pas les pointeurs (ou C, etc.). Je me promenais avec une copie de l'IBM ROM BIOS Pocket Reference, et quand j'écrivais l'assemblage et forçais mon ordinateur dans des modes vidéo drôles et écrivais mes propres bits de rendu de police pour eux et les systèmes de fenêtrage (certes trash), je ne faisais pas '' Je pense que les développeurs QuickBasic étaient des wusses. J'étaisun développeur QuickBasic (en plus du reste). Ne cédez jamais au machisme nerd. Si vous n'aimez pas C, et si vous n'aimez pas les pointeurs, et si vous voulez rester aussi loin que possible de la gestion manuelle de la mémoire (et, pour être honnête, ce n'est pas mal du tout en ObjC), alors. .. MonoTouch. Et ne vous en faites pas.

• Souhaitez-vous cibler des utilisateurs ou des entreprises? Cela n'a pas beaucoup d'importance pour moi, mais il y a encore des gens sur Edge, et le fait est: vous pouvez créer un package de téléchargement beaucoup plus petit si vous utilisez la pile d'Apple. J'ai joué avec MonoTouch, et j'ai une petite application décente qui, une fois compressée, atteint environ 2,7 Mo (lorsque vous soumettez votre application pour distribution, vous la fermez - lorsque les applications sont téléchargées depuis la boutique, elles '' zippé à nouveau - donc lorsque vous déterminez si votre application va entrer sous la limite de 10 Mo OTA, fermez d'abord la ventouse - vous serez agréablement surpris par MonoTouch). Mais, le bonheur MT mis à part, une demi-méga contre près de trois (par exemple) est quelque chose qui pourrait être important pour vous si vous ciblez les utilisateurs finaux. Si vous songez au travail en entreprise, quelques Mo n'auront aucune importance. Et, juste pour être clair - je vais bientôt soumettre une application basée sur MT au magasin, et je n'ai aucun problème avec la taille. Ça ne me dérange pas du tout. Mais si c'est quelque chose qui concerneraitvous , alors la pile d'Apple gagne celle-ci.

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

• Manipulation de chaînes? Manipulation de date? Un million d'autres petites choses auxquelles nous nous sommes habitués avec les cadres tout-ET-la-cuisine-évier de .Net? MonoTouch.

• Services Web? MonoTouch.

• Syntaxiquement, ils ont tous deux leurs avantages. Objective-C a tendance à être plus verbeux là où vous devez l'écrire . Vous vous retrouverez à écrire du code avec C # que 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 d'un autre monde à Objective-C, j'ai appris à l'apprécier un peu. Je me moque de un peu en pourparlers (il est bizarre pour les devs qui sont utilisés pour C # / Java / etc.), Mais la vérité est que j'ai une forme Objective-C place dans mon cœur qui me rend heureux.

• Envisagez-vous d'utiliser Interface Builder? Parce que, même dans cette première version, je me retrouve à faire beaucoup moins de travail pour créer mes interfaces utilisateur avec IB, puis les utiliser dans le code. Il semble que des étapes entières manquent dans la façon de faire Objective-C / IB, et je suis sûr que c'est parce que des étapes entières manquent dans la façon de faire Objective-C / IB. Jusqu'à présent, et je ne pense pas avoir suffisamment testé, mais jusqu'à présent , MonoTouch est le gagnant ici pour combien moins de travail vous avez à faire.

• Pensez-vous que c'est amusant d'apprendre de nouvelles langues et plateformes? Si c'est le cas, l'iPhone a beaucoup à offrir, et la pile d'Apple vous sortira probablement de votre zone de confort - ce qui, pour certains développeurs, est amusant (Salut - je suis l'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 à mon premier point: si c'est pour les affaires et si vous pouvez obtenir le travail, vous gagnerez votre argent immédiatement.

Donc ... c'est aussi objectif que possible. Voici une courte liste de ce que vous pourriez vous demander, mais c'est un point de départ.

Personnellement (laissons tomber l'objectivité un instant), j'adore et j'utilise les deux. Et je suis content d'avoir d'abord appris la pile Apple. Il était plus facile pour moi de devenir opérationnel avec MonoTouch alors que je connaissais déjà mon chemin dans le monde d'Apple. Comme d'autres l'ont dit, vous allez toujours travailler avec CocoaTouch - cela va juste être dans un environnement .Net-ized.

Mais il y a plus que ça. Les gens qui n'ont pas utilisé MonoTouch ont tendance à s'arrêter là - "C'est un emballage bla bla bla" - ce n'est pas MonoTouch.

MonoTouch vous donne accès à ce que CocoaTouch a à offrir tout en vous donnant accès à ce que (un sous-ensemble de) .Net a à offrir, un IDE avec lequel certaines personnes se sentent plus à l'aise (j'en fais partie), une meilleure intégration avec Interface Builder , et bien que vous n'ayez pas à oublier complètement la gestion de la mémoire, vous bénéficiez d'une bonne marge de manœuvre.

Si vous n'êtes pas sûr, prenez la pile d'Apple (c'est gratuit) et prenez la pile d'évaluation 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 à savoir si vous préférez largement l'un à l'autre, et possible si MonoTouch vaut, pour vous, la valeur de 399 $.

Et n'écoutez pas les fanatiques - ils ont tendance à être ceux qui n'ont pas utilisé la technologie contre laquelle ils se repentent :)

Il y a beaucoup de ouï-dire dans ce post de développeurs qui n'ont pas essayé MonoTouch et Objective-C. Il semble que ce soient principalement des développeurs Objective-C qui n'ont jamais essayé MonoTouch.

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

http://xamarin.com

Vous y trouverez plusieurs articles de développeurs ayant développé à la fois Objective-C et C #.

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

Cela va probablement offenser certains mais pour être honnête, si vous voulez faire un développement sérieux, vous devriez apprendre Objective-C. Ne pas connaître Objective-C dans le développement d'iPhone ne sera qu'un obstacle. Vous ne pourrez pas comprendre de nombreux exemples; vous devez gérer les bizarreries de Mono alors que si vous aviez une connaissance pratique d'Objective-C, vous pourriez tirer beaucoup plus de la documentation de la plate-forme.

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 par rapport à la langue maternelle de la plate-forme. Cela me semble quelque peu contre-productif. Je pense que si c'est une proposition très coûteuse (apprendre un nouveau langage), cela peut valoir la peine de passer du temps sur des concepts de programmation fondamentaux pour que l'apprentissage de nouveaux langages soit une proposition assez bon marché.

Un autre utilisateur a également écrit ceci:

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

Par exemple, que se passe-t-il lorsque de nouvelles graines sortent, que vous devez tester mais casser MonoTouch pour une raison quelconque?

En restant avec Mono, chaque fois que vous recherchez des ressources pour les frameworks, vous devez traduire mentalement la façon dont vous allez les utiliser avec Mono. Vos binaires d'application seront plus volumineux, votre temps de développement ne sera pas beaucoup plus rapide après quelques mois dans Objective-C, et les autres développeurs d'applications auront d'autant plus d'avantages sur vous car ils utilisent la plate-forme native.

Une autre considération est que vous cherchez à utiliser C # parce que vous connaissez mieux le langage qu'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, c'est-à-dire Objective-C. Pensez à cela sous l'angle inverse, si un développeur Linux habitué à la programmation en GTK voulait écrire des applications Windows, recommanderiez-vous sérieusement de ne pas utiliser C # et de s'en tenir à GTK parce que c'était "plus facile" pour eux de le faire?

Utiliser Mono n'est pas une béquille. Il y a beaucoup de choses qu'il ajoute à l'iPhone OS. LINQ, WCF, code partageable entre une application Silverlight, une page ASP.NET, une application WPF, une application Windows Form, et il y a aussi mono pour Android et cela fonctionnera également pour Windows Mobile.

Ainsi, vous pouvez passer beaucoup de temps à écrire Objective-C (vous verrez dans de nombreuses études où le même exemple de code exact en C # est beaucoup moins à écrire qu'en OC), puis DUPLICATE it all pour d'autres plates-formes. Pour moi, j'ai choisi MonoTouch car l'application Cloud que j'écris aura de nombreuses interfaces, l'iPhone n'étant qu'une seule d'entre elles. La diffusion en continu des données WCF depuis le cloud vers l'application MonoTouch est incroyablement simple. J'ai des bibliothèques de base qui sont partagées entre les différentes plates-formes et je n'ai plus qu'à écrire une simple couche de présentation pour les déploiements iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET. Recréer le tout dans Objective-C serait une énorme perte de temps à la fois pour le développement initial et la maintenance, car le produit continue d'avancer, 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 de celui-ci ont besoin d'une béquille ne savent pas ce que signifie avoir le cadre .NET à portée de main et ne comprennent peut-être pas la séparation appropriée de la logique de la présentation d'une manière qui peut être réutilisé sur toutes les plateformes et tous les appareils.

Objective-C est intéressant et très différent de nombreux langages courants. J'aime un défi et apprendre différentes approches ... mais pas lorsque cela empêche ma progression ou crée un recodage inutile. Il y a de très bonnes choses sur le framework SDK iPhone, mais toute cette grandeur 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, me permet de réutiliser mes assemblages, et 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 vite (4 applications par mois par rapport à mon ancienne 1 par mois en Obj C)

Beaucoup moins de frappe.

Juste mon expérience.

Si c'est la seule application iPhone que vous développez jamais, et que vous n'avez également aucun intérêt à développer des applications Mac, alors MonoTouch en vaut probablement le coût.

Si vous pensez que vous développerez un jour plus d'applications iPhone, ou que vous voudrez jamais faire du développement natif pour 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 passerez un meilleur moment en apprenant simplement Objective-C.

En bref:

• "Learning Objective-C" n'est pas un défi de taille comme vous pourriez le penser, vous pouvez même en profiter après les premières semaines
• Vous connaissez déjà la syntaxe de "style C" avec beaucoup de * & () {}; partout
• Apple a fait un très bon travail de documentation des choses
• Vous interagirez avec l'iPhone comme Apple l'avait prévu, ce qui signifie que vous obtiendrez les avantages directement de la source et non via un filtre.

J'ai trouvé que des projets comme Unity et MonoTouch sont censés vous "faire gagner du temps", mais en fin de compte, vous devrez de toute façon apprendre leur langue spécifique au domaine et devrez parfois faire un pas de côté. Tout cela va probablement vous prendre autant de temps que pour apprendre la langue que vous essayez d'éviter d'apprendre (en temps calendaire). Au final, vous n'avez pas gagné de temps et vous êtes étroitement lié à un produit.

EDIT: Je n'ai jamais voulu suggérer quoi que ce soit de négatif à propos de .NET, il se trouve que j'en suis un grand fan. Mon point est que l'ajout de couches de complexité simplement parce que vous n'êtes pas encore à l'aise avec la notation de support objc excentrique n'a pas vraiment de sens pour moi.

Mise à jour 2019: 7 ans plus tard. Je ressens toujours la même chose sinon plus. Bien sûr, `` langage spécifique au domaine '' n'était peut-être pas le bon terme à utiliser, mais je pense toujours qu'il vaut mieux écrire directement pour la plate-forme avec laquelle vous travaillez et éviter autant que possible les couches de compatibilité et les abstractions. Si vous êtes préoccupé par la réutilisation et le retravail du code, d'une manière générale, toutes les fonctionnalités que votre application multiplateforme doit exécuter peuvent probablement être accomplies avec les technologies Web modernes.

Pour ajouter à ce que les autres ont déjà dit (enfin!): Mon sentiment est que vous doublez fondamentalement le nombre de bugs dont vous devez vous soucier, en ajoutant ceux de MonoTouch à ceux déjà dans iPhone OS. La mise à jour pour les nouvelles versions du système d'exploitation sera encore plus douloureuse que la normale. Beurk, tout autour.

Le seul cas convaincant que je puisse voir pour MonoTouch est celui des organisations qui ont beaucoup, beaucoup de programmeurs C # et du code C # qu'ils doivent exploiter sur iPhone. (Le genre de boutique qui ne clignotera même pas à 3500 $.)

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

Trois mots: Linq à SQL

Oui, cela vaut bien le $.

Quelque chose que j'aimerais ajouter, même s'il existe une réponse acceptée - qui veut dire qu'Apple ne rejettera pas seulement les applications qui ont des signes de construction avec Mono Touch?

J'investirais du temps dans Objective-C principalement à cause de toute l'aide que vous pouvez obtenir sur des sites comme celui-ci. L'une des forces d'Objective-C est que vous pouvez utiliser du code C et C ++, et il y a beaucoup de projets qui 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 comme MonoTouch? Que direz-vous alors à vos clients?

Peut-être vaut-il mieux 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 d'ObjectiveC afin de pouvoir prendre en charge Android à un moment donné dans le futur.

Voici mon expérience:

Mauvais bits:

• Xamarin Studio. Les développeurs indépendants comme moi sont obligés d'utiliser Xamarin Studio. Cela s'améliore chaque semaine, les développeurs sont très actifs sur les forums pour identifier et corriger les bugs, mais c'est toujours très lent, se bloque fréquemment, a beaucoup de bugs et le débogage est assez lent également.

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

• Problèmes de 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 en place des solutions de contournement assez laides pour éviter les fuites, telles que l'attachement et le détachement d'événements lors de l'entrée et de la sortie de vues. Les développeurs Xamarin étudient activement des problèmes comme celui-ci.

• Bibliothèques tierces. J'ai passé beaucoup de temps à convertir / lier les bibliothèques ObjectiveC à utiliser dans mon application, bien que cela s'améliore avec les logiciels automatisés tels que Objective Sharpie.

• Binaires plus grands. Cela ne me dérange pas vraiment, mais j'ai pensé le mentionner. OMI un couple de Mb supplémentaires n'est rien de nos jours.

Bons morceaux:

• Multi plateforme. Mon ami crée avec plaisir une version Android de mon application à partir de ma base de code principale, nous développons en parallèle et nous nous engageons sur un référentiel Git distant sur Dropbox, ça se passe bien.

• .Net. Travailler en C # .Net est beaucoup plus agréable que Objective C IMO.

• MonoTouch. Presque tout dans iOS est reflété dans .Net et il est assez simple de faire fonctionner les choses.

• Xamarin. Vous pouvez voir que ces gars travaillent vraiment pour tout améliorer, ce qui rend le développement plus fluide et plus facile.

Je recommande définitivement Xamarin pour le développement multiplateforme, surtout si vous avez l'argent pour 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 l'instant.

En tant que personne ayant de l'expérience avec C # ainsi qu'avec Objective-C, je dirais que pour la plupart des gens, Xamarin en vaudra bien la peine.

C # est un très bon langage conçu et les API C # sont également bien conçues. Bien sûr, les API Cocoa Touch (y compris UIKit) ont également un excellent design, mais le langage pourrait être amélioré de plusieurs façons. 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 seraient:

• C # a une inférence de type . L'inférence de type rend l'écriture de code plus rapide, car vous n'avez pas à "connaître" le type sur le côté 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 existe des solutions de contournement dans Objective-C, dans la plupart des situations, les développeurs les éviteront).

• Récemment, Xamarin a ajouté la prise en charge d' Async / Await , ce qui rend l'écriture de code 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 ..., de même MonoTouch.Foundation a des classes pour NSString, NSData, etc ...).

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

Objective-C présente maintenant certains avantages par rapport à C #, mais dans la plupart des situations, l'écriture d'applications en C # entraînera généralement moins de temps de développement et un code plus propre et moins de travail pour porter la même application sur d'autres plates-formes. Une exception notable pourrait être les jeux haute performance qui reposent sur OpenGL.

Le coût de la bibliothèque MonoTouch est entièrement hors de propos. La raison pour laquelle vous ne devriez pas utiliser Mono pour vos applications iPhone, c'est qu'il s'agit d'une béquille. Si vous ne pouvez pas vous soucier 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 l'iTunes Store. C'est comme cela devrait être. Apple a vu de nombreux ports peu profonds sur le Mac, utilisant des boîtes à outils multiplates-formes comme Qt, ou la propre re-implémentation partielle d'Adobe de la boîte à outils System 7, et le long et le court sont qu'ils ne sont tout simplement pas assez bons.