@forcelain Je pense que vous devez vérifier ce PDF IO Pdf pour la conception . Dans ce pdf, allez à la page n ° 77 dans laquelle vous trouverez comment il est suggéré d’utiliser dimens.xml pour différents appareils d’android pour l’exemple voir structure ci-dessous:

 res/values/dimens.xml res/values-small/dimens.xml res/values-normal/dimens.xml res/values-large/dimens.xml res/values-xlarge/dimens.xml 

Par exemple, vous avez utilisé sous dimens.xml dans des valeurs.

   18sp  

Dans d’autres dossiers de valeurs, vous devez modifier les valeurs de la taille de votre texte.

Note: Comme indiqué par @espinchi, les petites, normales, grandes et xlarge sont obsolètes depuis Android 3.2 en faveur de ce qui suit:

Déclaration des dispositions de la tablette pour Android 3.2

Pour la première génération de tablettes fonctionnant sous Android 3.0, la manière appropriée de déclarer les mises en forme de tablette était de les placer dans un répertoire avec le qualificatif de configuration xlarge (par exemple, res / layout-xlarge /). Afin de prendre en charge d’autres types de tablettes et de tailles d’écran, en particulier les tablettes 7 pouces, Android 3.2 introduit une nouvelle façon de spécifier des ressources pour des tailles d’écran plus discrètes. La nouvelle technique repose sur la quantité d’espace requirejse 600dp de largeur), plutôt que d’essayer de faire en sorte que votre mise en page corresponde aux groupes de taille généralisés (tels que large ou xlarge).

La raison pour laquelle les tablettes de 7 pouces sont conçues avec des groupes de tailles généralisées est qu’une tablette de 7 pouces est techniquement dans le même groupe que les combinés de 5 pouces (le groupe de grande taille). La quantité d’espace pour l’interface utilisateur d’une application est très différente, de même que le style d’interaction utilisateur. Ainsi, un écran de 7 “et 5” ne doit pas toujours utiliser la même mise en page. Deux types d’écrans, Android vous permet désormais de spécifier vos ressources de mise en page en fonction de la largeur et / ou de la hauteur réellement disponible pour la mise en page de votre application, spécifiée en unités dp.

Par exemple, après avoir conçu la mise en page que vous souhaitez utiliser pour les périphériques de type tablette, vous pouvez déterminer que la mise en page ne fonctionne plus correctement lorsque l’écran mesure moins de 600dp de large. Ce seuil devient ainsi la taille minimale requirejse pour la mise en page de votre tablette. En tant que tel, vous pouvez maintenant spécifier que ces ressources de mise en page doivent être utilisées uniquement lorsque la largeur de l’interface graphique de votre application est d’au moins 600dp.

Vous devez choisir une largeur et la définir comme votre taille minimale, ou tester la plus petite largeur prise en charge par votre mise en page une fois terminée.

Remarque: N’oubliez pas que tous les chiffres utilisés avec ces API de nouvelle taille sont des valeurs de pixels (dp) indépendantes de la densité et que les dimensions de votre mise en page doivent toujours être définies à l’aide des unités dp. compte pour la densité de l’écran (par opposition à la résolution des pixels bruts). Pour plus d’informations sur les pixels indépendants de la densité, lisez Termes et concepts, plus haut dans ce document. Utilisation de nouveaux qualificatifs de taille

Les différentes configurations de ressources que vous pouvez spécifier en fonction de l’espace disponible pour votre mise en page sont résumées dans le tableau 2. Ces nouveaux qualificateurs vous permettent de mieux contrôler les tailles d’écran que votre application prend en charge par rapport aux groupes de taille d’écran traditionnels (petit, normal, large et xlarge).

Remarque: Les tailles que vous spécifiez à l’aide de ces qualificatifs ne sont pas les tailles d’écran réelles. Les tailles correspondent plutôt à la largeur ou à la hauteur en unités dp disponibles dans la fenêtre de votre activité. Le système Android peut utiliser une partie de l’écran de l’interface utilisateur du système (telle que la barre système en bas de l’écran ou la barre d’état en haut), de sorte qu’une partie de l’écran peut ne pas être disponible pour votre mise en page. Ainsi, les tailles que vous déclarez doivent porter spécifiquement sur les tailles requirejses par votre activité: le système prend en compte l’espace utilisé par l’interface utilisateur lors de la déclaration de la quantité d’espace fournie pour votre mise en page. Méfiez-vous également du fait que la barre d’action est considérée comme faisant partie de l’espace de la fenêtre de votre application, bien que votre mise en page ne la déclare pas, réduisant ainsi l’espace disponible pour votre mise en page.

Tableau 2. Nouveaux qualificateurs de configuration pour la taille de l’écran (introduits dans Android 3.2). Configuration de l’écran Valeurs du qualificateur Description smallestWidth swdp

Exemples: sw600dp sw720dp

La taille fondamentale d’un écran, indiquée par la plus petite dimension de la zone d’écran disponible. Plus précisément, la plus petite largeur de périphérique est la plus courte de la hauteur et de la largeur disponibles de l’écran (vous pouvez également la considérer comme la “plus petite largeur possible” pour l’écran). Vous pouvez utiliser ce qualificatif pour vous assurer que, quelle que soit l’orientation actuelle de l’écran, votre application dispose d’au moins une largeur de bande disponible pour son interface utilisateur.

Par exemple, si votre mise en page nécessite que sa plus petite dimension de zone d’écran soit d’au moins 600 dp à tout moment, vous pouvez utiliser ce qualificatif pour créer les ressources de mise en page res / layout-sw600dp /. Le système utilisera ces ressources uniquement lorsque la plus petite dimension de l’écran disponible est d’au moins 600dp, que le côté 600dp soit la hauteur ou la largeur perçue par l’utilisateur. La plus petite largeur est une caractéristique de taille d’écran fixe du périphérique; La plus petite largeur de l’appareil ne change pas lorsque l’orientation de l’écran change.

La plus petite largeur d’un périphérique prend en compte les décorations d’écran et l’interface utilisateur du système. Par exemple, si certains éléments d’interface utilisateur persistante de l’écran représentent de l’espace le long de l’axe de la plus petite largeur, le système déclare que la plus petite largeur est inférieure à la taille réelle de l’écran.

Ceci est une alternative aux qualificateurs de taille d’écran généralisés (petit, normal, grand, xlarge) qui vous permettent de définir un nombre discret pour la taille effective disponible pour votre interface utilisateur. L’utilisation de smallestWidth pour déterminer la taille d’écran générale est utile car la largeur est souvent le facteur déterminant dans la conception d’une mise en page. Une interface utilisateur défile souvent verticalement, mais impose des contraintes assez difficiles sur l’espace minimum dont elle a besoin horizontalement. La largeur disponible est également le facteur clé pour déterminer si une disposition à un volet doit être utilisée pour les combinés ou la disposition à plusieurs volets pour les tablettes. Ainsi, vous vous souciez probablement de la plus petite largeur possible sur chaque appareil. Largeur d’écran disponible wdp

Exemples: w720dp w1024dp

Spécifie une largeur minimale disponible en unités dp à laquelle les ressources doivent être utilisées, définies par la valeur. La valeur correspondante du système pour la largeur change lorsque l’orientation de l’écran bascule entre paysage et portrait pour refléter la largeur réelle actuelle disponible pour votre interface utilisateur.

Cela est souvent utile pour déterminer s’il faut utiliser une disposition à plusieurs volets, car même sur une tablette, vous ne voudrez pas forcément utiliser la même disposition à plusieurs volets pour l’orientation portrait que pour le paysage. Ainsi, vous pouvez l’utiliser pour spécifier la largeur minimale requirejse pour la mise en page, au lieu d’utiliser à la fois la taille de l’écran et les qualificateurs d’orientation. Hauteur d’écran disponible hdp

Exemples: h720dp h1024dp etc.

Spécifie une hauteur d’écran minimale en unités dp à laquelle les ressources doivent être utilisées, définies par la valeur. La valeur correspondante du système pour la hauteur change lorsque l’orientation de l’écran bascule entre paysage et portrait pour refléter la hauteur réelle actuelle disponible pour votre interface utilisateur.

Utiliser ceci pour définir la hauteur requirejse par votre mise en page est utile de la même manière que wdp pour définir la largeur requirejse, au lieu d’utiliser à la fois la taille de l’écran et les qualificateurs d’orientation. Cependant, la plupart des applications n’auront pas besoin de ce qualificatif, étant donné que les interfaces utilisateur défilent souvent verticalement et sont donc plus flexibles en termes de hauteur disponible, tandis que la largeur est plus rigide.

Bien que l’utilisation de ces qualificatifs puisse sembler plus compliquée que l’utilisation de groupes de taille d’écran, il devrait être plus simple une fois que vous aurez déterminé les exigences de votre interface utilisateur. Lorsque vous concevez votre interface utilisateur, la principale préoccupation est la taille réelle de votre application entre une interface utilisateur de type combiné et une interface utilisateur de type tablette utilisant plusieurs volets. Le point exact de ce commutateur dépendra de votre conception particulière. Peut-être avez-vous besoin d’une largeur de 720dp pour la disposition de votre tablette, peut-être 600dp ou 480dp, ou d’un nombre entre eux. En utilisant ces qualificatifs dans le tableau 2, vous contrôlez la taille exacte à laquelle votre disposition change.

Pour plus d’informations sur ces qualificateurs de configuration de la taille, consultez le document Ressources fournissant. Exemples de configuration

Pour vous aider à cibler certains de vos designs pour différents types de périphériques, voici quelques chiffres pour les largeurs d’écran typiques:

 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). 

En utilisant les qualificatifs de taille de la table 2, votre application peut basculer entre vos différentes ressources de mise en page pour les combinés et les tablettes en utilisant n’importe quel nombre souhaité pour la largeur et / ou la hauteur. Par exemple, si 600dp est la plus petite largeur disponible prise en charge par la disposition de votre tablette, vous pouvez fournir ces deux ensembles de mises en page:

res / layout / main_activity.xml # Pour les combinés res / layout-sw600dp / main_activity.xml # Pour les tablettes

Dans ce cas, la plus petite largeur de l’espace d’écran disponible doit être de 600dp pour que la disposition de la tablette soit appliquée.

Pour les autres cas dans lesquels vous souhaitez personnaliser davantage votre interface utilisateur afin de différencier les tailles telles que les tablettes de 7 et 10 pouces, vous pouvez définir des dispositions de plus petite largeur supplémentaires:

res / layout / main_activity.xml # Pour les combinés (largeur inférieure à 600dp disponible) res / layout-sw600dp / main_activity.xml # Pour les tablettes de 7 ”(600d de large et plus) res / layout-sw720dp / main_activity.xml

Pour tablettes de 10 “(720dp de large et plus grandes)

Notez que les deux ensembles précédents de ressources exemple utilisent le qualificatif «plus petite largeur», swdp, qui spécifie le plus petit des deux côtés de l’écran, quelle que soit l’orientation actuelle du périphérique. Ainsi, l’utilisation de swdp est un moyen simple de spécifier la taille d’écran globale disponible pour votre mise en page en ignorant l’orientation de l’écran.

Cependant, dans certains cas, ce qui peut être important pour votre mise en page est exactement la largeur ou la hauteur actuellement disponible. Par exemple, si vous disposez d’une mise en page à deux volets avec deux fragments côte à côte, vous souhaiterez peut-être l’utiliser lorsque l’écran fournit une largeur d’au moins 600dp, que le périphérique soit en mode paysage ou portrait. Dans ce cas, vos ressources peuvent ressembler à ceci:

res / layout / main_activity.xml # Pour les combinés (largeur inférieure à 600dp disponible) res / layout-w600dp / main_activity.xml # Multi-volet (tout écran avec une largeur disponible de 600dp ou plus)

Notez que le second ensemble utilise le qualificatif “largeur disponible”, wdp. De cette façon, un appareil peut réellement utiliser les deux dispositions, en fonction de l’orientation de l’écran (si la largeur disponible est d’au moins 600dp dans une orientation et inférieure à 600dp dans l’autre orientation).

Si la hauteur disponible vous préoccupe, vous pouvez faire la même chose en utilisant le qualificatif hdp. Vous pouvez même combiner les qualificatifs wdp et hdp si vous devez être vraiment spécifique.

Je pense qu’il est trop tard pour répondre sur ce sujet. Mais je voudrais partager mon idée ou mon moyen de résoudre le problème de la taille du texte sur les périphériques de résolution différentielle. De nombreux sites de développeurs Android suggèrent que nous devions utiliser l’unité sp pour la taille du texte, ce qui permettrait de gérer la taille du texte pour les périphériques de résolution différentielle. Mais je suis toujours incapable d’obtenir le résultat souhaité. J’ai donc trouvé une solution que j’utilise de mes 4 à 5 derniers projets et que cela fonctionne très bien. Selon ma suggestion, vous devez placer la taille du texte pour chaque périphérique de résolution, ce qui est un travail fastidieux, mais qui répondra à vos besoins. Chaque développeur doit écouter le rapport comme 4: 6: 8: 12 (h: xh: xxh: xxxh respectivement) . Maintenant, dans votre dossier de projet, vous devez créer 4 dossiers avec un fichier dimens, par ex.

1. res / values-hdpi / dimens.xml
2. res / values-xhdpi / dimens.xml
3. res / values-xxhdpi / dimens.xml
4. res / values-xxxhdpi / dimens.xml

Maintenant, dans le fichier dimens.xml, vous devez placer des tailles de texte. Je vous montre le code pour values-hdpi , de même vous devez placer le code pour d’autres valeurs de résolution / fichier dimens.xml.

   4px  

Pour les autres résolutions, c’est comme xhdpi : 6px, xxhdpi : 8px, xxxhdpi : 12px. Ceci est calculé avec le ratio (3: 4: 6: 8: 12) que j’ai écrit ci-dessus. Discutons d’autres exemples de taille de texte avec le ratio ci-dessus. Si vous voulez prendre la taille de texte de 12px dans hdpi, alors dans une autre résolution, il serait

1. hdpi: 12px
2. xhdpi: 18px
3. xxhdpi: 24px
4. xxxhdpi: 36px

C’est la solution simple pour implémenter la taille de texte requirejse pour toutes les résolutions. Je ne considère pas les périphériques de résolution de valeurs-mdpi ici. Si quelqu’un veut inclure la taille du texte pour cette résolution, alors la ration est comme 3: 4: 6: 8: 12 . Dans toute requête s’il vous plaît faites le moi savoir. J’espère que ça va vous aider.

J’ai fait la même chose par dimension et peindre quelque chose comme (avec dp mais seulement pour le texte et dans drawText ())

XML:

  30sp 

Code:

  Paint p =new Paint(); p.setTextSize(getResources().getDimension(R.dimen.text_Size)); 

Parfois, il vaut mieux n’avoir que trois options

  style="@android:style/TextAppearance.Small" 

Utilisez petit et grand pour différencier de la taille de l’écran normal.

Pour la normale, vous n’avez rien à spécifier.

Grâce à cela, vous pouvez éviter de tester et de spécifier des dimensions pour différentes tailles d’écran.

Je pense que vous pouvez archiver cela en ajoutant plusieurs ressources de mise en page pour chaque taille d’écran, par exemple:

 res/layout/my_layout.xml // layout for normal screen size ("default") res/layout-small/my_layout.xml // layout for small screen size with small text res/layout-large/my_layout.xml // layout for large screen size with larger text res/layout-xlarge/my_layout.xml // layout for extra large screen size with even larger text res/layout-xlarge-land/my_layout.xml // layout for extra large in landscape orientation 

Référence: 1. http://developer.android.com/guide/practices/screens_support.html

Tout le monde peut utiliser la bibliothèque Android mentionnée ci-dessous, qui est le moyen le plus simple de rendre les tailles de texte compatibles avec presque tous les écrans de périphériques. Il a été développé sur la base de nouveaux qualificatifs de configuration Android pour la taille de l’écran (introduite dans Android 3.2).

https://github.com/intuit/sdp

Pour unifier tous les écrans afin d’afficher les mêmes tailles d’éléments, y compris la taille de police: – Concevez l’UI sur une taille d’écran avec les tailles appropriées pendant la conception, c.-à-d.

• Calculer par programme la taille d’écran physique des autres téléphones, par exemple 5’2 pouces d’autres téléphones / écrans.

• Utilisez une formule pour calculer la différence de pourcentage entre les 2 écrans. c’est à dire quelle est la différence de% entre 4’6 et 5’2.

• Calculez la différence de pixels entre les 2 TextViews sur la base de la formule ci-dessus.

• Obtenez la taille réelle (en pixels) de la police de caractère TextView et appliquez la différence de pixels (calculée précédemment) à la taille de police par défaut.

De cette façon, vous pouvez appliquer des proportions dynamics à toutes les tailles d’écran et le résultat est excellent. Vous aurez une disposition et des tailles identiques sur chaque écran.

Cela peut être un peu délicat au début, mais atteint l’objective une fois que vous avez trouvé la formule. Avec cette méthode, vous n’avez pas besoin de faire plusieurs mises en page pour s’adapter à différentes tailles d’écran.

Ne pas coder en dur les tailles.

Pour plus de flexibilité et de nouvelles résolutions d’écran, la meilleure pratique est de placer TextView factice dans la mise en page pour obtenir la taille du texte:

Et dans votre code par exemple:

 TextView testTextView = (TextView) rootView.findViewById(R.id.dummyTextView); float textSize = testTextView.getTextSize(); 

Gardez textSize comme référence à laquelle vous pouvez append une taille constante ou percetage (en calculant).

Comme @espinchi mentionné à partir de 3.2 (API niveau 13), les groupes de taille sont obsolètes. Les gammes de taille d’écran sont l’approche privilégiée à l’avenir.