Wie entwickle ich als .NET-Entwickler Branchen-Tablet-Apps? [geschlossen]

Mein Unternehmen verfügt über viel Erfahrung in der .NET-Entwicklung und eines unserer Produkte in einem ERP-System. Kürzlich fragte uns ein Kunde, ob wir eine Tablet-Schnittstelle für dieses System bereitstellen könnten, dh eine Software, mit der der Kunde Produktinformationen anzeigen und Bestellungen auf einem Tablet erstellen kann.

Natürlich freuen wir uns nicht über die Idee, viel Zeit und Geld in das Erlernen von Objective-C, den Kauf von Mac-Entwicklungsarbeitsplätzen, die Zahlung von Gebühren an Apple usw. nur für dieses eine Projekt zu investieren ( möglicherweise können wir die App verkaufen an einige zusätzliche Kunden danach, aber der Markt ist sehr klein, da er nur für bestehende Kunden unseres ERP-Systems nützlich wäre).

Also, was sollten wir tun? Soweit ich sehen kann, haben wir folgende Möglichkeiten:

• Schreiben Sie eine " einfache alte Windows-Anwendung " (WPF) und führen Sie sie auf einem Windows 7-Tablet wie Samsung Slate oder Acer Iconia aus.

  Nachteile: Schwere, teure Geräte mit kurzer Laufzeit (im Vergleich zu "echten" Tablets).

• Warten Sie auf Windows 8 ARM-basierte Tablets und schreiben Sie eine Metro (WinRT) -App.

  Nachteile: Warten Sie mindestens ein Jahr; Es ist unklar, ob Windows 8 ARM die Installation von benutzerdefinierten B2B-Apps unterstützt, ohne den App Store zu durchlaufen.

• Verwenden Sie Mono für Android und schreiben Sie eine .NET-App für Android.

  Nachteile: Noch eine UI-Bibliothek (anders als WPF und Silverlight); Einige Anbieter verbieten das Seitenladen von Apps.

Bisher scheinen die Optionen 1 und 3 am realistischsten zu sein. Habe ich offensichtliche Nachteile oder Vorteile verpasst? Gibt es eine andere Option, die ich noch nicht in Betracht gezogen habe? Waren Sie in einer ähnlichen Situation und haben (erfolgreich) eine bestimmte Option ausgewählt?

JQuery Mobile + Phone Gap Build .

Dies bedeutet im Grunde genommen "Verwenden Sie HTML5 und JavaScript, um Ihre App zu erstellen", wie bereits gesagt, aber mit einer wichtigen Wendung.

Mit dem Phone Gap Build- Dienst von Nitobi (jetzt im Besitz von Adobe) können Entwickler HTML5 / JavaScript-Apps in "native" Apps (wirklich hybride Apps) konvertieren, die lokal auf einem Gerät bereitgestellt werden können. Ich verstehe, dass im Grunde genommen unter der Haube eine kleine native Binärdatei gepackt wird, die den nativen Browser aufruft und Ihre Site von einer Datei lädt: // URL.

Sie müssen kein bestimmtes JavaScript-Framework als Ziel festlegen - dasselbe HTML und JavaScript, das in einer mobilen Web-App sehr gut funktioniert, funktioniert einwandfrei.

Auch der Offline-Support ist nicht schwer. Mit dem lokalen Browserspeicher, der von vielen Mobilgeräten gut unterstützt wird, können Sie auf diese Weise wirklich leistungsstarke Offline-Apps erstellen. Es wird empfohlen, Ihre externen Abhängigkeiten lokal zu verpacken, anstatt ein CDN zu verwenden, damit Ihre App offline gut funktioniert.

Frameworks wie KnockoutJS und BackboneJS sind sehr hilfreich, damit Sie ausgereifte JavaScript-Apps erstellen können, und sie funktionieren problemlos mit dem Build-Service von Phone Gap.

Wenn das Gerät online ist, können Sie es problemlos auf die Backends des ASP.NET / MVC-, WebAPI- oder WCF-Dienstes klicken lassen, um Daten zu aktualisieren.

Die daraus resultierenden Apps sind wirklich recht gut und können auf den Apple- und Android-Märkten vertrieben werden. Es gibt bereits viele Apps auf diesen Marktplätzen, die mit Phone Gap Build und anderen ähnlichen Produkten erstellt wurden, und 99% der Menschen (einschließlich der meisten Entwickler) können den Unterschied nicht erkennen.

Offensichtlich werden Sie nicht versuchen, Angry Birds auf diese Weise zu erstellen (obwohl Sie es mit Canvas wahrscheinlich versuchen würden), funktioniert es wunderbar mit den Arten von Apps, über die Sie sprechen.

Nimm mein Wort nicht dafür. PhoneGap wurde die Runde auf der PodCast Schaltung zu tun, nachdem sie auf vor kurzem Hansel , DotNetRocks und das Tablet anzeigen . Außerdem habe ich kürzlich in einem Blog-Beitrag darüber geschrieben .

Produktinformationen anzeigen und Bestellungen erstellen

Klingt nach Dingen, die gut zu HTML 5 passen (und zu den verwandten Technologien, die normalerweise in einem Atemzug erwähnt werden). Wenn Sie eine umfangreiche Webanwendung schreiben, unterstützen Sie jedes Gerät sofort mit einem Browser .

Ich würde empfehlen, es als MVC-Web-App zu entwickeln. Auf diese Weise können Sie es auf fast jedem Gerät von einem Desktop auf ein Smartphone ausführen, sofern Sie es gut gestalten. HTML5 funktioniert möglicherweise, hängt jedoch von den Arten von Geräten / Browsern ab, die Sie unterstützen müssen. Es wäre schön, wenn Sie damit durchkommen könnten. Stellen Sie sicher, dass Sie es so gestalten, dass Sie Teile davon in Zukunft als WCF-Backend für eine Metro-App anpassen können.

Wenn Sie das vorhandene .NET-Wissen nutzen möchten, sollten Sie sich für einen SOA-Ansatz entscheiden und so viele Funktionen wie möglich in einen Webdienst integrieren (SOAP oder REST, wählen Sie die für Sie am besten geeignete aus). Auf diese Weise benötigen Sie nur eine kleine Client-App auf dem Gerät, die nur die Webdienstfunktionalität aufruft und die Ergebnisse anzeigt. Dies sollte viel einfacher zu entwickeln sein als ein ausgewachsener Client, der Geschäftslogik implementiert, unabhängig davon, für welchen Client Sie sich entscheiden.

Sie können später auch Unterstützung für verschiedene Geräte hinzufügen. Sie benötigen lediglich eine kleine Client-App für das neue Gerät.

Um ein Gerät auszuwählen, sehe ich zwei Kriterien:

1. Wählen Sie die aus, die Ihr aktueller Kunde bevorzugt (wenn er nach einer Tablet-App fragt, hat er sich Gedanken darüber gemacht).
2. Wählen Sie die aus, die am wahrscheinlichsten auch von anderen Kunden akzeptiert wird. Dies könnte sehr gut das iPad oder vielleicht der Kindle Fire sein, weil die Leute diese bereits gesehen haben.

Warten Sie auf keinen Fall auf Geräte, die noch nicht auf dem Markt sind. Dies würde Ihre Option 2 ausschließen (Windows 8 auf ARM-Tablets).

Jede Windows-Anwendung bedeutet, dass Sie an MS gebunden sind. Außerdem passen Silverlight und iOS / IE 10 nicht gut zusammen. Wählen Sie HTML 5 und JavaScript mit Web Services und / oder JQuery. Tools von Drittanbietern wie die Telerik-Kendo-Benutzeroberfläche sollten Ihre GUI für die LOB-App cool genug machen. Dot Net konnte nur auf der Serverseite von Wert sein.

Dieser letzte Kommentar sagt wirklich alles: "Dot Net könnte nur auf der Serverseite von Wert sein" - vielleicht hätte Microsoft es so nennen sollen. Nicht? Oder .WindowsOnly?

Sie können nicht einmal clientseitige Windows RT-Apps in .Net schreiben.

Es ist richtig, dass Ihre in .Net geschriebenen Geschäftslogiken und Datendienste auf einem Windows-Server leben und eine webfreundliche API verfügbar machen müssen, um im plattformübergreifenden Spiel zu spielen. Die neueste ASP.Net-Web-API hat im April 2013 fast industrielle Stärke. Auf diese Weise können Sie Ihre .NET-Objekte als JSON verfügbar machen, sodass clientseitige JQuery / JS-Apps problemlos integriert werden können.

Auf der Clientseite können Sie .Net nicht verwenden. Sie müssen Ihren gesamten UI-Code in HTML / CSS / JQuery und Ihre Logik unter Verwendung von JS mit möglicherweise Knockout für datenorientiertes Binden schreiben.

Für uns .Net-Entwickler ist es das Nirvana der Entwicklung von LOB-Apps, einfach unsere Benutzeroberfläche zu zeichnen, ohne MARKUP schreiben zu müssen. Wer ein clientseitiges .Net-Framework entwickelt, das genauso gut funktioniert wie VS / .Net / WinForms / C # / VB.Net, wird die Welt regieren - und NEIN - meiner Meinung nach ist Mono nirgendwo (keine Unterstützung durch Komponentenanbieter von Drittanbietern). in der Nähe von VS / .Net / WinForms.