blog design kotlin OOP

Kotlin extension functions

 A world without extension functions

Imagine a scenario, you are coding a java android app, and you are using java.util.Calendar class for data and time management. You realize that you need to convert a calendar instance into a pretty format like “4 minutes ago…” but you are out of luck since Calendar object has no method that returns pretty format like that. The most common solution to this problem involves creating a util function that does that. Something like this:
So what is the main problem with this solution? It goes against OOP principles. Accessing CalendarUtils class directly all over the project tightly couples your code to this utils class, and that is not a good thing.  It is impossible to switch later on to a different implementation of this class since its imported directly.
Another issue is testing, how can you test a class that directly imports a utils class? Tests written for this class will also test the utils class, and when you change that utils class, tests may break even if you did not touch your original class.

Object-oriented programming to save the day

A better way to solve this problem would be to use a wrapper around calendar object. Something like this:
Now, this is a much better implementation. We can create an interface around this class, provide multiple implementations, use dependency injection to provide this functionality to our app, a much better object-oriented solution.
What are downsides to this object-oriented implementation? It requires more code then the first solution, and it does almost the same thing. A whole class is created just to wrap a calendar object and provide one method on top of it.

A world with extension functions

For simple use cases, it would be nice to have some way of declaring functions that can be attached to some objects, and that function would have access to all properties of that object. So the effect would be similar to creating a wrapper class around that object, and we would not import that extension function all our code base, we would just call it upon the receiver object. It is still not a perfect solution but much better than creating utils classes.
Kotlin extension functions to the rescue! How would an extension function look like for the problem above?
The extension function is the second function in the snippet above, Calendar.minutesAgoFrom, and you can immediately recognize that in the name of the extension function we specify on which class we want to attach the method. In this case, it is the Calendar class. So every time we create a Calendar instance in our code minutesAgoFrom will be available on that Calendar instance. The second thing to notice is the use of this keyword inside the extension function. This is the main power of extension functions, it provides an access to all internals of the Calendar object, hence the use of this.timeInMillis.
Extension functions are a middle ground between a fully object-oriented solution and procedural coding with static utils classes.
To really appreciate the power of extension functions let’s look at the code below, taken from the Kotlin extension documentation.
How powerful is that? We just created an extension function that applies to all possible list types. Now every list in your app has a swap function that can swap elements no matter the list type.


This just scratches the beginning of what extension functions look like, in part 2 we will see some popular collections of extension functions and how they actually work behind the scenes.

android architecture blog design kotlin

Android architecture components with Kotlin


After Google announced android architecture components, it was, for the first time, a Google-approved android architecture guidelines. Before this, the whole community would try to come up with best ways to structure android apps. First, everyone tried to follow MVC pattern that Google sort of provided with Android. But MVC for android is very confusing, you have a controller who is a view also (Activity, Fragment). Then MVP came along. model view presenter architecture, which clearly separates responsibilities of views and presenters (controllers). The main idea was to define interfaces (responsibilities) for each view and its presenter, making the app much easier to refactor down the road, given the fact that you know exactly what are responsibilities of each screen. One downside for MVP is the total amount of interfaces you have to create and maintain.
When reactive java came along, it turned everything upside down. MVP did not fit quite well with rxJava, since data is reactive, you do not have to specify what happens when data changes, you just map it to the view and the view became reactive to its data. With reactive programming, you react to changes in the app, whether its user input or network fetching and the view is this dummy representation of that data. It turned out, that reactive programming is perfect for Android, since events are something that is very natural to mobile phones, it became much easier to write and maintain complex UIs with rxJava. So what are downsides to rxJava? Spaghetti code, if you can not recognize when to use rxJava, it is very easy to write spaghetti code.
So what exactly does architecture components bring to the table?

Architecture components overview

Before we look into what architecture components offer, what problems do they solve, let’s look at common issues Android developers face.

  • Configuration change (device rotation),
  • Synchronized UI with data
  • Fetching data from database
  • … (lots more)

Let’s start with the configuration change, what would be a proper way to solve this problem? In my opinion, I want no memory leaks :D, then I would like the data to survive the change, I don’t want to fetch data again just because a user rotated the screen. So we need some kind of lifecycle aware component which survives the configuration change, knows when it can update the activity, but also knows when to destroy itself when it is not needed anymore. This is exactly what ViewModel class is. With few lines of code, you can have a UI that reacts to data changes and also display the latest data when UI gets recreated.
What about UI synchronization? That is where LiveData comes in. Once you create a LiveData instance, you can subscribe to it, and receive updates every time you update that LiveData instance.
What about the database? There are plenty of ORM libraries out there, do we need another one? Well, what if you want an ORM which returns a LiveData, which you can subscribe to it, so when you insert new data into the database, you get updates immediately? That is where Room comes in.
Those are the building blocks of Android architecture components, but the question remains, what about Android architecture? These components serve a specific purpose, how to structure the whole app now?
Well, just follow MVVM architecture, the View reacts to ViewModel, which exposes Models for Views to use and update their representation. Instead of wiring the Views to Models manually, Data-Binding library can be used to that automatically. So what we described above is just a Google recommended/provided implementation of the required components for MVVM architecture.

Github repository

I made a Github repository for a sample project that uses Kotlin and android architecture components, check it out to see how everything fits together in one app. Here are the main specifications of the project in that repository:

  • ViewModel for reactive data binding
  • Room as ORM library
  • Paging Library as a reactive data source for adapters
  • Dagger 2 as dependency injection framework
  • Repository pattern for data fetching
  • Retrofit as a REST client