Technologie für eine Mobile-GUI-App

[Schrompf]

Kopie meines Beitrags aus dem sppro. Ich hoffe, ihr nehmt mir das nicht übel.

Hallo!

Ich werde evtl. für einen Kunden eine App entwickeln. Das ist kein Spiel, sondern eine GUI-zentrische App mit so ner News-Feed, Text- und Sprachinteraktionen, optional mit Push Notifications und einem dicken Server dahinter, der die Ereignisse zwischen den Usern verteilt. Der Auftraggeber träumt von einigen Millionen Usern, und so wie ich den bisher kennengelernt habe, hat er sogar eine gewisse Chance, das auch zu erreichen. Deutlich mehr Chance jedenfalls als die MMO-Visionäre in den Foren.

Meine Fragen sind nun:

1) Was ist heutzutage Stand der Technik bei der Entwicklung solcher Apps?

Es soll nach Möglichkeit nicht zwischendurch mal ne halbe Sekunde Denkpause haben wie praktisch alle Android-Apps, die mir bisher begegnet sind. Ich hätte trotzdem gern einfach Flug-, Transparenz- und Schwurbel-Effekte eingebaut, die unaufdringlich Polishing suggerieren. Ich liebäugele mit Qt und Qt Quick, weil ich mit der Tech vertraut bin und ich weiß, dass ich damit iDings, Androids und WinPhones erreichen kann. Allerdings ziehe ich mir dann den Ärger eventuell nachfolgender Coder zu, von denen die meisten kein C++ mehr können werden. Und evtl. ist das die Chance, mal in andere Programmiersprachen und Frameworks reinzuschnuppern, auch wenn ich dann wahrscheinlich deutlich länger für den Auftrag brauche.

2) Was benutzt man für den Server?

Ich könnte mir genauso mit C++ und SQL einen Server schreiben, aber mir scheint, das wäre sehr mühsam. Dafür gibt's sicher schon irgendwelche Frameworks. Oder ich setze das Ganze mit ein paar PHP-Skripten im Apache auf, aber da habe ich die Angst, dass ich irgendwann mehr als nur reine zustandslose Anfragen brauche und dann von vorn beginnen muss. Was also benutzt der Coder von Welt heutzutage für sowas?

Danke.

Bye, Thomas

[hagbard]

Für den ersten Prototypen hätte ich als Server tatsächlich es auch erstmal mit ein paar PHP Skripten versucht. Ansonsten ist hier für eher datenbanklastige Backends glaube Java Standard. Man kann dass sicherlich auch mit Qt und C++ machen wenn das allerdings im Internet erreichbar sein sollen muss man wohl etwas mehr Hirnschmalz in die Sicherheitsfrage stecken (Meine Firma macht das für Serveranwendungen die nur in lokalen Kundennetzen laufen, da ist das Risko von Hackerangriffen ja auch eher überschaubar). Ansonsten gibt es Frameworks für Ruby und Python, wie gut die mit der Nutzeranzahl skalieren weiss ich aber nicht.

Was die App Seite angeht kann ich leider nix beitragen. Bis jetzt scheint sich da noch kein Cross-Plattform Framework durchgesetzt zu haben. Wenn Qt dafür tatsächlich produktiv einsetzbar ist würde es mich freuen brauche ich mich nicht weiter mit der Android Java API rumschlagen...

[Chromanoid]

Welche Client-Zielsysteme sind's denn genau? So viele wie möglich?

Sehr viele User bedeutet ja eigentlich immer horizontale Skalierbarkeit. Wenn es erst mal um reine Performance geht, gibt das hier https://www.techempower.com/benchmarks/ ... nvironment mMn einen interessanten Überblick über so einige Bibliotheken und Frameworks in verschiedenen Sprachen. Ich würde Dir natürlich ein Java-Framework empfehlen :)

Evt. solltest Du mit Deinem Auftraggeber auch überlegen, ob die Serverseite vielleicht für einen Platform-as-a-Service-Anbieter entwickelt werden sollte (Google App Engine, Microsoft Azure, Heroku...). Die haben meistens bestimmte Patterns wie man Skalierbarkeit erreichen soll.

Auf dieser Seite http://highscalability.com/ findet man des Öfteren interessante Architekturüberblicke verschiedener Anwendungen.

Mal ein paar Vorschläge, wenn Du auf HTTP-Kommunikation setzen willst:
Microsoft Azure (Server) + Xamarin (iOS, Android, Windows Phone)
Google App Engine oder eigene Infrastruktur mit beliebigem Java-Framework + Native Anwendungen für iOS und Android + J2ObjC zur Übersetzung des Domänenmodells von Java nach ObjC (so macht das Google AFAIK für einige Client-Anwendungen)
ULib als TLS/HTTP Server, Postgres als Datenbank (bei C++ ist der Datenbankzugriff glaube ich nicht ganz so abstrahiert wie bei Java/.NET), QT für Client (iOS, Android, Windows Phone...)
Beliebiges Java Framework für Server + Robovm für Client (iOS und Android)

[Schrompf]

Danke, damit habe ich einige praktische Stichworte zum Weitergoogeln!

Plattformen sollen wie schon geschrieben iZeuchs, Android und WinPhone sein. Wenn Blackberry mit abfällt, auch gern das.

[Chromanoid]

Wenn es möglichst viele Plattformen sein sollen und Du Javascript nicht scheust, ist Apache Cordova / Adobe PhoneGap (Cordova-Distribution mit Adobe-Geschmack) noch einen Blick wert. Das Teil nutzt die Webview-Komponenten der Geräte um HTML5 und Javascript als "native App" darzustellen. Die internen Browser der Geräte werden immer schneller und HTML5 ist echt nicht schlecht für GUIs. Mit CSS kann man mittlerweile schon viel von den Flug-, Transparenz- und Schwurbel-Effekten einbauen. Für die Serverseite würde dann vielleicht node.js interessant sein, dann hat man alles in einer Sprache.

[dawit]

Ich werfe mal noch React Native in den Raum, einfach, weil gerade alle darüber reden. Es benutzt JavaScript, welches allerdings in einem von der GUI unabhängigen Thread läuft und so für flüssige Animationen ohne Ruckler sorgen soll. Und wie der Name schon vermuten lässt, werden größtenteils native GUI-Elemente verwendet. Soweit ich weiß werden momentan allerdings nur Android und iOS unterstützt.

Ich weiß nicht, ob der Coder von Welt NodeJS verwenden würde, aber man bekommts sehr schnell zum laufen, und wenn du eine persistente Verbindung brauchst (z.B. für Live-Updates), ist dessen eventbasierte Architektur vermutlich besser geeignet als Apaches, das pro Verbindung einen neuen Thread erstellt.

[Schrompf]

Ja moin, Danke nochmal für alle Links. Ich habe noch gewisse Probleme, ein gedankliches Modell von dem Gesamtsystem zu entwickeln, im Speziellen der Backend-Teil. Aber so langsam ergibt sich ein Bild.

Mein bisheriger Plan sieht so aus:
- Frontend: JavaScript mit PhoneGap
- Backend: Heroku oder so was, NodeJS daraus mit ner REST-API und WebSocket für Push-Gedöns, während die App aktiv ist.

Was benutzen die Messenger wie z.b. WhatsApp? Halten die stunden-, tage-, wochenlang eine TCP/IP-Verbindung offen, um immer mitzukriegen, wenn Du ne Nachricht bekommst? Das erscheint mir irgendwie... verschwenderisch. Oder kann man über IPV6 oder so einfach UDP-Pakete gezielt an einzelne Mobiltelefone abfeuern?

[Chromanoid]

Push-Notifications werden i.d.R. vom Server direkt an einen Dienst des Smartphone-Betriebssystem-Herstellers gesendet. Der sorgt dann dafür, dass die Nachricht ankommt. Hier ein veraltetes? PhoneGap Tutorial: http://devgirl.org/2013/07/17/tutorial- ... plication/

Alles andere funktioniert nicht wirklich. Ich glaube bei iOS kann man gar keinen Thread im Hintergrund haben.

[kimmi]

Wir haben für sehr grafik-lastige Anwendungen auch gute Erfahrungen mit Qml gemacht, sprich Qt5.5. Allerdings geht es da auch weniger um Webzeug.

Gruß Kim

[dawit]

Push-Notifications werden i.d.R. vom Server direkt an einen Dienst des Smartphone-Betriebssystem-Herstellers gesendet. Der sorgt dann dafür, dass die Nachricht ankommt.

Ah, gut zu wissen. War im Kopf irgendwie bei der Web-Entwicklung.

[odenter]

Habe mich zufällig mit ner Bekannten vor einiger Zeit gedanklich mit dem Thema beschäftigt da Sie eine vergleichbare Anfrage hatte.

Wir haben nur eine Grobe Aufwandsabschätzung vorgenommen und waren damit schon zu teuer. :P

Wir sind am Ende bei zwei Varianten gelandet.
1.) Andriod und Nutzung von Google Diensten (GCM https://developers.google.com/cloud-messaging/)
- Verhältnismässig geringer Aufwand
DB <--> Java ComServer <--> GCM <--> Gerät
- DB wäre MySql gewesen
Umsetzung wäre komplett in Java erfolgt

2.) Android und eigene(r) Server
- Eigener Kommunikationsserver (https://pushframework.codeplex.com/ oder http://www.serverframework.com/products ... ework.html), Kommunikation entsprechend über Sockets.
DB <--> C++ ComServer <--> GCM <--> Gerät
- DB MySql
Hier hätten wir die Sprachen gemixt. Die Serversoftware (Kommunikation und DB) wäre in c++ geschrieben. GUI auf dem Telefon in Java.

Selbst das GCM Zeug nimmt Dir nicht alles ab! Im Grunde nimmt es Dir nur die Nachrichten vom und zum Gerät ab! Den Rest musst Du trotzdem selber machen.

Android ist nunmal am verbreitetsten. Apple und iOS stand gar nicht zur Diskussion.
Variante 1 ist sicher ohne Frage die einfachere, Variante 2 die aufwendigere aber geilere. Allerdings sollten ebenfalls die sicher auftretenden Probleme nicht unterschätzt werden (speziell Netzwerk). Auch müssen die Requests ja fix genug an den oder die DB-Server verteilt werden!
Uns gefiel Variante 2 am besten, da wir eine Lösung wollten die auch mehr als 10k Clients bedienen kann. Das es mit c++ möglich ist wussten wir, ob es mit Java möglich ist wussten wir nicht. Daher viel das eigentlich raus.

Wenn Du eh schon mit Qt warm bist, dann würde ich es auch verwenden. Ich wage zu orakeln das der Java Trend auf den Geräten zurück gehen wird. Liegt schlicht und ergreifend an den Akku Kapazitäten. Instruktionen pro Watt sind und werden immer wichtiger als schnelle/einfache Umsetzung mittels Java!
DB Zugriff mit Qt ist jetzt ja nicht so das Problem. Bei einer Millionen Usern muss alles halt nur gut skalieren. :)
Wenn das Budget hoch genug ist, dann würde würde ich mit mal mit JetByte auseinander setzen. Dann haste am Ende nur noch die GUI und den DB-Zugriff.

Eine Option über die wir ebenfalls nachgedacht haben war die Verwendung von JBoss und seiner Funktionalitäten (DB-Zugriff, MessageQueues, etc.) haben wir aber Aufgrund der negativen Praxis Erfahrungen meiner Bekannten in Ihrem Job, da verwenden die das Ding produktiv, verworfen.

Webservices waren ebenfalls keine Option, da zuviele Nachrichten dafür hin- und hergehen, wenn die App dann mal aktiv gewesen wäre.

[Chromanoid]

Instruktionen pro Watt sind und werden immer wichtiger als schnelle/einfache Umsetzung mittels Java!

Mir geht's da jetzt nicht konkret um Java oder die Vorzüge von "einfacheren" Sprachen, aber ich würde sagen der Trend geht genau in die andere Richtung. Apple hat doch nicht einfach so Swift entwickelt oder auf Automatic Reference Counting gesetzt. Das mit App-Entwicklung verbundene Risiko wird doch immer größer. Man sollte sich da nur für besonders gute Performance entscheiden, wenn die Kosten der Umsetzung im Vergleich zur Umsetzung mit einfacheren Mitteln dadurch nicht besonders steigen. Wenn man sich sowas anschaut: http://www.statista.com/statistics/2581 ... per-month/ (allein im Dezember 2014 30k neue Apps im iTunes Store), dann glaube ich, dass man sich nur in sehr etablierten App-Genres mit besonderer Performance besonders hervortun kann.

Android ist nunmal am verbreitetsten. Apple und iOS stand gar nicht zur Diskussion.

Das sollte man bei solchen Berichten wohl etwas differenzierter betrachten, oder? http://techcrunch.com/2015/04/14/revenu ... -to-china/ "As of Q1 2015, iOS App Store worldwide revenue was about 70% higher than on Google Play, up from 60% in Q3 2014, the report notes."

Eine Option über die wir ebenfalls nachgedacht haben war die Verwendung von JBoss und seiner Funktionalitäten (DB-Zugriff, MessageQueues, etc.) haben wir aber Aufgrund der negativen Praxis Erfahrungen meiner Bekannten in Ihrem Job, da verwenden die das Ding produktiv, verworfen.

Das hört sich etwas seltsam an. Inwiefern habt ihr denn "JBoss" evaluiert? Habt ihr auf Basis einiger negativer Erfahrungen im Bekanntenkreis den Einsatz eines JavaEE-Containers (da gibt's ja nicht nur Wildfly) verworfen? Ein JavaEE-Container macht vielleicht erst bei größeren insbesondere transaktionsgetriebenen Anwendungen Sinn, aber dann ist man mit einem JavaEE-Container oder der Konkurrenz Spring eigentlich ziemlich gut bedient...

[TTakio]

Aloha zusammen!

als JS-Entwickler würde ich den folgenden Stack verwenden:

Client
Für den Client eine Hybride App: Web-App mit Zugang zu nativen Funktion dank Cordova / PhoneGap. Für die Effekte und Gesten kann man CSS Animations. Text- und Spracherkennung würde ich eher auf den Server schieben, sei es mein eigener Server oder AlchemyAPI. Aber mit passenden Plugins bekommt man diese Funktion über PhoneGap / Cordova rein.

Server
Am Anfang würde ich gucken, ob ich mit externen Diensten auskomme. Ich nutze gerne den Dienst von Firebase. Ich kann es als Datenbank, zur Datensychronisierung und für die User Authentifikation nutzen. Aber das ist eher für einen Prototypen interessant.

Wenn ich eine eigene Recheneinheit haben möchte, tendiere ich eher zu DigitalOcean und den Droplets. Durch die Nutzung der Droplets hast du auch stets eine Beschreibung deiner Server-Umgebung in Form eines Dockerfiles parat. Und das ist durchaus praktisch.

Als Javascript-Entwickler würde ich den Server mit Node.js / Io.js betrieben. Man kann es schnell einrichten und reicht für die genannten Fälle aus. Für eine polyglotte Entwicklung finde ich vert.x interessant. Du kannst damit den Server in mehreren Sprachen schreiben: Java, JavaScript, Ruby und Groovy. Und die Performance sollte (kA, nicht gemessen, nur meine Erwartung) besser sein als mit JBoss und Tomcat. Man kann es mit Node.js vergleichen.

Liebe Grüße
;)

[odenter]

@Chromanoid
iOS und Windows Phone 8 stand als Platform für das wo wir Aufwand schätzten nicht zur Diskussion. Mit anderen Worten unsere Zielplatform war Android.
Ich würde die Umsätze einer Platform jetzt nicht als Indikator für die Verbreitung heranziehen. Klar ist das Apple User tendenziell eher zu denjenigen gehören die auch für etwas zahlen, und Android (damit Linux User) tendenziell zu denen die eher etwas kostenlos haben wollen, das aber ne andere Diskussion.

Das mit den Instruktionen pro Watt kam aus einer Studie/Diskussion von einem großen Chip-Hersteller der heftig für low level Sprachen statt high level Sprachen warb, ich hab den Link gesucht aber leider nicht gefunden. Sonst hätte ich Ihn geliefert. Die wollen gerne mehr in Ihren Chips machen, sind aber limitiert weil mobile und kein Stromkabel.
Es geht nicht primär um die Performance der Apps, sondern um den Stromverbrauch der durch die laufende Software verursacht wird. Und da immer mehr läuft wird immer mehr verbraucht.

Wieso ist die Evaluierung eine Applikationsservers seltsam? Bei Verwendung von GCM musst den Kommunikationsserver und den Appserver komplett selber schreiben, oder eben was vorhandenes anpassen/verwenden. Insofern ist es eine weitere Option für das was wir machen wollten. Verworfen wurde das weil die beruflich das JavaEE Zeugs verwenden und damit nur Probleme haben. Welcher Art die Probleme sind kann ich nicht beurteilen weil ich das Ding nicht kenne. Ich habe Ihr da einfach mal vertraut. Frauen haben halt immer Recht. ^^ :D

Was auch immer er machen will.
Er braucht doch mindestens folgende Dinge:
1.) Eine Ort wo die Daten gespeichert werden
2.) Kommunikation DB <--> Applogik
3.) Etwas das die Applikationslogik enthält
4.) Kommunikation Applogik <--> Gerät oder Kommunikation Applogik <--> Dienst der mit dem Gerät kommuniziert
5.) Und die GUI auf dem Gerät welche das geringste Übel ist.

Und wenn Dein Datenbank Kommunikationsserver und dein Applogik Server noch skalieren soll, dann wirds doch erst interessant. Der Rest ist doch simpel.

Er kann natürlich seine ganze Logik aufs Gerät packen, ist dann aber so sicher wie ein Multiplayergame bei dem der Client alles macht.
Aber er schreibt hier von bis zu einer Millionen Nutzer. Da würde ich mir erst Gedanken über Performance und Alternativen machen, als erst nen Prototypen in irgendwas zu bauen um dann festzustellen das es nicht brauchbar ist weil damit das Ziel nicht erreicht werden kann. Und dann ist der Auftrag mal fix nicht mehr erfüllbar.

[Chromanoid]

Ich würde die Umsätze einer Platform jetzt nicht als Indikator für die Verbreitung heranziehen.

Mache ich doch auch gar nicht. Nur ist man i.d.R. am Ende am Umsatz interessiert und nicht daran wieviele Leute das Spiel ausprobieren. Im Report geht doch ganz klar hervor, dass man bei Google Play mehr Kunden hat und man beim Apple Appstore durchschnittlich mehr verdient.

Das mit den Instruktionen pro Watt kam aus einer Studie/Diskussion von einem großen Chip-Hersteller der heftig für low level Sprachen statt high level Sprachen warb, ich hab den Link gesucht aber leider nicht gefunden. Sonst hätte ich Ihn geliefert. Die wollen gerne mehr in Ihren Chips machen, sind aber limitiert weil mobile und kein Stromkabel.
Es geht nicht primär um die Performance der Apps, sondern um den Stromverbrauch der durch die laufende Software verursacht wird. Und da immer mehr läuft wird immer mehr verbraucht.

Das interessiert aber nur den Chip-Hersteller und ein paar Energiesparfüchse. Dem Rest ist es doch egal, solange der Verbrauch nicht überhand nimmt. Die müssen ihr Smartphone eh jeden Tag aufladen.

Wieso ist die Evaluierung eine Applikationsservers seltsam?

Wenn sich hier jemand mit so einer Argumentation gegen den Einsatz von OpenGL entscheiden würde, würde Dir das nicht auch seltsam vorkommen? ;) :D

[Schrompf]

Wollte nur kurz nochmal Danke sagen für den Input. Der Auftraggeber hat aber inzwischen entschieden, dass ihm mein Angebot zu teuer sei. Tsss.

[TTakio]

Aus Neugier würde mich interessieren: Welches Angebot hast du unterbreitet? Von den Technologien her?

LG
;)

[Schrompf]

Ich habe keine konkrete Technologie angeboten, und nach deren Mangel an Fachkenntnis hätte es auch keinen Unterschied gemacht, was ich angeboten hätte. Privat gedachte ich Adobe PhoneGap für den Client und NodeJS für den Server zu benutzen.

[odenter]

Wieso ist die Evaluierung eine Applikationsservers seltsam?

Wenn sich hier jemand mit so einer Argumentation gegen den Einsatz von OpenGL entscheiden würde, würde Dir das nicht auch seltsam vorkommen? ;) :D

Vielleicht ein bischen :)