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


273

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 $?


13
Je pense que beaucoup de commentaires sur MonoTouch ne pouvant pas fonctionner sur iOS ne sont plus valables depuis qu'Apple a assoupli sa restriction des outils de développement. Voir: apple.com/pr/library/2010/09/09statement.html
sivabudh

Réponses:


520

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 :)


50
Wow, Rory, merci d'avoir pris le temps de répondre à ma question avec autant de détails. D'après ce que je peux dire, vous êtes le seul à avoir utilisé les deux options, c'est-à-dire de qui je cherchais une réponse. Je vais certainement essayer les deux à partir de là. BTW, je vous ai entendu sur le podcast SO le plus récent, non? Bon produit. Merci encore!
jamesaharvey

17
Merci pour les commentaires :) J'ai été frustré par une partie de la haine de genou que j'ai vue. À plusieurs reprises, la question est répondue par "Ur un idiot de rebondir pour lâcher le système d'exploitation en premier!" Ce qui est inutile et insultant. MonoTouch a ses points faibles, mais ces gars-là ont un historique de génie. MT a progressé rapidement et est chaque jour plus belle. Je n'arrête pas de dire: donnez-leur quelques mois. Ils sont prudents sur les fonctionnalités, mais je pense que nous allons voir de grandes choses. J'adore la pile d'Apple, mais j'ai maintenant un autre terrain de jeu - c'est une bonne chose et je suis étourdi :)
Rory Blyth

4
@Stephan - Il n'est peut-être pas juste de dire ce qui "manque" - je peux faire le travail avec Cocoa. C'est plus sur les API. Il est juste beaucoup plus facile de travailler avec des chaînes, des dates, du XML, etc., avec .Net. Je ne sais pas si vous connaissez la façon de faire .Net de ces choses, ainsi que l'étendue de la prise en charge de MonoTouch pour eux - si vous ne l'avez pas examiné, vous devriez - juste pour le vérifier. Je ne veux pas dire qu'il y a des choses que vous ne pouvez pas faire avec Cocoa, mais il y a beaucoup de choses qui sont beaucoup plus faciles à faire avec .Net. L'analyse est plus facile à tous les niveaux - les calculs de dates sont plus faciles à tous les niveaux - etc.
Rory Blyth

3
Il y a aussi le problème de votre propre réutilisation de code dans l'iPhone / iPad avec MT. Nous avons du code crypto et du code de logique métier, en cours d'exécution sur nos homologues de serveur et de bureau, que nous pourrions simplement recompiler avec MT et utiliser dans notre application client iOS. Cela peut être important pour certains projets.
Monoman

2
Il convient également de tenir compte du fait que, bien que la licence coûte 400 $, il existe également un abonnement de maintenance que vous devez renouveler (pour des raisons évidentes) chaque année - 250 $. C'est probablement un prix juste, mais ça vaut quand même la peine d'être pris en considération.
Amc_rtty

62

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 #.


29
@NSResponder - Avez-vous utilisé MonoTouch? C'est une version v1.x, pratiquement neuve, et est déjà incroyable. Essayez-le avant de le commenter. Il y a de grands changements (son intégration Interface Builder est bien meilleure que celle de Xcode), et il y a peu de changements (comparez la façon ObjC / Cocoa d'obtenir le dossier de documents de l'utilisateur par rapport aux MT, par exemple). J'utilise toujours la pile d'Apple pour certaines choses, mais MT est beau et plein de potentiel. Sérieusement - essayez-le. Ou regardez comment les API Cocoa ont été liées - vous n'avez pas à l'utiliser - ne jetez pas le travail sans en avoir connaissance .
Rory Blyth

Oui! De plus, certaines des nouvelles fonctionnalités C # 5.0 rendent le codage encore plus amusant par rapport à objective-c.
harsimranb

39

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?



12
Vous avez, probablement involontairement, déformé MT. Ce n'est pas du tout - pas à distance - analogue à l'utilisation de GTK pour écrire des applications Win. Les fixations MT sont très fidèles à CocoaTouch. Ils ont en fait amélioré certaines des conventions de l'API CT. Mais vous n'écrivez pas vos applications en utilisant, par exemple, une abstraction basée sur Windows Forms sur CT. MT avec MonoDevelop a une meilleure intégration avec IB que Xcode (si vous le souhaitez), et vous pouvez souvent faire les mêmes choses avec la moitié du code ou moins. La taille binaire est en cours d'amélioration et les outils (générateur de reliures, etc.) sont toujours meilleurs. Une application MT est une application native.
Rory Blyth,

7
Pour donner des exemples plutôt que de vous attendre à prendre mon opinion (évidemment) MT-fanboy seule, je peux faire des choses comme (et ce n'est qu'un minuscule sous-ensemble d'avantages): créer une propriété avec une seule ligne; saisir une référence au dossier Document sans spéléologie ridicule (une application a un dossier docs, toujours au même endroit - pourquoi tout le travail supplémentaire pour le "trouver"?); utiliser le framework .Net où Cocoa pue (NSDate, n'importe qui?); utiliser les compétences de base pour les applications d'entreprise; utilisez des bits XML appropriés et modernes (j'adore quand Cocoa s'étouffe silencieusement sur les caractères et s'arrête simplement - pas de plantage - s'arrête juste ).
Rory Blyth,

8
Je ne dis pas que je l'utiliserais pour tout. J'aime ObjC et je l'utilise toujours. Et, si les performances sont un problème, j'ai un contrôle plus précis sur ce qui se passe. Mais ... il y a des moments où MT aura plus de sens, et je pense que cela fera de l'iPhone une option viable pour le développement des entreprises. Jetez un rocher en l'air et vous atteindrez un développeur .Net. La plupart des entreprises ne disposent pas de développeurs ObjC internes. Et pour le travail en entreprise, ils ne devraient pas avoir à le faire. MT est beaucoup plus facile à utiliser avec les services Web et les bases de données. Vous pouvez vraiment écrire de nombreux types d'applications avec MT avec la moitié du code qu'il faudrait en ObjC.
Rory Blyth,

8
Enfin (je pourrais continuer, mais je pense que je fais mt point), les changements qui "cassent" MonoTouch sont probablement tout aussi susceptibles de casser les applications ObjC. Une fois que votre application est dans le magasin, c'est une application iPhone native (comme il se doit). Les appels ne sont finalement pas différents - même temps d'exécution que les applications construites avec la pile d'Apple. Si votre application MT tombe en panne en raison d'une modification de l'environnement d'exécution, il en sera de même des applications créées avec ObjC. Et l'équipe MT a été au top de tout ça, publiant rapidement des mises à jour et des corrections de bugs. Les liaisons de MT sont suffisamment proches des CT pour que la probabilité de tout problème réel soit faible. Aight - Je vais me taire maintenant :)
Rory Blyth

27

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.


19

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.


2
"4 applications par mois" - Lorsque la quantité est plus importante que la qualité. MT est comme McDonalds. Mais vous obtenez une meilleure nourriture au XCode-Restaurant.
netshark1000

2
Les résultats parlent cependant différemment, Rdio et iCircuit sont des applications MT démontrées par Steve Jobs. C # et MT se débarrassent du travail de plomberie que obj-C vous oblige à faire.
Ian Vink

17

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.


6
Si c'est la seule application iPhone que vous développez, le 99 $ / an n'en vaut pas la peine non plus.
Dinah

Vous pouvez utiliser les mêmes outils de développement C # pour créer des applications Mac. En fait, vous pouvez coder le partage entre les applications iPhone C # et Mac C #. MonoTouch s'appelle désormais Xamarin
Ian Vink

9

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.


12
Tout d'abord, C # n'est pas un "langage spécifique au domaine" - loin de là. C'est une compétence de base. Cela fait partie de la valeur de MonoTouch. On pourrait faire valoir (de manière injuste et inexacte) qu'ObjC est une DSL dans la mesure où la plupart des développeurs (en dehors des laboratoires financiers et universitaires et des sous-sols) ne l'utiliseront que pour le développement d'OS X ou d'iPhone. Mais ce n'est pas le cas. Comme C #, c'est un langage polyvalent qui existe essentiellement pour vous permettre de vous concentrer sur les cadres plutôt que sur le langage lui-même (je pense que nous sommes d'accord là-bas). Mais gardez à l'esprit que votre code ObjC rompra avec les mises à jour d'Apple. Ce n'est pas un problème spécifique à MT.
Rory Blyth

3
MT pourrait même vous sauver dans certains cas, car il y a cette couche d'abstraction. Apple modifie une API? Eh bien, votre application ObjC et votre application (supposons qu'elle existe) MT équivalente se briseront. Les gars de MT pourraient libérer une solution de colmatage pour modifier la façon dont l'API MonoTouch traite l'appel dans les coulisses. Votre code MT ne devrait pas changer - vous pouvez simplement reconstruire avec la version stopgap MT. Oui: c'est un correctif sale qui pourrait facilement entraîner des problèmes, mais la dépréciation appropriée de l'API MT stopgap donnerait aux développeurs le temps de gérer le changement de manière transparente et de gagner du temps pour un vrai correctif.
Rory Blyth,

4
De plus, aussi nouveau que MT, il est devenu beaucoup plus facile de créer vos propres fixations si nécessaire (MT 1.2). Vous n'êtes pas complètement dépendante sur les MT coups d' oeil à faire tout ce travail (bien qu'ils sont en train de faire ce travail), et n'a jamais été. Ils ont des façons simples de créer des liaisons. Ils exposent suffisamment de runtime ObjC avec les frameworks MT pour que vous ne soyez pas enfermé dans leur façon de faire les choses. J'ai réimplémenté les fixations juste pour voir si j'aime mieux ma façon. Vous pouvez ignorer les frameworks MT et envoyer et recevoir des messages "manuellement" si vous le souhaitez, et cela prend peu de code. Ce sont des gens intelligents. Faites-leur confiance :)
Rory Blyth

2
Je pense que slf n'est pas conscient du fait que Monotouch est juste C # (avec GC) qui se lie directement aux bibliothèques ObjC + bibliothèques .NET facultatives. Vous utilisez donc toujours l'API fournie par apple. Mais avec une syntaxe et une collecte des ordures plus soignées.
basarat

4

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.


-1: Qu'entendez-vous par "plus de bugs"? Y a-t-il un décalage flagrant d'impédance entre Mono et Objective-C?
Jim G.

4

Trois mots: Linq à SQL

Oui, cela vaut bien le $.


4
Avec les liaisons de valeur-clé et les données de base d'Objective-C, vous obtenez quelque chose de très similaire à Linq-to-SQL. Pas le même. Peut-être pas aussi puissant - mais couvrant beaucoup du même terrain. Notez que Core-Data n'est pas actuellement pris en charge par MonoTouch
philsquared

Linq to SQL est-il même pertinent pour une application iPhone? Ça marche avec SQLite?
bpapa

1
Et vous voulez que vos utilisateurs partagent des données sur un réseau. Que faites-vous avec SQL Lite?
Bryan

"MonoTouch est basé sur un profil API hybride .NET 2.0 et Silverlight 2" LINQ to objects est-il pris en charge?
Chris S

2

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?


Ils le devraient certainement, et ils devraient également rejeter les applications Flash, mais leurs termes App Store ne les empêchent pas de les utiliser.
NSResponder

3
@bpapa - c'est une préoccupation tout à fait valable, mais: 1) Il n'y a aucune raison de rejeter les applications (les utilisateurs ne se soucient pas de ce avec quoi leurs applications sont écrites - ils se soucient des applications elles-mêmes), et 2) MonoTouch a beaucoup de potentiel pour le développement d' entreprise , et tant que vous avez un compte de développement d'entreprise, Apple ne peut pas vous empêcher de distribuer votre application. De plus, Apple accepte les jeux construits avec Unity. En fin de compte, MT suit les règles. Le processus d'Apple semble parfois aléatoire, mais ... MT suit les règles: |
Rory Blyth,

1
@bpapa - Je ne sais pas comment j'ai manqué ce commentaire pendant si longtemps, mais: 1) Des tonnes d'applications ObjC sont "bloquées" pour l'utilisation d'API non documentées ("privées") - FB, comme vous l'avez noté, étant l'une d'entre elles, pourtant FB est toujours en vie et disponible en téléchargement, 2) Le problème d'Unity a été rapidement résolu et Unity est de retour. - En ce qui concerne Apple qui veut que vous utilisiez ses propres trucs, je ne suis pas en désaccord, mais les souhaits et les exigences sont très différents. Comme pour les applications d'entreprise: vous pouvez déployer des applications d'entreprise MT. Ce ne sont que des binaires natifs. Je ne vois pas le problème et je ne comprends pas pourquoi vous êtes si anti-MT.
Rory Blyth

1
Je dois ajouter que ce n'est pas que je "déteste" la syntaxe d'ObjC, mais que je préfère de loin C #. Je préfère également les méthodes du framework .Net à celles de Cocoa. Manipulation de chaînes, traitement XML, tout ce qui implique des dates, etc. - J'utiliserai les liaisons MT CocoaTouch pour le travail de l'interface utilisateur, mais pour la plupart des autres tâches, le sous-ensemble du cadre .Net fourni avec MT facilite la vie. Je pourrais continuer indéfiniment (comme ma préférence pour trouver certains bogues au moment de la compilation ). Je critique la pile d'Apple, mais je ne l'aime pas. Il est possible d'aimer MT et ObjC / etc.
Rory Blyth,

1
Apple a changé d'avis et accepte désormais les applications dans n'importe quel langage / cadre, et établit une liste de critères plus «objectifs» pour accepter les applications sur la boutique.
Monoman

2

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?


Je trouve l'argument qu'en utilisant MonoTouch vous vous retrouvez enfermé dans un fournisseur qu'Apple pourrait arrêter pour autoriser / soutenir très fort. Vous pourriez finir par investir dans une plate-forme qui est à la merci d'une pomme qui a sa propre plate-forme de développement de toute façon ...
jl.

2

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.


Une mise à jour rapide sur ma réponse ci-dessus. Depuis que je suis passé à un Mac plus rapide, j'ai trouvé que les temps de construction étaient beaucoup plus rapides, ce n'est toujours pas instantané comme XCode mais c'est bien.
danfordham

1

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.


-35

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.


14
La part de marché de Mac OS X est très faible et l'iPhone est donc pour beaucoup la seule raison impérieuse d'envisager de s'embêter avec X-Code et ObjC. Les deux étaient excellents il y a plus de 15 ans quand il s'agissait de Project Builder et ont fait des complications et des emballages multiplateformes, mais franchement - en tant que personne qui utilise une gamme de plates-formes - avec sans doute de meilleurs outils et langages maintenant, il n'est pas surprenant que les développeurs souhaitent tirer parti d'un outil commun. base de code et utiliser des outils de développement alternatifs. Cela n'implique pas que leurs créations seront inférieures au pair.
Iain Collins

37
Je ne sais pas, mec ... Je pense que Objective-C et CocoaTouch sont une béquille. Si vous n'écrivez pas d'assemblage, je vais avoir l'impression que vous ne vous en souciez pas beaucoup, et je ne vais pas télécharger votre application (car la première chose que les utilisateurs font, bien sûr, est de vérifier quels outils étaient utilisé pour construire l'application de simulation de flatulence qu'ils téléchargent).
Rory Blyth

3
Andrew, vous ne savez pas de quoi vous parlez. Objective-C n'est pas un remous; c'est l'épine dorsale de l'environnement de développement natif pour Mac, iPhone et iPad.
NSResponder

5
Donc, vous choisissez un exemple simple de quelque chose qu'Apple a intégré dans le cadre et revendiquez la supériorité, tout en ignorant commodément les parties du cadre qui sont beaucoup plus maladroites que l'équivalent C #? N'est-ce pas quelque chose d'un argument de paille?
Andrew Rollings du

8
Je suis passé à MonoTouch et j'ai publié jusqu'à présent 47 applications sur 4.0. Je le fais à plein temps. Fonctionne très bien, rapidement. J'avais l'habitude d'écrire en Objective C mais de trouver C # avec Linq plus rapidement avec beaucoup moins de code à écrire.
Ian Vink
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.