Wie entscheide ich mich zwischen MonoTouch und Objective-C? [geschlossen]

273

Nachdem wir heute eine Sitzung auf Mono bei einer lokalen .Net-Veranstaltung absolviert hatten, wurde die Verwendung von MonoTouch als Alternative für die iPhone-Entwicklung "angesprochen". Da es sich in C # und .Net sehr wohl fühlt, scheint es eine ansprechende Option zu sein, trotz einiger Eigenheiten des Mono-Stacks. Da MonoTouch jedoch 400 US-Dollar kostet, bin ich etwas hin und her gerissen, wenn dies der richtige Weg für die iPhone-Entwicklung ist.

Hat jemand Erfahrung mit der Entwicklung mit MonoTouch und Objective-C, und wenn ja, ist die Entwicklung mit MonoTouch viel einfacher und schneller als das Erlernen von Objective-C und im Gegenzug die 400 US-Dollar wert?

Jamesaharvey
quelle
13
Ich denke, viele Kommentare darüber, dass MonoTouch nicht unter iOS ausgeführt werden kann, sind nicht mehr gültig, da Apple die Einschränkung für Entwicklertools gelockert hat. Siehe: apple.com/pr/library/2010/09/09statement.html
sivabudh

Antworten:

520

Ich habe diese Frage (und Variationen davon) in letzter Zeit oft gesehen. Was mich erstaunt ist, wie oft Menschen antworten, aber wie wenige antworten .

Ich habe meine Vorlieben (ich mag beide Stapel), aber hier beginnen die meisten "Antworten" falsch zu laufen. Es sollte nicht darum gehen, was ich will (oder was jemand anderes will).

So würde ich den Wert von MonoTouch bestimmen - ich kann natürlich nicht objektiv sein, aber ich denke, das ist ziemlich eifrig:

  • Ist das zum Spaß oder geschäftlich? Wenn Sie sich in diesem Bereich beraten lassen möchten, können Sie Ihre 399 US-Dollar sehr schnell zurückerhalten.

  • Möchten Sie die Plattform von innen nach außen lernen oder möchten Sie "nur" Apps dafür schreiben?

  • Gefällt dir .Net genug, dass die Verwendung eines anderen Entwickler-Stacks dir den Spaß nehmen würde? Auch hier mag ich beide Stacks (Apple und Mono), aber für mich macht MonoTouch die Erfahrung so viel mehr Spaß. Ich habe nicht aufgehört, Apples Tools zu verwenden, aber das liegt hauptsächlich daran, dass ich beide Stacks wirklich mag . Ich liebe das iPhone und ich liebe .Net. In diesem Fall war MonoTouch für mich ein Kinderspiel.

  • Fühlen Sie sich wohl bei der Arbeit mit C? Ich meine nicht Objective-C, sondern C - es ist wichtig, weil Objective-C C ist . Es ist eine nette, schicke, freundliche OO-Version, aber wenn Zeiger Ihnen die heebie-jeebies geben, ist MonoTouch Ihr Freund. Und hören Sie nicht auf die Neinsager, die denken, Sie sind ein Entwickler, wenn es passiert, dass Sie keine Zeiger (oder C usw.) mögen. Früher bin ich mit einer Kopie der IBM ROM BIOS Pocket Reference herumgelaufen, und als ich Assembler schrieb und meinen Computer in lustige Videomodi zwang und meine eigenen Schriftwiedergabebits für sie und (zugegebenermaßen trashige) Fenstersysteme schrieb, tat ich das nicht. Ich glaube nicht, dass die QuickBasic-Entwickler Trottel waren. Ich warein QuickBasic-Entwickler (zusätzlich zu den anderen). Gib niemals dem Nerd-Machismo nach. Wenn Sie C nicht mögen und wenn Sie keine Zeiger mögen und wenn Sie sich so weit wie möglich von der manuellen Speicherverwaltung entfernen möchten (und um fair zu sein, ist es in ObjC überhaupt nicht schlecht), dann. .. MonoTouch. Und nimm keinen Scherz dafür.

  • Möchten Sie Benutzer oder Unternehmen ansprechen? Es ist mir nicht wichtig, aber es gibt immer noch Leute auf Edge, und Tatsache ist: Sie können ein weitaus kleineres Download-Paket erstellen, wenn Sie den Apple-Stack verwenden. Ich habe mit MonoTouch herumgespielt und es gibt eine anständige kleine App, die nach dem Komprimieren auf etwa 2,7 MB reduziert wird (wenn Sie Ihre App zur Verteilung einreichen, komprimieren Sie sie - wenn Apps aus dem Store heruntergeladen werden, werden sie ' re zipped - Wenn Sie also herausfinden, ob Ihre App unter das 10-MB-OTA-Limit fällt, zippen Sie zuerst den Sauger - Sie werden von MonoTouch angenehm überrascht sein. Abgesehen von MT-Glück ist eine halbe Megabyte gegenüber fast drei (zum Beispiel) etwas, das für Sie wichtig sein könnte, wenn Sie Endbenutzer ansprechen. Wenn Sie an Unternehmensarbeit denken, spielen ein paar MB überhaupt keine Rolle. Und, Nur um klar zu sein - ich werde demnächst eine MT-basierte App im Store einreichen, und ich habe keinerlei Probleme mit der Größe. Stört mich überhaupt nicht. Aber wenn das etwas ist, das Sie betreffen würdeSie , dann gewinnt Apples Stack diesen.

  • Arbeiten Sie mit XML? MonoTouch. Zeitraum.

  • String-Manipulation? Datumsmanipulation? Eine Million anderer kleiner Dinge, an die wir uns mit .Nets Rahmen für alles und die Küchenspüle gewöhnt haben? MonoTouch.

  • Internetdienste? MonoTouch.

  • Syntaktisch haben beide ihre Vorteile. Objective-C ist in der Regel ausführlicher, wenn Sie es schreiben müssen . Sie werden feststellen, dass Sie Code mit C # schreiben, den Sie nicht mit ObjC schreiben müssten, aber es geht in beide Richtungen. Dieses spezielle Thema könnte ein Buch füllen. Ich bevorzuge die C # -Syntax, aber nachdem ich meine anfängliche Reaktion auf Objective-C überwunden habe, habe ich gelernt, sie ziemlich zu genießen. Ich mache mich in Gesprächen ein bisschen darüber lustig (es ist komisch für Entwickler, die an C # / Java / etc. Gewohnt sind), aber die Wahrheit ist, dass ich einen objektiv-C-förmigen Fleck in meinem Herzen habe, der mich glücklich macht.

  • Planen Sie Interface Builder zu verwenden? Denn selbst in dieser frühen Version mache ich viel weniger Arbeit, um meine Benutzeroberflächen mit IB zu erstellen und sie dann im Code zu verwenden. Es fühlt sich so an, als ob in der Objective-C / IB-Vorgehensweise ganze Schritte fehlen, und ich bin mir ziemlich sicher, dass ganze Schritte in der Objective-C / IB-Vorgehensweise fehlen. Bisher und ich glaube nicht, dass ich ausreichend getestet habe, aber bisher ist MonoTouch hier der Gewinner dafür, wie viel weniger Arbeit Sie erledigen müssen.

  • Denkst du, es macht Spaß, neue Sprachen und Plattformen zu lernen? Wenn ja, hat das iPhone viel zu bieten, und Apples Stack wird Sie wahrscheinlich aus Ihrer Komfortzone bringen - was für einige Entwickler Spaß macht (Hallo - ich bin einer dieser Entwickler - ich scherze darüber und gebe Apple hat es schwer, aber ich hatte viel Spaß beim Erlernen der iPhone-Entwicklung mit Apples Tools.

Es gibt so viele Dinge zu beachten. Wert ist so abstrakt. Wenn wir über die Kosten sprechen und ob es sich lohnt, kommt die Antwort auf meinen ersten Punkt: Wenn dies geschäftlich ist und Sie die Arbeit bekommen können, werden Sie Ihr Geld sofort zurückverdienen.

Also ... das ist ungefähr so ​​objektiv wie ich sein kann. Dies ist eine kurze Liste dessen, was Sie sich fragen könnten, aber es ist ein Ausgangspunkt.

Persönlich (lassen Sie uns die Objektivität für einen Moment fallen), ich liebe und benutze beide. Und ich bin froh, dass ich zuerst den Apple-Stack gelernt habe. Es war für mich einfacher, mit MonoTouch zu arbeiten, als ich mich bereits in der Welt von Apple auskannte. Wie andere gesagt haben, werden Sie immer noch mit CocoaTouch arbeiten - es wird nur in einer .NET-Umgebung sein.

Aber es gibt noch mehr. Die Leute, die MonoTouch nicht benutzt haben, neigen dazu, hier anzuhalten - "Es ist ein Wrapper bla bla bla" - das ist nicht MonoTouch.

Mit MonoTouch haben Sie Zugriff auf das, was CocoaTouch zu bieten hat, und gleichzeitig auf das, was (eine Teilmenge von) .Net zu bieten hat. Eine IDE, mit der sich einige Leute wohler fühlen (ich bin einer von ihnen), und eine bessere Integration in Interface Builder und obwohl Sie die Speicherverwaltung nicht völlig vergessen, haben Sie ein gutes Maß an Spielraum.

Wenn Sie sich nicht sicher sind, greifen Sie zu Apples Stack (kostenlos) und zum MonoTouch-Evaluierungsstapel (kostenlos). Bis Sie sich Apples Entwicklungsprogramm anschließen, laufen beide nur gegen den Simulator. Dies reicht jedoch aus, um herauszufinden, ob Sie das eine dem anderen vorziehen und ob MonoTouch für Sie die 399 US-Dollar wert ist.

Und hör nicht auf die Eiferer - sie sind in der Regel diejenigen, die die Technologie, gegen die sie schimpfen, nicht benutzt haben :)

Rory Blyth
quelle
50
Wow, Rory, danke, dass du dir die Zeit genommen hast, meine Frage so ausführlich zu beantworten. Soweit ich weiß, sind Sie der einzige, der beide Optionen verwendet hat, und von wem ich nach einer Antwort gesucht habe. Ich werde es auf jeden Fall versuchen. Übrigens, ich habe dich im letzten SO-Podcast gehört, oder? Gutes Zeug. Danke noch einmal!
Jamesaharvey
17
Vielen Dank für die Kommentare :) Ich bin frustriert über den Knie-Ruck-Hass, den ich gesehen habe. Immer wieder wird die Frage mit "Ur ein Idiot Lurn beantwortet, um das opurierende System zuerst lockerer zu riten !! ??" Welches ist nicht hilfreich und beleidigend. MonoTouch hat seine rauen Stellen, aber diese Jungs haben eine geniale Erfolgsgeschichte. MT hat sich schnell weiterentwickelt und ist jeden Tag schöner. Ich sage immer wieder: Gib ihnen ein paar Monate. Sie sind vorsichtig in Bezug auf Funktionen, aber ich denke, wir werden große Dinge sehen. Ich liebe Apples Stack, aber ich habe jetzt einen anderen Spielplatz - das ist eine gute Sache und ich bin schwindlig :)
Rory Blyth
4
@Stephan - Es ist möglicherweise nicht richtig zu sagen, was "fehlt" - ich kann die Arbeit mit Cocoa erledigen. Es geht mehr um die APIs. Mit .Net ist es viel einfacher, mit Zeichenfolgen, Datumsangaben, XML usw. zu arbeiten. Keine Ahnung, ob Sie mit der .Net-Methode und den Umfang der Unterstützung durch MonoTouch vertraut sind - wenn Sie sich nicht damit befasst haben, sollten Sie es tun -, um es sich anzusehen. Ich will damit nicht sagen, dass es Dinge gibt, die man mit Kakao nicht machen kann, aber es gibt viele Dinge, die mit .Net viel einfacher zu machen sind. Das Parsen ist auf der ganzen Linie einfacher - Datumsberechnung ist auf der ganzen Linie einfacher - usw.
Rory Blyth
3
Außerdem gibt es das Problem der Wiederverwendung Ihres eigenen Codes im iPhone / iPad mit MT. Wir haben Krypto-Code und Geschäftslogik-Code auf unseren Server- und Desktop-Gegenstücken, die wir einfach mit MT neu kompilieren und in unserer iOS-Client-App verwenden können. Das kann für einige Projekte wichtig sein.
Monoman
2
Erwägenswert ist auch die Tatsache, dass die Lizenz zwar 400 US-Dollar kostet, es aber auch ein Wartungsabonnement gibt, das Sie (aus offensichtlichen Gründen) jedes Jahr erneuern müssen - 250 US-Dollar. Es ist wahrscheinlich ein fairer Preis, aber dennoch eine Überlegung wert.
Amc_rtty
62

In diesem Beitrag gibt es viel Hörensagen von Entwicklern, die MonoTouch und Objective-C noch nicht ausprobiert haben . Es scheinen hauptsächlich Objective-C-Entwickler zu sein, die MonoTouch noch nie ausprobiert haben.

Ich bin offensichtlich voreingenommen, aber Sie können nachlesen, was die MonoTouch-Community vorhat:

http://xamarin.com

Dort finden Sie mehrere Artikel von Entwicklern, die sowohl in Objective-C als auch in C # entwickelt wurden.

miguel.de.icaza
quelle
29
@NSResponder - Haben Sie verwendet Monotouch? Es ist eine Version 1.x, praktisch brandneu und bereits erstaunlich. Probieren Sie es aus, bevor Sie es kommentieren. Es gibt große Änderungen (die Integration des Interface Builder ist weitaus besser als die von Xcode) und es gibt kleine Änderungen (vergleichen Sie beispielsweise die ObjC / Cocoa-Methode zum Abrufen des Dokumentenordners des Benutzers im Vergleich zu MTs). Ich benutze immer noch Apples Stack für einige Dinge, aber MT ist wunderschön und voller Potenzial. Im Ernst - probieren Sie es einfach aus. Oder schauen Sie sich an, wie die Cocoa-APIs gebunden wurden - Sie müssen sie nicht verwenden - werfen Sie die Arbeit einfach nicht in den Papierkorb, ohne etwas darüber zu lernen .
Rory Blyth
Ja! Mit einigen der neuen C # 5.0-Funktionen macht das Codieren im Vergleich zu Objective-C noch mehr Spaß.
Harsimranb
39

Meine Antwort auf eine frühere ähnliche Frage lautet also, Objective-C zu lernen. (Vergessen Sie auch nicht die Debugging-Unterstützung)

Dies wird wahrscheinlich einige beleidigen, aber um ehrlich zu sein, wenn Sie ernsthafte Entwicklungen durchführen wollen, sollten Sie Objective-C lernen. Wenn Sie Objective-C in der iPhone-Entwicklung nicht kennen, ist dies nur ein Hindernis. Sie werden nicht viele Beispiele verstehen können; Sie müssen sich mit den Macken von Mono auseinandersetzen, während Sie, wenn Sie über Kenntnisse in Objective-C verfügen, viel mehr aus der Plattformdokumentation herausholen können.

Persönlich verstehe ich die Position nicht, die besagt, dass Sie die Menge an Informationen erhöhen müssen, die Sie für die Verwendung von Mono gegenüber der Muttersprache der Plattform benötigen. Es scheint mir etwas kontraproduktiv. Ich denke, wenn dies eine sehr teure Angelegenheit ist (Lernen einer neuen Sprache), kann es sich lohnen, einige Zeit mit grundlegenden Programmierkonzepten zu verbringen, damit das Erlernen neuer Sprachen eine ziemlich billige Angelegenheit ist.

Ein anderer Benutzer schrieb auch Folgendes:


Monotouch ist jetzt einfacher für Sie. Aber später schwieriger.

Was passiert zum Beispiel, wenn neue Samen herauskommen, gegen die Sie MonoTouch testen, aber aus irgendeinem Grund brechen müssen?

Wenn Sie bei Mono bleiben, müssen Sie jedes Mal, wenn Sie nach Ressourcen für Frameworks suchen, mental übersetzen, wie Sie sie mit Mono verwenden werden. Ihre App-Binärdateien werden größer, Ihre Entwicklungszeit nach einigen Monaten in Objective-C nicht viel schneller, und andere App-Entwickler haben einen viel größeren Vorteil gegenüber Ihnen, da sie die native Plattform verwenden.

Eine weitere Überlegung ist, dass Sie C # verwenden möchten, da Sie mit der Sprache besser vertraut sind als Objective-C. Die überwiegende Mehrheit der Lernkurve für das iPhone ist jedoch nicht Objective-C, sondern die Frameworks, auf die Sie auch mit C # zugreifen müssen.

Für jede Plattform sollten Sie die Plattform verwenden, die die Designphilosophie dieser Plattform direkt zum Ausdruck bringt - auf dem iPhone ist dies Objective-C. Wenn ein Linux-Entwickler, der an das Programmieren in GTK gewöhnt war, Windows-Apps schreiben wollte, würden Sie ernsthaft empfehlen, C # nicht zu verwenden und sich an GTK zu halten, weil dies für ihn "einfacher" war?


BobbyShaftoe
quelle
12
Sie haben MT wahrscheinlich unbeabsichtigt falsch dargestellt. Es ist überhaupt nicht - nicht aus der Ferne - analog zur Verwendung von GTK zum Schreiben von Win-Apps. Die Bindungen von MT sind CocoaTouch sehr treu. Sie haben tatsächlich einige der CT-API-Konventionen verbessert . Sie schreiben Ihre Apps jedoch nicht mit einer Windows Forms-basierten Abstraktion über CT. MT mit MonoDevelop lässt sich besser in IB integrieren als Xcode (wenn Sie möchten), und Sie können häufig die gleichen Aufgaben mit der Hälfte des Codes oder weniger erledigen. Die Binärgröße wird verbessert und die Werkzeuge (Bindungsgenerator usw.) sind immer besser. Eine MT-App ist eine native App.
Rory Blyth
7
Um Beispiele zu nennen, anstatt von Ihnen zu erwarten, dass Sie meine (offensichtlich) MT-Fanboy-Meinung selbst vertreten, kann ich Dinge tun (und dies ist nur eine winzige Untergruppe von Vorteilen): Erstellen Sie eine Eigenschaft mit einer Zeile; Holen Sie sich einen Verweis auf den Dokumentordner ohne lächerliche Array-Höhlenforschung (eine App hat einen Dokumentordner, immer am selben Ort - warum all die zusätzliche Arbeit, um ihn zu "finden"?); Verwenden Sie das .Net-Framework, in dem Kakao stinkt (NSDate, irgendjemand?). Verwenden Sie Commodity-Fähigkeiten für Unternehmensanwendungen. Verwenden Sie richtige, moderne XML-Bits (ich liebe es, wenn Cocoa Zeichen still erstickt und einfach aufhört - kein Absturz - hört einfach auf ).
Rory Blyth
8
Ich sage nicht, dass ich es für alles verwenden würde. Ich mag ObjC und benutze es immer noch. Und wenn Leistung ein Problem ist, habe ich eine genauere Kontrolle darüber, was los ist. Aber ... es gibt Zeiten, in denen MT sinnvoller ist, und ich denke, es wird das iPhone zu einer praktikablen Option für die Unternehmensentwicklung machen. Werfen Sie einen Stein in die Luft und Sie werden einen .Net-Entwickler treffen. Die meisten Unternehmen haben keine internen ObjC-Entwickler. Und für Unternehmensarbeit sollten sie nicht müssen. MT ist viel einfacher für die Arbeit mit Webdiensten und DBs. Mit MT können Sie wirklich viele Arten von Apps mit der Hälfte des Codes schreiben, der in ObjC benötigt wird.
Rory Blyth
8
Schließlich (ich könnte weitermachen, aber ich denke, ich mache mt point) sind Änderungen, die MonoTouch "brechen", wahrscheinlich genauso wahrscheinlich, dass ObjC-Apps kaputt gehen. Sobald Ihre App im Store ist, handelt es sich um eine native iPhone-App (wie es sein muss). Die Aufrufe sind letztendlich nicht anders - dieselbe Laufzeit wie Apps, die mit Apples Stack erstellt wurden. Wenn Ihre MT-App aufgrund einer Änderung der Laufzeitumgebung nicht mehr funktioniert, werden auch Apps mit ObjC erstellt. Und das MT-Team hat alles im Griff und Updates und Fehlerbehebungen schnell veröffentlicht. Die Bindungen von MT sind eng genug mit den CTs verknüpft, sodass die Wahrscheinlichkeit eines echten Problems gering ist. Aight - Ich werde jetzt die Klappe halten :)
Rory Blyth
27

Die Verwendung von Mono ist keine Krücke. Es gibt viele Dinge, die es zum iPhone OS hinzufügt. LINQ, WCF, gemeinsam nutzbarer Code zwischen einer Silverlight-App, einer ASP.NET-Seite, einer WPF-App, einer Windows Form-App sowie Mono für Android und auch für Windows Mobile.

Sie können also eine Menge Zeit damit verbringen, Objective-C zu schreiben (Sie werden aus vielen Studien ersehen, in denen genau der gleiche Beispielcode in C # deutlich weniger zu schreiben ist als in OC) und dann alles für andere Plattformen DUPLIZIEREN. Für mich habe ich mich für MonoTouch entschieden, weil die Cloud-App, die ich schreibe, viele Schnittstellen hat, von denen das iPhone nur eine ist. Das Streaming von WCF-Daten aus der Cloud zur MonoTouch-App ist wahnsinnig einfach. Ich habe Kernbibliotheken, die von den verschiedenen Plattformen gemeinsam genutzt werden, und muss dann nur noch eine einfache Präsentationsebene für die Bereitstellungen für iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET schreiben. Es wäre enorm, alles in Objective-C neu zu erstellen Zeitverschwendung sowohl für die anfängliche Entwicklung als auch für die Wartung, da das Produkt weiterentwickelt wird, da alle Funktionen repliziert und nicht wiederverwendet werden müssten.

Den Leuten, die MonoTouch beleidigen oder unterstellen, dass Benutzer eine Krücke benötigen, fehlt das Gesamtbild dessen, was es bedeutet, das .NET-Framework zur Hand zu haben, und sie verstehen möglicherweise nicht die richtige Trennung von Logik und Präsentation auf diese Weise kann plattform- und geräteübergreifend wiederverwendet werden.

Objective-C ist interessant und unterscheidet sich stark von vielen gängigen Sprachen. Ich mag eine Herausforderung und lerne verschiedene Ansätze ... aber nicht, wenn dies meinen Fortschritt behindert oder unnötige Neucodierungen verursacht. Es gibt einige wirklich großartige Dinge am iPhone SDK-Framework, aber all diese Größe wird von MonoTouch vollständig unterstützt und reduziert die manuelle Speicherverwaltung, reduziert die Menge an Code, die für die Ausführung derselben Aufgaben erforderlich ist, ermöglicht mir die Wiederverwendung meiner Assemblys und hält meine Optionen offen, um auf andere Geräte und Plattformen wechseln zu können.

Paul
quelle
19

Ich wechselte. Mit Monotouch kann ich Apps mindestens 3-4 Mal so schnell schreiben (4 Apps pro Monat im Vergleich zu meiner alten 1 pro Monat in Obj C).

Viel weniger tippen.

Nur meine Erfahrung.

Ian Vink
quelle
2
"4 Apps pro Monat" - Wenn Quantität wichtiger ist als Qualität. MT ist wie McDonalds. Aber im XCode-Restaurant bekommt man besseres Essen.
Netshark1000
2
Die Ergebnisse sprechen jedoch anders. Rdio und iCircuit sind MT-Apps, die von Steve Jobs vorgeführt wurden. C # und MT werden die Klempnerarbeiten los, zu denen obj-C Sie zwingt.
Ian Vink
17

Wenn dies die einzige iPhone-App ist, die Sie jemals entwickeln werden, und Sie auch kein Interesse daran haben, Mac-Anwendungen zu entwickeln, dann ist MonoTouch wahrscheinlich die Kosten wert.

Wenn Sie glauben, dass Sie jemals mehr iPhone-Apps entwickeln werden oder jemals eine native Mac-Entwicklung durchführen möchten, lohnt es sich wahrscheinlich, Objective-C und die damit verbundenen Frameworks zu lernen. Wenn Sie ein Programmierer sind, der gerne neue Dinge lernt, ist das Lernen ein unterhaltsames neues Paradigma.

Phoebus
quelle
6
Wenn dies die einzige iPhone-App ist, die Sie jemals entwickeln werden, sind die 99 US-Dollar pro Jahr auch nicht wert.
Dinah
Sie können dieselben C # -Entwicklungstools verwenden, um Mac-Apps zu erstellen. Tatsächlich können Sie die Code-Freigabe zwischen iPhone C # - und Mac C # -Anwendungen codieren. MonoTouch heißt jetzt Xamarin
Ian Vink
9

Persönlich denke ich, dass Sie eine bessere Zeit haben werden, wenn Sie nur Objective-C lernen.

Zusamenfassend:

  • "Learning Objective-C" ist nicht entmutigend, wie Sie vielleicht denken, Sie können es sogar schon nach den ersten Wochen genießen
  • Sie kennen die Syntax "C-Stil" bereits mit vielen * & () {}; überall
  • Apple hat die Dinge sehr gut dokumentiert
  • Sie interagieren mit dem iPhone so, wie Apple es beabsichtigt hat, was bedeutet, dass Sie die Vorteile direkt von der Quelle erhalten, nicht durch einen Filter.

Ich habe festgestellt, dass Projekte wie Unity und MonoTouch "Zeit sparen" sollen, aber letztendlich müssen Sie ihre domänenspezifische Sprache trotzdem lernen und müssen manchmal die Dinge umgehen. All das wird wahrscheinlich genauso lange dauern, bis Sie die Sprache gelernt haben, die Sie vermeiden wollten (in der Kalenderzeit). Am Ende haben Sie keine Zeit gespart und sind eng mit einem Produkt verbunden.

EDIT: Ich wollte nie etwas Negatives über .NET implizieren. Ich bin zufällig ein großer Fan davon. Mein Punkt ist, dass das Hinzufügen weiterer Komplexitätsebenen, nur weil Sie mit der skurrilen objc-Klammer-Notation noch nicht vertraut sind, für mich nicht wirklich sinnvoll ist.

Update 2019: Es ist 7 Jahre später. Mir geht es immer noch genauso, wenn nicht mehr. Sicher, "domänenspezifische Sprache" war möglicherweise der falsche Begriff, aber ich glaube immer noch, dass es viel besser ist, direkt für die Plattform zu schreiben, mit der Sie arbeiten, und Kompatibilitätsebenen und Abstraktionen so weit wie möglich zu vermeiden. Wenn Sie sich Sorgen über die Wiederverwendung und Nachbearbeitung von Code machen, können im Allgemeinen alle Funktionen, die Ihre plattformübergreifende App ausführen muss, wahrscheinlich mit modernen Webtechnologien ausgeführt werden.

slf
quelle
12
Zunächst einmal ist C # keine "domänenspezifische Sprache" - weit davon entfernt. Es ist eine Warenfertigkeit. Das ist Teil des Wertes von MonoTouch. Es könnte argumentiert werden (zu Unrecht und ungenau), dass ObjC ein DSL ist, da die meisten Entwickler (außerhalb von Finanz- und Universitätslabors und -kellern) es immer nur für die Entwicklung von OS X oder iPhone verwenden werden. Aber es ist nicht so. Wie C # ist es eine vielseitige Sprache, die es im Grunde gibt, damit Sie sich eher auf Frameworks als auf die Sprache selbst konzentrieren können (ich denke, wir sind uns da einig). Beachten Sie jedoch, dass Ihr ObjC- Code mit Apple-Updates nicht mehr funktioniert. Das ist kein MT-spezifisches Problem.
Rory Blyth
3
MT könnte Sie in einigen Fällen sogar retten, weil es diese Abstraktionsebene gibt. Apple ändert eine API? Nun, Ihre ObjC-App und Ihre äquivalente MT-App (tun wir so, als ob sie existiert) werden kaputt gehen. Die MT-Leute könnten eine Notlösung veröffentlichen, um zu ändern, wie die MonoTouch-API den Anruf hinter den Kulissen behandelt. Ihr MT-Code müsste sich nicht ändern - Sie können ihn einfach gegen die Notlösung MT neu erstellen. Ja, dies ist ein schmutziger Fix, der leicht zu Problemen führen kann. Wenn Sie jedoch die Stopgap-MT-API ordnungsgemäß ablehnen, haben Entwickler Zeit, die Änderung nahtlos durchzuführen und Zeit für einen echten Fix zu gewinnen.
Rory Blyth
4
Neu wie MT ist, ist es jetzt viel einfacher, bei Bedarf eigene Bindungen zu erstellen (MT 1.2). Sie sind nicht völlig abhängig von dem MT lugt all diese Arbeit zu tun (obwohl sie sind , diese Arbeit zu tun), und waren nie. Sie haben ganz einfache Möglichkeiten, Bindungen zu erstellen. Sie stellen mit den MT-Frameworks genug von der ObjC-Laufzeit zur Verfügung, sodass Sie nicht an ihre Vorgehensweise gebunden sind. Ich habe Bindungen neu implementiert, um zu sehen, ob mir mein Weg besser gefällt. Sie können die MT-Frameworks ignorieren und Nachrichten "manuell" senden und empfangen, wenn Sie möchten, und es wird wenig Code benötigt. Sie sind kluge Leute. Vertraue ihnen :)
Rory Blyth
2
Ich denke, slf ist sich der Tatsache nicht bewusst, dass Monotouch nur C # (mit GC) ist, das direkt an die ObjC-Bibliotheken + optionale .NET-Bibliotheken bindet. Sie verwenden also weiterhin die von Apple bereitgestellte API. Aber mit einer übersichtlicheren Syntax und Garbage Collection.
Basarat
4

Um zu dem hinzuzufügen, was andere bereits gesagt haben (na ja!): Ich habe das Gefühl, dass Sie die Anzahl der Fehler, über die Sie sich Sorgen machen müssen, im Grunde verdoppeln, indem Sie die in MonoTouch zu den bereits in iPhone OS hinzugefügten hinzufügen. Das Aktualisieren für neue Betriebssystemversionen ist noch schmerzhafter als normal. Yuck, überall.

Der einzige überzeugende Fall, den ich für MonoTouch sehen kann, sind Organisationen, in denen viele, viele C # -Programmierer und C # -Code herumliegen, die sie benötigen auf dem iPhone nutzen. (Die Art von Laden, der bei $ 3500 nicht einmal blinkt.)

Aber für jeden, der von vorne anfängt, kann ich es wirklich nicht als lohnenswert oder weise ansehen.

Sixten Otto
quelle
-1: Was meinst du mit "mehr Bugs"? Gibt es eine offensichtliche Impedanzfehlanpassung zwischen Mono und Objective-C?
Jim G.
4

Drei Wörter: Linq to SQL

Ja, es ist das Geld wert.

Bryan
quelle
4
Mit den Schlüsselwertbindungen und Kerndaten von Objective-C erhalten Sie etwas, das Linq-to-SQL sehr ähnlich ist. Nicht das gleiche. Vielleicht nicht ganz so mächtig - aber auf dem gleichen Gebiet. Beachten Sie, dass Core-Data derzeit nicht von MonoTouch unterstützt wird
philsquared
Ist Linq to SQL überhaupt für eine iPhone-App relevant? Es funktioniert mit SQLite?
Papa
1
Und Sie möchten, dass Ihre Benutzer Daten über ein Netzwerk austauschen. Was machst du mit SQL Lite?
Bryan
"MonoTouch basiert auf einem hybriden .NET 2.0- und Silverlight 2-API-Profil" Wird LINQ für Objekte unterstützt?
Chris S
2

Etwas, das ich hinzufügen möchte, obwohl es eine akzeptierte Antwort gibt - wer soll sagen, dass Apple nicht einfach Apps ablehnt, die Anzeichen dafür haben, dass sie mit Mono Touch erstellt wurden?

bpapa
quelle
Sie sollten es auf jeden Fall tun und sie sollten auch Flash-Apps ablehnen, aber ihre App Store-Bedingungen schließen ihre Verwendung nicht aus.
NSResponder
3
@bpapa - das ist ein absolut berechtigtes Anliegen, aber: 1) Es gibt keinen Grund, die Apps abzulehnen (Benutzer kümmern sich nicht darum, womit ihre Apps geschrieben sind - sie kümmern sich um die Apps selbst), und 2) MonoTouch hat viel Potenzial Für die Unternehmensentwicklung und solange Sie über ein Unternehmensentwicklungskonto verfügen, kann Apple Sie nicht davon abhalten, Ihre App zu verteilen. Außerdem akzeptiert Apple Spiele, die mit Unity erstellt wurden. Letztendlich folgt MT den Regeln. Apples Prozess scheint manchmal zufällig zu sein, aber ... MT folgt den Regeln: |
Rory Blyth
1
@bpapa - Ich weiß nicht, wie ich diesen Kommentar so lange verpasst habe, aber: 1) Unzählige ObjC-Apps werden "kaputt", weil sie undokumentierte ("private") APIs verwenden - FB ist, wie Sie bemerkt haben, noch eine davon FB ist noch am Leben und steht zum Download zur Verfügung. 2) Das Problem von Unity wurde schnell behoben, und Unity ist wieder da draußen. - Soweit Apple möchte, dass Sie ihre eigenen Produkte verwenden, würde ich dem nicht widersprechen, aber wollen und verlangen sind sehr unterschiedlich. Für Unternehmensanwendungen: Sie können MT-Unternehmensanwendungen bereitstellen. Sie sind nur native Binärdateien. Ich sehe das Problem nicht und verstehe auch nicht, warum Sie so gegen MT sind.
Rory Blyth
1
Ich sollte hinzufügen, dass es nicht so ist, dass ich die Syntax von ObjC "hasse", sondern dass ich C # sehr bevorzuge. Ich bevorzuge auch die Wege des .Net-Frameworks gegenüber denen von Cocoa. String - Manipulation, die Verarbeitung von XML, alles beteiligt Daten, etc. - Ich werde die MT Cocoatouch - Bindings für UI Arbeit verwenden, aber für die meisten anderen Aufgaben, die Teilmenge des .NET Framework , die Schiffe mit MT macht das Leben viel einfacher. Ich könnte immer weiter machen (wie zum Beispiel meine Präferenz, bestimmte Fehler beim Kompilieren zu finden ). Ich bin kritisch gegenüber Apples Stack, aber ich mag ihn nicht. Es ist möglich, MT und ObjC / etc. Zu mögen .
Rory Blyth
1
Apple hat seine Meinung geändert und akzeptiert jetzt Apps in jeder Sprache / jedem Framework und erstellt eine objektivere Liste von Kriterien für die Annahme von Apps im Store.
Monoman
2

Ich würde die Zeit in Objective-C investieren, hauptsächlich wegen all der Hilfe, die Sie von solchen Websites erhalten können. Eine der Stärken von Objective-C ist, dass Sie C- und C ++ - Code verwenden können, und es gibt viele Projekte, die gut getestet sind .

Eine andere Sache ist, dass Ihr Code (Sprache der Wahl) von Apple unterstützt wird. Womit entfernt iOS 5.x beispielsweise die Unterstützung für eine Drittanbieterlösung wie MonoTouch? Was sagen Sie dann Ihren Kunden?

Vielleicht ist es besser, eine plattformunabhängige Lösung wie HTML5 zu verwenden, wenn Sie nicht vollständig bereit sind, auf Objective-C umzusteigen?

Konrad77
quelle
Ich finde das Argument, dass Sie durch die Verwendung von MonoTouch an einen Anbieter gebunden werden, den Apple möglicherweise nicht mehr zulässt / unterstützt. Sie könnten am Ende in eine Plattform investieren, die einem Apple ausgeliefert ist, der ohnehin über eine eigene Entwicklungsplattform verfügt ...
jl.
2

Ich benutze MonoTouch seit einigen Monaten und habe meine halbfertige App von ObjectiveC portiert, damit ich irgendwann in der Zukunft Android unterstützen kann.

Hier ist meine Erfahrung:

Schlechte Teile:

  • Xamarin Studio. Indie-Entwickler wie ich sind gezwungen, Xamarin Studio zu verwenden. Es wird von Woche zu Woche besser, die Entwickler sind sehr aktiv in den Foren, um Fehler zu identifizieren und zu beheben, aber es ist immer noch sehr langsam, hängt häufig, hat viele Fehler und das Debuggen ist auch ziemlich langsam.

  • Bauzeiten. Das Erstellen meiner großen (verknüpften) App zum Debuggen auf einem Gerät kann einige Minuten dauern. Dies wird mit XCode verglichen, das fast sofort bereitgestellt wird. Das Erstellen für den Simulator (nicht verknüpft) ist etwas schneller.

  • MonoTouch-Probleme. Ich habe Probleme mit Speicherverlusten, die durch die Ereignisbehandlung verursacht wurden, und musste einige ziemlich hässliche Problemumgehungen vornehmen, um die Lecks zu verhindern, z. B. das Anhängen und Trennen von Ereignissen beim Eingeben und Verlassen von Ansichten. Die Xamarin-Entwickler beschäftigen sich aktiv mit solchen Problemen.

  • Bibliotheken von Drittanbietern. Ich habe eine ganze Weile damit verbracht, ObjectiveC-Bibliotheken für die Verwendung in meiner App zu konvertieren / zu binden, obwohl dies mit automatisierter Software wie Objective Sharpie immer besser wird.

  • Größere Binärdateien. Das stört mich nicht wirklich, aber ich dachte, ich würde es erwähnen. IMO ein paar extra Mb ist heutzutage nichts mehr.

Gute Teile:

  • Multi-Plattform. Mein Freund erstellt gerne eine Android-Version meiner App aus meiner Kerncodebasis. Wir entwickeln sie parallel und legen ein Remote-Git-Repository auf Dropbox fest. Es läuft gut.

  • .Netz. Das Arbeiten in C # .Net ist viel schöner als Objective C IMO.

  • MonoTouch. So ziemlich alles in iOS ist in .Net gespiegelt und es ist ziemlich einfach, die Dinge zum Laufen zu bringen.

  • Xamarin. Sie können sehen, dass diese Leute wirklich daran arbeiten, alles zu verbessern und die Entwicklung reibungsloser und einfacher zu gestalten.

Ich empfehle Xamarin auf jeden Fall für die plattformübergreifende Entwicklung, insbesondere wenn Sie das Geld haben, um die Business- oder Enterprise-Editionen zu verwenden, die mit Visual Studio funktionieren.

Wenn Sie ausschließlich eine iPhone-App erstellen, die auf einer anderen Plattform niemals benötigt wird, und Indie-Entwickler sind, bleibe ich vorerst bei XCode und Objective C.

Danfordham
quelle
Ein kurzes Update zu meiner Antwort oben. Seit ich auf einen schnelleren Mac umgestiegen bin, habe ich festgestellt, dass die Build-Zeiten viel schneller sind. Es ist immer noch nicht sofort wie bei XCode, aber es ist in Ordnung.
Danfordham
1

Als jemand mit Erfahrung sowohl mit C # als auch mit Objective-C würde ich sagen, dass Xamarin für die meisten Menschen das Geld wert sein wird.

C # ist eine wirklich gut gestaltete Sprache und die C # -APIs sind ebenfalls gut gestaltet. Natürlich haben auch die Cocoa Touch-APIs (einschließlich UIKit) ein großartiges Design, aber die Sprache könnte auf verschiedene Weise verbessert werden. Wenn Sie in C # schreiben, sind Sie wahrscheinlich produktiver als wenn Sie denselben Code in Objective-C schreiben. Dies hat mehrere Gründe, aber einige Gründe wären:

  • C # hat Typinferenz . Die Typinferenz beschleunigt das Schreiben von Code, da Sie den Typ auf der linken Seite einer Zuweisung nicht "kennen" müssen. Es macht auch das Refactoring einfacher und spart mehr.

  • C # verfügt über Generika , die Fehler im Vergleich zu gleichwertigem Objective-C-Code reduzieren (obwohl es in Objective-C einige Problemumgehungen gibt, werden Entwickler diese in den meisten Situationen vermeiden).

  • Kürzlich hat Xamarin Unterstützung für Async / Await hinzugefügt , was das Schreiben von asynchronem Code sehr einfach macht.

  • Sie können einen Teil der Codebasis unter iOS, Android und Windows Phone wiederverwenden.

  • MonoTouch implementiert die CocoaTouch-APIs weitgehend auf sehr einfache Weise. Beispiel: Wenn Sie Erfahrung mit CocoaTouch haben, wissen Sie, wo Sie Klassen für Steuerelemente in MonoTouch finden können (MonoTouch.UIKit enthält Klassen für UIButton, UIView, UINavigationController usw.), ebenso wie MonoTouch.Foundation Klassen für NSString, NSData, etc ...).

  • Im Gegensatz zu Lösungen wie PhoneGap oder Titanium bietet Xamarin Benutzern eine native Erfahrung.

Jetzt hat Objective-C einige Vorteile gegenüber C #, aber in den meisten Situationen führt das Schreiben von Apps in C # im Allgemeinen zu weniger Entwicklungszeit und saubererem Code und weniger Arbeit beim Portieren derselben App auf andere Plattformen. Eine bemerkenswerte Ausnahme könnten Hochleistungsspiele sein, die auf OpenGL basieren.

Wolfgang Schreurs
quelle
-35

Die Kosten für die MonoTouch-Bibliothek spielen keine Rolle. Der Grund, warum Sie Mono nicht für Ihre iPhone-Apps verwenden sollten, ist, dass es sich um eine Krücke handelt. Wenn Sie sich nicht die Mühe machen müssen, die nativen Tools zu erlernen, habe ich keinen Grund zu der Annahme, dass Ihr Produkt einen Download wert ist.

Bearbeiten: 14.04.2010 Mit MonoTouch geschriebene Anwendungen sind nicht für den iTunes Store berechtigt. Das ist so wie es sein sollte. Apple sah viele flache Ports auf dem Mac, die plattformübergreifende Toolkits wie Qt oder die teilweise teilweise Neuimplementierung der System 7-Toolbox durch Adobe verwendeten. Kurz und gut, sie sind einfach nicht gut genug.

NSResponder
quelle
14
Der Marktanteil für Mac OS X ist sehr gering und daher ist das iPhone für viele der einzige zwingende Grund, sich überhaupt mit X-Code und ObjC zu beschäftigen. Beide waren vor mehr als 15 Jahren großartig, als es Project Builder war, und haben plattformübergreifende Komplikationen und Verpackungen durchgeführt, aber ehrlich gesagt - als jemand, der eine Reihe von Plattformen verwendet - mit wohl besseren Tools und Sprachen da draußen ist es kaum überraschend, dass Entwickler eine gemeinsame nutzen wollen Codebasis und verwenden Sie alternative Entwicklungstools. Es bedeutet nicht, dass ihre Kreationen unterdurchschnittlich sein werden.
Iain Collins
37
Ich weiß nicht, Alter ... Ich denke, Objective-C und CocoaTouch sind eine Krücke. Wenn Sie keine Assembly schreiben, wird es Ihnen einfach egal sein, und Sie werden Ihre App nicht herunterladen (denn das erste, was Benutzer tun, ist natürlich zu überprüfen, welche Tools vorhanden sind verwendet, um die Flatulenz-Simulations-App zu erstellen, die sie herunterladen).
Rory Blyth
3
Andrew, du weißt nicht wovon du sprichst. Ziel-C ist kein Rückstau; Es ist das Rückgrat der nativen Entwicklungsumgebung für Mac, iPhone und iPad.
NSResponder
5
Sie wählen also ein einfaches Beispiel für etwas aus, das Apple in das Framework integriert hat, und behaupten, überlegen zu sein, während Sie die Teile des Frameworks ignorieren, die weitaus klobiger sind als das C # -Äquivalent? Ist das nicht so etwas wie ein Strohmann-Argument?
Andrew Rollings
8
Ich bin zu MonoTouch gewechselt und habe bisher auch 47 Apps auf 4.0 veröffentlicht. Ich mache es ganztägig. Funktioniert super, schnell. Früher habe ich in Objective C geschrieben, aber C # mit Linq schneller gefunden, mit viel weniger Code zum Schreiben.
Ian Vink