Kotlin Bricks: When is better than If

One of my favorite things about Kotlin is the when expression. Its like a combination of an if and a switch you might be familiar with from Java. Performance is that of a standard if statement, , but it reads better and is more functional. Here is a quick example that handles specific values, ranges, and anything beyond.

val people = 10
when (people) {
    0 -> print("none")
    1 -> print("party of one")
    2 -> print("a couple")
    3, 4, 5 -> print("a few")
    in 6..12 -> print("a group")
    in 13..50 -> print("a gathering")
    else -> print("way too many")

My favorite ways to use when is to have it return a value based on a condition. Here is an example where I get a string based on the value of an enum.

val message = when (status) {
    Status.ONLINE -> R.string.connected
    Status.OFFLINE -> R.string.offline
    Status.CHECKING -> R.string.checking
    else -> R.string.unknown

Another way to use when is more like an if else statement. I generally don't use there because it can lead to comprehension issues. Here is an example where a mammal weighing more than 300 it would never reach the print statement, even though you might expect it to.

when {
    animal.isMammal() -> growHair()
    animal.isBird() -> {
    animal.weight > 300 -> print("make way")

What is Gradle?

While some of you may know Gradle (or Maven or Ant) from other projects, for Android developers its of great importance to understand and utilize Gradle to its fullest. Gradle ensures your builds run as consistently as possible across multiple devices while empowering you to dynamically change and easily update the core requirements of your application.

Its like a recipe

Take a standard recipe, like this awesome chocolate cake – it contains a description of all the parts and instructions required to make it. For starters, you need flour, sugar, oil, and a bunch of other things. These are the Gradle dependencies. You also need a bunch of tools like a bowl, mixer, and measuring instruments. These are the Gradle plugins. Where do you get all this stuff? Probably your pantry or the grocery store; these are Gradle (Maven) repositories.

Now that you've collected all of your tools and ingredients, you'll need to follow the instructions to actually make the cake. For Android developers this means configuring the android object, telling it how you want the app built. configurationsbuildscript, and many others also provide instructions.

Finally, you've completed the instructions for sifting, whisking, and folding. Now its time to bake this cake! In our analogy gradle or gradlew executable is the oven. You pass in your build.gradle file and it bakes you an APK.

While many stop here, often recipes leave room for interpretation to make it your own. This is where Gradle really shines. You can inject your own ingredients (dependencies), tools (plugins), and instructions (additional code.) Just like modifying a cake, this could change the entire process. Maybe it takes longer to bake (slower build times) or it outputs multiple cakes (like a magical cake copy machine.)

This is just the beginning

After you build a project or two you'll find that many open source projects and tools utilize Gradle. It could be generating more code, archiving artifacts, counting the methods in your app, running adb commands, or even sending a message to your group chat when its done.

Android Bricks: Image loading

There are three major image loading libraries on Android. Their purpose is to manage network requests, caching, and display of images loaded from your web server. This is a key component in many apps and I'll walk your through how to pick one.

Picasso & Glide

I lumped these first two together because they function very similarly internally. Based entirely in the standard Android heap, these represent a straight forward and simple solution to image loading. You access a singleton, with a url and target, then the library does the rest. Its a short and sweet single line with no other required set up.





As you can see they are nearly identical. The difference is that Glide is configured for better memory performance right out of the box. It decodes images as Bitmap.Config.RGB_565 and resizes them to fit the view they'll occupy. Together these two configurations lead to fewer memory spikes and lower sustained memory usage.

Its worth noting that Picasso can be configured to work near identically, but its not the default. At the time of this writing Picasso 2.5.2 is 18 months old and contains some unfixed edge case bugs you'll need to manually patch. Glide remains in active development and maintains more regular releases.


Fresco is a product of Facebook's engineering team and backed by ashmem, making it a significantly different approach to nearly all other open source solutions. It is in heavy development but used on a massive scale. It also displays animated GIFs and progressive JPEGs giving it a leg up if you need support for either.

The biggest down side is the implementation. If you are dealing with a legacy codebase that loads a ton of images or has specialized needs you'll be hard pressed to adopt Fresco in a week, let alone a day. Since its such a different pattern and has its own special rules, you'll want to be 100% sure you like it before making a call one way or the other.

// In your custom Application.java

// Load image

As you might have noticed, draweeView looks a little odd and it requires an initialization call. With Fresco you cannot use a standard ImageView due to its optimizations around memory usage. One last down side here is that if you have a custom ImageView that applies an effect, Fresco could make it way more complicated and you'll be stuck trying to make it work rather than using something off the self.


  1. If you load a low to moderate amount of images Glide is a great choice with complexity built in if you need it down the road. 
  2. If you need GIFs, progressive JPEGs, really care about memory, or push a ton of images through your app go, with Fresco
  3. If you are totally into Square engineering (and who isn't?) go with Picasso.