Design responsif/adaptatif avec vues

Les mises en page responsives et adaptatives offrent une expérience utilisateur optimisée, quelles que soient la taille de l'écran. Implémentez des mises en page responsives/adaptatives pour permettre à vos compatible avec toutes les tailles d'écran, toutes les orientations de configuration, y compris les configurations redimensionnables comme le mode multifenêtre mode.

Responsive design

La première étape pour prendre en charge différents facteurs de forme d'appareils consiste à créer un Une mise en page qui s'adapte aux variations de l'espace d'affichage disponible à votre application.

ConstraintLayout

La meilleure façon de créer une mise en page responsive est d'utiliser ConstraintLayout comme mise en page de base pour votre UI. ConstraintLayout vous permet de spécifier le la position et la taille de chaque vue en fonction des relations spatiales entre dans la mise en page. Toutes les vues peuvent alors se déplacer et se redimensionner afficher les modifications de l'espace.

Le moyen le plus simple de créer une mise en page avec ConstraintLayout consiste à utiliser la classe Layout Editor dans Android Studio. L'éditeur de mise en page vous permet de faire glisser de nouvelles vues vers le appliquer des contraintes relatives aux vues parent et frère, et définir la vue sans avoir à modifier manuellement le code XML.

Pour en savoir plus, consultez Créer une UI responsive avec ConstraintLayout.

Largeur et hauteur responsives

Pour vous assurer que votre mise en page s'adapte à différentes tailles d'écran, utilisez wrap_content, match_parent ou 0dp (match constraint) pour la largeur et composants de hauteur de la vue au lieu des valeurs codées en dur:

• wrap_content: la vue adapte sa taille à son contenu.
• match_parent: la vue se développe le plus possible dans la vue parent.
• 0dp (match constraint): dans un ConstraintLayout, semblable à match_parent La vue occupe tout l'espace disponible dans les de contraintes.

Exemple :

<TextView
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:text="@string/lorem_ipsum" />

La figure 4 montre comment la largeur et la hauteur du TextView s'ajustent en fonction de l'affichage. la largeur change en fonction de l'orientation de l'appareil.

La TextView définit sa largeur de manière à occuper tout l'espace disponible (match_parent). sa hauteur à l'espace requis par la hauteur du conteneur (wrap_content), ce qui permet à l'affichage de s'adapter à différents affichages et différentes quantités de texte.

Si vous utilisez un LinearLayout, vous peut également développer les vues enfants en fonction de la mise en page poids pour que les vues occupent l'espace disponible. Toutefois, l'utilisation de pondérations dans un élément LinearLayout imbriqué nécessite au système d'effectuer plusieurs passes de mise en page afin de déterminer la taille de chaque ce qui ralentit les performances de l'UI.

ConstraintLayout peut créer presque toutes les mises en page possibles avec LinearLayout sans impact sur les performances, alors convertissez vos LinearLayout jusqu'à ConstraintLayout Ensuite, peuvent définir des mises en page pondérées avec des contraintes les chaînes.

Design adaptatif

La mise en page de votre application doit toujours s'adapter à différentes tailles d'écran. Cependant, même une mise en page responsive ne peut pas offrir la meilleure expérience utilisateur sur sur chaque appareil ou en mode multifenêtre. Par exemple, l'UI que vous conçue pour un téléphone, n'offre probablement pas une expérience utilisateur optimale sur un tablette. La conception adaptative fournit des mises en page alternatives optimisées pour différentes les dimensions d'affichage.

SlidingPaneLayout pour les interfaces utilisateur détaillées en liste

Une UI liste/détails offre généralement une expérience utilisateur différente sur d'écrans de différentes tailles. Sur les grands écrans, les volets de liste et de vue détaillée sont généralement côte à côte. Lorsqu'un élément de la liste est sélectionné, les informations le concernant sont affiché dans le volet des détails sans modifier l'interface utilisateur, les deux volets restent côte à côte. Toutefois, sur les petits écrans, les deux volets s'affichent séparément, chaque volet occupant la totalité de la zone d'affichage. Lorsqu'un élément du volet de liste est sélectionné, le volet Détails (contenant les informations sur l'élément sélectionné) remplace le volet de liste. Le bouton "Retour" remplace le volet de vue détaillée par le volet de liste.

SlidingPaneLayout gère la logique pour déterminer laquelle des deux expériences utilisateur est adaptée à la taille de fenêtre actuelle:

<?xml version="1.0" encoding="utf-8"?>
<androidx.slidingpanelayout.widget.SlidingPaneLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <androidx.recyclerview.widget.RecyclerView
        android:id="@+id/recycler_view"
        android:layout_width="280dp"
        android:layout_height="match_parent"
        android:layout_gravity="start" />

    <androidx.fragment.app.FragmentContainerView
        android:id="@+id/nav_host_fragment"
        android:name="androidx.navigation.fragment.NavHostFragment"
        android:layout_width="300dp"
        android:layout_height="match_parent"
        android:layout_weight="1"
        app:defaultNavHost="true"
        app:navGraph="@navigation/item_navigation" />

</androidx.slidingpanelayout.widget.SlidingPaneLayout>

Les attributs layout_width et layout_weight des deux vues contenues dans SlidingPaneLayout déterminent le comportement de SlidingPaneLayout. Dans cet exemple, Si la fenêtre est suffisamment grande (au moins 580 dp de large) pour afficher les deux vues, la volets sont affichés côte à côte. En revanche, si la largeur de la fenêtre est inférieure 580 dp, les volets glissent les uns sur les autres pour occuper individuellement la totalité de l'application fenêtre.

Si la largeur de la fenêtre est supérieure à la largeur minimale totale spécifiée (580 dp), Les valeurs layout_weight peuvent être utilisées pour dimensionner les deux volets de manière proportionnelle. Dans Par exemple, la largeur du volet de liste est toujours de 280 dp, car il n'a pas de pondération. Le volet de vue détaillée remplit toujours tout espace horizontal au-delà de 580 dp, car du paramètre layout_weight de la vue.

Autres ressources de mise en page

Pour adapter la conception de votre interface utilisateur à des tailles d'écran très différentes, utilisez d'autres mises en page. identifié par la ressource qualificatifs.

Vous pouvez fournir des mises en page adaptatives spécifiques à l'écran en créant des mises en page res/layout/ du code source de votre application. Créez un répertoire pour chaque configuration d'écran qui nécessite une mise en page différente. Ajoutez ensuite un écran le qualificatif de configuration au nom du répertoire layout (par exemple, layout-w600dp pour les écrans dont la largeur disponible est de 600 dp.

Les qualificatifs de configuration représentent l'espace d'affichage visible disponible pour l'UI de votre application. Le système prend en compte toutes les décorations système (telles que le la barre de navigation) et la configuration des fenêtres (mode multifenêtre, par exemple). ) lorsque vous sélectionnez la mise en page de votre application.

Pour créer d'autres mises en page dans Android Studio, consultez Utiliser des variantes de mise en page pour à optimiser pour différents écrans Développer une interface utilisateur avec des vues

Qualificatif de plus petite largeur

Le qualificatif de taille d'écran plus petite largeur vous permet de fournir mises en page pour les écrans dont la largeur minimale est mesurée indépendante de la densité pixels (dp).

En décrivant la taille de l'écran comme une mesure de dp, Android vous permet de créer mises en page conçues pour des dimensions d'affichage spécifiques, sans se soucier différentes densités de pixels.

Par exemple, vous pouvez créer une mise en page nommée main_activity optimisée pour téléphones et tablettes en créant différentes versions du fichier dans différentes répertoires:

res/layout/main_activity.xml           # For phones (smaller than 600dp smallest width)
res/layout-sw600dp/main_activity.xml   # For 7" tablets (600dp wide or wider)

Le qualificatif de largeur la plus petite spécifie le plus petit des deux côtés de l'écran, quelle que soit l'orientation de l'appareil. C'est donc un moyen de spécifier la taille globale d'affichage disponible pour votre mise en page.

Voici comment les autres valeurs de largeur minimale correspondent aux tailles d'écran classiques :

• 320 dp: petit écran de téléphone (240 x 320 pixels, 320 x 480 mdpi, 480 x 800 hdpi, etc.)
• 480 dp : grand écran de téléphone d'environ 5 pouces (480 x 800 mdpi)
• 600 dp: 7 pouces Tablette (600 x 1 024 mdpi)
• 720 dp: 10 pouces Tablette (720 x 1 280 mdpi, 800 x 1 280 mdpi, etc.)

La figure suivante montre plus en détail comment différents dp d'écran les largeurs correspondent à différentes tailles et orientations d'écran.

Les valeurs du qualificatif de plus petite largeur sont dp, car ce qui compte, quantité d'espace d'affichage disponible une fois que le système a pris en compte la densité en pixels (et non la résolution brute).

Les tailles que vous spécifiez à l'aide de qualificatifs de ressource comme la plus petite largeur et non la taille réelle de l'écran. Au lieu de cela, les tailles indiquent la largeur ou la hauteur unités dp disponibles dans la fenêtre de votre application. Le système Android peut utiliser une partie de l'écran pour l'UI du système (comme la barre système en bas de ou sur la barre d'état située en haut), de sorte qu'une partie de l'écran disponibles pour votre mise en page. Si votre application est utilisée en mode multifenêtre, l'icône l'application n'a accès qu'à la taille de la fenêtre dans laquelle elle se trouve. Lorsque est redimensionnée, il déclenche une configuration change par la nouvelle taille de la fenêtre. permet au système de sélectionner un fichier de mise en page approprié. La ressource les tailles de qualificatifs que vous déclarez ne doivent spécifier que l'espace nécessaire à votre application. Le système tient compte de tout espace utilisé par son UI lorsqu'il fournit de l'espace pour votre mise en page.

Qualificatif de largeur disponible

Au lieu de modifier la mise en page en fonction de la plus petite largeur de l'écran, vous vous pouvez modifier la mise en page en fonction de la largeur ou de la hauteur disponible. Par exemple, vous pouvez utiliser une mise en page à deux volets chaque fois que l'écran fournit une largeur d'au moins 600 dp, qui peut varier selon que la l'appareil est en mode paysage ou portrait ; Dans ce cas, vous devez utiliser la largeur disponible comme suit:

res/layout/main_activity.xml         # For phones (smaller than 600dp available width)
res/layout-w600dp/main_activity.xml  # For 7" tablets or any screen with 600dp available width
                                     # (possibly landscape phones)

Si la hauteur disponible pose problème pour votre application, vous pouvez utiliser la qualificatif de hauteur disponible. Par exemple, layout-h600dp pour les écrans avec d'au moins 600 dp de hauteur d'écran.

Qualificatifs d'orientation

Même si vous pouvez accepter toutes les variantes de taille en n'utilisant des qualificatifs plus petite largeur et largeur disponible, vous pouvez veulent également modifier l'expérience utilisateur lorsque l'utilisateur passe du mode portrait et les orientations paysage.

Pour cela, vous pouvez ajouter les qualificatifs port ou land au répertoire de mise en page. noms. Assurez-vous simplement que les qualificatifs d'orientation sont placés après les qualificatifs de taille. Exemple :

res/layout/main_activity.xml                # For phones
res/layout-land/main_activity.xml           # For phones in landscape
res/layout-sw600dp/main_activity.xml        # For 7" tablets
res/layout-sw600dp-land/main_activity.xml   # For 7" tablets in landscape

Pour en savoir plus sur tous les qualificatifs de configuration d'écran, consultez la section App de présentation des ressources.

Classes de taille de fenêtre

Les classes de taille de fenêtre sont des points d'arrêt de fenêtre d'affichage qui vous aident à créer mises en page. Les points d'arrêt identifient la zone d'affichage disponible pour votre application comme compact, medium ou expanded. La largeur et la hauteur sont spécifiées séparément. Votre application dispose donc toujours d'une classe de taille de fenêtre pour la largeur et d'une classe de taille de fenêtre pour hauteur.

Pour appliquer des mises en page adaptatives de manière programmatique, procédez comme suit:

• Créer des ressources de mise en page en fonction des points d'arrêt de la classe de taille de fenêtre
• Calculez les classes de taille de fenêtre de largeur et de hauteur de votre application à l'aide des WindowSizeClass#compute() de Jetpack WindowManager bibliothèque
• Gonfler la ressource de mise en page pour les classes de taille de fenêtre actuelles

Pour en savoir plus, consultez la section Taille de la fenêtre classes.

Composants d'interface utilisateur modulaires à l'aide de fragments

Lorsque vous concevez votre application pour plusieurs tailles d'affichage, utilisez des fragments pour extraire votre logique d'UI en composants distincts pour vous assurer que vous n'êtes pas en dupliquant le comportement de l'interface utilisateur entre les activités. Vous pouvez ensuite combiner des fragments créer des mises en page à plusieurs volets sur les grands écrans ou placer des fragments dans des activités distinctes sur les petits écrans.

Par exemple, le modèle list-detail (voir SlidingPaneLayout ci-dessus) peuvent être implémentées avec une fragment contenant la liste et un autre fragment contenant l'élément de liste plus de détails. Sur les grands écrans, les fragments peuvent s'afficher côte à côte. sur petits écrans, individuellement, qui remplissent l'écran.

Pour en savoir plus, consultez la présentation des fragments.

Intégration d'activités

Si votre application comprend plusieurs activités, l'intégration d'activités vous permet : créer facilement une UI adaptative.

L'intégration d'activités affiche plusieurs activités ou instances de la classe même activité simultanément dans la fenêtre de tâches d'une application. Sur les grands écrans, les activités peuvent s'afficher côte à côte ; sur les petits écrans, empilés les uns sur les autres de l'autre.

Vous déterminez la manière dont votre application affiche ses activités en créant un fichier XML que le système utilise pour déterminer en fonction de la taille d'affichage. Vous pouvez aussi créer Jetpack API WindowManager appels.

L'intégration d'activités est compatible avec les changements d'orientation des appareils et les appareils pliables. des activités d'empilement et de désempilement lorsque l'appareil pivote ou se plie et se déplie.

Pour en savoir plus, consultez la page Activité représentation vectorielle continue.

Tailles d'écran et formats

Testez votre application sur différents formats et tailles d'écran pour vous assurer que votre UI évolue correctement.

Android version 10 (niveau d'API 29) ou ultérieure est compatible avec de nombreux formats. Les facteurs de forme pliables peuvent aller des écrans grands et étroits, comme 21:9 quand plié, au format carré 1:1 lorsqu'il est déplié.

Pour garantir la compatibilité avec un maximum d'appareils, testez vos applications pour autant la plupart des formats d'écran suivants:

Si vous n'avez pas accès à des appareils pour toutes les différentes tailles d'écran que vous souhaitez vous pouvez utiliser Android Emulator pour émuler presque toutes les tailles d'écran.

Si vous préférez effectuer le test sur un appareil réel, mais que vous ne l'avez pas, vous pouvez utiliser Firebase Test Lab pour accéder dans un centre de données Google.

Ressources supplémentaires

• Material Design – Comprendre la mise en page