Keep your class OCP compliant by using enums instead of booleans

Open for extension closed for modification. This means that our code is written in such a way that our class can have new behaviour without changing its structure.

Lets say that we have a Task and this task can have a description, a status and a couple of on/off characteristics like the fact that can be edited, shared or tracked.

Using flags

One way to depict this in code is by using flags in the form of booleans:

	class Task(
	val description: String,
	val status: Status,
	val isEditable: Boolean,
	val isTrackable: Boolean,
	val isSharable: Boolean
	)

view raw task-with-flags.kt hosted with ❤ by GitHub

This means that every time we need to add a new characteristic we have to modify the Task class and add a new boolean property. This violates the open close principle making the code difficult to scale.

Using a list of enums

Another way is to replace all these flags with a list of enums:

	class Task(
	val description: String,
	val status: Status,
	private val characteristics: List<Characteristic>
	) {
	fun hasCharacteristic(characteristic: Characteristic): Boolean {
	return characteristic in characteristics
	}
	}

	enum class Characteristic {
	Editable,
	Trackable,
	Sharable
	}

view raw task-with-enums.kt hosted with ❤ by GitHub

Now if we need to add a new characteristic we simply add a new enum entry and the entire project can keep using the hasCharacteristic method to query a task for its characteristics.

Bonus benefit: this way we also avoid the wall of properties that sometimes hides information instead of revealing it!

Relax, take a step back and start from the business logic

Another year of advent of code and this time I decided to participate. Not only that but I thought it would be a great way to teach myself Ruby.
This means that my train of thought gets interrupted quite often since for every little thing I come up with I have to stop and search how Ruby does it.

Day 3 – Gear Ratios

In today’s challenge the target is to calculate the sum of all numbers that are adjacent, even diagonally, to a symbol. The input looks like this:

467..114..
...*......
..35..633.
......#...
617*......
.....+.58.
..592.....
......755.
...$.*....
.664.598..

and a symbol is everything that is not a number or a dot (.).

Head first

Seeing this input combined with the fact that I don’t know Ruby throw me in a crazy rabbit hole where I was searching for two-dimensional arrays at one point and parsing strings at another.

Then I remembered that the adjacent part includes diagonals too so I dropped everything and start thinking of how I will combine numbers from one line with symbols from another.

This is getting big. Should I start smaller? Should I try to approach this in a 2×2 array? Should I do this or that? Chaos!

Start from the business logic

Thankfully after taking a break and drinking some water I realized that my need to answer all my unknowns had taken the best of me and I was viewing things wrong.

It does not matter how the input looks. It is just that, an input. I shouldn’t start from there.
It does not matter what/how Ruby does things. It is just a tool.

What matters is the business logic and in this case its quite simple:

Our business entities are Numbers and Symbols.
Our business logic dictates that a Number is next to a Symbol if it lies to the area that surrounds it.

Translating this to code:

	class Symbol
	attr_reader :value, :row, :column

	def initialize(value, row, column)
	@value = value
	@row = row
	@column = column
	end
	end

	class Number
	attr_reader :value, :row, :starting_column, :ending_column

	def initialize(value, row, starting_column, ending_column)
	@value = value
	@row = row
	@starting_column = starting_column
	@ending_column = ending_column
	end

	def is_next_to?(symbol)
	return false if (@row <= symbol.row – 2) \|\| (@row >= symbol.row + 2)
	return false if (@ending_column <= symbol.column – 2) \|\| (@starting_column >= symbol.column + 2)
	true
	end
	end

view raw gear_ratios.rb hosted with ❤ by GitHub

made things so much simpler:

	class GearRatios
	def initialize(numbers, symbols)
	@numbers = numbers
	@symbols = symbols
	end

	def sum
	@numbers.filter { \|number\| @symbols.any? { \|symbol\| number.is_next_to? symbol } }
	.sum { \|number\| number.value }
	end
	end

view raw gear_ratios_2.rb hosted with ❤ by GitHub

After writing and testing the business logic all I had left to do was to write the code that will produce our lists for numbers and symbols. In this case it just happens to be a two-dimensional array with string values.

Start from what matters

Being overwhelmed or not, relax, take a step back and start from what matters.

Presentation is important but it shouldn’t drive an approach since it might change often. Input is also important but it shouldn’t matter if we are dealing with a database, a web service or the file system.

Start from the business, make it work and then try to figure out how everything else can be plugged in.

Working with checkpoints

There are times that my workflow involves a lot of small and consecutive commits. Commits that their message does not really matter since I will squash them into one that describes my work.

An example is when TDDing a certain functionality. In that case I usually write the test, make it pass and finally make a commit.

Why am I doing that? I see it like small checkpoints. I conclude a part of the functionality so I save it. This helps in restoring my code back to last point that I was happy with its state.

One commit

When I first started working this way I was making a distinct checkpoint for each part. Soon enough I realized that these commits didn’t provide any value. I was making them quick for just saving the code and their message was something like save or checkpoint or t.

So instead of doing this and having to squash lots of commits I started using amend. One commit for the first checkpoint and amend for the rest of them. This way, when I’m finished, I rename the HEAD of the branch to something descriptive and move on.

Lots of steps for one commit

I write my code using an IDE (Android Studio or Intellij IDEA) but when it comes to git I move to a terminal.

This means that for committing I have to (1) move to the terminal, (2) make the proper commit/amend and (3) move back to the IDE. Three steps for one save!

Alt + P

So I decided to fix it.

First the bash script that makes the commit:

	#!/bin/bash

	CHECKPOINT="checkpoint"

	git add .

	if [[ "$(git log –format=%B -n 1 HEAD \| cat)" == "$CHECKPOINT" ]]; then
	git commit –amend –no-edit
	else
	git commit -m"$CHECKPOINT"
	fi

view raw checkpoint.sh hosted with ❤ by GitHub

A simple script that either makes a commit with the message checkpoint or amends the staged changes.

Second the import of this script to the IDE:

The Intellij platform provides a functionality called External Tools:
– Go to Settings -> Tools -> External Tools and click on the add button.
– Set the path of your script where it says Program .
– Disable the Open console for tool output if you don’t want to see the result of your script.

At this point you can either use checkpoint as an action (double shift, type checkpoint) or you can go a step further and create a keyboard shortcut:

Go to Settings -> Keymap -> External Tools -> Right click on the script -> Add Keyboard shortcut.

So now every time I want to create a checkpoint I simple press `Alt + P` and continue working without moving from one program to another!

Bring me both your problems and your suggestions

It’s been a little over a year that I have the role of an engineering manager for the first time in my career. Needless to say that I’m still learning. I read the dos and don’ts and try to incorporate them in my everyday work life. Sometimes everything works fine, some others everything goes wrong!

The don’t I keep doing

The one thing that I often find myself doing is providing, immediately, a solution to a problem that was brought to my attention. No “tell me what you think we should do”, no “what approaches have you tried?”, nothing that will spark a dialogue between me and my report. A dialogue that will helps us to figure things out and grow as engineers.

Figuring something on your own, instead of being told about it, has proven to be vital in understanding it better. So, if I want my reports to grow as engineers, I must lead them to a solution rather than give them one. The aforementioned questions must be my first reaction.

The do we can start doing

this part is a message to all my current and future reports

My hope is that writing about this don’t will make me more conscious about this behavior and avoid doing it. But, we are all humans and it will be better to have a safeguard.

So, what I propose is for you to come to me both with a problem and a suggestion as to how we can solve it. This will keep me from offering an answer right away and, most importantly, it will help you grow as an engineer. Forcing yourself to think about a suggestion or to reflect upon the approaches you’ve taken will make you understand the problem and its domain better. That alone will benefit our discussion or, even better, might lead you in a solution without any help!

Let me be a feedback loop for you

(this post was written with the intent to give it to my current, and future, direct reports in an attempt to establish part of our relationship)

Every time we need to solve a problem (or implement a feature) the process is the same

First we think the approach we are going to follow. This is an abstract flow that we believe will solve the problem.
Based on that we divide our approach to one or more components (modules / classes / functions, whatever suits the size of the problem) and assign a certain behavior to each one of them.
Finally, we start implementing each component.

Feedback loop

How do we know if something we implemented is correct?

By getting feedback. Based on it we make improvements and try again. This loop keeps us on track and allows us to deliver something valuable.

This is why we try to have frequent and short feedback loops. This way any corrections occur sooner than later and we don’t spend time and effort into something that might, potentially, thrown away.

Tech lead as a feedback loop

Looking back to the process of solving a problem we could say that two out of the three steps do have a feedback loop to helps us.

In the implementation step we can argue that the compiler / linter / etc gives us immediate feedback on what we wrote. We fix it and move forward.

For the behavior step we get the feedback through tests. Is the component’s behavior the expected one? How about the components API? Can we use it easily in our tests? Answering these question helps in having solid components.

But what about the approach step? This is where the tech lead comes in.

Right before writing any code, thus putting effort into something, prepare a simple list with the steps you are about to take and discuss them with your tech lead. If there is any feedback use it to improve your approach and have another meeting.

Is it time consuming?
No. In case the approach needs improvement after the implementation the time to fix it will be longer.

Do you feel bad on spending your TL’s time?
Don’t. It is, literally, their job to help you.

Add tests, discover things!

The benefits that you get from testing your code will never cease to amaze me.

I was working on a new feature and part of it required changing one of our oldest classes. The class was still in Java so I decided, before doing any other work, to convert it to Kotlin. There were no tests so my first step was to add them and make sure that the conversion wasn’t going to break anything.

The class is a simple configuration one that

setups a couple of its fields upon construction and
exposes its validity state

something like this

	public final class Configuration {
	private final String agent;
	private final String header;
	private final String version;

	public Configuration(final Storage storage) {
	this.agent = storage.get(KEY_AGENT);
	this.version = storage.get(KEY_VERSION);
	this.header = storage.get(KEY_HEADER) + "/" + VERSION_PREFIX + this.version;
	}

	public boolean isValid() {
	if (getAgent().length() == 0) return false;
	if (getVersion().length() == 0) return false;
	return getHeader().length() != 0;
	}

	public String getAgent() {
	return agent;
	}

	public String getHeader() {
	return header;
	}

	public String getVersion() {
	return version;
	}
	}

view raw discover_by_testing_initial.java hosted with ❤ by GitHub

but with many more fields.

Falsely valid

So I started writing tests to cover all cases and the one that failed immediately was

	@Test fun `the configuration is not valid when its header is empty`() {
	whenever(mockStorage.get(KEY_AGENT)).thenReturn("an agent")
	whenever(mockStorage.get(KEY_VERSION)).thenReturn("a version")
	whenever(mockStorage.get(KEY_HEADER)).thenReturn("")

	val actual = configuration().isValid

	assertFalse(actual)
	}

view raw discover_by_testing_failed_test.kt hosted with ❤ by GitHub

at first I thought I had an error in the test but looking closely at the production code I saw the problem. Actually the problems. Plural:

Even thought in this case its subtle, the constructor is violating the SRP. It initializes the fields and makes a decision on what will be exposed. This is a job for the getter.
Which brings us to the second problem. Getters are great way to expose information allowing us to make internal changes without breaking anything outside the class. They help us decouple ourselves from the classes that consume us.
By using the getters instead of the fields, as in isValid, we couple the class with itself making it depend on what will be exposed and not the actual internal state of the class.

For the record the fix is

	public final class Configuration {
	private final String agent;
	private final String header;
	private final String version;

	public Configuration(final Storage storage) {
	this.agent = storage.get(KEY_AGENT);
	this.version = storage.get(KEY_VERSION);
	this.header = storage.get(KEY_HEADER);
	}

	public boolean isValid() {
	if (agent.length() == 0) return false;
	if (version.length() == 0) return false;
	return header.length() != 0;
	}

	public String getAgent() {
	return agent;
	}

	public String getHeader() {
	return header + "/" + VERSION_PREFIX + this.version;
	}

	public String getVersion() {
	return version;
	}
	}

view raw discover_by_testing_fixed.java hosted with ❤ by GitHub

and we managed to figure it out by writing a small, simple test.

Quick feedback

Having a quick feedback loop is a great way to keep yourself focused on the end result and to make less mistakes on the way. In our profession this is achieved with tests.

This bug was hiding for quite some time so the loop in this implementation was literally years!
Aim for shorter time periods! Seconds is the best and to do that is to write the test along side the production code.

I strongly encourage you to follow TDD but it doesn’t matter if its not your cup of tea. Write it after the production code, just do it immediately after.

Use Parceler to put your parcels on a diet

kotlin-parcelize is a great tool. Its simple to use and it helps in avoiding writing a lot of boilerplate code. There are times though that we need to take control of writing and reading to/from the parcel. One of these times is to cut down a few bytes from it (TransactionTooLargeException I am looking at you).

Meet me in the middle

@Parcelize takes full control and creates everything. Without the annotation, the developer has to do this on her own. Parceler lives in the middle of this spectrum. The plugin will create all necessary methods and classes but the actual write and read to/from the parcel will be the developer’s responsibility.

Without a Parceler the write/read looks like this:

	public void writeToParcel(@NotNull Parcel parcel, int flags) {
	Intrinsics.checkNotNullParameter(parcel, "parcel");
	parcel.writeInt(this.id);
	parcel.writeString(this.description);
	parcel.writeString(this.priority.name());
	parcel.writeParcelable(this.status, flags);
	Attachment var10001 = this.attachment;
	if (var10001 != null) {
	parcel.writeInt(1);
	var10001.writeToParcel(parcel, 0);
	} else {
	parcel.writeInt(0);
	}
	}

	@NotNull
	public final Task createFromParcel(@NotNull Parcel in) {
	Intrinsics.checkNotNullParameter(in, "in");
	return new Task(
	in.readInt(),
	in.readString(),
	(Priority)Enum.valueOf(Priority.class, in.readString()),
	(Status)in.readParcelable(Task.class.getClassLoader()),
	in.readInt() != 0 ? (Attachment)Attachment.CREATOR.createFromParcel(in) : null
	);
	}

view raw parcelable_on_diet__generated_write_read.java hosted with ❤ by GitHub

with a Parceler like this (where the Companion object is acting as a Parceler):

	public void writeToParcel(@NotNull Parcel parcel, int flags) {
	Intrinsics.checkNotNullParameter(parcel, "parcel");
	Companion.write(this, parcel, flags);
	}

	@NotNull
	public final Task createFromParcel(@NotNull Parcel in) {
	Intrinsics.checkNotNullParameter(in, "in");
	return Task.Companion.create(in);
	}

view raw parcelable_on_diet__generated_write_read_after.java hosted with ❤ by GitHub

Cutting down parcel’s size

The above-generated code is based on Task

	@Parcelize
	class Task(
	val id: Int,
	val description: Description,
	val priority: Priority = Normal,
	val status: Status = NotStarted,
	val attachment: Attachment? = null
	) : Parcelable

	@Parcelize
	class Attachment(val path: String) : Parcelable

	@Parcelize
	@JvmInline
	value class Description(val value: String) : Parcelable

	enum class Priority {
	Low,
	Normal,
	High
	}

	sealed class Status : Parcelable {
	@Parcelize
	object NotStarted : Status()

	@Parcelize
	object InProgress : Status()

	@Parcelize
	class Completed(val completedAt: LocalDate) : Status()
	}

view raw parcelable_on_diet__example.kt hosted with ❤ by GitHub

which, creates a parcel of 248 bytes. The code does not do anything weird. All primitives, which include the value classes too, are well handled. So nothing to do here. This leaves parcelables and enums.

But first, let’s use a Parceler. This means that writing and reading to/from the parcel has to be implemented by us. For starters, we will do exactly what the generated code does except for the attachment property. For that, the generated code uses parcelable’s methods and CREATOR. In the Parceler we don’t have access to the CREATOR.

	companion object : Parceler<Task> {
	override fun create(parcel: Parcel): Task {
	return Task(
	parcel.readInt(),
	Description(parcel.readString()!!),
	Priority.valueOf(parcel.readString()!!),
	parcel.readParcelable(Status::class.java.classLoader)!!,
	parcel.readParcelable(Attachment::class.java.classLoader)
	)
	}

	override fun Task.write(parcel: Parcel, flags: Int) {
	with(parcel) {
	writeInt(id)
	writeString(description.value)
	writeString(priority.name)
	writeParcelable(status, flags)
	writeParcelable(attachment, flags)
	}
	}
	}

view raw parcelable_on_diet__writeparcelable.kt hosted with ❤ by GitHub

That leaves us with writeParcelable and readParcelable but now the parcel’s size is bigger, it is 328 bytes! Turns out that writeParcelable first writes the parcelable’s name and then the parcelable itself!

We need to use the CREATOR. After searching around I found parcelableCreator. A function that solved a well-known problem and will be added to Kotlin 1.6.20.

	inline fun <reified T : Parcelable> Parcel.readParcelable(): T? {
	val exists = readInt() == 1
	if (!exists) return null
	return parcelableCreator<T>().createFromParcel(this)
	}

	@Suppress("UNCHECKED_CAST")
	inline fun <reified T : Parcelable> parcelableCreator(): Parcelable.Creator<T> =
	T::class.java.getDeclaredField("CREATOR").get(null) as? Parcelable.Creator<T>
	?: throw IllegalArgumentException("Could not access CREATOR field in class ${T::class.simpleName}")

	fun <T : Parcelable> Parcel.writeParcelable(t: T?) {
	if (t == null) {
	writeInt(0)
	} else {
	writeInt(1)
	t.writeToParcel(this, 0)
	}
	}

view raw parcelable_on_diet__creator.kt hosted with ❤ by GitHub

This allows us to revert the size increment back to 248 bytes

	companion object : Parceler<Task> {
	override fun create(parcel: Parcel): Task {
	return Task(
	//…
	parcel.readParcelable()
	)
	}

	override fun Task.write(parcel: Parcel, flags: Int) {
	with(parcel) {
	//…
	writeParcelable(attachment)
	}
	}
	}

view raw parcelable_on_diet__creator_usage.kt hosted with ❤ by GitHub

Use enum’s ordinal than its name. The generated code writes enum’s name so that it can use Enum.valueOf when reading. We can write an int instead by using enum’s ordinal

	companion object : Parceler<Task> {
	override fun create(parcel: Parcel): Task {
	return Task(
	//…
	parcel.readEnum()
	)
	}

	override fun Task.write(parcel: Parcel, flags: Int) {
	with(parcel) {
	//…
	writeEnum(priority)
	}
	}
	}

	inline fun <reified T : Enum<T>> Parcel.readEnum(): T {
	return enumValues<T>()[readInt()]
	}

	inline fun <reified T : Enum<T>> Parcel.writeEnum(t: T) {
	writeInt(t.ordinal)
	}

view raw parcelable_on_diet__enum.kt hosted with ❤ by GitHub

and use Enum.values() when reading. This drops the parcel’s size to 232 bytes.

Skip a class’s parcelable implementation. This of course depends on each implementation.
For instance, Status is a sealed class that only one of its children has a construction parameter. We can leverage this by writing only that value

	companion object : Parceler<Task> {

	override fun create(parcel: Parcel): Task {
	return Task(
	//…
	parcel.readStatus()
	)
	}

	override fun Task.write(parcel: Parcel, flags: Int) {

	with(parcel) {
	//…
	writeStatus(status)
	}
	}
	}

	fun Parcel.readStatus(): Status {
	return readLong().let { value ->
	when (value) {
	0L -> NotStarted
	1L -> InProgress
	else -> Completed(LocalDate.ofEpochDay(value))
	}
	}
	}

	fun Parcel.writeStatus(status: Status) {
	when (status) {
	is Completed -> writeLong(status.completedAt.toEpochDay())
	InProgress -> writeLong(1)
	NotStarted -> writeLong(0)
	}
	}

view raw parcelable_on_diet__status.kt hosted with ❤ by GitHub

this drops the parcel’s size to 136 bytes!

Conclusion

Fortunately, the generated code does a pretty good job and making any optimizations is not that common. But when needed Parceler and parcelableCreator are great tools.

PS: for measuring the parcel’s size I was using this method

	fun Parcelable.sizeInBytes(): Int {
	val parcel = Parcel.obtain()
	try {
	parcel.writeParcelable(this, 0)
	return parcel.dataSize()
	} finally {
	parcel.recycle()
	}
	}

view raw parcelable_on_diet__size_in_bytes.kt hosted with ❤ by GitHub

which was shamelessly stolen from Guardian’s TooLargeTool.

This is how I use Todoist

Disclaimer: this is not a paid post. I wrote it because I like the app and find it helpful. I also want to see, in a year, what has changed in the way I use it.

I always have a notebook next to my keyboard. I use it when trying to solve a bug or put in place a new feature. There was also a time that I used it to plan my day or keep notes for things that I wanted to ask or communicate. That didn’t last long since it wasn’t scaling!

That’s when I decided to move to a digital solution and search for the best to-do app. To be honest I can’t remember how I found out about Todoist. What I do remember though was that I did not check any other apps. Both its amazing human language parser and its shortcuts got me hooked immediately!

My usage

A little context. I use Todoist for over a year and only for work. That means that I don’t take advantage of their projects support. Every task gets added to the #Inbox which is my main driver. Throughout this year I’ve tried many setups and ways to incorporate my needs into the app. Here is how I use it:

Plan my day by setting the tasks that need completion

Every morning I see what needs to be done and create a task for it.

That does not mean that I open the company’s project management tool and copy whatever is assigned to me. I add only what cannot be tracked by the management tool. For instance, if a PR of mine got approved I add a task to merge my work in the main branch.

Also, if a meeting ends up with a couple of actionable items for me, I make sure to add them to Todoist. For example, talk to product about blah blah, comment on this thread, read that article, etc.

Another great source of action items is email. I go by them one by one and if something requires my attention I make a task for it.

Help me build habits

I try to cut down any distractions and one of them is looking at my emails every once in a while. What seems to work for me is to check them in the morning and create, if needed, tasks from them.

To force me in making it a habit I created a task that reminds me every weekday at 8:55 am to check my emails. This is 5 minutes earlier than when I start working so it gets registered, in my mind, as the first thing to do.

To show you the power of Todoist, for creating this task you need to write:

Check emails every weekday at 8:55

It will know what to do:

Reminders

Having a recurring task with a reminder is a good way to document things that do not belong anywhere else.

For example, every two weeks, on a Monday, I need to archive a column in our team’s board and create a new one.

Again, you can write it down

Archive column, create new every two weeks starting mon

and Todoist will understand it:

Write topics, questions, thoughts

Not everything is a task that needs completion. There will be topics and questions that must be communicated in a recurring meeting.

This is where I use labels for each meeting type and a task, with no date, for the topic/question.

This way, every time I am in one of these meetings, I open the label and have a list of what I wanted to discuss.

A task with no date and no label is also my way to write down my thoughts/ideas about the project. A possible refactoring, research for a new tool. Things that I need to get off my head but without setting a deadline.

Filters

I couldn’t close this post without mentioning filters. A feature that took me a while to use but can’t live without it anymore.

Better show you what I mean:

So, this is a filter I run every morning to see:

today’s high-priority (P1) tasks or
what needs discussion in the team’s stand-up

Another example is

that I use to resurface the thoughts and ideas that I mentioned before.

I think that data classes help in violating the YAGNI principle

Let me ask you something. You are the reviewer in a PR that creates a simple calculator which needs to know how to add numbers. Just that. There are no reasons to make us think that the calculator will need more functionality.

Despite that the PR includes a calculator that can add, subtract and multiply. What do you do as a reviewer?

I want to believe that you will, respectfully, discuss the removal of the extra functionality otherwise the calculator will violate the YAGNI principle and add (a) more code for the developers to maintain and (b) more ways to couple the project with the calculator. And all that with no immediate benefit.

Do we need all that functionality?

The same goes with data classes. There is no reason to have a class that can be uniquely identified by all of its properties if we don’t use its instances this way. There is no reason to have an extra getter for every property if we don’t use, extensively, the destructuring declaration. There is no reason to have a copy mechanism if we never copy instances!

If it is there it is going to be used

I recently removed the data keyword from one of our oldest classes and I noticed that many of our newest tests started to fail in compilation. The compiler could not find the copy method which was used to create dummy values from other dummy values by changing one property per test.

When to create a data class?

Here is my thought process when trying to decide the type of class I’ll use:

Q: Is this class anything but a domain entity or value object?

A: Then a simple class is just fine.

Q: Is this class a domain entity? Meaning that it can be uniquely identified by a subset of its properties (ex: an id)?

A: Then a simple class with an implementation of equals/hashCode will be enough.

Q: Is this a value object? Meaning that it can be uniquely identified by all of its properties?

A: Yes.

Q: How many properties?

A: One. Then a value class is a must.

Q: Are you sure its just one?

A: Turns out its more! We’ll use a data class.

Don’t do it for the test

Our test code is the first consumer of our production code. Changing the production code, in this case change/create a class as data, to write more quickly a couple of tests will result in having tests that can easily break every time the production code changes since the tests know too much about the code’s internals and not its behavior.

TextAppearanceSpan with custom font on min SDK 21 – part 2

In the previous post we created FontAwareTextAppearanceSpan. A TextAppearanceSpan descendant that can be used exactly as its parent

	textView.text = buildSpannedString {
	inSpans(FontAwareTextAppearanceSpan(context, R.style.AcmeText)) {
	append(context.getString(R.string.le0nidas_gr))
	}
	}

view raw font_aware_textappearancespan__font_aware_span.kt hosted with ❤ by GitHub

but with the addition that it uses the font found in the provided style.

The thing is that this implementation works only in debug apks or if the project has AGP v4.1 and lower!

Optimizing resources

Android Gradle Plugin 4.2 introduced a number of resources optimizations in order to cut down the apk’s size. One of these optimization is the obfuscation/shortening of their filenames.
This means that when the span reads the family name from the style

	public TextAppearanceSpan(Context context, int appearance, int colorList) {
	// …
	if (mTypeface != null) {
	mFamilyName = null;
	} else {
	String family = a.getString(com.android.internal.R.styleable.TextAppearance_fontFamily);
	if (family != null) {
	mFamilyName = family;
	}
	// …
	}

view raw font_aware_textappearancespan__family_name.java hosted with ❤ by GitHub

instead of getting something like res/font/acme_family.xml it gets res/Zx.xml which breaks completely FontAwareTextAppearanceSpan‘s getFont since it takes for granted that the resource’s name can be extracted from the aforementioned value

val cleanFamilyName = family.removePrefix("res/font/").removeSuffix(".xml")

view raw fontawaretextappearance_the_fix__cleaning_name.kt hosted with ❤ by GitHub

Temporary fix

One way to fix this is by adding android.enableResourceOptimizations=false in gradle.properties. This will prevent the optimization from happening thus allowing the extraction of the resource’s name.

But, and this is a big but, this is just a temporary fix since google has announced that from AGP v8 and on the optimizations will be hard forced with no way to change that. You can see it as a message when building while using the flag:

The option setting 'android.enableResourceOptimizations=false' is deprecated.
The current default is 'true'.
It will be removed in version 8.0 of the Android Gradle plugin.

Permanent fix

Turns out that the best way to go is to provide the font’s name ourselfs. In other words there must be a duplication of information since the name already exists in the style.

We could change FontAwareTextAppearanceSpan and pass the name in its constructor but this means that the duplication takes place in many places: in the style and in every instantiation. Also the developer instead of just using the span by providing a style, she needs to open the style, figure out the font’s name and then pass it to the constructor. Manual work that is error prone.

A better approach is to have the duplicated information at the place that gets provided instead the one that gets consumed. This leaves us with the style itself:

	<style name="AcmeText" parent="TextAppearance.MaterialComponents.Body1">
	<item name="android:fontFamily">@font/acme_family</item>
	<item name="fontFamily">@font/acme_family</item>
	<item name="android:textSize">20sp</item>

	<item name="fontFamilyName">@string/acme_family</item>
	</style>

view raw fontawaretextappearance_the_fix__style_with_name.kt hosted with ❤ by GitHub

where fontFamilyName is an attribute:

view raw fontawaretextappearance_the_fix__attr.kt hosted with ❤ by GitHub

This way the information gets duplicated once and the developer uses the span as before by just providing the style.

Ofcourse we need to change FontAwareTextAppearanceSpan so that it reads the resource’s name from the style:

	class FontAwareTextAppearanceSpan(
	private val context: Context,
	private val appearance: Int
	) : TextAppearanceSpan(context, appearance) {

	private var font: Typeface? = null

	override fun updateMeasureState(ds: TextPaint) {
	super.updateMeasureState(ds)

	val font = getFont() ?: Typeface.DEFAULT
	val oldStyle = ds.typeface?.style ?: 0
	ds.typeface = Typeface.create(font, oldStyle)
	}

	private fun getFont(): Typeface? {
	if (font != null) {
	return font
	}

	val cleanFamilyName = getFontFamilyName() ?: return null
	val appPackageName = context.applicationContext.packageName
	val id = context.resources.getIdentifier(cleanFamilyName, "font", appPackageName)
	return getFont(context, id).also { font = it }
	}

	private fun getFontFamilyName(): String? {
	val attrs = intArrayOf(R.attr.fontFamilyName)
	val a = context.obtainStyledAttributes(appearance, attrs)
	val fontFamilyName = a.getString(0)
	a.recycle()

	return fontFamilyName
	}
	}

view raw fontawaretextappearance_the_fix__fontawarespan.kt hosted with ❤ by GitHub

And that is it 🙂 .