Text Size and Different Android Screen Sizes

Text size and different android screen sizes

@forcelain I think you need to check this Google IO Pdf for Design. In that pdf go to Page No:77 in which you will find how there suggesting for using dimens.xml for different devices of android for Example see Below structure :

res/values/dimens.xml

res/values-small/dimens.xml

res/values-normal/dimens.xml

res/values-large/dimens.xml

res/values-xlarge/dimens.xml

for Example you have used below dimens.xml in values.

<?xml version="1.0" encoding="utf-8"?>
<resources>
   <dimen name="text_size">18sp</dimen>
</resources>

In other values folder you need to change values for your text size .

Note: As indicated by @espinchi the small, normal, large and xlarge have been deprecated since Android 3.2 in favor of the following:

Declaring Tablet Layouts for Android 3.2

For the first generation of tablets running Android 3.0, the proper
way to declare tablet layouts was to put them in a directory with the
xlarge configuration qualifier (for example, res/layout-xlarge/). In
order to accommodate other types of tablets and screen sizes—in
particular, 7" tablets—Android 3.2 introduces a new way to specify
resources for more discrete screen sizes. The new technique is based
on the amount of space your layout needs (such as 600dp of width),
rather than trying to make your layout fit the generalized size groups
(such as large or xlarge).

The reason designing for 7" tablets is tricky when using the
generalized size groups is that a 7" tablet is technically in the same
group as a 5" handset (the large group). While these two devices are
seemingly close to each other in size, the amount of space for an
application's UI is significantly different, as is the style of user
interaction. Thus, a 7" and 5" screen should not always use the same
layout. To make it possible for you to provide different layouts for
these two kinds of screens, Android now allows you to specify your
layout resources based on the width and/or height that's actually
available for your application's layout, specified in dp units.

For example, after you've designed the layout you want to use for
tablet-style devices, you might determine that the layout stops
working well when the screen is less than 600dp wide. This threshold
thus becomes the minimum size that you require for your tablet layout.
As such, you can now specify that these layout resources should be
used only when there is at least 600dp of width available for your
application's UI.

You should either pick a width and design to it as your minimum size,
or test what is the smallest width your layout supports once it's
complete.

Note: Remember that all the figures used with these new size APIs are
density-independent pixel (dp) values and your layout dimensions
should also always be defined using dp units, because what you care
about is the amount of screen space available after the system
accounts for screen density (as opposed to using raw pixel
resolution). For more information about density-independent pixels,
read Terms and concepts, earlier in this document. Using new size
qualifiers

The different resource configurations that you can specify based on
the space available for your layout are summarized in table 2. These
new qualifiers offer you more control over the specific screen sizes
your application supports, compared to the traditional screen size
groups (small, normal, large, and xlarge).

Note: The sizes that you specify using these qualifiers are not the
actual screen sizes. Rather, the sizes are for the width or height in
dp units that are available to your activity's window. The Android
system might use some of the screen for system UI (such as the system
bar at the bottom of the screen or the status bar at the top), so some
of the screen might not be available for your layout. Thus, the sizes
you declare should be specifically about the sizes needed by your
activity—the system accounts for any space used by system UI when
declaring how much space it provides for your layout. Also beware that
the Action Bar is considered a part of your application's window
space, although your layout does not declare it, so it reduces the
space available for your layout and you must account for it in your
design.

Table 2. New configuration qualifiers for screen size (introduced in
Android 3.2). Screen configuration Qualifier values Description
smallestWidth swdp

Examples: sw600dp sw720dp

The fundamental size of a screen, as indicated by the shortest
dimension of the available screen area. Specifically, the device's
smallestWidth is the shortest of the screen's available height and
width (you may also think of it as the "smallest possible width" for
the screen). You can use this qualifier to ensure that, regardless of
the screen's current orientation, your application's has at least
dps of width available for its UI.

For example, if your layout requires that its smallest dimension of
screen area be at least 600 dp at all times, then you can use this
qualifier to create the layout resources, res/layout-sw600dp/. The
system will use these resources only when the smallest dimension of
available screen is at least 600dp, regardless of whether the 600dp
side is the user-perceived height or width. The smallestWidth is a
fixed screen size characteristic of the device; the device's
smallestWidth does not change when the screen's orientation changes.

The smallestWidth of a device takes into account screen decorations
and system UI. For example, if the device has some persistent UI
elements on the screen that account for space along the axis of the
smallestWidth, the system declares the smallestWidth to be smaller
than the actual screen size, because those are screen pixels not
available for your UI.

This is an alternative to the generalized screen size qualifiers
(small, normal, large, xlarge) that allows you to define a discrete
number for the effective size available for your UI. Using
smallestWidth to determine the general screen size is useful because
width is often the driving factor in designing a layout. A UI will
often scroll vertically, but have fairly hard constraints on the
minimum space it needs horizontally. The available width is also the
key factor in determining whether to use a one-pane layout for
handsets or multi-pane layout for tablets. Thus, you likely care most
about what the smallest possible width will be on each device.
Available screen width wdp

Examples: w720dp w1024dp

Specifies a minimum available width in dp units at which the resources
should be used—defined by the value. The system's corresponding
value for the width changes when the screen's orientation switches
between landscape and portrait to reflect the current actual width
that's available for your UI.

This is often useful to determine whether to use a multi-pane layout,
because even on a tablet device, you often won't want the same
multi-pane layout for portrait orientation as you do for landscape.
Thus, you can use this to specify the minimum width required for the
layout, instead of using both the screen size and orientation
qualifiers together. Available screen height hdp

Examples: h720dp h1024dp etc.

Specifies a minimum screen height in dp units at which the resources
should be used—defined by the value. The system's corresponding
value for the height changes when the screen's orientation switches
between landscape and portrait to reflect the current actual height
that's available for your UI.

Using this to define the height required by your layout is useful in
the same way as wdp is for defining the required width, instead of
using both the screen size and orientation qualifiers. However, most
apps won't need this qualifier, considering that UIs often scroll
vertically and are thus more flexible with how much height is
available, whereas the width is more rigid.

While using these qualifiers might seem more complicated than using
screen size groups, it should actually be simpler once you determine
the requirements for your UI. When you design your UI, the main thing
you probably care about is the actual size at which your application
switches between a handset-style UI and a tablet-style UI that uses
multiple panes. The exact point of this switch will depend on your
particular design—maybe you need a 720dp width for your tablet layout,
maybe 600dp is enough, or 480dp, or some number between these. Using
these qualifiers in table 2, you are in control of the precise size at
which your layout changes.

For more discussion about these size configuration qualifiers, see the
Providing Resources document. Configuration examples

To help you target some of your designs for different types of
devices, here are some numbers for typical screen widths:

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

Using the size qualifiers from table 2, your application can switch
between your different layout resources for handsets and tablets using
any number you want for width and/or height. For example, if 600dp is
the smallest available width supported by your tablet layout, you can
provide these two sets of layouts:

res/layout/main_activity.xml # For handsets
res/layout-sw600dp/main_activity.xml # For tablets

In this case, the smallest width of the available screen space must be
600dp in order for the tablet layout to be applied.

For other cases in which you want to further customize your UI to
differentiate between sizes such as 7” and 10” tablets, you can define
additional smallest width layouts:

res/layout/main_activity.xml # For handsets (smaller than
600dp available width) res/layout-sw600dp/main_activity.xml # For 7”
tablets (600dp wide and bigger) res/layout-sw720dp/main_activity.xml

For 10” tablets (720dp wide and bigger)

Notice that the previous two sets of example resources use the
"smallest width" qualifier, swdp, which specifies the smallest of
the screen's two sides, regardless of the device's current
orientation. Thus, using swdp is a simple way to specify the
overall screen size available for your layout by ignoring the screen's
orientation.

However, in some cases, what might be important for your layout is
exactly how much width or height is currently available. For example,
if you have a two-pane layout with two fragments side by side, you
might want to use it whenever the screen provides at least 600dp of
width, whether the device is in landscape or portrait orientation. In
this case, your resources might look like this:

res/layout/main_activity.xml # For handsets (smaller than
600dp available width) res/layout-w600dp/main_activity.xml #
Multi-pane (any screen with 600dp available width or more)

Notice that the second set is using the "available width" qualifier,
wdp. This way, one device may actually use both layouts, depending
on the orientation of the screen (if the available width is at least
600dp in one orientation and less than 600dp in the other
orientation).

If the available height is a concern for you, then you can do the same
using the hdp qualifier. Or, even combine the wdp and hdp
qualifiers if you need to be really specific.

Android TextView size in different screen size

I already try to set it as 'dp' or 'sp'. You must use sp .

You can use this logic .

DisplayMetrics: A structure describing general information about a
display, such as its size, density, and font scaling.

   DisplayMetrics metrics = getResources().getDisplayMetrics();

   int DeviceTotalWidth = metrics.widthPixels;
   int DeviceTotalHeight = metrics.heightPixels;

   TextViewObj.setTextSize(DeviceTotalWidth/8); // As per your Requirement 

You can check How to change TextView font size in android

Change Text size according to screen programatically

Hello guys I found the answer

This awesome library will help everyone do it https://github.com/intuit/sdp

No need for many dimens or many layouts you just need this

How to dynamically adjust text size and margins for different screen sizes?

You can different size for your tex using values-[smallestWidth].

SW : The fundamental size of a screen, as indicated by the shortest dimension of the available screen area. Specifically, the device's smallestWidth is the shortest of the screen's available height and width (you may also think of it as the "smallest possible width" for the screen). You can use this qualifier to ensure that, regardless of the screen's current orientation, your application's has at least dps of width available for it UI.

Example:
Let's confider 3 type different layout , small , medium , large

values       : <dimen name="text_size">10sp</dimen>
values-sw375 : <dimen name="text_size">11sp</dimen>
values-sw600 : <dimen name="text_size">18sp</dimen>

How to change the font size according to the screen size in android if I set the font sizes according to a specific phone?

You first need to get the screen size ratio between iPhone 11 and the phone on which the app is running. Define a static variable in your MainActivity:

private static double SCREEN_SIZE_RATIO;

Then get iPhone 11's screen size. Don't use the raw dimensions because they don't take into account the fact that the screen does not cover the entire phone. Instead, take the pixel resolution and divide it by the ppi. Calculate iPhone 11's diagonal length and your target phone's diagonal length, and divide the latter by the former to get the screen size ratio.

private void calculateScreenSizeRatio() {
    double iphone11Width = ((double) 828) / ((double) 326); // Values from https://www.apple.com/iphone-11/specs/
    double iphone11Height = ((double) 1792) / ((double) 326);
    double iphone11Diagonal = Math.hypot(iphone11Width, iphone11Height);

    DisplayMetrics displayMetrics = getResources().getDisplayMetrics();
    double screenWidthPixels = displayMetrics.widthPixels;
    double screenHeightPixels = displayMetrics.heightPixels;
    double screenWidth = screenWidthPixels / displayMetrics.xdpi;
    double screenHeight = screenHeightPixels / displayMetrics.ydpi;
    double screenDiagonal = Math.hypot(screenWidth, screenHeight);

    SCREEN_SIZE_RATIO = screenDiagonal / iphone11Diagonal;
}

Note that when calculating the diagonal length, the ratio of height-to-width is not taken into account, which introduces a slight inaccuracy.

Now, write a static function to get the font size (which was originally defined in the .xml), multiply it by the screen size ratio, and set the result to the new font size.

public static void setTextSize(TextView view) {
    view.setTextSize(TypedValue.COMPLEX_UNIT_PX, (float) (view.getTextSize() * SCREEN_SIZE_RATIO));
}

The getTextSize() function returns the size in pixels, that's why we set the size in pixels (using TypedValue.COMPLEX_UNIT_PX). Remember that both EditText and Button subclass from TextView, so this function can also be used for EditTexts and Buttons.

In your MainActivity, write a function similar to the following:

private void setTextSizes() {
    setTextSize(emailEditText);
    setTextSize(passwordEditText);
    setTextSize(logInButton);
    setTextSize(registerTextView);
    setTextSize(invalidTextView);
    setTextSize((TextView) findViewById(R.id.text_view_no_account));
}

In other activities, write a function similar to the following:

private void setTextSizes() {
    MainActivity.setTextSize(amountEditText);
    MainActivity.setTextSize((TextView) findViewById(R.id.edit_text_payment_method));
    MainActivity.setTextSize((TextView) findViewById(R.id.add_button));
    MainActivity.setTextSize(creditDebitCardTextView);
    MainActivity.setTextSize(bankTransferTextView);
}

You can put any of your TextViews, EditTexts and Buttons in this function. Remember to cast your EditTexts and Buttons to (TextView) when using findViewbyId(), as I've done with edit_text_payment_method and add_button in the second code snippet.

Finally call setTextSizes() in onCreate() in each of your acivities, preferably after you have assigned the class variables.

How to make TextView's text size based on device screen size in android

I had the same issue and I used this library and it did the thing for me.

The thing is you just have to replace sp with ssp in your xml after adding this library in your gradle and you'll be good to go.

---

Related Topics