Apps für Tablets anpassen

Hey kennt sich jemand bei der Anpassung von Apps für Tablets aus?

Mir gehts primär darum meine Bitmaps richtig zu skalieren da Tablets ja mehr Quadratförmig sind als Handy Displays

Ich würde gern mal wissen auf was Ihr da Designtechnisch achtet oder man achten sollte

den Goggole Guide kenn ich schon

Jetzt vielleicht ein paar praktische Tipps von euch noch vllt?

wie kommst du darauf, das tablet's eher quadratisch sind ? Ich hatte bislang nur
welche in den händen, die eine "rechteckige" auflösung hatten.
und laut dieser Tabelle Tablet Auflösung Übersicht
sind die alle rechteckig.

Das einzig quadratische Handy was ich kenne kam con Motorola und hieß glaube ich Flipout

Also ich dachte ein Handy hat eine kleinere aspect ratio(breite durch höhe) als ein tablet

Tut das Format tatsächlich was zur Sache (ernstgemeinte Frage)? Zumindest sind meine Tablets aber eigentlich auch ähnlich rechteckig, wie Handys auch.

Ich bin der Meinung, dass doch die größere Nutzfläche der springende Punkt ist, ans Format muss sich das Design so oder anpassen.
Das heißt für mich: Dimens anpassen, dass nicht alles zu eng aneinander gestaut ist (schau mal auf Metrics & keylines - Layout - Google design guidelines) und mehr Content anzeigen. Also beispielsweise, wenn du zuvor ein NavDrawer bei Handys hattest, könntest du den jetzt immer anzeigen, oder Detail-Fragments etc., um auch mehr effektiv nutzbaren Inhalt auf den großen Screens zu platzieren anstatt einfach nur alle Abstände etc. größer zu machen und dafür quasi das Selbe an Inhalt zeigen.

Aber auch das ist glaub ich etwas von der jeweiligen App abhängig. Bei einer Bildbearbeitungsapp würde ich z.B. den NavDrawer auch NavDrawer sein lassen, um eine größere Nutzfläche zur Bildbearbeitung zu erhalten.

Um was für eine App handelt es sich denn? Wie schaut die aktuell aus?

Das sind so meine spontanen Einfälle, die du aber wahrscheinlich schon kennst, da das auf der Hand liegt und du die Doku ja gelesen hast

Oh läuft bei dir mit Test geräten

Naja darums gings nicht Sondern wollte nur beispielhaft zeigen, wie ichs umgesetzt habe mit der zusätzlichen Nutzung des freien Platzes. (Und 1 geliehenes Tab und 2 olle Galaxy S1 zählen nicht xD)

Aber das wäre doch ganz interessant: Um was für eine App handelt es sich denn? Wie schaut die aktuell aus?

Hehe, sieht schon gut aus mit den ganzen Geräten. 2 PC Bildschirme + Beamer und 5x Genymotion geöffnet -> so gehts auch
Aber wenns Richtung Release geht, gibt es keinen Ersatz für ein echtes Gerät...
Ansonsten hat reneph schon den passenden (und aktuellen) Link zur Doku bereitgestellt.

ich hab nur allgemein überlegungen angestellt für meine games weil es ja sein kann falls der screen viel breiter ist als hoch dann würden sich einige bitmaps wie buttons etc überlappen da ich immer nach breite skaliere und den faktor zur skalierung in die höhe mitnehme...ich habe deswegen ncoh zur sicherheit eine Abfrage mit reingeschmissen die überprüft ob sich die bitmaps evtl überschneiden ooder zu nah dran sind dann skaliere ich nach der höhe bzw. ändere die skalierung ettwas ab beruhend auf den ermittelten werten.

Wollte mal einfach in die runde werfen ob das sinn macht.

Der ursprüngliche Beitrag von 18:08 Uhr wurde um 18:12 Uhr ergänzt:

na toll ich erfahre jetzt erst etwas über genymotion?!

Das mit der Skalierung im Programmcode kann man eigentlich vergessen. Ist aufwendig und macht kein Sinn.

Eigentlich muss man nur für 4 Größen entwickeln:


320dp: a typical phone screen (240x320 ldpi, 320x480 mdpi, 480x800 hdpi, etc).
480dp: a tweener tablet like the Streak (480x800 mdpi).
600dp: a 7” tablet (600x1024 mdpi).
720dp: a 10” tablet (720x1280 mdpi, 800x1280 mdpi, etc).

Supporting Multiple Screens | Android Developers

Die Geräte skalieren die Bilder auf die passende Auflösung. Und sonst würde ich Fragmente benutzen.

also aspect ratio reicht von (B:H) ungefähr 1:2 über 3:5 , 2:3 bis 3:4(0.5,0.6,0.66,0.75)
wobei der durchschnitt ungefähr zwischen 0.55 und 0.65 liegt

mir machen alle über 0.7 ja eben sorgen...oh mann die hersteller sollten sich mal alle auf ein vllt zwei ratio standards einigen endlich damit entwickler sich nciht so viele gedanken amchen müssen bei ihrer software wie z.B. bei apple naja vllt eines tages oder wenn alle nur ncoh samsungs haben oder so...egal danke für die info

Der ursprüngliche Beitrag von 20:22 Uhr wurde um 20:25 Uhr ergänzt:

und ich gehe bestimmt nciht googles weg und erstelle mehrere layout in vers größen da pack ich mir meine apk viel zu voll lieber ein paar bilder mit höherer auflösung und dann programmatiscvh runterskalieren hab dann zwar für ne kurze zeit den ram etwas voll und der gc muss etwas emhr hand anlegen aber lieber einmal eine performance intensive arbeit durchführen statt die ganze zeit schweres gepäck mit sich rumtragen!

Ich sehe in den Ansatz von Jail ein Problem. Unter Android skalieren die Devices selbständig die Darstellung (In dem Fall auf von den Standartgrößen für Tabletts auf die reale Größe). Die Algorithmen sind so angepasst, dass möglichst keine Treppen entstehen.

Bei Jails Ansatz arbeiten jetzt zwei Algorithmen, die das gleiche machen:

das Layout skalieren. Gute Chancen für Treppen in der Darstellung.

Nene ich skaliert. Keine Layout nur.Bitmaps
mit.Layouts arbeite ich nicht wenn ich etwas.in XML. Mache dann nur um activities zu registrieren und so

Der ursprüngliche Beitrag von 23:15 Uhr wurde um 23:29 Uhr ergänzt:

sry kam hab wohl aus versehen layout getippt

Sehe ich das richtig, du baust alle Views ohne ein xml - Layout zusammen?

Das macht doch kein Sinn. Gegen ein Paradigma des Frameworks (Android) zu programmieren.

Das ist nur etwas für Leute, die ausgeprägte Einzelkämpfer sind. Man sollte immer so programmiern, dass jeder die Möglichkeit hat, den Code zu verstehen. Am besten wählt man immer die einfachste und gängigsten Lösung.

Hier geht's doch bestimmt wieder um ein Spiel oder?

markus.tullius schrieb:

Man sollte immer so programmiern, dass jeder die Möglichkeit hat, den Code zu verstehen.

Zum Vergrößern anklicken....

Es geht nicht nur um die anderen. Um es mit den Worten von Brian Kerningham zu sagen:

Debugging ist doppelt so schwer wie Programmieren. Wenn man so schlau programmiert wie es geht, ist man also per Definition nicht in der Lage, den Code zu debuggen.

Zum Vergrößern anklicken....

DagobertDokate schrieb:

Hier geht's doch bestimmt wieder um ein Spiel oder?

Zum Vergrößern anklicken....

Ja ... höre ich da einen gewissen Unterton?


Also ne surface view in XML macht da kein Sinn

Wenn ich jetzt ne app hätte mit Standard view child würde ich natürlich alles mit XML erstellen

höre ich da einen gewissen Unterton?

Zum Vergrößern anklicken....

nö... aber müsste deine Engine nicht automatisch das Bild für die jeweilige Auflösung scalieren? oO

lg.

tu ich ja
hab mir nur gedanken gemacht wie es auf tablkets aussieht aber ich hab da jetzt paar abfragen mehr reingetan um sicher zu gehen dass sich nichts überlappt somit case closed

Skaliert sureface nicht automatisch im xml - layout?
Warum benutzt du kein OpenGL, da du sowieso den Sureface benutzt. Dann braucht den foobar auch nicht.

Ich dachte immer, Programmierer sind faul, und benutzen am liebsten die vorgegebenen Schnittstellen.