I had to introduce a new model in one of my projects, and by that time, I wasn’t sure about its type (Int or String). I had to start the implementation to meet the deadline, so I choose to hide the type somehow. Kotlin’s type aliases came to help me.

typealias Key = Int

From the official docs: Type aliases do not introduce new types. They are equivalent to the corresponding underlying types.

Start coding ASAP

Using the type alias feature I could start the implementation of my app using Key everywhere, like this:

interface KeyStore {
    fun currentKey(): Flow<Key>
}


data class MyModel(
    val key: Key,
    val urls: List<String>,
)

I skipped the parts, where the type of Key is crucial, e.g. the implementation of the above KeyStore. In that class, I needed the exact type, as I wanted to persist it into SharedPreferences. It’s not the same if it’s an Int or String.

I knew that it will be visible on the UI directly in the future, so during binding I called toString() on it.

val key: LiveData<String> =
    keyStore
        .currentKey()
        .map { it.toString() }
        .asLiveData(Dispatchers.Default)

Decision on the type

The only constant is change, and it materialized in my project as the type of Key became a String rather than an Int.

Maybe my decision on type alias usage will pay off here!

Refactoring

Let’s change:

  • the type in typealias
  • remove the redundant toString() calls on the usage side (Analyze -> Inspect Code in Android Studio helped me to find them)

Guess what? That’s all!

No changes in my stores, viewModels, model classes, nowhere!

Conclusion

Kotlin’s type alias helped me to start coding quickly while skipping some domain-related decisions at the beginning of the development process. Meantime it saved me time on changing the type later.

Win-win.