Was sind die Vor- und Nachteile von HTML5, nativen und hybriden mobilen App-Ansätzen?

Ich möchte eine mobile Anwendung entwickeln. Ich habe kürzlich einen Artikel im Telerik-Forum gelesen , in dem drei Arten mobiler Anwendungen verglichen werden, und ich weiß nicht, für welche ich mich zuerst entscheiden soll. Hier ist ein Bild, das die Vor- und Nachteile der verschiedenen Optionen für das mobile Design beschreibt

Um zwischen diesen Entwurfswahlen zu entscheiden, möchte ich die Vor- und Nachteile jeder im Diagramm aufgelisteten Architekturwahl besser verstehen. Welche Vor- und Nachteile hat jeder Architekturansatz?

Ich bin ein mobiler Entwickler, der sich intensiv mit diesem Thema beschäftigt hat.

Warum fragst du?

Höchstwahrscheinlich möchten Sie die Kosten für die App-Entwicklung senken, indem Sie:

• Nutzung vorhandener HTML5 / Javascript-Entwicklungsfähigkeiten
• Auf mehrere Plattformen abzielen, ohne mehrere Apps von Grund auf neu zu schreiben
• In Zukunft müssen nicht mehrere Codebasen verwaltet werden

Gründe können auch sein:

• HTML5 / Javascript-Entwicklung wird als "einfacher" empfunden als native Plattformentwicklung
• Vermeidung der Zahlung von Registrierungsgebühren für Entwicklerprogramme
• Vermeidung von Beschränkungen für Appstore-Inhalte (Glücksspiele usw.)
• Vermeiden des Kaufs von Entwicklungshardware (zB Mac für iPhone-Entwicklung)

Definitionen

Lassen Sie uns genau festlegen, was wir mit jedem der drei genannten Ansätze meinen:

Native
Eine App, die auf einem Gerät installiert ist, normalerweise aus dem App Store (obwohl sie manchmal von der Seite geladen werden kann). Für die Zwecke dieser Diskussion besteht die Benutzeroberfläche einer nativen App normalerweise nicht nur aus einer Vollbild-Webansicht.

Mobiles Web
Dies kann in der Tat eine beliebige Webseite sein. In dieser Diskussion wird jedoch eine einseitige Web-App betrachtet, die versucht, das Erscheinungsbild einer nativen App zu imitieren. Es ist keine native App, sondern wird im Browser des Geräts ausgeführt.

Hybrid
Hybrid App instanceofnative App.

Die meisten Leute verstehen eine Hybrid-App wahrscheinlich als eine einseitige mobile Web-App (die wahrscheinlich das Erscheinungsbild einer nativen App imitiert), aber als native App mit Zugriff auf native Services (à la Phonegap).

Tatsächlich gibt es jedoch ein Spektrum zwischen dem Phonegap-Modell und dem vollständig nativen, auf das ich später noch eingehen werde.

Mobiles Web

Technische Einschränkungen
Lassen Sie uns zunächst einige technische Einschränkungen für mobile Web-Apps auflisten, die für sich genommen, abhängig von Ihren Aktivitäten, zu Bruch gehen können:

• Nur HTML / Canvas-Benutzeroberfläche
• Kein Zugriff auf bestimmte Geräteereignisse und -dienste (diese sind weitgehend dokumentiert)
• Kann nicht in App Stores aufgeführt werden (Auswirkungen auf die Erkennbarkeit)
• Unter iOS können Vollbild- und Startbildschirmsymbole angezeigt werden. Dies ist jedoch für die meisten Benutzer eine ungewöhnliche und ungewohnte Erfahrung

Wenn Sie mit all dem leben können, lesen Sie weiter, um mehr über die Herausforderungen von einseitigen nativen Web-Apps zu erfahren. Dieser Abschnitt wäre jedoch ohne Bezugnahme auf die FT-App nicht vollständig.

Financial Times
Die FT-Web-App ist ein bekanntes Beispiel für diesen App-Stil. Hier ist ein interessantes Feature der britischen Guardian-Zeitung dazu.

Es ist sicherlich eine bemerkenswerte Leistung der Technik. Beachten Sie, dass es derzeit nur noch auf iOS verfügbar ist. Dies zeigt, dass es für sie sehr schwierig ist, die Herausforderungen der fortschrittlichen browserübergreifenden Entwicklung zu lösen.

Einseitige Web-Apps im einheitlichen Stil

Dieser Abschnitt gilt sowohl für mobile Webanwendungen als auch für Apps im Phonegap-Stil.

Das native Erscheinungsbild einer Web-App wird normalerweise mit einem Framework wie Sencha Touch erzielt , das eine Reihe von UI-Komponenten zur Verfügung stellt.

Solche Frameworks eignen sich gut für sehr einfache Benutzeroberflächen. Ihnen fehlt jedoch Flexibilität. Mit Sencha können Sie kein natives App-Design implementieren. Sie müssen Ihr Design an die Anforderungen des Frameworks anpassen.

Die Hauptursache für diese Frameworks ist der Versuch, die Feinheiten der Benutzeroberfläche der Plattform zu emulieren. Welchen netten kleinen Springeffekt bekommst du, wenn du auf dem iPhone zum Ende einer Liste gescrollt hast? Ihr Framework muss dies in Javascript emulieren. Es ist unmöglich, es vollständig neu zu erstellen, es wird sich verlangsamen und Ihre Benutzer werden im "unheimlichen Tal" einer App gefangen sein, die ein bisschen wie einheimisch aussieht, es aber eindeutig nicht ist und nicht technisch ist Der Benutzer kann nicht genau sagen, warum.

Der Mythos "HTML5 / Javascript ist einfach"

Die Fragmentierung von Geräten in Webbrowsern ist weit verbreitet, und wenn Sie über das grundlegendste HTML und CSS hinausgehen, werden Sie feststellen, dass die Dinge nicht so funktionieren, wie Sie es erwarten. Möglicherweise verbringen Sie mehr Zeit mit der Lösung umständlicher Benutzeroberflächenprobleme, als Sie es sich zweimal erspart hätten. Wenn Sie nativ werden, beachten Sie, dass native App-Webviews nicht mit Gerätebrowsern identisch sind und ihre eigenen Fragmentierungsprobleme haben.

Und da Ihre App immer komplexer wird, werden Sie feststellen, dass Sie mehr als nur grundlegende JQuery-Kenntnisse benötigen, um Ihr Javascript sauber und wartbar zu halten.

Mit diesem Ansatz ist es jedoch durchaus möglich, recht schnell einfache, funktionierende Apps zu erstellen. Aber es ist ziemlich offensichtlich, wann eine App es tut.

Weiter entlang des Spektrums

Wir wollen also ein besseres UX, als es Apps im Phonegap-Stil bieten können, ohne absolut alles von Grund auf neu zu schreiben. Was können wir tun?

Teilen Sie Nicht-UI-Code

Für die gemeinsame Nutzung der Geschäftslogik auf mehreren nativen Plattformen stehen verschiedene Techniken zur Verfügung. Google hat J2ObjC gestartet, das Java in Objective-C übersetzt. Unter sorgfältiger Berücksichtigung von Code kann eine Java-Bibliothek sowohl auf Android als auch auf iOS verwendet werden.

Mit Bibliotheken wie Calatrava und Kirin können in Javascript geschriebene Codebasen (und damit alles, was mit Javascript kompiliert werden kann) aus nativem Code manipuliert werden. Haftungsausschluss: Ich arbeite für Future Platforms, die Kirin erstellt haben. Wir hatten großen Erfolg damit auf iOS mit Javascript, das aus Java mit GWT generiert wurde, wobei Java-Code auch nativ auf Android ausgeführt wird.

Verwenden Sie gegebenenfalls Webviews

Vollbild-Webviews haben viel zu tun, um Bildschirmübergänge und Bounce-Effekte zu imitieren. Eine Webansicht in nativem App-Chrom kann jedoch nicht von nativem unterschieden werden.

Es gibt Standardmethoden und gut dokumentierte Methoden für die Kommunikation mit nativen Apps und Webviews.

Auf diese Weise können Listen und Tabellen besonders gut funktionieren. Die Texteingabe ist jedoch ein Beispiel für eine native Vorgehensweise (für die vollständige Kontrolle über die Tastatur).

Zusammenfassend

Welcher Ansatz für Sie am besten geeignet ist, hängt davon ab, wie kompliziert Ihre App ist und mit welcher Oberflächenpolitur Sie zufrieden sind.

Mein Motto: Verwenden Sie Webviews, wo immer Sie können, aber stellen Sie sicher, dass Ihre Benutzer es nicht wissen .

Überprüfen Sie zuerst diese Umfrage, um zu wissen, was los ist!

Vergleich zwischen den drei Typen: Grundlegendes zu den Entwicklungsoptionen für mobile Anwendungen

Vergleiche zwischen einheimischen und hyprid:

HTML5 vs Native

HTML5 vs Native App: Welche soll ich wählen?

Dieser ist wirklich gut: HTML5 v native Apps: Wichtige Überlegungen für Ihre mobile Strategie

Bemerkungen:

• Sie können sich für eine von ihnen entscheiden, abhängig davon, was Sie haben (Fähigkeiten) und was Sie bekommen können (Aussehen und Verhalten, Leistung, Funktionalität, ...).
• Jeder Entwickler einer mobilen App sollte eine klare Vision / Anforderungen an die Anwendung haben, die er für die ersten und die zukünftigen Versionen entwickeln möchte! Nur um sicherzustellen, dass die Option, die er verwenden würde, ihn irgendwann nicht mehr einschränkt.
• Es gibt nichts Schöneres als eine echte Erfahrung mit den drei Möglichkeiten und gleichzeitig auf dem neuesten Stand zu sein. Dies gibt Ihnen den Sinn und die Fähigkeit, die richtige Entscheidung zu treffen.

Wenn Sie auf die Hardware des Telefons zugreifen müssen, sollten Sie eine native App erstellen (in HTML5 können Sie auf einige Hardwarekomponenten des Geräts zugreifen, z. B. auf GPS).

Wenn Sie mit der Webentwicklung vertraut sind, sollten Sie sich daran halten, es sei denn, Sie müssen eine native App erstellen.

Soweit Sie wissen sollten, würde ich sagen, dass Sie alle unterschiedlichen Bildschirmgrößen (einschließlich vertikaler und horizontaler Ausrichtung) berücksichtigen sollten. Sie sollten verschiedene Versionen des Betriebssystems beachten (dies ist mehr für Android). Da es sich um mobile Geräte handelt, besteht die Möglichkeit, dass der Benutzer einen Anruf entgegennimmt und nicht über die Rechenleistung eines Desktops oder Servers verfügt.

Wenn ich eine Consumer-App schreibe, ist für mich die Akzeptanz und Wahrnehmung der App durch den Benutzer von größter Bedeutung für den Erfolg. Aus diesem Grund gibt es vier Gründe, sich für native Apps zu entscheiden:

1. Schnellerer App-Start
2. Reibungsloseres Scrollen
3. Mehr Konsistenz-App-Benutzeroberfläche, die konsistenter mit dem Rest des Betriebssystems und der Apps verbunden ist
4. Schnellere Reaktion der App-Benutzeroberfläche

Was Sie vor allem wollen, ist eine großartige Benutzererfahrung, die Ihrer App hilft, auf dem Markt erfolgreich zu sein. Natürlich gibt es Ausnahmen, insbesondere mangelnde Fähigkeiten, Zeit- und Budgetmangel. Manchmal richten sich Apps an eine begrenzte Anzahl von Geschäftsbenutzern, denen diese Dinge möglicherweise nicht so wichtig sind.

Aus ähnlichen Gründen hat Facebook seine App-Strategie zugunsten nativer Apps für iOS und Android aufgegeben:

Lesen Sie bitte:

Mark Zuckerberg: Unser größter Fehler war, dass wir zu viel auf HTML5 gewettet haben http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on--- html5 /

Warum Facebook das mobile Web über Bord geworfen hat und mit seiner neuen iOS-App gebürtig wurde http://readwrite.com/2012/08/23/how-facebook-ditched-the-mobile-web-went-native-with-its-new- ios-app # awesm = ~ o9jDrRefxdgnpS

Hoffe das hilft.

Nachstehend meine derzeitige Haltung zu diesem Debakel: Hybrid ist zunächst gut, um Ihre App zu erkunden, schnell auf Kundenfeedback zu reagieren und den Funktionsumfang zu stabilisieren. Anschließend können Sie die App entsprechend der Spezifikation in native umschreiben, um die Benutzererfahrung zu verbessern.

Ich habe Mobile Web weggelassen, weil es einem ganz anderen Zweck dient. Wenn Sie in den App Stores sein möchten, ist Native / Hybrid der richtige Weg. Wenn Sie die Bereitstellung vereinfachen möchten und Erfahrung und technische Fähigkeiten einbüßen möchten, entscheiden Sie sich für Mobile Web.

Pro / Cons Native :

• Pro: Es passt zum restlichen Geräteerlebnis, keine unheimlichen Talprobleme.
• Pro: Meist bietet es eine reibungslose, konsistente Benutzeroberfläche, keine Verzögerungen, keine Ruckler.
• Pro: Nur wenige technische Einschränkungen, Sie können das Gerät voll ausnutzen.
• Pro: Native-Tools gewährleisten die Konformität mit der Validierung von App Stores.
• Pro: Native Frameworks enthalten Optimierungen pro Plattformversion, wodurch weniger Zeit für die Feinabstimmung aufgewendet wird.
• Con: Es ist für die Ewigkeit gebaut und braucht daher mehr Zeit zum Bauen.
• Con: Benötigt Polyglot-Entwickler, die schwer zu finden und teuer sind.
• Con: Sie müssen sich mit den APIs aller Geräteplattformen (iOS / Android / usw.) vertraut machen.
• Con: Steile Lernkurve.
• Con: Unterschiedliches Toolset pro Plattform.

Pro / Contra Hybrid :

• Pro: Eine einzige Codebasis für mehrere Geräteplattformen.
• Pro: Schnelle Entwicklungszyklen, große Flexibilität im Layout, perfekt für Prototyping und MVPs .
• Pro: Bequeme Lernkurve, viele Dokumentationen, Frameworks, die Ihnen helfen.
• Pro: Toolset für die Einzelentwicklung. Chrome-Debugger-Tools sind ausgezeichnet.
• Pro: Eine Codebasis für mehrere Geräteplattformen.
• Pro: Viele Entwickler verfügbar, leicht zu erlernen.
• Con: Benötigt ein anständiges UI-Framework, um die Benutzeroberfläche für jede Plattform so anzupassen, dass sie dem Geräteerlebnis entspricht. Es gibt Lösungen wie Kendo UI , Sencha Touch .
• Con: Müssen sehr bewusst über Speicher-und Computing-Nutzung sein, einige CSS, Javascript-Schleifen können die App ernsthaft verlangsamen. Auf dem Gerät sind keine sehr guten Tools zum Debuggen verfügbar.
• Con: Noch nicht ausgereift, Dinge können sich plötzlich ändern, aber die Werkzeuge werden besser.

Als mobiler Entwickler ist der Offline-Zugriff das Schlimmste. Sie erzwingen einfach, dass Benutzer online sind, was in vielen Apps funktionieren sollte, aber nicht in allen.

Der andere große Nachteil ist die Langsamkeit. Die zum Parsen entfernter Daten erforderliche Zeit kann beträchtlich sein. Ja, Sie können Daten während der Ladezeit vorab abrufen, aber in allen anderen Fällen können Sie eine Langsamkeit nicht vermeiden.

Ich fand, dass eine solche App App teurer als native beendet. Ich empfehle sie keinem meiner Kunden mehr.

Das große Problem bei hybriden Apps ist die Fragmentierung der Frameworks: Es gibt deutlich mehr davon (Ionic, Xamarin, React Native usw.) als native mobile Plattformen (in der Regel nur zwei, Android und iOS). Diese Frameworks konkurrieren, entstehen und sinken, sodass Sie sich durch den Wechsel zu einem Hybrid nicht vom Sprung von Plattform zu Plattform abhalten lassen, selbst wenn Sie vorhaben, Ihr aktuelles Team für immer zu behalten.

Google und Apple geben ihr Bestes, um Editoren, Debugger, Testframeworks, Refactoring-Tools und andere Mittel bereitzustellen und zu unterstützen, die sie für ihre Plattformen entwickeln können. Daher würde ich eine typische Formulierung nehmen: " Es ist viel einfacher, eine Hybrid-App zu entwickeln, mit Ihrem Lieblingseditor zu bearbeiten und in einem Browser zu öffnen ", mit der begründeten Einschränkung. Xamarin und React Native sind Entwicklungsplattformen, genauso wie Swift oder Java / Android, und während "Hallo Welt" kürzer aussehen mag, sollte es sich irgendwann die vergleichbare Zeit nehmen, um richtig zu lernen.

Wenn auf jeden Fall native Komponenten benötigt werden (z. B. muss eine vorhandene Bibliothek eines Drittanbieters integriert werden), stehen drei Frameworks anstelle von zwei zur Verfügung: iOS, Android und Ihr Hybrid-Framework mit komplexerer Architektur. Das Debuggen solcher Apps, das Wechseln zwischen schichtübergreifenden Aufrufen, das Protokollieren aller Schichten und das Synchronisieren von Code ist komplex bis manchmal unmöglich.

Einige sagen, die " App wird für alle Plattformen gleich aussehen ". Ist es wirklich eine gute Sache? Die Android-App muss aussehen wie die Android-App und die iOS-App muss aussehen wie die iOS-App.

Was ist mit den neuen Funktionen? Wearables? Sofort-Apps jetzt von Android-Plattform angeboten? Zusätzliche Daten auf externem Display anzeigen? Hybrid-Apps unterstützen jetzt viele native Funktionen, aber unterstützen sie wirklich alle ? Jederzeit sofort?

Nicht nur die Leistung und die Benutzerfreundlichkeit, sondern auch die Sicherheit können für die native App von größerer Bedeutung sein. Das hybride Framework fügt die Ebene der Indirektion hinzu, die möglicherweise eigene Fehler enthält, einschließlich Sicherheitslücken.

Zusammenfassend würde ich unter der Auswahlmöglichkeit entweder die beiden nativen Apps wählen, eine für iOS und eine für Android, oder alternativ einfach eine mobile Version der Website entwerfen, ohne die App-Entwicklung für irgendeine Plattform zu beeinträchtigen .