Wir möchten eine datenintensive Anwendung für mobile Geräte entwickeln. Unser zentrales Problem ist
- Wir werden ziemlich viele Daten auf dem Client speichern müssen
- Der Client möchte, dass die App offline funktioniert
- Unsere Fähigkeiten sind sehr viel Webentwicklung C# ASP.Net. Definitiv nicht Object C
Wir haben an drei Möglichkeiten für dev gedacht
-
Webanwendung mit lokalem HTML5-Speicher, die den Offline-Anwendungscache nutzt. Wir haben ein Limit von 5 MB für den lokalen Speicher, aber dies kann für bestimmte Browser auf 2,5 MB reduziert werden
-
Webanwendung durch PhoneGap um eine native App zu erstellen. Großer Vorteil hierbei ist, dass wir das Dateisystem zur Speicherung nutzen können. Der Nachteil ist, dass es über den App Store gehen muss (insbesondere für iOS) – 30 % Einnahmen für eine Abonnement-App von Apple
-
Wir bauen die App mit MonoTouch für Android und iOS. Gut – C# und .Net können wir tun. Schlecht – kein Blackberry
Frage
Ich habe Mühe, in diesem Fall echte Vorteile der Verwendung von MonoTouch gegenüber PhoneGap zu erkennen. Was sind Sie? Sind sie welche?
Als Beispiel wäre es in diesem Fall wirklich nützlich, Daten im Dateisystem zu speichern, aber ich glaube, dass die Telefonlücke dies über das tun kann Dateiobjekt. Offensichtlich würde monoTouch System.IO nutzen.
Gibt es Fälle, in denen es bestimmte zusätzliche Funktionen in MonoTouch gibt – insbesondere Funktionen, die für mobile Entwickler nützlich sind, z. B. Geolokalisierung oder Kameratypfunktionen?. Oder hat die Telefonlücke so ziemlich alle diese abgedeckt.
Freche Zusatzfragen
Gibt es andere Optionen, die ich übersehen habe, oder andere wichtige Vor-/Nachteile für die drei von mir skizzierten Ansätze, die ich vergessen habe?
Danke für das Fachwissen aller
Wir haben gerade eine sehr datenintensive App fertiggestellt, die in MonoTouch geschrieben wurde. Die App greift über eine mittlere Ebene auf SAP-Daten zu und stellt diese in der App bereit. Es ermöglicht auch direkte Updates von der App zu SAP, wiederum über dieselbe mittlere Schicht.
Wir sind dabei, dies mit MonoDroid auf Windows Phone und Android zu portieren.
Ich habe eine Weile gebraucht, um den Chef davon zu überzeugen, dass MonoTouch der richtige Weg ist, und wir haben vorher ein paar verschiedene Produkte ausprobiert, darunter jQuery Mobile, ExtJS und Obj C.
Die Zeit, als ich versuchte, ihn zu überzeugen, war die Zeit der Attachmate-Akquisition, und es sah manchmal so aus, als wäre MonoTouch dem Untergang geweiht. Zum Glück für uns (ich) erhob sich Xamarin wie der sprichwörtliche Phönix aus den Flammen, und sie haben Mono* zu dem entwickelt, was es heute ist.
Als C#-Entwickler (und Mono-Enthusiast) war der Hauptgewinn gegenüber Obj C oder HTML/JavaScript die Tatsache, dass ich C# verwenden konnte, um die Arbeit zu erledigen. Die Dokumentation war sehr gut, und als die Doku nicht ganz schnitt (vor kurzem aktualisiert), tat es die Community.
Der IRC-Kanal ist sehr aktiv, mit Xamarin-Mitarbeitern und Community-Evangelisten, die immer bereit sind, zu helfen oder einen Einblick in ein Problem zu geben. Genauso wie die Mailinglisten.
Ein weiteres Plus sind die Ökosysteme, die um MT herum wachsen. MT.Dialog macht die Entwicklung von tabellenbasierten UIs im Vergleich zum XCode-Äquivalent zu einem absoluten Kinderspiel. Verbinden Sie damit die .Net BCL, die zugegebenermaßen eine Teilmenge ist, die auf Silverlight basiert, aber alles von Serialisierung, E-Mail bis hin zu Kryptografie usw. enthält … Wenn .Net dies nicht abdeckt oder es kein bestimmtes Mono * -Projekt gibt , können Sie weiterhin ObjC-Plugins mit Ihrem MT-Code verwenden.
Ich bin nicht der Meinung, dass MT sich als bewährte Plattform „noch beweisen muss“. Wir verwenden es, und obwohl wir ein relativ kleines Unternehmen sind, verwenden es auch viele größere Unternehmen. Einige der von Apple in den TV-Spots hier in Aus präsentierten Apps sind Berichten zufolge in MT geschrieben.
Um objektiv zu bleiben, waren die 2 “Nachteile” von MonoTouch für mich, dass Sie immer noch in der Lage sein müssen, ObjC zu lesen (obwohl ich dies nicht als Nachteil sehe … Als “C#”-Entwickler Ich muss sowieso in der Lage sein, eine Vielzahl von Sprachen zu lesen und zu schreiben) und die Tatsache, dass MonoDevelop historisch gesehen ein bisschen fehlerhaft war. Die größten Fehler scheinen behoben worden zu sein, und da es sich um ein Open-Source-Projekt handelt, können Sie sie jederzeit beheben und uns anderen helfen!
Um Ihre Bedenken zu beantworten:
- Wir werden ziemlich viele Daten auf dem Client speichern müssen
Verwenden Sie die System.IO-Klassen von .Net in C#. Wenn Sie sich nicht sicher sind, bietet MSDN unzählige Beispiele (MT verbirgt die iOS-Implementierung der Dateispeicherung).
- Der Client möchte, dass die App offline funktioniert
Sie können das alle, aber meiner Meinung nach wird sich eine native App immer besser anfühlen.
- Unsere Fähigkeiten sind sehr viel Webentwicklung C# ASP.Net. Definitiv nicht Object C
MonoTouch ist C# – spielen Sie Ihre Stärken aus und haben Sie eine App in Wochen, nicht Monaten!
Meine 2 Cent! Ich würde nicht zögern, immer wieder dieselbe Route zu wählen.
Ich benutze PhoneGap schon seit einiger Zeit (auf WP7), aber nicht MonoTouch, bin aber ein erfahrener C# / Silverlight-Entwickler.
Einige Vorteile von MonoTouch:
- Sie codieren Ergebnisse in einer nativen Benutzeroberfläche, die auf allen Plattformen das beste Erlebnis bietet
- C# ist eine unternehmensstarke Programmiersprache. Es eignet sich gut für die Entwicklung datenintensiver Anwendungen
- Ihre aktuellen Fähigkeiten werden Ihnen hier gute Dienste leisten
- Es gibt zahlreiche mit MonoTouch geschriebene Anwendungen über den App-Store erhältlich.
Ein paar Nachteile von MonoTouch:
- Sie schreiben C#-Code erneut für die iPhone-APIs, daher benötigen Sie für die Portierung auf Android eine separate UI-Schicht für MonoDroid.
Vorteile von PhoneGap:
- Es fängt an, wie ein ziemlich ausgereiftes Framework auszusehen, mit zahlreiche Anwendungen, die mit PhoneGap geschrieben wurden über die gesamte Palette der unterstützten Betriebssysteme hinweg.
- Es gibt gute Community-Unterstützung für PhoneGap
- Es verwendet HTML5, das viele als die Technologie der Zukunft ansehen. Dies ist eine ziemlich weit gefasste Aussage, die jedoch von den meisten großen Playern (Microsoft, Adobe, …) unterstützt wird.
Nachteile von PhoneGap:
- Es verwendet JavaScript, wahrscheinlich das am meisten missverstandene Sprache in weit verbreiteter Verwendung!
- Die Benutzeroberfläche ist in HTML geschrieben. Trotz der besten Bemühungen von Frameworks wie z jQuery Mobile es wird sich niemals heimisch anfühlen.
- Da es über plattformspezifischen „Shim“-Code verfügt, um eine konsistente API bereitzustellen, werden Sie plattformspezifische Probleme feststellen. Ich habe jedoch festgestellt, dass das PhoneGap-Team diese recht schnell behebt.
Zusammenfassend eine schwierige Wahl!
Persönlich würde ich aber zu PhoneGap gehen nicht Versuchen Sie, das Aussehen und Verhalten eines bestimmten Betriebssystems zu emulieren, erstellen Sie stattdessen Ihre eigene Benutzeroberfläche, die für Ihre Anwendung gut funktioniert, und verwenden Sie diese auf allen Plattformen.
Es gibt eine neue Version von MonoTouch, die gestern (8. Februar 2012) herauskam – 5.2. Viele neue Funktionen, um die Entwicklung von iOS-Apps einfacher und schneller zu machen. Details dazu können hier abgerufen werden: http://blog.xamarin.com/
Eine Sache, die MonoTouch zu einer besonders interessanten Technologie macht, ist die Fähigkeit, einige ziemlich ausgeklügelte Apps zu entwickeln, die ohne Internetverbindung ausgeführt werden können. Das kann ein großes Problem sein.
Du könntest einen Blick auf AdobeFlex werfen (adobe.com/de/products/flex.html). Das behauptet auch, in native iOS-Binärdateien herunterkompilieren zu können.
– Basti
8. Februar 2012 um 10:56 Uhr
@chiffre. Danke – aber was ist die verwendete Sprache. Es sieht aus wie ActionScript, ist also wie eine Flash-Variante. Ist das richtig?
– Krabbeneimer
8. Februar 2012 um 11:07 Uhr
Es ist ActionScript und MXML. Solange Sie nur die vorgegebenen Steuerelemente verwenden, ist alles ziemlich einfach. Es gibt eine 60-Tage-Testversion von FlashBuilder, also können Sie es einfach ausprobieren. Ich bin selbst ein wenig durch den Versuch, eigene Benutzersteuerelemente/Komponenten zu erstellen, steckengeblieben.
– Basti
8. Februar 2012 um 11:17 Uhr
Ich dachte, MobileAIR wird nicht zu nativem iOS kompiliert, sondern läuft innerhalb der AIR-Laufzeitumgebung, die jetzt für iOS verfügbar ist. Unabhängig davon programmieren Sie immer noch mit ActionScript und den Flex-APIs.
– ColinE
8. Februar 2012 um 11:42 Uhr
@ColinE Sie können einen Blick darauf werfen flex.org/flexgame Ich habe es ausprobiert und musste nichts anderes auf meinem iPad installieren. Vielleicht ist AIR irgendwie in die App gepackt oder so, aber der Benutzer weiß/sieht es nicht 🙂
– Basti
8. Februar 2012 um 11:54 Uhr