Fonts have always been a vital part of brand identity and UI design. With the development of modern Web standards it has become easy to implement customized fonts in websites, but native mobile apps somehow still lag behind in this area. Platform guides warn us against unleashing our creativity in that aspect and state that the built-in fonts have been optimized for memory and performance constraints of mobile devices. I think today, with more and more horse power under the hood of our latest mobile gadgets, we should not limit ourselves to the modest assortment of default typefaces.
Going the hard way
Using custom fonts in Android is not that straightforward. In TextViews, for instance, there is the fontFamily tag, but it only lets you pick one of the built-in typefaces. You can call setTypeface() for each TextView, but this is cumbersome to say the least. The most popular approach is to define your own tag that inherits from the TextView. Then you can even have a global setting for the typeface, but you still have to manually replace all the TextViews in your app with this new tag (and there will be no fewer than hundreds of them). You’ll also have to implement and replace all the other views that use texts, like EditText, Button and many more. And lastly, beware of calling Typeface.createFromAsset() for each text instance as your app will literally explode at some point. Does all this sound encouraging?..
If you google for “custom fonts in Android”, you’ll find lots of recipes on stackoverflow.com. If you want to take the long path of either manually implementing custom fonts in your app or trying a dozen of different libraries out there, go ahead. But if you simply don’t have that time, keep reading. I’ve been there, done that. Find out what I discovered.
As you may already know, I’m a big fan of simple and elegant solutions that still allow customization. My winner is Christopher Jenkins’ Calligraphy library (https://github.com/chrisjenx/Calligraphy). Here’s why:
You don’t have to introduce your own overridden TextView component, you use the built-in TextView.
You can easily include the library using gradle.
The library doesn’t limit your choice of fonts; you just add your preferred ones to the assets directory.
Not only do you get custom text views — all the other text-based Android components will also be displayed using your preferred font.
And why it’s elegant? Below’s everything you need to do to use a custom font in your app.
Add the library in gradle’s dependencies section:
Place custom font(s) in the assets/fonts directory of your app.
Override the default Application class and initialize Calligraphy with your default font:
And you’re good to go. Every text in your app will use the custom font. If you want some of the views to use a different font, use android:fontFamily="fonts/your-other-font.ttf" or define a separate style for that (see Calligraphy documentation on GitHub).
Weigh your fonts
Sometimes, when it’s all that simple, we tend to turn off caution and lose our common sense. When there are fast-food booths all over the city, we devour juicy hamburgers every day for launch and — to our inexplicable surprise — get fat. Custom fonts can also make our apps chubby. Firstly, a good UI design should include no more than one or two typefaces, otherwise your apps will look like those glittering toys on a chinatown market. Secondly, if you find your favorite font larger than hundred-and-something kilobytes… hold on and think.
One reason might be that your font is made of overly complex glyphs (elementary symbols) that are just not made for small screen and limited memory. Always begin selecting your fonts with displaying them with the planned size on a real device. If they’re hard to read, find something less elaborate. Remember that mobile users are always on the go, so the contents have to be legible and clear. But that’s a designer’s job.
Way more often a font is fatty because it contains hundreds or thousands of glyphs for many different languages. It’s nice that a font designer has created Cyrillic, Greek, Hebrew, Arabic and Chinese variants and put them in one ttf/otf file, but do you really need them all in your app? If you don’t plan to localize it to some or any of these languages, cherry-pick the glyphs you need (it’s called font subsetting). To do that, you can use FontForge, an open-source app for manipulating fonts. It is free, versatile, but also ugly and hard to use. Subsetting is not an easy task with FontForge as you have to manually delete the glyphs you don’t need. My favorite here is fontsquirrel @font-face generator — a web-based app that lets you upload the font, show the number of glyphs contained in the font definition and, more importantly, allows you to pick the Unicode tables (character sets) you want to limit your font to (switch to the expert mode to do that). Then you just download the subsetted font file and find out that it shrunk from, say, 1 MB to 50 kilobytes. Voila! (By the way, you can follow the same procedure to slim down your Web pages and conserve bandwidth.)
Finally, don’t forget to make sure that the cost of using a custom font is not too high performance-wise. Get one of the older devices you target your app at, use your preferred profiling tool and check memory and CPU usage before and after implementing the new typeface.
Last but not least — copyright
It’s obvious that you have to observe intellectual property of the font maker, so read the legal notices and decide whether they allow you to use the font for free. Keep in mind that a well-designed font is a work of art and its author deserves the money for the job. Don’t cheat. If moral arguments don’t appeal to you, remember that once your app goes live it becomes publicly available and you may have to face legal action against you. There’s also a caveat related to subsetting fonts — even though you don’t touch the glyphs themselves, by manipulating a font file you create a derivative work, and an otherwise free license may not allow that. Then it’s best to contact the author, describe your case and ask for permission.
Former Senior Solutions Consultant at Aspire Systems Poland. Mobile developer and blogger, co-creating Aspire Systems Poland’s mobile vision and implementing the Mobile First strategy. In his free time – avid traveller.
We process cookies and make them available to Google Analytics (a service provided by Google, Inc.) to improve the performance of the website, to learn your preferences about using it and to tailor it to your needs. The data will be anonymised before being transmitted. If you do not agree to this, you may disable cookies in your browser. If you do not change your browser settings, you accept the fact that it saves cookies.