spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »ventrix«

Alle apps laufen konstant auf 60fps (...) 25-35% cpu

Das ist pure Akku-Verschwendung für eine reine GUI-Anwendung. Als User wäre ich ziemlich ungehalten, wenn mein Smartphone bei simpler GUI so warm wird und so viel Akku verbrät.

Zitat von »[Anonymer Benutzer]«

Ein android App ohne das UI mit Fragmenten aufzubauen ist gelinde gesagt keine gute Idee. Möchtest du dort etwa 20 views hinklatschen oder eine riesen view?

Du kannst unter iOS und unter Android Deine GUI auch prima aus Views aufbauen, die ihr Design in XML (bzw. XIB unter iOS) ausgelagert haben. Dazu braucht's keine Fragmente. Und das ist auch nichts, was nur Android kann.

Zitat von »Schrompf«

Hab mal Deinen Link angeklickt. Gleich der zweite Anstrich enthält einen Tippfehler: "Wundevolles Erwachen:" - die App verteilt Wunden beim Wecken? Aua

Oh, das ist in all den Jahren noch niemanden aufgefallen. Liegt wohl daran, dass die meisten Nutzer Englisch sprechen. In der Schweiz hatten wir auch kaum Downloads.

Zitat von »Schrompf«

Welche Programmiersprache und welche sonstigen Frameworks wurden da verwendet? "Native" auf Android heißt Java? Oder was wurde da benutzt?

Genau Java. Das Android SDK ist ja an sich bereits ein gutes Framework. Wir haben noch AndroidAnnotations benutzt. Das nimmt einem viel mühsamen Code ab. Ebenfalls kam Dagger zum Einsatz. Ziemlich praktisch. Gibt sicher noch ein paar neue Sachen.

Zitat von »Schrompf«

Das "native Steuerelemente" stelle ich mir ehrlich gesagt unwichtig vor. Immerhin ist das ja kein Windows/Linux/OSX, bei dem man Fensterrahmen mit Bedienelementen und eine vertraute Tab-Reihenfolge erwartet. Und wenn ich mir WhatsApp, Facebook oder Telegram anschaue, benutzen die auch alle ihre eigenen Design-Elemente. Was genau wären denn die Native-Elemente, die jeder Mobile-Benutzer erwarten würde?

Unterschätz das nicht. Vor allem auf Android ist die Erwartung schon gross. Der Teufel liegt im Detail. iOS und Android sind zum Teil sehr verschieden und wirklich gute Apps unterscheiden gewisse UI Elemente. Zum Beispiel funktioniert die Navigation auf iOS fundamental anders wie auf Android. iOS kennt ja an sich nur den Back Button in der Top Navigation Bar. Auf Android hast du Back (als Hardware Button) und den Up (in der App). Hier ein einfach nur ein Pattern nehmen kommt nicht gut.

Ich habe mal eine Analyse für eine Schweizer News App gemacht (iOS, Android). Die haben auch den "Fehler" gemacht das ganze 1x zu designen (iOS Fokus) und dann auf Android zu kopieren. Als es dann darum ging, dass die Android App ganz Ok ist, aber nicht so gut bewertet, wie die iOS App kam dabei raus, dass sehr viele Kleinigkeiten falsch (nicht den Android Guidelines entsprechend) sind und korrigiert werden müssten.

Weitere Sachen um darüber nachzudenken wie es welche Platform macht: iOS Style Back Swipe, Android Long Press, iOS Swipe auf Listen Elementen, Android Toasts (vor allem wegen Undo, iOS kennt eigl. kein Undo) etc. Mehr Informationen und Details sind in den jeweiligen Guides zu finden.

Versteh mich nicht falsch. Es ist durchaus möglich ganz gute App Cross Platform zu machen, aber wenn es wirklich darum geht das 2 (ja, ich lasse WP aussen vor) Top Apps zu machen, dann kommt man wohl immer noch nicht umher beide praktisch ohne Code Share zu bauen. Die Implementierung ist ja dann auch nur die eine Sache. Design/UI ist eben auch nicht so gut kopierbar, wie man es gerne hätte.

Zitat von »[Anonymer Benutzer]«

Hast du schonmal etwas in Android entwickelt nebenbei gefragt?

Ich bin Teamleiter für mobile Applikationen. Ich entwickle auch immer mit (nicht nur etwas, sondern richtig). Also ja, ich habe schon für Android und für iOS entwickelt. Ich kenne sehr gut auch die Probleme von nested Fragments bei "älteren" Android-Versionen (schon alle 4.X Versionen sind in dieser Hinsicht schon schwierig unter den Hut zu bekommen, verschiedene Hersteller sogar noch mehr) trotz Support-Library. Ich würde daher nur bedingt zu Fragments raten und stark von nested Fragments abraten, wenn man gewisse Versionen mit unterstützen soll. Der einzige große Unterschied zwischen Fragments und inflated Views bezieht sich nur auf den Lebenszyklus mit Unterstützung durch den FragmentManager. Speicher spart man damit keinen - zumindest wenn man es richtig macht.

Zitat von »[Anonymer Benutzer]«

Fragmente werden spätestens bei Apps die auch für Tablets angepasst werden sollen wichtig!!!

Das ist Quatsch. Auch mit drei Ausrufezeichen wird das nicht richtiger. Genau dafür gibt es ja schließlich die verschiedenen XMLs für verschiedene Layout-Klassen. Nichts was mit Fragments geht, geht nicht auch mit inflated Views. Wäre auch aberwitzig, wenn es anders wäre.
Man beachte, dass ich nicht generell gegen Verwendung von Fragments bin. Aber zu behaupten, dass sich ähnliche Verhalten nicht unter iOS oder mit Views unter Android abbilden ließen, ist schlicht falsch. Das kann ich guten Gewissens sagen, denn ich habe es schon gemacht. Und da gab's nie Probleme mit Lags oder ähnlichem. Speziell iOS hat mit den ganzen XIBs, Auto-Layouts und Animationen total coole Mechanismen, die ich mir manchmal auch unter Android wünschen würde.

[Anonymer Benutzer], hast du nicht am Anfang noch vorgeschlagen er soll mit libgdx arbeiten und sich die GUI Komponenten selbst basteln?

@Topic: Wir haben damals die Serveranwendungen in C#/Java entwickelt. Die Apps wurden nativ für die jeweiligen Systeme gebaut. Kommuniziert haben die Systeme dann über einfache Webservices. Laut deinen grob umrissenen Anforderungen sollte das ja an sich gut funktionieren. Die Entwicklung der Clients ist dann natürlich ordentlich arbeit. Bei uns bei der Arbeit waren da halt ein paar Entwickler mit beschäftigt. Es stellt sich für mich aber auch die Frage ob du da überhaupt allein ran gehen möchtest. Das hängt vermutlich auch ein wenig vom Zeitraum ab den du für das ganze hast.
Was Look & Fell angeht da würde ich einfach mal in die Richtlinien gucken. Am Ende unterscheidet das eben oft die guten von den schlechten Apps.

Ich kann für die Serverseite auch nur zustimmen übliche und bewährte Mechanismen einzusetzen. Gerade ein Java/C# REST-Server ist super einfach und schnell implementiert mit durchaus auch guter Performance. Der entsprechende REST-Client ist auf jedem System ebenfalls einfach gemacht. Die Techniken sind ja nicht umsonst überall verfügbar.

Zitat von »LetsGo«

GUI Anwendungen laufen iDR außerdem nicht mit FPS, sondern sind Eventbasiert(kein continuous rendering), alles andere ist Akkuverschwendung. Natürlich mit der Ausnahme, wo man sowas eben doch braucht.

Jain. Natuerlich wird nur gerendert wenn noetig. Aber sobald etwas auf dem Bildschirm passiert versucht Android konstant mit 60 fps zu rendern. Das war eins der primaeren Ziele von "Project Butter". D.h. FPS ist durchaus noch eine wichtige Metrik und mit Android M wird es auch wesentlich mehr Werkzeuge fuer Entwickler geben um sicher zu stellen, dass dies auch in deren Apps so laeuft: http://developer.android.com/preview/tes…erformance.html

PS: Ich arbeite momentan an Android end-to-end touch performance benchmarks... ich spiele schon laenger mit der Idee diese ganzen Frameworks mal in Performance vergleichen. Besteht da interesse?

Zitat von »xardias«

Besteht da interesse?

Interessant wäre es, aber meist entscheidet man sich für Frameworks dann doch aus anderen Gründen - wie gut sie eben zu dem passen, was man machen will und zum Budget des Kunden.

Zitat

Das ist pure Akku-Verschwendung für eine reine GUI-Anwendung. Als User wäre ich ziemlich ungehalten, wenn mein Smartphone bei simpler GUI so warm wird und so viel Akku verbrät.

Ich rede hier auch von Spielen auf konstanten 60fps mit gpu rendering, aber dein hobby scheint ja eh cherry picking zu sein.
Wenn einem der overhead von gpu-rendering (besonders auf 60+ fps) nicht gefällt (bzw. event-basierten Sprachen an sich), kann z.B. problemlos software-rendering nutzen.
Oder, pro-tipp: setzt die fps je nach Belieben nach unten. Mit 30 fps, was für GUI-Anwendungen auch vollkommen ausreicht, kommt man auf 5-10%.
Es gibt noch einige andere features, um das dauerhafte rendering statischer Objekte komplett zu stoppen und unnötige features zu deaktivieren (texture flattening, blend modes etc.).
Eine meiner GUI-apps läuft durch Optimierungen auf durchschnittlich 15% mit 60fps. Warm wird da garnix, der Akku hält seine normalen 8+ Stunden.

Zitat von »ventrix«

Mit 30 fps, was für GUI-Anwendungen auch vollkommen ausreicht, kommt man auf 5-10%.

Funktionieren wuerden 30fps schon, aber es wird dann nicht "Buttery-smooth"
https://www.youtube.com/watch?v=CaMTIgxC…VjPTPoDPLdPIFCE

Kommt immer auf die Animationen und Effekte an.
Ich hab meine apps deshalb auch immer auf 60fps laufen.
Es gibt aber theoretisch kein Problem, die fps je nach Bedarf zur Laufzeit zu regulieren.
Aber ja, air/starling haben einen gewissen cpu overhead. Hat sich aber bei mir oder unseren testern bisher nie negativ bemerkbar gemacht.
Für normale GUI kann man je nach Anforderung starling weg lassen. Das framework ist eh nur für 2d-Spiele richtig sinnvoll. Dann hat man seine 0-3%, wenn idle. Ist also kein Argument gegen AIR als Plattform selbst.

Ich bin selbst kein großer flash-Verfechter, finde aber air besonders unter den konstenfreien cross platform Lösungen recht weit vorne.
Wer gerne monatlich Gebühren für die Konkurrenz zahlen will, oder html5 nutzen, kann das ja gerne machen.