In this series of articles, we explore features and techniques which may help developers starting or currently using Kotlin. In it, we compare them with their relevant ones in Java as many of us are moving forward from it.

We also look at the reasons behind some of the features and how we can use them to improve our code.

Every now on then, I may sprinkle in some Android specific example since it’s the community that seems to be embracing the language with open arms.

More coming 🔜

If you want to get updates on new articles in this…

This is part of a series of articles. You can find the rest here.

For better or worse, we still require inheritance when developing with Kotlin. However, things are a bit different, mostly for the better. Let’s have a look at what tools do we have in the language to solve classical problems in Object Modelling.

The final modifier

In Java, inheritance is available by default. Meaning that when declaring a new type we can define children types that inherit their behaviour and data model. …

This is part of a series of articles. You can find the rest here.

Most of us, who are lucky enough to be able to work with Kotlin often come from other programming languages. The vast majority also come from the beautiful and verbose world of Java.

However, things are different on the other side, and it’s not uncommon to fall for the convenience of bringing our old baggage with us because we are used to it and feels comfortable.

We don’t have to. We can also think of it as moving to a new home. Packing all our old…

Photo: me — Product:

Recently, I came across a component that relied on threads. I wanted to test it’s behaviour. However, soon I came across the issues that come with parallelisation (always have to look up how to spell that word).

val scheduler = Scheduler()
var result: String? = null

scheduler.schedule {
result = "expected value"

assertThat(result, equalTo("expected value"))

The problem with this code is that it will always reach the assertion before it has a chance to execute the code provided to the scheduler. Hence why result remains with a null value at the assert stage.

Back in Java days, one way…

When I first started using Mockito, I was amazed at how it manipulates objects for tests. I used annotations to declare mock fields and then either use initMock on the setup method or a MockitoRule, as it was what most online tutorials explain to do.

public void setUp() {
public MockitoRule rule = MockitoJUnit.rule();

Both these techniques use reflexion to find and instantiate fields in the test class marked with Mockito related annotations. In fact, MockitoJUnit internally uses MockitoJUnitRule which in turn uses initMocks.

However, there is a couple of things to consider next time you…

Part of the 3 peaks challenge, last leg going to Snowdonia

For the last two and a half years, at Moonpig/Photobox, I’ve been part of a great team dedicated to creating mobile solutions, always aiming for code and UI/UX quality. Now, it’s come the time to say goodbye and move on to new frontiers.

I started as part of a (brand new at the time) team called the AppFactory, an internal app making “agency”. Before that, the strategy was to transfer the responsibility for Android and iOS apps to third parties.

Involved with multiple brands inside the Photobox Group, I had opportunities to work on diverse elements of various apps.


Android Themes are not very intuitive, and I bet I’m not the only one that has spent a whole evening scratching my head figuring out why something that, on the surface, should be working is not. The documentation is scarce and confusing. Especially regarding style and theme inheritance.

There are two ways a Theme can descend from another one. And the same applies to styles. The first one, and most straight forward, is to define the parent attribute in the XML description.

<style name”AppTheme” parent=”BaseTheme”></style>

The other one, useful as a horrible interview question, is using namespacing.

<style name”BaseTheme.Dialog”></style>


Intents are an integral part of any app. Thanks to Kotlin, we can now simplify the way we can use them. All driven by Extension Functions. We touched on this back in my post about Extending Resources.

Starting an Activity

Let’s start with the most common case. If we are inside a Context such an Activity, we can start another one in java.

Intent intent = new Intent(this, NextActivity.class);

Using Extensions, we can come to something a bit more readable.

startActivity {
component = componentFor(HomeActivity::class)

The higher-order function startActivity takes a lambda which is applied to a new Intent and then…

Loading bars and spinners are so last decade. And for a good reason. They can break the flow of a website or app. Facebook, for instance, started showing a “ghost” of what the content will look like:

The concept provides a smoother transition from the loading state to the actual content. It can also ensure, when using a soft animation; the user knows that the content is coming up, and nothing went wrong. In Android, this can be done using ViewAnimator. In this article, we are going to look at how to do this for ImageView and TextView instances.



In Java, static factory methods are useful to instantiate a Type when we don’t want to expose what implementation is produced. If we find a better way, or the business requirements change, we can change it internally without affecting the client of our Type.

It’s specially useful when our Type doesn’t take too many arguments. If we have more than 2 or 3, it may be more beneficial to use a Builder Object instead.

For example, let’s say that we have a lighting system that has different lifecycles depending on the day of the week:

abstract class DayOfTheWeek {…


Software Artisan

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store