Fenstergrößenklassen verwenden

Compose ausprobieren

Jetpack Compose ist das empfohlene UI-Toolkit für Android. Informationen zum Verwenden von Fenstergrößenklassen in Compose

Fenstergrößenklassen in „Schreiben“ →

Fenstergrößenklassen sind eine Reihe von subjektiven Ansichtsbereichs-Breakpoints, die Ihnen beim Entwerfen, Entwickeln und Testen responsiver/adaptiver Layouts helfen. Die Breakpoints sorgen für eine ausgewogene Kombination aus einfacher Layoutgestaltung und Flexibilität bei der Optimierung Ihrer App für individuelle Anwendungsfälle.

Fenstergrößenklassen kategorisieren den für Ihre App verfügbaren Displaybereich als kompakt, mittel oder erweitert. Verfügbare Breite und Höhe werden separat klassifiziert. Ihre App hat also jederzeit zwei Fenstergrößenklassen – eine für die Breite und eine für die Höhe. Aufgrund der flächendeckenden Verwendung des vertikalen Scrollens ist die verfügbare Breite in der Regel wichtiger als die verfügbare Höhe. Daher ist die Fenstergrößenklasse „Breite“ für die Benutzeroberfläche Ihrer App wahrscheinlich relevanter.

Wie in den Abbildungen dargestellt, können Sie mithilfe der Grenzwerte weiterhin Layouts in Bezug auf Geräte und Konfigurationen planen. Jeder Größenklassen-Bruchpunkt stellt einen häufigen Fall für typische Geräteszenarien dar. Dies kann ein hilfreicher Referenzrahmen sein, wenn Sie über das Design Ihrer bruchpunktbasierten Layouts nachdenken.

Die Visualisierung von Größenklassen als physische Geräte kann zwar hilfreich sein, die Fenstergrößenklassen werden jedoch nicht durch die Größe des Gerätebildschirms bestimmt. Fenstergrößenklassen sind nicht für Logik vom Typ isTablet vorgesehen. Die Fenstergrößenklassen werden vielmehr von der Fenstergröße bestimmt, die für Ihre Anwendung verfügbar ist, unabhängig vom Gerätetyp, auf dem die App ausgeführt wird. Das hat zwei wichtige Auswirkungen:

• Physische Geräte garantieren keine bestimmte Fenstergrößenklasse. Der für Ihre App verfügbare Bildschirmbereich kann aus vielen Gründen von der Bildschirmgröße des Geräts abweichen. Auf Mobilgeräten kann der Splitscreen-Modus den Bildschirm in zwei Bereiche aufteilen, die jeweils einer App zugewiesen werden. Unter ChromeOS können Android-Apps in Desktopfenstern angezeigt werden, die beliebig skaliert werden können. Faltbare Geräte können zwei Bildschirme unterschiedlicher Größe haben, auf die Sie durch Zusammen- oder Aufklappen des Geräts zugreifen können.

• Die Fenstergrößenklasse kann sich während der Lebensdauer Ihrer App ändern. Wenn Ihre App ausgeführt wird, kann sich die verfügbare Bildschirmfläche durch Änderungen der Geräteausrichtung, durch Multitasking und durch das Zusammen- und Aufklappen des Geräts ändern. Daher ist die Fenstergrößenklasse dynamisch und die Benutzeroberfläche Ihrer App sollte sich entsprechend anpassen.

Fenstergrößenklassen entsprechen den Grenzwerten „Kompakt“, „Mittel“ und „Maximiert“ in den Leitfäden für das Material Design-Layout. Verwenden Sie Fenstergrößenklassen, um übergeordnete Entscheidungen zum Anwendungslayout zu treffen, z. B. ob Sie ein bestimmtes kanonisches Layout verwenden möchten, um zusätzlichen Bildschirmplatz zu nutzen.

Sie können den aktuellen WindowSizeClass mithilfe der WindowSizeClass#compute() vom Jetpack bereitgestellte Funktion WindowManager-Bibliothek. Im folgenden Beispiel zeigt, wie Sie die Fenstergrößenklasse berechnen und Aktualisierungen erhalten, wenn die Fenstergrößenänderungen:

class MainActivity : Activity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // ...

        // Replace with a known container that you can safely add a
        // view to where the view won't affect the layout and the view
        // won't be replaced.
        val container: ViewGroup = binding.container

        // Add a utility view to the container to hook into
        // View.onConfigurationChanged(). This is required for all
        // activities, even those that don't handle configuration
        // changes. You can't use Activity.onConfigurationChanged(),
        // since there are situations where that won't be called when
        // the configuration changes. View.onConfigurationChanged() is
        // called in those scenarios.
        container.addView(object : View(this) {
            override fun onConfigurationChanged(newConfig: Configuration?) {
                super.onConfigurationChanged(newConfig)
                computeWindowSizeClasses()
            }
        })

        computeWindowSizeClasses()
    }

    private fun computeWindowSizeClasses() {
        val metrics = WindowMetricsCalculator.getOrCreate().computeCurrentWindowMetrics(this)
        val width = metrics.bounds.width()
        val height = metrics.bounds.height()
        val density = resources.displayMetrics.density
        val windowSizeClass = WindowSizeClass.compute(width/density, height/density)
        // COMPACT, MEDIUM, or EXPANDED
        val widthWindowSizeClass = windowSizeClass.windowWidthSizeClass
        // COMPACT, MEDIUM, or EXPANDED
        val heightWindowSizeClass = windowSizeClass.windowHeightSizeClass

        // Use widthWindowSizeClass and heightWindowSizeClass.
    }
}

public class MainActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // ...

        // Replace with a known container that you can safely add a
        // view to where the view won't affect the layout and the view
        // won't be replaced.
        ViewGroup container = binding.container;

        // Add a utility view to the container to hook into
        // View.onConfigurationChanged(). This is required for all
        // activities, even those that don't handle configuration
        // changes. You can't use Activity.onConfigurationChanged(),
        // since there are situations where that won't be called when
        // the configuration changes. View.onConfigurationChanged() is
        // called in those scenarios.
        container.addView(new View(this) {
            @Override
            protected void onConfigurationChanged(Configuration newConfig) {
                super.onConfigurationChanged(newConfig);
                computeWindowSizeClasses();
            }
        });

        computeWindowSizeClasses();
    }

    private void computeWindowSizeClasses() {
        WindowMetrics metrics = WindowMetricsCalculator.getOrCreate()
                .computeCurrentWindowMetrics(this);

        int width = metrics.getBounds().width
        int height = metrics.getBounds().height()
        float density = getResources().getDisplayMetrics().density;
        WindowSizeClass windowSizeClass = WindowSizeClass.compute(width/density, height/density)
        // COMPACT, MEDIUM, or EXPANDED
        WindowWidthSizeClass widthWindowSizeClass = windowSizeClass.getWindowWidthSizeClass()
        // COMPACT, MEDIUM, or EXPANDED
        WindowHeightSizeClass heightWindowSizeClass = windowSizeClass.getWindowHeightSizeClass()

        // Use widthWindowSizeClass and heightWindowSizeClass.
    }
}

Fenstergrößenklassen testen

Testen Sie das Layoutverhalten bei allen Fenstergrößen, insbesondere bei den Grenzbreiten für die kompakte, mittlere und erweiterte Ansicht.

Wenn Sie bereits ein Layout für kompakte Bildschirme haben, optimieren Sie es zuerst für die Größe „Maximale Breite“, da diese Größe den meisten Platz für zusätzliche Inhalte und Änderungen an der Benutzeroberfläche bietet. Entscheiden Sie dann, welches Layout für die mittlere Breite sinnvoll ist. Sie können auch ein spezielles Layout hinzufügen.

Nächste Schritte

Weitere Informationen zum Erstellen responsiver/adaptiver Layouts mithilfe von Fenstergrößenklassen finden Sie unter:

• Für Compose-basierte Layouts: Unterstützung verschiedener Bildschirmgrößen

• Für ansichtsbasierte Layouts: Responsives/adaptives Design mit Ansichten

Weitere Informationen dazu, was eine App auf allen Geräten und Bildschirmgrößen erfolgreich macht, finden Sie unter:

• UI zu responsiven Layouts migrieren
• Qualität von Apps auf großen Bildschirmen