Native Android-Apps vs. Flash Player Apps

[wm54]

Hi zusammen,

hat sich schon mal jemand informiert, wo genau die unterschiedlichen Anwendungsgebiete von nativen Apps (Android SDK) und Flash Player/AIR-Anwendungen auf einem Android-Device liegen?

Würde mich mal allgemein interessieren, wenn welcher Applikationstyp in Frage kommt (und wann nicht)? Also im Sinne einer Entscheidungsfindung, auf welche Technologie man setzt und welche Einschränkungen hinsichtlich Flash/AIR bestehen.

Mangels Device konnte ich mich damit noch nicht wirklich näher beschäftigen…

Danke für Hinweise.

[Omega Psi]

Ich denke, native Applikationen werden immer performanter sein. Deswegen dürfte die resultierende Useabilty ein ausschlaggebender Punkt sein.

[bobby]

alternativ dann noch dies - google präsentiert seinen app-builder
Google Launches "App Inventor," DIY App Creation Tool for Android

[medianetic]

Zitat von Omega Psi

Ich denke, native Applikationen werden immer performanter sein. Deswegen dürfte die resultierende Useabilty ein ausschlaggebender Punkt sein.

Das native Anwendungen immer performanter sind als nicht native Anwendungen ist relativ selbstverständlich. 'Tomaten bspw. sind in einer Bolognese meist auch performanter als Chilli'.

Das Usability damit irgendetwas zu tun haben sollte, glaube ich nicht.
Es hängt vielleicht eher davon ab, welche nativen-Funktionen Flash (AIR) unterstützt und welche Entwicklergruppen dahinter stehen. Native Technik ist nicht Alles.

Sorry, ist eher eine Korrektur von mir, als eine Antwort (Ich hab keinen Plan).

PS: Guck Dir die Usability von vielen schlechten nativen IPhone-Apps an und dann guck Dir bspw. die IPhone-App "Reifengröße bei Fahrrädern" (auf Flash-Basis) von Saban an. Ich seh da keinen Unterschied.

[medianetic]

Ich kaufe ein "(eine der wenigen verfügbaren)".

Der Satz geht dann so:
Guck Dir die Usability von vielen schlechten nativen IPhone-Apps an und dann guck Dir bspw. die IPhone-App (eine der wenigen verfügbaren) "Reifengröße bei Fahrrädern" ...

[Omega Psi]

Entschuldige, die Nachricht hatte ich zwischen Tür und Angel geschrieben. Meinen Gedanken hätte ich ausführen sollen.

Als UI Developer ist man darauf angewiesen, dass die verfügbare Hardware so performant ist, dass eine gewisse Grundlast an Berechnungen pro Sekunde möglich ist - der Prozessor muss also was leisten können.

UI getriebene Entwicklung lebt zudem von clever konzipierten Views als Teil der Anwendung. Hier kommt für mich die Useabilty zum tragen. In der Regel möchte man Benutzungsschnittstellen nicht mit Effekten überladen, diese aber zumindest so einsetzen, dass es einen Gewinn für die Nutzung der Software gibt.

Ich weiss nun nicht, wie viel Leistung man durch den Einsatz einer VM wie der AVM verliert, aber eine Verlustleistung ist zwangsläufig vorhanden. Das heisst ActionScript oder JavaScript (Interpreter) Anwendungen sind diesem Problem mehr oder weniger stark ausgesetzt - je nach Ausprägung - das führt zu Einschränkungen.

Als Besitzer eines iPads und eines iPhones bin ich als Endnutzer dem Problem direkt ausgesetzt, da aufgrund der mangelnden Leistung Websites teilweise nur bedingt angenehm zu bedienen sind (langsamer Aufbau, schlechtere Performanz zur Laufzeit). Das führt meines Erachtens zu dem Problem, dass man das Web nicht so erleben kann, wie auf einem Desktop Rechner oder einem Notebook - was man aber möchte. Einer der Gründe, warum es dedizierte Websites (mobil Versionen) für mobile Endgeräte gibt. Beispiel GMX Website: das Login Panel animiert unsagbar schlecht.

Den Begriff Useabilty verwendete ich initial falsch - sorry an der Stelle. Mir geht es in erster Linie darum, dass man nicht davon ausgehen kann, dass komplexe Flash Anwendungen so laufen, wie man es erwartet - eher im Gegenteil (die Anwendung wird schlechter benutzbar). Die Hardware macht einem da einfach einen Strich durch die Rechnung. Ausserdem hat man noch konzeptionelle Aufwände im Hinblick auf Screensize und Optimierungen für mobile Endsysteme (Speicherverwaltung, günstige Algorithmen) um nur zwei Punkte zu nennen.

Mein Lieblingspunkt an dieser Stelle: Fehlerbehandlungen. Es sind immer noch nur Flash Sites und Flash Applets, die meinen Browser zum Stillstand bringen weil die werten Herren Kollegen mal wieder keine Fehlerbehandlung einbauten. Das würde zu einem Neustart des Systems führen müssten.

Und all diese Punkte, zusammengefasst, würde mich in erster Linie zu guten spezialisierten Lösungen bewegen, als zu einer überladenen Cross browser Lösung.

Ich sehe das im Hinblick auf JavaScript Frameworks übrigens ähnlich: Sproutscore rendert schlecht auf Safari Mobile...

Ich hoffe ich konnte mich etwas besser erklären.

[medianetic]

Lässt sich für mich viel einfacher und direkter formulieren:

Usability hat letzten Endes überhaupt nichts mit technischen Vorraussetzungen zu tun. Die gilt es zu beachten, ob nativ oder nicht, macht dabei keinen Unterschied. Auf einem C64 lassen sich Anwendungen programmieren, die bzgl. Usability Anwendungen auf dem IPhone 4 in nichts nachstehen. Die Qualität von Usability hängt m.E. davon ab, wieviel Arbeit man in diesen Bereich investieren möchte bzw. kann. Mit Performance des Geräts (nativ oder nicht) hat das imho nichts zu tun.

Ist zwar relativ nebensächlich, aber ich kann mich wirklich nicht daran erinnern, wann bei mir das letzte Mal der Browser abgestützt ist.

Ich habe Nichts gegen Spezialisierung, finde aber den Ansatz "Crossplattform" ebenso berechtigt und für mich war das bis heute auch immer meine erste Wahl.

Hardware wurde und wird immer leistungsfähiger. Anstatt, als Einzelperson sprechend, jede 3-5 Jahre eine neue native Sprache zu lernen, würde ich mich lieber auf andere Bereiche konzentrieren (z.B. um über Crossplattform-Usability nachzudenken).

Das nicht jede Anwendung auf jedem Gerät läuft ist selbstredend.

[Mr.Twister]

Zur Grundfrage:

Für AIR spricht:
- wenn die Anwendung nicht nur auf einem OS genutzt werden soll. Das bereits erwähnte Schlagwort Crossplattform wurde ja schon mehrfach genannt.

- wenn klar ist, dass ich eine Anwendung schneller in AIR entwickeln kann als eine adäquate Anwednung nativ für Android.

Für Android spricht:
- wenn ich gewisse Funktionen des Android Devides nutzen möchte, die AIR nicht bietet

- wenn die Anwednung viel Leistung braucht und der Performance-Unterschied sich deutlich auswirkt (Akku-Leistung, Look & Feel ...)

[wm54]

Zitat von Mr.Twister

Für Android spricht:
- wenn ich gewisse Funktionen des Android Devides nutzen möchte, die AIR nicht bietet

Würde mich interessieren, ob es hierzu schon Erfahrungswerte von jemandem gibt?

Also Kamerazugriff scheint auf jeden Fall kein Problem zu sein, siehe theFlashBlog New Video Tutorial on Android Camera Access

Unsere AIR-Devices sind bestellt, kann also hoffentlich bald selbst berichten.

[wm54]

Um meine ursprüngliche Frage selbst zu beantworten:
Mitterweile hat sich ja vieles geklärt und es ist jetzt klar, wie die Abläufe gedacht sind und das Zusammenspiel Flash/AIR und Android funktioniert.

Habe das hier zusammengefasst:
Überblick: Adobe AIR für Android | www.video-flash.de
Flash Player auf Android (HTC Desire) | www.video-flash.de

Zum Thema Performance kann ich allerdings noch nichts sagen.

[_geo_]

Zitat von Mr.Twister

Für AIR spricht:
[...]
- wenn klar ist, dass ich eine Anwendung schneller in AIR entwickeln kann als eine adäquate Anwednung nativ für Android.

Ich denke besonders den Punkt kann man leicht unterschätzen. Hab mich in letzer Zeit sowohl mit iPhone und Anroid mit Flash beschäftigt (Hardware: iPhone 2g, Android HTC Magic). Wenn man mit seiner Anwendung an die Leistungsgrenzen der Hardware kommt steigt der Aufwand die Applikation zu entwickeln sehr steil an. Das ging bei mir dann so weit, dass ich mehr Zeit damit verbracht habe Flash auf dem Gerät "schnell" zu bekommen als ich mit einer nativen Implementierung benötigt hätte um alles selbst zu machen.

Ich finde Flash zahlt sich nur in den Fällen aus in denen man ohne große Umwege die API wirklich ausnutzen kann, ansonsten ist man wohl mit einer ordentlichen nativen Implementierung besser beraten. Die Frage "Flash oder nicht Flash" muss man gut abschätzen können und ist wohl ein Lernprozess durch den wir alle gehen müssen.

lg

[Omega Psi]

Sag ich doch

[medianetic]

'Sag ich doch' Pfff.

Was man ja im Idealfall nachher haben will:
Man entwickelt X,Y, passt es für Gerät X,Y etwas an und es läuft = Crossplattform!

Touch-Geräte gibt es nicht seit 10 Jahren.
Wir müssen alle dazu lernen ... (so hart ist es auch nicht ...).

An den Softwareanbietern, wie bspw. Adobe, liegt es ja uns diese Möglichkeit so zu geben. Das funktioniert aus verschiedenen Gründen bisher suboptimal.

Was man nachher in Flash haben will ist:
1. Android
2. iOS
3. AIR (Desktop)

oder so Ähnlich.

Je nach Ziel müssen wir da im Moment noch viel machen.

[medianetic]

Zitat von _geo_

Ich denke besonders den Punkt kann man leicht unterschätzen. Hab mich in letzer Zeit sowohl mit iPhone und Anroid mit Flash beschäftigt (Hardware: iPhone 2g, Android HTC Magic).

iPhone 2g = wie gesagt, fail.
(Nicht weil es nicht auch zuviel Geld gekostet hat, sondern, weil selbst native Apps auf nem 3G nicht mehr flüssig laufen und es bei einem 2G nicht viel besser sein wird).

[l_ch]

weil selbst native Apps auf nem 3G nicht mehr flüssig laufen und es bei einem 2G nicht viel besser sein wird

also mein silberruecken sieht das anders.