Après avoir passé une session aujourd'hui sur Mono lors d'un événement .Net local, l'utilisation de MonoTouch a été "évoquée" comme une alternative au développement d'un iPhone. Étant très à l'aise en C # et .Net, cela semble être une option attrayante, en dépit de la bizarrerie de la pile Mono. Cependant, comme MonoTouch coûte 400 dollars, je suis un peu déchiré si c'est la voie à suivre pour le développement d'un iPhone.
Quelqu'un a-t-il déjà développé avec MonoTouch et Objective-C, et si tel est le cas, le développement avec MonoTouch est-il beaucoup plus simple et rapide que d'apprendre Objective-C, avec une valeur de 400 $?
J'ai souvent vu cette question (et ses variations) récemment. Ce qui me surprend, c’est la fréquence à laquelle les gens répondent, mais combien peu answer .
J'ai mes préférences (j'aime les deux piles), mais c'est là que la plupart des "réponses" commencent à aller mal. Cela ne devrait pas concerner ce que je veux (ou ce que quelqu'un d'autre veut).
Voici comment procéder pour déterminer la valeur de MonoTouch - je ne peux évidemment pas être objectif, mais je pense que cela ne nécessite pas de fanatisme:
Est-ce pour le plaisir ou les affaires? Si vous vouliez faire de la consultation dans ce domaine, vous pourriez récupérer très rapidement votre somme de 399 $.
Voulez-vous apprendre la plate-forme à fond ou voulez-vous simplement "écrire" des applications pour cela?
Aimez-vous suffisamment .Net pour que l’utilisation d’une pile de développement différente en retire le plaisir? Encore une fois, j'aime les deux piles (Apple et Mono), mais pour moi, MonoTouch rend l'expérience encore plus amusante. Je n'ai pas arrêté d'utiliser les outils d'Apple, mais c'est principalement parce que je aime vraiment les deux piles . J'aime l'iPhone et j'aime .Net. Dans ce cas, MonoTouch était pour moi une évidence.
Vous sentez-vous à l'aise de travailler avec C? Je ne veux pas dire Objective-C, mais C - ça compte car Objective-C est C. C'est une version agréable, élégante et conviviale OO, 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 développeur si il vous arrive not comme des pointeurs (ou C, etc.). J'avais l'habitude de me promener avec une copie de l'IBM ROM BIOS Pocket Reference, et lorsque j'écrivais Assembly et forçais mon ordinateur dans des modes vidéo amusants et que j'écrivais mes propres bits de rendu de police pour eux et (certes trash) systèmes de fenêtrage, je ne pensais pas que les développeurs QuickBasic étaient des wusses. I était un dev QuickBasic (en plus du reste). Ne jamais céder au machisme nerd. Si vous n'aimez pas le 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 juste, ce n'est pas mal du tout dans ObjC), alors. .. MonoTouch. Et ne prenez pas de guff pour cela.
Souhaitez-vous cibler des utilisateurs ou des entreprises? Cela n'a pas beaucoup d'importance pour moi, mais il y a toujours des utilisateurs sur Edge, et le fait est que vous pouvez créer un package de téléchargement beaucoup plus petit si vous utilisez la pile d'Apple. Je joue 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 la distribution, vous la zippez - lorsque les applications sont téléchargées du magasin, elles ' re zippé - alors, pour déterminer si votre application va entrer sous la limite de 10 Mo OTA, fermez le ventouse en premier - vous serez agréablement surpris par MonoTouch). Mais, MT côté bonheur, un demi-octet contre près de trois (par exemple) est peut-être un élément 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 soumettre une application basée sur MT au magasin rapidement, et je n’ai aucun problème avec la taille. Ne me dérange pas du tout. Mais si c'est quelque chose qui concerne you , alors la pile d'Apple gagne celle-ci.
Faire du travail XML? MonoTouch. Période.
Manipulation de chaîne? Manipulation de la date? Un million d'autres petites choses auxquelles nous nous sommes habitués avec les frameworks tout-ET-la-cuisine-évier de .Net? MonoTouch.
Services Web? MonoTouch.
Syntaxiquement, ils ont tous les deux leurs avantages. Objective-C a tendance à être plus bavard où il faut l'écrire . Vous vous retrouverez à écrire du code en 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 face à Objective-C, j'ai appris à en profiter un peu. Je me moque un peu en discussions (c'est est bizarre pour les développeurs habitués à C #/Java/etc.), Mais la vérité est que j'ai un objectif- C forme de tache dans mon coeur qui me rend heureux.
Prévoyez-vous d'utiliser Interface Builder? Parce que, même dans cette première version, je me retrouvais beaucoup moins à construire mes interfaces utilisateur avec IB, puis à les utiliser dans le code. Il me semble que des étapes entières manquent à la façon de faire Objective-C/IB, et je suis presque certaine que c'est parce que des étapes entières manquent à 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 de nouvelles plateformes? Si c'est le cas, l'iPhone a beaucoup à offrir, et la pile d'Apple vous sortira probablement de votre zone de confort - qui, pour certains développeurs, est fun (Bonjour, je m un de ces développeurs - je plaisante à ce sujet et je passe un difficile moment à Apple, mais je me suis beaucoup amusé à apprendre le développement d’un iPhone à l’aide des 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 allez récupérer votre argent.
Donc ... c'est à peu près aussi objectif que possible. Voici une courte liste de ce que vous pourriez vous demander, mais c'est un point de départ.
Personnellement (abandonnons un instant l'objectivité), j'aime et utilise les deux. Et je suis heureux d’avoir appris la pile Apple en premier. Il était plus facile pour moi de commencer à utiliser MonoTouch lorsque je connaissais déjà le monde d’Apple. Comme d’autres l’ont déjà dit, vous allez toujours travailler avec CocoaTouch, mais uniquement 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 bla 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) a à offrir, un IDE avec lequel certaines personnes se sentent plus à l'aise (j'en suis un) , meilleure intégration avec Interface Builder, et même si vous n’oubliez pas complètement la gestion de la mémoire, vous disposez d’une marge de manœuvre agréable.
Si vous n'êtes pas sûr, récupérez la pile d'Apple (c'est gratuit), et récupérez la pile MonoTouch eval (c'est gratuit). Tant que vous ne rejoindrez pas le programme de développement d’Apple, les deux versions ne fonctionneront que sur le simulateur, mais c’est suffisant pour vous aider à déterminer si vous préférez vraiment l’un à l’autre, et si MonoTouch vous rapportera 399 $.
Et n'écoutez pas les fanatiques - ils ont tendance à être ceux qui n'ont pas utilisé la technologie contre laquelle ils se plaignent :)
Il y a beaucoup de rumeurs dans ce billet de développeurs qui n'ont pas essayé MonoTouch et Objective-C. Il semble s'agir 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 réalisé:
Vous y trouverez plusieurs articles de développeurs développés à la fois en Objective-C et en C #.
Donc, ma réponse à une précédente question similaire est d'apprendre Objective-C. (N'oubliez pas non plus le support de débogage)
Cela heurtera probablement 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 de l'iPhone ne sera qu'un obstacle. Vous ne serez pas en mesure de comprendre de nombreux exemples; vous devez faire face aux bizarreries de Mono alors que si vous aviez une connaissance pratique d'Objective-C, vous pourriez obtenir 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 sur la langue maternelle de la plate-forme. 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 vaut peut-être la peine de passer un peu de temps sur les concepts fondamentaux de la programmation afin que l’apprentissage de nouvelles langues soit une proposition assez économique.
n autre utilisateur a aussi écrit ceci:
Monotouch est plus facile pour vous maintenant. Mais plus difficile plus tard.
Par exemple, que se passe-t-il lorsque de nouvelles graines sortent et que vous devez tester mais casser MonoTouch pour une raison quelconque?
En restant avec Mono, chaque fois que vous recherchez des ressources pour des frameworks, vous devez traduire mentalement la manière dont vous allez les utiliser avec Mono. Les fichiers binaires de votre application seront plus volumineux, votre temps de développement ne sera pas beaucoup plus rapide après quelques mois avec Objective-C, et les autres développeurs d’applications auront un avantage bien plus grand sur vous car ils utilisent la plate-forme native.
Une autre considération est que vous envisagez d'utiliser C # parce que vous maîtrisez 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 appeler en 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 qui programmait dans 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" pour eux?
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 mono pour Android et cela fonctionnera également pour Windows Mobile .
Vous pouvez donc passer beaucoup de temps à écrire Objective-C (vous constaterez dans de nombreuses études que le même exemple de code en C # est beaucoup moins écrit que OC), puis dupliquez le tout pour d'autres plates-formes. Pour moi, j'ai choisi MonoTouch parce que l'application Cloud que je suis en train d'écrire aura de nombreuses interfaces, l'iPhone n'étant que l'une d'entre elles. Transférer des données WCF en continu depuis le cloud vers l'application MonoTouch est extrêmement simple. J'ai des bibliothèques de base qui sont partagées entre les différentes plates-formes et il ne reste alors plus qu'à écrire une couche de présentation simple 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 de progresser, toutes les fonctionnalités ayant être répliqué plutôt que réutilisé.
Les personnes qui insultent MonoTouch ou insinuent que ses utilisateurs ont besoin d'une béquille n'ont pas une vue d'ensemble de ce que signifie avoir le framework .NET à portée de main et ne comprennent peut-être pas la séparation appropriée de la logique entre la présentation et la présentation. peut être réutilisé sur plusieurs plates-formes et appareils.
Objective-C est intéressant et très différent de nombreux langages courants. J'aime les défis et apprendre différentes approches ... mais cela ne gêne pas mon progrès ou ne crée pas de recodage inutile. Le framework SDK pour iPhone présente de très bonnes choses, mais toute cette splendeur 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 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, jamais, MonoTouch en vaut probablement la peine.
Si vous pensez que vous développerez plus d'applications iPhone, ou voudrez faire du développement natif 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:
J'ai constaté que les projets comme Unity et MonoTouch sont supposés "vous faire gagner du temps", mais vous devrez au final apprendre le langage spécifique à votre domaine et vous devrez parfois vous écarter des choses. Tout cela va probablement vous prendre tout le temps nécessaire pour apprendre la langue que vous tentiez d'éviter d'apprendre (dans le calendrier). En fin de compte, vous n'avez pas économisé de temps et vous êtes étroitement lié à certains produits.
EDIT: Je n’ai jamais voulu dire quoi que ce soit de négatif sur .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 de parenthèse bizarre d'objet ne me semble pas vraiment logique.
Pour ajouter à ce que d’autres ont déjà dit (enfin!): J’ai l’impression que vous doublez le nombre de bugs dont vous devez vous soucier, en ajoutant ceux de MonoTouch à ceux déjà présents dans iPhone OS. La mise à jour pour les nouvelles versions du système d'exploitation sera encore plus pénible que la normale. Beurk, tout autour.
Le seul cas convaincant que je puisse voir pour MonoTouch concerne les organisations qui ont beaucoup de programmeurs C # et de code C # qui traînent et qui doivent tirer parti de l’iPhone. (Le genre de magasin qui ne clignote même pas à 3500 $.)
Mais pour ceux qui partent de zéro, je ne peux vraiment pas le voir comme valable ou sage.
Trois mots: Linq to SQL
Oui, ça vaut bien le $.
J'investirais mon temps dans Objective-C principalement à cause de toute l'aide que vous pouvez obtenir de sites comme celui-ci. L’un des points forts d’Objective-C est que vous pouvez utiliser du code C et C++, et il existe de nombreux 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 c'est iOS 5.x par exemple supprime la prise en charge d'une solution tierce telle que MonoTouch? Qu'allez-vous dire à vos clients alors?
Peut-être vaut-il mieux utiliser une solution indépendante de la plate-forme telle que HTML5 si vous n'êtes pas tout à fait 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 l'avenir.
Voici mon expérience:
Bad bits:
Xamarin Studio. Les développeurs indépendants tels que moi sont obligés d'utiliser Xamarin Studio. Cela s'améliore chaque semaine, les développeurs sont très actifs sur les forums en identifiant et en corrigeant les bugs, mais cela reste très lent, se bloque fréquemment, a beaucoup de bugs et le débogage est assez lent également.
Temps de construction. Construire mon grande (liée) application à déboguer sur un appareil peut prendre quelques minutes, ce qui est comparé à XCode qui se déploie presque immédiatement. La construction 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 en place des solutions de contournement assez laides pour éviter les fuites, telles que la fixation 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 de ce type.
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 je pensais le mentionner. IMO un couple supplémentaire n'est rien ces jours-ci.
Bons bits:
Multi plateforme. Mon ami est heureux de créer une Android) de mon application à partir de ma base de code, nous développons en parallèle et nous nous engageons dans un référentiel Git distant sur Dropbox, tout va bien.
.Net. Travailler en C # .Net est beaucoup plus agréable que Objective C IMO.
MonoTouch. Presque tout dans iOS se reflète 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, rendant le développement plus fluide et plus facile.
Je recommande sans aucun doute Xamarin pour le développement multiplate-forme, en particulier si vous avez l’argent nécessaire 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.
J'aimerais ajouter quelque chose, même s'il existe une réponse acceptée: qui dira que Apple ne rejettera pas simplement les applications qui ont l'air d'être conçues avec Mono Touch?
En tant que personne ayant de l'expérience en C # et en Objective-C, je dirais que pour la plupart des gens, Xamarin vaudra bien l'argent.
C # est un très bon langage conçu et les API C # sont également bien conçus. Bien sûr, les API de Cocoa Touch (y compris UIKit) ont également un excellent design, mais le langage pourrait être amélioré de plusieurs manières. En écrivant en C #, vous serez probablement plus productif que d’écrire le même code en Objective-C. Cela est dû à plusieurs raisons, mais certaines sont:
C # a inférence de type . L'inférence de type accélère la rédaction du code, car vous n'avez pas à "connaître" le type situé à gauche d'une affectation. Cela facilite également la refactorisation et permet d’économiser davantage de ressources.
C # a génériques , ce qui réduira le nombre d'erreurs par rapport à un code Objective-C équivalent (bien qu'il existe des solutions de rechange dans Objective-C, dans la plupart des situations les développeurs les éviteront).
Récemment, Xamarin a ajouté le support de 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. 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 pour MonoTouch.Foundation a des cours pour NSString NSData, etc ...).
Xamarin offrira aux utilisateurs une expérience native, contrairement aux solutions telles que PhoneGap ou Titanium.
Désormais, Objective-C présente certains avantages par rapport à C #, mais dans la plupart des cas, l'écriture d'applications en C # entraîne généralement moins de temps de développement, 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.