Verständnisprobleme beim Layout

Aber wie machst du das mit den SP bei Texten? Also ich finde Android gibt schon alles in die Hand, ohne großen Code beim Layout schreiben zu müssen.

Zum Vergrößern anklicken....

Die setze ich als Pixel aus Millimeter ( kein DP , kein SP )


TextView.setTextSize (mm2pixel (0.8F));

Das Ergebnis ist sogar recht exakt - obwohl man es nicht vermuten könnte

Tut mir leid, aber ich sehe überhaupt keinen Vorteil.
Was würdest du machen, wenn du nur bei sw360 eine kleinere Schriftgröße nehmen möchtest?

Dann haben wir uns falsch verstanden :

Die Schriftgrösse und deren Berechnung ist ausschliesslich für das Layout.

Je nach Anwendung auch halt meintwegen frei Scalierbar durch den User. (Hat sich bei mir noch nicht ergeben)

Es ist doch völlig schnuppe , ob der User mit seinem Slider mm oder SP / DP verstellt ( innerhalb der Anwendung)

Und Dein Beispiel ist dadurch nicht eliminiert

Bei einem kleinen Layout kann ich zumindest damit sicherstellen , das der Text auch wirklich angezeigt wird und nicht durch
die Systemeinstellung überschrieben wird und dadurch nicht mehr voll lesbar

Bei der Überlegung welche Geräte man Unterstützen möchte wegen welchem Aspekt auch immer (Version, Screendensity/-größe oder OpenGL-Version) kann man hier reinschauen: Dashboards | Android Developers

swa00 schrieb:

A set of four generalized sizes: small, normal, large, and xlarge

Zum Vergrößern anklicken....

Das ist allerdings Wunschdenken , denn viele Devices besitzen mittlerweile unterschiedliche
DPI Werte in Höhe und Breite.
Und dann kommt ein rundes Element einem Ei gleich. (Selbst Samsung und Lenovo bekommen das hin)

Zum Vergrößern anklicken....

Das ist eigentlich schon immer so gewesen.

Für verschiedene Auflösungen im Layout braucht man drei Ordner
layout - Smartphone
layout-sw600dp - Tablet 7"
layout-sw820dp - Tablet 10"

Das ist alles. Der Vorteil ist, dass man auch unterschiedliche Layout für Tablets und Smartphones benutzen kann, bei gleichen Code. Beispiel:
System-Einstellungen. Dort sieht bei gleichen Programmcode das Layout zwischen Tablet und Smartphone unterschiedlich aus.

Moin Zusammen !

Grundsätzlich : Ich habe nicht behauptet, dass man die von Google angegeben Richtlinien nicht verwenden soll

In allen obigen XML Ausführungen gebe ich Recht und widerspreche dem auch gar nicht und behaupte auch nicht
das meine Vorgehensweise ( obwohl sie Jaeil im übrigen auch anwendet) die Richtige sei und Google damit falsch

Vielleicht ist es nicht richtig rüber gekommen :

Meine Vorgehensweise bezieht sich auf ein festes Grössen Layout, welches bei manchen Applikationen von Nöten ist.
Da helfen sämtliche Layoutvarianten nicht, ein 10Zoll Tablet ist nicht ein 10Zoll Tablet

Hierzu drei Beispiele um es ein wenig zu verdeutlichen :

a)
Möchte ich einen Imagebutton haben, der immer die gleiche Größe besitzen soll ( also z.B. 1 cm Durchmesser rund) -
egal welche ausserirdische Displaygröße & Dpi, dann müsste man nach meinem Beispiel vorgehen. Besonders dann,
damit das Ding auch rund bleibt.
Zur Erinnerung : die Angabe von DP berücksichtigt die unterschiedlichen DPI auf ein und dem gleichen Display nicht.
Die Werte können gerade bei IPS Screens unterschiedlich sein / Bauartbedingt.
(Anwendungsbeispiel : Apps für Sehbehinderte, Layouts für Fahrzeuge etc)

b)
Möchte ich so etwas generieren, wie die Ursprungsfrage hier lautet und möchte vermeiden , dass das Image
in irgend einer form Verzerrt, verkleinert oder angeschnitten im 1:1 Verhältnis angezeigt wird , dann komme ich nun mal
um eine ordentliche Berechnung der Ursrpungswerte im Verhältnis des Bitmaps nicht drumrum.

Der TE möchte sein gesamtes Layout so anpassen , dass sein Image linksbündig formatfüllend ist und
nicht verzerrt (oder verkleinert - wie angegeben)

Nicht das Layout bestimmt , wie das Bitmap dargestellt wird, sondern das Bitmap bestimmt , wie das Layout sein soll.

Der Bezug der Berechnungsgrundlage ist hier ein ganz Anderer.


c) Habe ich eine Hintergrundgrafik - nehmen wir mal an , es wäre mit Gitterlinien - und ich möchte auf
jedem Schnittpunkt Buttons plazieren , dann muss ich das auch manuell berechnen.

All diese drei Beispiele stellt Google mit seinen Standardlayout-XML-Layout-Funktionen NICHT zur Verfügung .
Es berechnet irgendwas in der Hoffnung es passt

Deshalb habe ich mir auch die Mühe gemacht, meine Layouts dementsprechend in der Berechnung umzustellen.

Auf den Trichter bin ich auch erst dann gekommen , als ich mal all meine schrott Devices aus der
Schublade gekramt habe - und bin dann ziemlich geerdet worden . :-(

Ist das Bereitstellen von mehreren Layouts (für small, normal, large) jetzt auch deprecated?

Deka hast du scaletype auf "centerCrop" gestellt? Egal wie du dein Layout nun machst würde ich das benutzen damit es alles unverzerrt auffüllt.

Ja habe ich. Sieht soweit gut aus. Danke für den Tipp.
Ich arbeite gerade mit dem PercentageRelativeLayout und bin begeistert. Klappt wunderbar.
Habe nun definiert, dass das Bild von der width 30% einnimmt das sieht auf beiden Geräten gut aus. Damit hätte ich schon mal ein Problem gelöst.

Weißt du wie ich am besten mit der Schriftgröße umgehen sollte? Aktuell habe ich für meine CheckBoxen keine Schriftgröße definiert. Das sieht auf meinem LG G2 ja noch gut aus, aber auf dem OnePlus 3T ist sie viel zu klein:



Muss ich hier verschiedene dimens.xml anlegen und für die verschiedenen Screens die Schriftgröße festlegen?

Du kannst die Textgröße ja in mm angeben. sp benutzt man nur damit der Text mit den Einstellungen des Users mitgeht, sprich stellt der User die Textgröße um dann verändern sich auch die physischen Größen deiner Texte.

Du könntest alle Texte an die Höhe deiner Views anpassen. Wie hoch hast du deine Checkbox eingestellt? Einfach die dp davon benutzen

swa00 schrieb:

All diese drei Beispiele stellt Google mit seinen Standardlayout-XML-Layout-Funktionen NICHT zur Verfügung .
Es berechnet irgendwas in der Hoffnung es passt

Zum Vergrößern anklicken....

Wo du recht hast, hast du recht. Mein größter Spaß war bis jetzt ein Gerät welches die Masse 250x426. War als Android-Gerät ausgezeichnet, da hat nichts mehr gepasst. Auch Berechnungen haben mir nicht mehr geholfen.

markus.tullius schrieb:

Wo du recht hast, hast du recht. Mein größter Spaß war bis jetzt ein Gerät welches die Masse 250x426. War als Android-Gerät ausgezeichnet, da hat nichts mehr gepasst. Auch Berechnungen haben mir nicht mehr geholfen.

Zum Vergrößern anklicken....

Für solche Endgeräte mache ich mir nicht mehr die Arbeit. Die erfüllen dann ganz einfach meine Mindestvorraussetzungen nicht. Wer solch ein Telefon noch benutzt in 2017 der braucht auch keine Apps ausser die Standardapps die schon installiert sind

[QUOTE="deka, post: 10322196, member: 80327"
Ich arbeite gerade mit dem PercentageRelativeLayout und bin begeistert. Klappt wunderbar.
[/QUOTE]

Ich habe noch gar nichts vom PercentageRelativeLayout gehört. Ist das sowas wie ein LinearLayout mit WeightSum?

@Kardroid
Ganz genau, funktioniert nach dem gleichen Prinzip.
Alles was du dafür tun musst, ist in deinem build.gradle die dependencies zu ergänzen:
compile 'com.android.supportercent:23.1.1'

Anschließend habe ich mein bestehendes RelativeLayout durch
android.support.percent.PercentRelativeLayout ersetzt.

Und dann habe ich z.B. für mein ImageView gesagt, dass es von der Breite immer 30% des Bildschirms einnehmen soll:
app:layout_widthPercent="30%"

EDIT: Der Smily steht für : p
Kann man die Smilys irgendwo deaktivieren?

Und dann habe ich z.B. für mein ImageView gesagt, dass es von der Breite immer 30% des Bildschirms einnehmen soll:
app:layout_widthPercent="30%"

Zum Vergrößern anklicken....

Das würde allerdings bedeuten , dass Dein Display IMMER ein Verhältnis von 30 % der Breite zur Höhe,
in Relation zum Image hätte.

Und was machst du dann ,wenn das Verhältnis des Screens unterschiedlich ist ??

Geht es nicht hier darum, es auf allen Devices gleich aussehen zu lassen ?
Oder beschränkst du dich nur auf die zwei Devices , die du vor dir liegen hast ?

Wie meinst du das genau? Weil ich verstehe das so, dass es sich auf jedem Gerät die 30% nimmt. Und das ist ja auch genau das was ich möchte.

Vielleicht habe ich mich falsch ausgedrückt gehabt, aber mein Ziel ist es, dass meine App auf jedem Bildschirm die gleiche Aufteilung hat und genau das macht ja das PercentageRelativeLayout.

Hallo deka,

mir liegt es wirklich fern, Dich in deiner Euphorie zu bremsen - jeder braucht dieses Glücksgefühl
(Ich auch)

Auch habe ich mich bewusst erst mal hier zurückgehalten, muss aber gestehen , dass ich
ein wenig den Kopf schüttel, weil das in eine falsche Richtung hoppelt

Und das deswegen, weil mein Haupt-Betätigungsfeld seit 30 Jahren im Image-Processing Bereich liegt,
und meine obigen Ausführungen schon eine gewisse Basis darstellt.



ich komme auf deinen ersten Post zurück :
Dort schreibst du :

So soll es auch auf allen anderen Geräten aussehen. D.h. das Bild links soll den Inhalt komplett ausfüllen und keine Ränder zeigen.

Zum Vergrößern anklicken....

Ich gehe mal davon aus , dass du das noch immer willst .

Wenn nicht, dann bitte ich um Mitteilung - dann hat sich das erledigt
Wenn ja , dann gibt mir ein paar Minuten Zeit , dann kann ich gerne dir genau erklären , wo der gravierende Denkfehler ist.

@swa00
Mein Ziel ist es immer noch, dass es auf jedem Gerät gleich aussieht. Damit beziehe mich aber auf die Verhältnisse. Das bedeutet auf einem 5 Zoll Gerät soll das Bild 30% einnehmen und auf einem 6 Zoll Gerät genauso. Die Bildschirmanteile, die sich die einzelnen Elemente nehmen sollten immer gleich sein; auf jedem Gerät. Und genau das möchte ich erreichen.

Und keine Angst du hast mich in der Euphorie nicht gebremst. Ich weiß selber wie komplex dieses Thema ist und ich tue mich hier auch wirklich schwer damit.

Gut , dann werde ich das mal wunschgemäß ein wenig ausführlicher erklären.

Ziel :

Unser Image soll formatfüllend und unverzerrt dargestellt werden.

Und zwar so :


und nicht so



Ausgangslage :

Wir nehmen dann mal zwei 10Zoll Tablets - z.b. ein Samsung TAB A (9,7) und ein Levono TAB 3 (10,1)
(Kann auch jedes andere Device sein)

Das Samsung hat eine Auflösung von 1024 x 768 also ein Ratio-Faktor von 1.3
Das Levono hat eine Auflösung von 1900 x 1200 also ein RatioFaktor von 1.6

Dann hast du ein Image, welches eine Grösse von 800Pixel in der Höhe und 240Pixel in der Breite hat.
Das Image hat also eine Ratio von 2.5
(Ich habe hier die Masse des Images bewusst erst mal auf 30% Breite im Verhältnis zur Höhe gewählt)



Die Berechnung : (wir gehen von Landscape aus)

Fall 1 : Das Samsung
30 Prozent der Bildschirmbreite entspricht einem Ausschnitt von 768 x 307 Pixel = Ratio 2.5
Die Ratio des Layoubereiches bei 30% UND die Ratio des Images sind beide 2.5
Alles passt perfekt !

Fall 2 : Das Lenovo
30 Prozent der Bildschirmbreite entspricht einem Ausschnitt von 1200 x 570 Pixel = Ratio 2.1
Da unser Image eine Ratio von 2.5 besitzt , aber der Ausschnitt bei 30% eine Ratio von 2.1
wird dieses Image also einen Rand bekommen.

Somit hast du wieder den Effekt , den du in deinem ersten Post angefragt hast.



Lösung :

Um das zu umgehen, musst du deinen Ausschnitt deines Layouts an die Ratio des Images
von 2.5 anpassen und nicht umgekehrt.

Und genau das wollte ich oben mit meinem Beispiel deutlich machen.

Zitat 1:

Nicht das Layout bestimmt , wie das Bitmap dargestellt wird, sondern das Bitmap bestimmt , wie das Layout sein soll.

Zum Vergrößern anklicken....

Völlig Schnuppe ob prozentual, Millimeter oder Pixel

Zitat 2 :


Fazit :

Für Dein Vorhaben nutzt dir also weder SP / DP / Prozentual und was Dir dazu noch alles einfällt.
Android geht immer von einem XML aus und berechnet das, was es für Richtig hält.

Dies entspricht allerdings nicht deiner Wunschvorstellung .

Lass Dich also bitte nicht verwirren , sondern folge einfach den logischen Gegebenheiten.

So, gefühlte 50 mal umgeschrieben , jetzt passts

Mit centerCrop füllt das Bild unverzerrt den Platz. Dadurch wirkt das Bild zwar gezoomt aber was solls. Er kann immer noch ein alternatives Layout machen falls es zu schlecht aussieht so. Dann eben 33 oder 35 %.

Oder halt im Code aber dann geht's schon los damit dass die Wartbarkeit und Übersichtlichkeit des Codes schwindet