Création de ressources pour différents écrans
Android s’exécute sur de nombreux appareils différents, chacun ayant une grande variété de résolutions, tailles d’écran et densités d’écran. Android effectue une mise à l’échelle et un redimensionnement pour que votre application fonctionne sur ces appareils, mais cela peut entraîner une expérience utilisateur sous-optimale. Par exemple, les images peuvent apparaître floues, ou elles peuvent être positionnées comme prévu sur une vue.
Concepts
Quelques termes et concepts sont importants à comprendre pour prendre en charge plusieurs écrans.
Taille de l’écran : quantité d’espace physique pour l’affichage de votre application
Densité de l’écran : nombre de pixels dans une zone donnée sur l’écran. L’unité de mesure typique est des points par pouce (ppp).
Résolution : nombre total de pixels sur l’écran. Lors du développement d’applications, la résolution n’est pas aussi importante que la taille et la densité de l’écran.
Pixels indépendants de la densité (dp) : unité virtuelle de mesure permettant aux dispositions d’être conçues indépendamment de la densité. Cette formule est utilisée pour convertir dp en pixels d’écran :
px = dp × ppp ÷ 160
Orientation : l’orientation de l’écran est considérée comme un paysage lorsqu’elle est plus large que la hauteur. En revanche, l’orientation portrait est quand l’écran est plus grand qu’il est large. L’orientation peut changer pendant la durée de vie d’une application lorsque l’utilisateur fait pivoter l’appareil.
Notez que les trois premiers de ces concepts sont liés entre eux : augmenter la résolution sans augmenter la densité augmente la taille de l’écran. Toutefois, si la densité et la résolution sont augmentées, la taille de l’écran peut rester inchangée. Cette relation entre la taille de l’écran, la densité et la résolution compliquent rapidement la prise en charge de l’écran.
Pour vous aider à gérer cette complexité, l’infrastructure Android préfère utiliser des pixels indépendants de la densité (dp) pour les dispositions d’écran. En utilisant des pixels indépendants de densité, les éléments de l’interface utilisateur semblent avoir la même taille physique sur les écrans avec des densités différentes.
Prise en charge de différentes tailles d’écran et densités
Android gère la plupart du travail pour afficher correctement les dispositions pour chaque configuration d’écran. Toutefois, il existe certaines actions qui peuvent être prises pour aider le système à sortir.
L’utilisation de pixels indépendants de la densité au lieu de pixels réels dans les dispositions est suffisante dans la plupart des cas pour garantir l’indépendance de la densité. Android met à l’échelle les dessinables au moment de l’exécution jusqu’à la taille appropriée. Toutefois, il est possible que la mise à l’échelle entraîne l’apparition de bitmaps floues. Pour contourner ce problème, fournissez d’autres ressources pour les différentes densités. Lors de la conception d’appareils pour plusieurs résolutions et densités d’écran, il s’avère plus facile de commencer avec les images de résolution ou de densité supérieures, puis de descendre en puissance.
Déclarer la taille d’écran prise en charge
La déclaration de la taille de l’écran garantit que seuls les appareils pris en charge peuvent télécharger l’application. Pour ce faire, définissez l’élément supports-écrans dans le fichier AndroidManifest.xml . Cet élément est utilisé pour spécifier les tailles d’écran prises en charge par l’application. Un écran donné est considéré comme pris en charge si l’application peut placer correctement ses dispositions pour remplir l’écran. En utilisant cet élément manifeste, l’application ne s’affiche pas dans Google Play pour les appareils qui ne répondent pas aux spécifications de l’écran. Toutefois, l’application s’exécute toujours sur des appareils avec des écrans non pris en charge, mais les dispositions peuvent apparaître floues et pixelisées.
Les six écrans pris en charge sont déclarés dans le fichier Properites/AndroidManifest.xml de la solution :
Modifiez AndroidManifest.xml pour inclure des écrans de prise en charge :
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1"
android:versionName="1.0"
package="HelloWorld.HelloWorld">
<uses-sdk android:minSdkVersion="21" android:targetSdkVersion="27" />
<supports-screens android:resizable="true"
android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true" />
<application android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true" android:theme="@style/AppTheme">
</application>
</manifest>
Fournir d’autres dispositions pour différentes tailles d’écran
D’autres dispositions permettent de personnaliser une vue pour une taille d’écran specifc, en modifiant le positionnement ou la taille des éléments de l’interface utilisateur du composant.
À compter du niveau d’API 13 (Android 3.2), les tailles d’écran sont déconseillées en faveur de l’utilisation du qualificateur swNdp. Ce nouveau qualificateur déclare la quantité d’espace nécessaire à une disposition donnée. Il est recommandé que les applications destinées à s’exécuter sur Android 3.2 ou version ultérieure utilisent ces qualificateurs plus récents.
Par exemple, si une disposition nécessitait une largeur d’écran minimale de 700 dp, la disposition alternative se trouverait dans une disposition de dossier-sw700dp :
Voici quelques nombres pour différents appareils :
Téléphone classique – 320 dp : un téléphone classique
Une tablette de 5 » / appareil « tweener » – 480 dp : par exemple la Note Samsung
Une tablette de 7 pouces – 600 dp : comme le Barnes &Noble Nook
Une tablette de 10 pouces – 720 dp : telle que le Motorola Xoom
Pour les applications qui ciblent les niveaux d’API jusqu’à 12 (Android 3.1), les dispositions doivent se trouver dans des répertoires qui utilisent les qualificateurs de taille/xlarge normale normale/comme/généralisations des différentes tailles d’écran disponibles dans la plupart des appareils. Par exemple, dans l’image ci-dessous, il existe d’autres ressources pour les quatre tailles d’écran différentes :
Voici une comparaison de la façon dont les qualificateurs de taille d’écran de niveau 13 antérieurs à l’API sont comparés aux pixels indépendants de la densité :
426 dp x 320 dp est petit
470 dp x 320 dp est normal
640 dp x 480 dp est grand
960 dp x 720 dp est xlarge
Les qualificateurs de taille d’écran plus récents au niveau de l’API 13 et supérieur ont une priorité plus élevée que les qualificateurs d’écran plus anciens des niveaux d’API 12 et inférieurs. Pour les applications qui s’étendent sur l’ancien et les nouveaux niveaux d’API, il peut être nécessaire de créer d’autres ressources à l’aide des deux ensembles de qualificateurs, comme illustré dans la capture d’écran suivante :
Fournir différentes bitmaps pour différentes densités d’écran
Bien qu’Android met à l’échelle les bitmaps si nécessaire pour un appareil, les bitmaps elles-mêmes peuvent ne pas effectuer un scale-up ou un scale-down élégant : ils peuvent devenir flous ou flous. Fournir des bitmaps appropriées pour la densité d’écran atténuera ce problème.
Par exemple, l’image ci-dessous est un exemple de problèmes de disposition et d’apparence qui peuvent se produire lorsque les ressources de spécification de densité ne sont pas fournies.
Comparez ceci à une disposition conçue avec des ressources spécifiques à la densité :
Créer des ressources de densité variables avec Android Asset Studio
La création de ces bitmaps de différentes densités peut être un peu fastidieuse. Par conséquent, Google a créé un utilitaire en ligne qui peut réduire certains des tédiums impliqués dans la création de ces bitmaps appelées Android Asset Studio.
Ce site web vous aidera à créer des bitmaps qui ciblent les quatre densités d’écran courantes en fournissant une image. Android Asset Studio crée ensuite les bitmaps avec certaines personnalisations, puis les autorise à être téléchargées en tant que fichier zip.
Conseils pour plusieurs écrans
Android s’exécute sur un nombre déroutant d’appareils, et la combinaison de tailles d’écran et de densités d’écran peut sembler écrasante. Les conseils suivants peuvent vous aider à réduire l’effort nécessaire pour prendre en charge différents appareils :
Conception et développement uniquement pour ce dont vous avez besoin – Il existe de nombreux appareils différents là-bas, mais certains existent dans de rares facteurs de forme qui peuvent prendre des efforts importants pour concevoir et développer pour. Le tableau de bord Taille et densité de l’écran est une page fournie par Google qui fournit des données sur la répartition de la matrice de densité d’écran/taille d’écran. Cette répartition fournit des informations sur l’effort de développement sur les écrans de prise en charge.
Utilisez des DPs plutôt que des pixels : les pixels deviennent gênants à mesure que la densité de l’écran change. Ne codez pas en dur les valeurs de pixels. Évitez les pixels en faveur de dp (pixels indépendants de la densité).
Évitez AbsoluteLayoutdans la mesure du possible : elle est déconseillée au niveau de l’API 3 (Android 1.5) et entraîne des dispositions fragiles. Il ne doit pas être utilisé. Au lieu de cela, essayez d’utiliser des widgets de disposition plus flexibles tels que LinearLayout, RelativeLayout ou le nouveau GridLayout.
Choisissez une orientation de disposition comme valeur par défaut : par exemple, au lieu de fournir les ressources de disposition et de port de disposition, placez les ressources pour le paysage dans la disposition et les ressources de portrait dans le port de disposition.
Utilisez LayoutParams pour hauteur et largeur : lors de la définition d’éléments d’interface utilisateur dans un fichier de disposition XML, une application Android utilisant les valeurs wrap_content et fill_parent aura plus de succès pour garantir une apparence appropriée sur différents appareils que l’utilisation d’unités indépendantes de pixels ou de densité. Ces valeurs de dimension amènent Android à mettre à l’échelle les ressources bitmap selon les besoins. Pour cette même raison, les unités indépendantes de la densité sont les mieux réservées lors de la spécification des marges et du remplissage des éléments d’interface utilisateur.
Test de plusieurs écrans
Une application Android doit être testée par rapport à toutes les configurations qui seront prises en charge. Dans l’idéal, les appareils doivent être testés sur les appareils eux-mêmes, mais dans de nombreux cas, cela n’est pas possible ou pratique. Dans ce cas, l’utilisation de l’émulateur et de la configuration des appareils virtuels Android pour chaque configuration d’appareil sera utile.
Le Kit de développement logiciel (SDK) Android fournit des apparences d’émulateur peuvent être utilisés pour créer des AVD répliqués la taille, la densité et la résolution de nombreux appareils. De nombreux fournisseurs de matériel fournissent également des peaux pour leurs appareils.
Une autre option consiste à utiliser les services d’un service de test tiers. Ces services prennent un APK, l’exécutent sur de nombreux appareils différents, puis fournissent des commentaires sur le fonctionnement de l’application.