Ich muss eine mobile App für iOS und Android (also 2 Apps) erstellen. Die App wird einige native mobile Funktionen nutzen und viele Funktionen beziehen sich auf die Anzeige statischer / dynamischer Informationen. Ich plane, die Informationen über die Web-App zu verschieben und einfach die Webseiten (HTML5) in die mobilen Apps einzubetten (im Grunde rufen Sie die URLs auf und zeigen Informationen an).
Ist das eine übliche Methode, um mobile Apps zu entwickeln? Oder kann es Probleme mit dem folgenden hybriden Ansatz geben? Gibt es Vorteile der nativen App gegenüber der hybriden App (oder umgekehrt)?
Danke Kamal
Ich habe hauptsächlich native Android-Entwicklung gemacht, aber ich habe auch geholfen, ein paar Apps zu debuggen, die mit den "Cross-Compile" -Plattformen wie PhoneGap erstellt wurden und die Cross-Compiled-Apps haben ein paar Macken, zu denen es nett ist Lassen Sie die Plattform einfach für Sie arbeiten, wenn Sie eine native App erstellen.
Zum Beispiel hat einer von denen, die ich in letzter Zeit debuggte, keine Handler für Back-Button-Ereignisse implementiert, was eine wirklich unangenehme Benutzererfahrung war. In einer nativen Android-App, und ich gehe davon aus, dass es für iOS dasselbe ist, obwohl ich noch nie versucht habe, iOs zu erstellen, handhabt das System die Tasten für Sie, weil es weiß, welche Aktivität vor der aktuellen ausgeführt wurde und die Benutzeroberfläche neu erstellen kann . In PhoneGap ist es im Wesentlichen ein Webkit-Browser, der in eine Android-Anwendung eingebettet ist, so dass er nicht auf Dinge wie den Backstack zugreifen kann.
Wenn Sie bedenken, dass das System diese Art von Ereignissen für Sie nicht verarbeiten wird und Sie nicht auf alle Sensoren am Telefon zugreifen müssen, könnten Sie wahrscheinlich mit einer dieser Methoden davonkommen Frameworks
Es ist lustig, wie oft ich gefragt oder über diese spezifische Frage gesprochen werde. Hier ist mein Grundgefühl:
HTML 5, Hybrid HTML 5 / Native und Native Apps sind alle gut, fast vergleichbare Optionen, aber was zu wählen ist eine andere Geschichte.
Hier sind einige Gründe, warum ich eine von ihnen wählen könnte, und da ihr mir hilft, die Programmierwelt zu verstehen, werde ich die Art und Weise, wie das Produkt (was ich hauptsächlich tue) über die Marktpositionierung und die Geschäftsseite der Dinge denken .
HTML 5 technical reasoning : Ich brauche diese Anwendung auf fast jedem Gerät, das ein Benutzer haben könnte. Diese Anwendung wird keine proprietären oder komplexen Gerätefunktionen nutzen (Fotos hochladen, Push-Benachrichtigungen auslösen). ..).
HTML 5 Produkterklärung : HTML 5 kann die Entwicklungskosten auf zwei Arten drastisch senken. (1) Es gibt einen größeren Talent-Pool (also niedrigere Kosten), der um Standard-Front-End-Engineering-Projekte wie HTML 5-Entwickler konkurriert, während iOS- und Android-Entwickler eine ernsthafte Prämie haben und nur schwer zu erreichen sind einmal und es ist viel einfacher zu pflegen, qa und einrichten Kopien.
Darüber hinaus müssen Sie sich nicht mit App-Stores auseinandersetzen, die einen Teil Ihres Umsatzes ausmachen. Das klassische Beispiel dafür ist die Financial Times (FT). Die FT vergütet teure Abonnements, die die meisten Banker von ihren jeweiligen Banken kaufen. Als solche haben sie eine loyale, intime und preisunabhängige Zielgruppe, und ihr hauptsächlicher Umsatz stammt fast ausschließlich aus Abonnements. Als sie ihre App im Apple App Store hatten, konnten sie unmöglich 30% eines neuen Abonnenten an Apple verschenken. Sie haben den App Store verlassen und eine der umfangreichsten und beeindruckendsten Webapps entwickelt, die sich sehr an eine App anlehnt, über fast jedes Java-fähige Telefon funktioniert und es ihnen ermöglicht, das Geld von Abonnenten zu behalten. In der Entwickler-Community haben sie viele Auszeichnungen für diese Seite bekommen (Sie können es auf Ihrem Telefon lesen, ich denke, es ist www.ft.com) und haben ihre Markenbekanntheit durch Innovatoren erhöht. Spiel, Satz, Spiel.
Der letzte große Vorteil von HTML 5 besteht darin, dass Sie sich nicht mit App-Stores beschäftigen müssen. Das bedeutet, dass Ihre Hände nicht gebunden sind und Sie können die Dinge auch im laufenden Betrieb ändern, so dass mehr Iteration und ein besseres Produkt sich viel schneller bilden als bei Apple und warten Sie zwei Wochen auf jede Verbesserung, die Sie machen möchten (das ist etwas) im Hybrid-Ansatz ebenfalls gemildert). Nach der Verwaltung der HTML 5-Tablet-Website bei ABC News war es von entscheidender Bedeutung, dass wir die Dinge sehr schnell in der Nachrichtenbranche beheben konnten, was diesen Ansatz perfekt für diese Art von App macht.
Hybrid HTML 5 / Natives technisches Denken: Ich möchte, dass diese Anwendung auf so vielen Plattformen wie möglich läuft, aber ich werde einige davon tauschen, um Zugriff auf proprietäre und komplexe Gerätefunktionen zu erhalten ein paar beliebte. Ich bin auch mit der Tatsache zufrieden, dass das Design nicht immer pixelgenau ist und das Potenzial für gelegentliche Trägheit besteht.
Hybride HTML 5 / Native Product Reasoning: Wenn ich eine App habe, die mindestens auf iOS / Android sein muss, ist das keine Erfahrung, die komplett benutzerdefiniert sein muss und eine sein muss App im App Store, denn ehrlich gesagt, werben die Werbetreibenden gerne für Apps, während das mobile Web kaum auf dem Radar steht, wäre der Hybrid-Ansatz wahrscheinlich mein bester Kandidat. Wie HTML 5 nur, ist es viel billiger, eine mobile Website zu erstellen, und dann einen nativen Entwickler anstellen, um einen schnellen App-Wrapper für Sie auf iOS / Android / Windows was auch immer zu bauen. Darüber hinaus müssen Sie nur den HTML-Teil optimieren, eine neue Instanz erstellen und Sie haben eine mobile Website als Bonus!
Eine der Gefahren hier ist, wenn der HTML 5 nicht etwas reaktionsfähig ist oder in 320x480 und 1028x768 gesperrt ist, da verschieden große Tablets herauskommen, müssen Sie viele Instanzen der Site machen und nach dem useragent suchen, was ist zeitaufwendig und ein Alptraum. Wenn dies passiert, wird es in der Regel nur als reaktionsfähige Seite neu aufgebaut, die es eigentlich hätte sein sollen.
Natives technisches Denken: Ich möchte, dass diese Anwendung auf einer Plattform genau so läuft, wie ich es möchte. Ich muss auf proprietäre und komplexe Gerätefunktionen zugreifen können. Diese Anwendung muss sehr komplexe Vorgänge ausführen, benötigt viel Speicher und ist eine sehr benutzerdefinierte Anwendung mit vielen benutzerdefinierten UI-Controllern. (Ein paar Kategorien gehören: 3D-Spiele, schwere UGC-Apps wie CNN iReport und viele Dienstprogramme)
Native Product Reasoning: Denken Sie daran, dass Sie als Produktperson, die mit Budgets und Ressourcen zu tun hat, bestenfalls fast immer begrenzt sind.Wenn ich oben sage, dass Native nur für 3D-Spiele geeignet ist, verstehe ich vollkommen, dass du es auch für einfachere Apps verwenden kannst, aber es ist viel teurer, weniger skalierbar und wenn du mit kleinen Budgets in einem UNTERNEHMEN hantierst Sinn. Wenn Sie Apps gut programmieren können, dann gehen Sie auf jeden Fall nativ vor, was auch immer Sie wählen. Das ist Ihr Recht, denn es kostet nur Ihre Zeit. Das heißt, hier sind meine Hauptgründe, eine native App zu verwenden:
Native Apps machen mehr Geld. Viel mehr Geld. Ob Sie ein großer Publisher oder ein kleiner Entwickler von In-App-Käufen sind, das Apple-Ökosystem ist für Sie in vielerlei Hinsicht geeignet. Als großer Publisher wird ein Werbetreibender die Chance nutzen, die Coca Cola VH1 Music Awards App zu erstellen und die Entwicklung für Sie in den meisten Fällen zu bezahlen! Wenn Sie versucht haben, ihnen nur ein paar Millionen Impressionen auf einer benutzerdefinierten mobilen Website anzubieten, reagieren sie wahrscheinlich nicht einmal darauf (der Hybrid-Ansatz ist oft eine clevere Brücke für dieses Problem). Als kleiner Entwickler wickelt Apple die Zahlungen für Sie ab, bringt all seinen Nutzern bei, wie einfach es ist, Dinge in Apps zu kaufen (hier kommt man und verkauft 10.000 Valor-Punkte für 9,99 $) und ja, nimmt einen Schnitt für Ihre Probleme, aber Sie haben die Verteilung und sind so eingerichtet, dass Sie nach der Veröffentlichung Ihres Produkts mit sehr wenig Aufwand Kontrollen erhalten.
Die App muss pixelgenau sein und animieren wie ein Traum. Vielleicht ist dies eine App für ein Magazin und sie werden keine Seite tolerieren, weil sie denken, dass die App kaputt ist, und ihre Designer werden Sie über Pixel hinweg hetzen, die fehl am Platz sind. Dies kann für die meisten Projekte gelten, die für Premiummarken bestimmt sind, die alle Aspekte der Benutzererfahrung steuern möchten. Das ist keine schlechte Sache, aber es ist selten gut gemacht.
Die App muss viele Inhalte vom Benutzer verarbeiten und mit vielen proprietären CMS-Systemen umgehen oder die App ist im Wesentlichen eine Art Plattform.
Die App ist eine benutzerdefinierte Erfahrung, die viel vom Prozessor des Telefons erfordert und in das Ökosystem des Betriebssystems eingebunden werden muss, um seine Kernfunktionen zu erledigen, zum Beispiel viele Dienstprogramme (denken Appkillern auf Android).
Sie interessieren sich nicht für das mobile Web oder andere Plattformen als die, für die Sie entwickeln. Ein Prozentsatz Ihrer Nutzer ist möglicherweise nicht in der Lage, auf Ihre App zuzugreifen, und Sie sind damit einverstanden.
TL: DR Alle drei sind sehr nützlich und wenn Sie sie verwenden möchten, müssen sie sorgfältig aus einer technischen, Produkt-, Business-und Design-Perspektive durchdacht werden.
PhoneGap ist sehr ausgereift und gut unterstützt. Am Ende werden Sie Ihre App in jQuery mobile entwickeln und CSS für das Design verwenden. Werfen Sie einen Blick auf diese jQuery Mobile-Galerie . All diese "Webseiten" können mit PhoneGap zu "Apps" gemacht werden.
Sie benötigen jedoch immer noch ein Apple-Entwicklerkonto, um Ihre App für das iPhone und den AppStore zu kompilieren und bereitzustellen.