Warum ist Android so schlecht?

[Verwunderter Entwickler]

Warum ist Android so schlecht?

Beispiel:
Eine App, die eine Liste oder ein Grid auf dem Tablet
darstellt, durch die man horizontal scrollen oder pagen kann. Auf iOS
macht man so etwas mit drei Mausklicks, implementiert eine
Datenquelle und fertig. Für Paging wählt man eine Checkbox aus.
Auf Android muss man erstmal ein paar xml Dateien erstellen, diese
referenziert man dann über RessourceIds und dann schreibt man lustige
Adapter für den Pager, für GridViews usw usf. UND DANN stellt man
fest, dass die Android Komponenten gar nicht horizontal scrollen
können. Gibt's nicht, hält Google nicht für nötig (bis auf den Pager,
der kann).

[Shink]

Vielleicht hat Apple ein Patent drauf...

[Ihm]

Hast du schon das FrameLayout HorizontalScrollView eingebaut?
http://developer.android.com/reference/android/widget/HorizontalScrollView.html

[Kampf-Sushi]

Horizontal ist doch kein Problem, welches Layout willst Du denn benutzen dass es nicht kann?
Zur Not benutze ggf die neue RecyclerView.

Du musst ja keine XML-Ressourcen / ressourceIds nutzen wenn du lieber alles selber Programmieren möchtest.
Es ist nur eine nette Hilfe wenn man mehr als ein Layout unterstützen möchte.

Android ist einfach flexibler, das macht es vielleicht etwas frustrierend für Einsteiger aber ich finde es eleganter.

[sth]

Wenn hier schon ein paar gerade ein paar Leute dabei sind, die sich etwas tiefer mit Android-Entwicklung auskennen: Gibt es applikationsseitige Wege um das Heap-Limit?

Das liegt selbst auf Geräten mit 2GB RAM teilweise bei weniger als 100MB pro Applikation, auf vielen noch weit verbreiteten Geräten bei gerade einmal 32MB. Benutzt man beispielsweise Google Maps in einer App, so frisst das allein schon >20MB davon auf.

[Kampf-Sushi]

Wenn hier schon ein paar gerade ein paar Leute dabei sind, die sich etwas tiefer mit Android-Entwicklung auskennen: Gibt es applikationsseitige Wege um das Heap-Limit?

Das liegt selbst auf Geräten mit 2GB RAM teilweise bei weniger als 100MB pro Applikation, auf vielen noch weit verbreiteten Geräten bei gerade einmal 32MB. Benutzt man beispielsweise Google Maps in einer App, so frisst das allein schon >20MB davon auf.
Ja gibt es, kenne es aber nur von Xamarin. Die .NET-Objekte sind nicht in der Davlik-GC mit drin. Wie das in Java läuft weiß ich nicht genau. Google z.B. mal das Stichwort Native Memory (edit: NDK, JNI.. habe da nicht viel Ahnung von, das ist mir zu kompliziert ;p)
Dann musst Du Dich aber glaube ich selber ums GC kümmern.

Ich frage mich allerdings wozu man so viel RAM braucht.

[sth]

Ja gibt es, kenne es aber nur von Xamarin. Die .NET-Objekte sind nicht in der Davlik-GC mit drin. Wie das in Java läuft weiß ich nicht genau. Google z.B. mal das Stichwort Native Memory.
Dann musst Du Dich aber glaube ich selber ums GC kümmern.
Okay, also auch nur über Umweg raus aus der Java-Welt, das war auch mein Stand. Schade.

Ich frage mich allerdings wozu man so viel RAM braucht.
Fall "normale Anwendung": Du hast 32MB zur Verfügung, davon raubt dir Google Maps ~26MB, d.h. du hast noch 6MB für den gesamten Rest der Anwendung. Die kriegt man verdammt schnell voll, vor allem weil der Java-Layer von Android alles andere als low-level ist (und noch dazu garbage collected).

Richtig spaßig wird es in dem Moment, wo man irgendwas mit Bildern oder Audiodaten macht. Ein unkomprimiertes Kamerabild belegt allein mehr Speicher als das Heap-Limit auf vielen Geräten zulässt.

Ernsthafte Audio/Video/Photo-Anwendungen lassen sich so im Grunde nur mittels NDK umsetzen, von Games ganz zu schweigen.

[Avalox]

Gibt es applikationsseitige Wege um das Heap-Limit?


Welcher API Level, soll Gingerbread noch oder nicht?

[Kampf-Sushi]

Bild und Ton kannste natürlich innerhalb von Davlik knicken. :-)

Das ist denke ich auch eher n UI-Framework. Fürs UI hat mir der Heap eigentlich immer dicke gereicht. Wenn ich Google Maps anzeige, ist IMHO nicht mehr viel Platz aufm Display für eigene Elemente die Speicher verbaten können. Wobei ich Google Maps noch nie integriert habe...

Wenn es gar nicht anders geht kann man immerhin noch einen Large-Heap nutzen, vll hilft Dir das.

[sth]

Welcher API Level, soll Gingerbread noch oder nicht?
Gingerbread klammern wir mal besser aus.
API Level 16 (aka Android 4.1) würde ich mal als Baseline setzen.

[sth]

Bild und Ton kannste natürlich innerhalb von Davlik knicken. :-)
Find' ich jetzt nicht so lustig, ehrlich gesagt.
Das ist ja noch schlimmer als zu MS-DOS-Zeiten: Nicht nur, dass man sich verrenken muss um eine wahllos gesetzte (= nach Gerätehersteller unterschiedliche und nicht zwangsläufig in Relation zur Arbeitsspeichermenge stehende) Speichergrenze zu umgehen. Man muss auch bei allem was über ein bisschen GUI hinaus geht auf eine komplett andere Programmiersprache wechseln.

Kommt nur mir das idiotisch vor?

Das ist denke ich auch eher n UI-Framework. Fürs UI hat mir der Heap eigentlich immer dicke gereicht. Wenn ich Google Maps anzeige, ist IMHO nicht mehr viel Platz aufm Display für eigene Elemente die Speicher verbaten können. Wobei ich Google Maps noch nie integriert habe...
Ist leider nicht so einfach, in einer Google Maps-basierten Anwendung passiert ja noch mehr als nur der Screen, auf dem die Karte angezeigt wird.

Natürlich alles nicht so wild auf einem Gerät mit 96MB Heap, aber in der Praxis gibt es leider noch jede Menge halbwegs aktuelle Geräte, die bei 32MB dicht machen (*hust* Samsung *hust*).

Wenn es gar nicht anders geht kann man immerhin noch einen Large-Heap nutzen, vll hilft Dir das.
Gutes Stichwort, danke.

[Gast]

https://developer.android.com/training/material/lists-cards.html#RecyclerView
Allerdings erst ab Android 5.

Bei GridView und ListView geht es nach wie vor nicht!

[Kampf-Sushi]

https://developer.android.com/training/material/lists-cards.html#RecyclerView
Allerdings erst ab Android 5.
android.support.v7.widget.RecyclerView

Du musst nur die Support Library einbauen. kompatibel ab api 7 bzw Android 2.1.

Wenn Du nicht so viele Datensätze hast, kannst Du statt der GridView ein GridLayout nehmen, das braucht auch kein Adapter-Gedöns

[sth]

Wenn es gar nicht anders geht kann man immerhin noch einen Large-Heap nutzen, vll hilft Dir das.
Gutes Stichwort, danke.
Wie erwartet: Hilft nur bei den Geräten, die ohnehin schon von Haus aus 'ne brauchbarere Heap Size haben. ;(