Telefonlücke vs. Monotouch für datenintensive App

Lesezeit: 9 Minuten

Benutzer-Avatar
Krabbeneimer

Wir möchten eine datenintensive Anwendung für mobile Geräte entwickeln. Unser zentrales Problem ist

  1. Wir werden ziemlich viele Daten auf dem Client speichern müssen
  2. Der Client möchte, dass die App offline funktioniert
  3. Unsere Fähigkeiten sind sehr viel Webentwicklung C# ASP.Net. Definitiv nicht Object C

Wir haben an drei Möglichkeiten für dev gedacht

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

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

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

  • 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

Benutzer-Avatar
Darbio

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:

  1. 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).

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

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

  • Gute Antwort. Eine Frage an Sie, wenn Sie auf MonoDroid portieren, müssen Sie wohl wieder mit dem UI-Code beginnen? Aber Sie können die Geschäftslogik teilen?

    – ColinE

    8. Februar 2012 um 13:59 Uhr

  • Wenn Sie die Lösung mit genügend Voraussicht entwerfen, können Sie die gesamte Geschäftslogik zwischen Ihren Apps wiederverwenden. Zwischen MonoDroid und MonoTouch gibt es einige Open-Source-Projekte mit den Namen MD.Dialog bzw. MT.Dialog – es gibt eine beträchtliche Wiederverwendung zwischen diesen beiden Bibliotheken, sodass Sie möglicherweise bestimmte Teile Ihrer Benutzeroberfläche wiederverwenden können – nicht alle, aber mit M*.Dialog können Sie in diesem Fall eigene Elemente schreiben.

    – Darbio

    8. Februar 2012 um 23:09 Uhr

  • @JD Das ist eine großartige Antwort. Vielen Dank dafür, es ist wirklich nützlich, sich in die reale Welterfahrung von jemandem einzuklinken. Mit dem Beispiel des Dateisystems und System.IO – keine Telefonlücke gibt es das gleiche mit dem Dateiobjekt. Gibt es nennenswerte funktionale Lücken in der Telefonlücke im Vergleich zu monoTouch? Die einen praktischen Unterschied machen würden? Oder ist der Vorteil wirklich, dass Sie C# anstelle von JavaScript für die Entwicklung verwenden, was einfacher wäre (zumindest für uns). Und natürlich, dass Sie statt einer Web-App in einem Wrapper eine echte native App bekommen

    – Krabbeneimer

    9. Februar 2012 um 9:02 Uhr


  • Vielen Dank. Ich habe nicht versucht, auf das Dateisystem in der Telefonlücke zuzugreifen, der Vorteil für Sie ist, dass Sie .net-Entwickler sind und als solcher wissen, wie man Dinge tut, wie das Dateisystem manipulieren, E-Mails senden, Webdienste nutzen, erstellen/verbrauchen Objekte auf iOS etc. bereits.

    – Darbio

    12. Februar 2012 um 7:37 Uhr


Benutzer-Avatar
ColinE

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.

  • Danke für die Antwort. Sehr informativ. Ich frage nach MonoTouch xamarin.com/monotouch nicht monCross – meinst du MonoTouch – ist es nur ein Tippfehler?

    – Krabbeneimer

    8. Februar 2012 um 10:50 Uhr

  • @ColinE: Haben Sie jemals eine datenintensive App mit PhoneGap gesehen? Mich würde das Thema auch interessieren, finde aber nur eher “einfache” Apps.

    – Basti

    8. Februar 2012 um 11:06 Uhr

  • Sie haben nicht im AppStore nach PhoneGap-Anwendungen gesucht, sondern sind auf die Website von PhoneGap gegangen. Wenn Sie MonoTouch der gleichen Behandlung unterziehen, werden Sie schnell Folgendes feststellen: xamarin.com/apps – Hunderte von Apps, die mit MonoTouch und Mono für Android erstellt wurden.

    – Rolf Bjarne Kvinge

    8. Februar 2012 um 11:33 Uhr

  • Gute Antwort. Zum Punkt über die Benutzeroberfläche von PhoneGap “es wird sich niemals nativ anfühlen”. Kendo UI in Verbindung mit PhoneGap kann dabei helfen.

    – Adam Caviness

    20. Mai 2012 um 1:12 Uhr

  • @ColinE Dieser Beitrag hat mir wirklich sehr geholfen. Aber ich bin mir immer noch nicht sicher, welche Sie für solche Apps bevorzugen würden: Pose bei iTunes. Es scheint mit HTML5 entwickelt zu werden, aber welches Tool und welche Technologie sind besser. Bitte helfen Sie mir.

    – Ajay Sharma

    16. Januar 2013 um 13:30 Uhr

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.

1228920cookie-checkTelefonlücke vs. Monotouch für datenintensive App

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy