Replacing global fonts in a rough way in Android

[[204795]]

sequence

Using custom fonts on Android is a common requirement, and we have done some in-depth research on this recently.

As usual, I'm going to write another article about font modification on Android, but I found that there is a lot of content, so I decided to split it up and explain it in several articles (maybe five articles). It will mainly introduce some commonly used font replacement solutions, and finally some global replacement solutions, and of course it will also include the "Fonts in XML" solution of ***.

Looking forward to your continued attention.

This is the second article in this series. If you are interested, you can take a look at the articles that have been published before.

Android font modification overview | opening chapter

Modifying fonts requires understanding all the details of Typeface

1. Introduction

We have analyzed all the details of modifying fonts and the Typeface class related to font modification. Next, we will discuss how to modify the global font.

This article will first introduce two rough ways to modify the global font.

2. Custom Controls

When starting a new project, it is usually a good idea to define a BaseActivity and BaseFragment as the base class of the page, so that we can add some unified logic to all pages later.

However, no one would think of defining a custom control implementation for all controls in advance.

However, if you have considered the need to modify the font in the early stage of development, you can rewrite some font display related controls to achieve the effect of global font replacement.

In Android, the most commonly used control for displaying fonts is TextView. Here we rewrite a TextView to achieve the effect of replacing the font.

In TextView, you can set a font for TextView through the setTypeface() method. The setTypeface() method has two overloaded methods, which simply pass an additional textStyle that needs to be set to mark bold and italic.

In fact, in the end, it all calls a parameter setTypeface (, which is the key to the setting.

As you can see, setting the font actually operates mTextPaint. mTextPaint is an object of the TextPaint class, which directly inherits from Paint and is a brush used to draw text.

Then, we can directly customize a TextView and modify the font of TextView through the setTypeface() method in the constructor.

The main code is as follows:

Note that we also need to consider the textStyle property set for the FontTextView we set in the layout, which may be bold or italic.

Usually, designers will choose a font to consider the unity and coordination of the App UI, so there is no big problem in encapsulating the font to be replaced in FontTextView.

Let's verify the effect of the implementation. Here, a special font is specially selected. In the layout xml file, add three FontTextView.

Let's take a look at the effect of operation.

The textStyle set in the layout is also taken into account here, and an already slanted font becomes more slanted after using the italic tag.

This method is acceptable in the early stages of development. The only difference is that when writing the layout, you need to pay attention to using custom controls. In addition to TextView, you also need to rewrite a series of controls that need to display text, such as Button and EditText. In the final analysis, it is still a bit troublesome.

Moreover, if this solution is used on an already mature project, it is still very difficult to make changes. Basically, it is just a text replacement, and the changes will be relatively large.

3. Traversing ViewTree

In Android, controls for displaying text are directly or indirectly integrated from TextView. So we just need to find a suitable time, traverse the layout's ViewTree, get all the subclasses of TextView, and then modify their fonts in batches, which can also achieve the effect of global replacement.

In this replaceCustomFont() method, it goes back to determine whether it inherits from TextView. If so, it replaces the font. If not, it determines whether it is a ViewGroup. If so, it takes out all the child Views from it and recursively calls the replaceCustomFont() method.

Usually, in order to modify the font at the right time, we can add this method after the Activity.onCreate() method or the Fragment.onCreateView() method. There are relatively few places to modify, but we also need to consider the logic of dynamically generated Views such as ListView and RecyclverView, and we also need to be careful not to omit them.

For example, write a layout and call the replaceCustomFont() method in the Activity.onCreate() method.

***The effects shown are as follows.

The advantage of this method is that you don't need to modify the XML layout or rewrite multiple controls. You only need to call the replaceCustomFont() method after the Inflater View.

The disadvantages are also very obvious. Every page needs to be modified, and places with dynamically loaded Views may be missed. Compared with the previous solution, the changes are slightly less. It also violates the design principles of components and the implementation method is a bit rough. At the same time, it recursively traverses the ViewTree every time, which will have some impact on performance.

IV. Summary

The methods introduced in this article may not be used in actual development. However, this does not affect our understanding of such methods.

[This article is an original article by 51CTO columnist "Zhang Yang". Please contact the author through WeChat official account to obtain authorization for reprinting]

Click here to read more articles by this author