Improving Code Quality in Android

Tips to help you write cleaner code

Photo by Joshua Woroniecki on Unsplash

This article documents things I read, PR comments I received, and some things I learned from my colleagues. If you can add more to this, please feel free to comment.

Val or Var

Mutability vs Immutability. If given a choice, which would you choose? I will always prefer immutability (val over var). When making a variable mutable, you are opening the door to uncertainty. No one can predict the value of that variable at some point in that class, and that variable can create a negative or positive impact on the whole class because of its ever-evolving nature. Try to use a var only if you are sure that val can’t work in your scenario. Don’t give the luxury to var. Confine that variable to some bounds using val.

Visibility Modifiers

There are four types of visibility modifiers in Kotlin:

• private
• protected
• internal
• public

Most of these modifiers will be limited to private or public if your code is poorly architected. They will come into play when your classes start to share things without depending too much on each other. Perhaps, if you’re writing clean code.

Let’s look into the following code:

abstract class Car {

    protected var name: String? = null
    protected var year: Int = 0
    private val welcomeMessage = "Hi, Welcome to your new car"

    abstract fun modelName()
    abstract fun manufacturedYear()

    fun printWelcomeMessage() {
        println(welcomeMessage)
    }

}

class Chevrolet : Car() {
    override fun modelName() {
        name = "Beat"
        printWelcomeMessage()
    }

    override fun manufacturedYear() {
        year = 2012
    }

}

class Hyundai : Car() {
    override fun modelName() {
        name = "Jazz"
        printWelcomeMessage()
    }

    override fun manufacturedYear() {
        year = 2015
    }
}

We have a base class called Car. Chevrolet and Hyundai extend it. They can access the name and year, which is a part of Car only because it is protected. So, protected has the same visibility as private. But it is also visible in the subclasses.

What if you make either name or year an internal variable.? Then you can access it anywhere from the same module. We don’t have to extend the class itself. What about the welcomeMessage variable in the Car class? It is private and will be accessible only in the Car class. Understanding the differences between visibility modifiers helps when you write code based on the SOLID principles.

Reduce Android Objects in Params

A little carelessness, and now you have methods that are not testable. Or, you will have to work double hard to make it testable.

fun importantMethod(size: Size) {
    // some logic using Size
}

We have passed an Android object Size as a param for this method. The problem comes when you try to create a mock for the same. It is challenging to build mock objects for Android-related stuff. Instead, you could have passed width and height of int as a param. Find the alternative in Java/Kotlin objects. Always try to limit the usage of Android objects in method parameters.

Don’t Overexploit Extension Functions

Extension functions are innovative. We are now able to extend a class without actually inheriting it. Also, we can add new properties to it and make it look like it was part of the original implementation.

fun Activity.showToast(message: String) {
 Toast.makeText(this, message, Toast.LENGTH_SHORT)
 .show()
}

It is a good extension function. Why? Because it is generic. You are extending the activity’s context and creating something handy. A lot of activities can make use of this extension function.

fun Activity.solvingAnIssueForActivityA() {
    // some logic
}

What about this one? We have created an extension function without thinking about good design. How will it impact the code.? This function will pop up as an auto-complete when someone uses a dot with an Activity. And the developer will wonder how my activity knows about something inside ActivityA. Create an extension function only if you think this code is repeatable, someone else can use it, no business logic is involved, etc. Use extension functions wisely. Try not to abuse them.

Kotlin Objects Are Not Thread-Safe

object someCalculations {

    var value1 = 0 
    var value2 = 0

    fun doingSomethingWithValue1() {
    // some logic
    }

    fun doingSomethingWithValue2() {
    // some logic
    }
}

As you may know already, we use Kotlin objects mainly to create singletons. The main advantage of using an object in Kotlin is that we don’t have to create a new instance of it. The problem is that there is a chance that we use objects to share data between other objects/classes.

Let’s review the above implementation. We designed it so value1 and value2 can change from anywhere, and the methods that use these properties can also be accessed from anywhere. If you are unlucky, they will get accessed simultaneously, and you might not get the updated result you expected. So, if such a scenario occurs, better refactor your code design to have some intermediate class that can help share data. Or, if you plan to move ahead with the object, make sure you are using some synchronization mechanism to ensure your fields are updated.

I have learned that when you write code based on design principles, your canvas expands. Do not limit yourselves to thinking only from Android’s perspective. It will help everyone involved. I will write more when I pick up something new. Have a great day. 😇

Feel free to take a look at my recent articles:

A Bitmap story

JNI on Android: How callbacks work

Scheduling tasks with WorkManager

This article was originally published at clintpauldev.com