The Best Way to Collect a Flow in Kotlin – launchIn

At some point you’ll need to collect (receive items) from a Flow (reactive stream) within a Kotlin Coroutine.  More than likely you will use a launch on a CoroutineScope, and then collect like this:

scope.launch {
  flow
    .onEach { println(it) }
    .collect()
}

This works great, but there is a better way for most use cases. It’s using a function called launchIn. What’s launchIn? It’s just shorthand to do what you did above. This is the equivalent logic as above, but using launchIn.

flow
  .onEach { println(it) }
  .launchIn(scope)

This is less code to write, but more importantly it’ll get you out of some hard to debug situations when collecting from Flows. The non obvious thing to understand is that collect() will block the coroutine until the flow has finished emitting. This behavior is sometimes desired, but for me it’s not in most cases.

In the example below, you’d think that both Flows are being collected at the same time, but flow1 is collected until the Flow finishes emitting, and then flow2 is collected until it is finished emitting.

scope.launch {
  flow1
    .onEach { println(it) }
    .collect()
  
  // Will not run until flow1 finishes emitting
  flow2
    .onEach { println(it) }
    .collect()
}

To collect both in parallel, you’d need to write this:

scope.launch {
  flow1
    .collect { println(it) }
}
scope.launch {
  flow2
    .collect { println(it) }
}

This is where launchIn comes to the rescue to make this reach much easier in my opinion. Here is the equivalent using launchIn:

myFlow1
  .onEach { println(it) }
  .launchIn(coroutineScope)
myFlow2
  .onEach { println(it) }
  .launchIn(coroutineScope)

I like launchIn because it’s less code to write, I don’t have to have indentation, and I just found it easier to understand.

In no way does this mean that the normal launch() and collect() aren’t great things to use, but for most use cases, I’d suggest considering using launchIn().

Kotlin Actors – No Drama Concurrency

Kotlin Actors are part of the Kotlin Coroutines library. I’ll walk you through the reasons why I use Kotlin Actors to achieve concurrency, while leveraging Coroutines to process reactive events in unknown order.

Concurrency?

  • Allows events to happen out-of-order or in partial order, without affecting the final outcome.
  • This allows for leveraging parallel execution without giving up determinism.

Why Does Android need Reactive Programming?

  • Click Events
  • Intents
  • Networking Requests
  • Disk Writes
  • etc.

Kotlin Coroutines?

Essentially, Kotlin Coroutines are light-weight threads. They are launched in a context of some CoroutineScope.

Kotlin Actors?

  • A Single Kotlin Coroutine
  • Processes incoming Messages
  • Backed by a Channel
  • Concurrent

Actors receive Messages (Intentions) via a Channel

Channels are the only way to safely communicate across Coroutines.

This example implements a Shopping Cart Dao from my GitHub Project ShoppingApp. I’ve created a type called Intention which are sent across the channel as messages. The intentions represent actions I want to perform, but keep my data thread safe.

sealed class Intention {
    class FindByLabel(
        val label: String,
        val deferred: CompletableDeferred<ItemWithQuantity?>
    ) : Intention()

    class Upsert(val itemWithQuantity: ItemWithQuantity) : Intention()

    class Remove(val itemWithQuantity: ItemWithQuantity) : Intention()

    object Empty : Intention()
}

Actors Process Messages Sequentially in a for() loop

These messages (Intentions) come in across a Channel from other Coroutines, get queued, and then get processed by the Actor sequentially to achieve concurrency.

scope.actor<Intention> {
    for (intention in channel) {
        // Process Messages/Intentions
        when (intention) {
            is Intention.FindByLabel -> {
                // ...
            }
            is Intention.Upsert -> {
                // ...
            }
            is Intention.Remove -> {
                // ...
            }
            is Intention.Empty -> {
                // ...
            }
        }
    }
}

Sending Messages to the Actor – send() vs offer()

To send messages to the actor, you send a message to it using actor.send(intention) or actor.offer(intention). Here are the differences between them (from the Kotlin documentation of SendChannel).

CompletableDeferred to await() Results

We send in messages to the actor, but sometimes we want to wait for a result once the message has been processed by the actor. We use CompletableDeferred to do this. We await() the result, like in this example where we are querying for a value:

class FindByLabel(
    val label: String,
    val deferred: CompletableDeferred<ItemWithQuantity?>
) : Intention()
// ---
val deferred = CompletableDeferred<ItemWithQuantity?>()
actor.send(
    Intention.FindByLabel(
        label = label,
        deferred = deferred
    )
)
val result : ItemWithQuantity? = deferred.await()

Aren’t Actors Marked with @ObsoleteCoroutineApi?

Yes, but complex actors will also support the same use cases, and there will be a clear path. Also, there is no planned replacement at this point. See the response from the Kotlin Coroutines tech lead from the GitHub issue:

Video & Slides

I was able to present this to Boston Android meetup group and 18 other meetup groups on Tuesday, July 14th which was an amazing experience. The video will be available soon and I’ll be sure to put it here. Here are the slides for now.

Links

Where Should I Put Kotlin Code in an Android Project?

Based on the results of a poll of 371 Android developers, the majority of responses endorse using “src/main/java” for Kotlin code in Android only projects.  My answer is always it depends, but let’s see why you would use “src/main/java” the majority of the time, and why you’d want to use “src/main/kotlin” in some cases.

Why src/main/java?

79% of people say it should go in “src/main/java”.  Here’s why:

  • The official documentation Android Developer Documentation recommends it, and shows additional configuration you must add to support a “src/main/kotlin” source set.
    android {
       sourceSets {
           main.java.srcDirs += 'src/main/kotlin'
       }
    }
    
  • When you create a new project Kotlin project in Android Studio, it uses “src/main/java” as the location for your Kotlin code.
  • I personally really like it for the reason that all of your source is in a single place, making it easier to find related code in a project mixed with Java.  This can help maintain consistency to have all your code in one location for any project that has or had Java code in the past.
  • There are no longer issues with the Kotlin Gradle Plugin which prevented you from mixing Kotlin and Java code in the same directory.

Why src/main/kotlin?

21% of people say it should go in  “src/main/kotlin”.  Here’s why:

  • Some projects like the clean separation of the languages into different directories.  While this is nice idea, from a pragmatic standpoint, having all your code in a single place is the ideal for discovery and browsing in my opinion.
  • Some projects are 100% Kotlin, so having this directory structure clearly calls this is a single to only write code in Kotlin.  This comes with the configuration overhead of each module, but if you share Gradle config between multiple projects, you’d only have to do this once.
  • OkHttp does it, but realize this is because it’s a Kotlin only project that is meant to be used on multiple platforms (including the JVM & Android).

Kotlin Source Sets beyond Android

The answers above only apply for Android only projects.  Kotlin is more than just a programming language used on Android.  It’s being used for Kotlin Multiplatform to create code that runs on iOS, it’s used in Kotlin Native to get blazing fast, low level speed and Kotlin JS to run in your Node server or web application.

You can see how some Kotlin Multiplatform projects are using source source sets such as “commonMain” where common code used for all platforms is kept, and then you can have additional source sets like “iosMain” for platform specific implementations.

I’m not going to pretend that I’m a Kotlin Multiplatform expert, but check out the official documentation, and the KaMPKit Github Repo from TouchLab to see a sample project of Kotlin Multiplatform.

Toggling to your Debug Activity

Toggling to your Debug/Diagnostic Activity made easy.
android:taskAffinity=”com.handstandsam.app.diagnostic”

AndroidManifest.xml, Activity declaration, add a taskAffinity property…

<activity
    android:name="com.handstandsam.app.diagnostic.DiagnosticActivity"
    android:icon="@drawable/ic_launcher_diagnostic"
    android:label="Diagnostic"
    android:launchMode="singleTask"
    android:taskAffinity="com.handstandsam.app.diagnostic"
    android:screenOrientation="portrait"
    android:theme="@style/AppTheme">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>    

I just had a breakthrough regarding the definition of debug activities in your app. If you specify a different taskAffinity for your debug activity, it’ll show appear in your task launcher like a separate app allowing you to toggle back and forth, making it super easy to jump around.

Thanks to the library Chuck for using this method so I was able to figure out! https://github.com/jgilfelt/chuck/blob/master/library/src/main/AndroidManifest.xml

Determine TLS Version & Cipher Suite Used in OkHttp Calls

Working with SSL Handshakes is no fun (to an application developer like me), but with an OkHttp 3 Interceptor, and the nicely typed TlsVersion and CipherSuite objects, it becomes a lot less painful.

If you want to know which TLS version and Cipher Suite was ACTUALLY used for a specific request, use this OkHttp 3 Interceptor:

 

You’ll get Logcat output that looks like this:

OkHttp3-SSLHandshake: TLS: TLS_1_2, CipherSuite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

With OkHttp 3, you can specify what TLS version(s) and Cipher Suite(s) you want your calls to support (But it only works on Lollipop and higher).

Check out the OkHttp 3 documentation on HTTPS for more info.

Note: You can get newer versions of TLS (Like 1.1 and 1.2) working on < Lollipop, but that has to be done outside the OkHttp 3 configuration unfortunately. See how to do that here.  Maybe this is a good reason to bump your minSdk to 21 🙂

Fragmented Podcast Intro Song Lyrics, Performed by Blueprint

The Fragmented Podcast which focuses on Android Development has a new intro song by Blueprint which is pretty nerdy/awesome. It’s new as of February 2017 and is first featured in Episode 72 about app shortcuts.  In case you want to sing along, here are the lyrics:


Null check, inject and bind, APK, lifecycle and design.
Null check, inject and bind, APK, lifecycle and design.
Null check, inject and bind, APK, lifecycle and design.
Null check, inject and bind, APK, lifecycle and design.
It’s time.

Continuous Integration for Android Using Jenkins

Dan Jarvis and I co-presented a talk entitled “Continuous Integration for Android Using Jenkins” at the Android Summit 2016 on August 26, 2016 in McLean, Virginia.  Here are our slides.  Video should be available in the coming weeks and will be posted here and on Twitter.

Some Highlights:

  • Automate everything (If you can script it, do it)
  • “There’s an app for that” on a smartphone, “There’s a plugin for that” on Jenkins
  • The Android Emulator is great for scalability in CI, it’s fast and you can configure it in many ways
  • Shard for speed

Lots of Upcoming Speaking Engagements!

I’m excited to announce I’ve been accepted to talk at a bunch of upcoming events.


Espresso: A Screenshot is Worth 1,000 Words

Do your product owners, designers and the people that pay you understand what in the world your Espresso tests are doing and why they are valuable? You’ve spent so much time and effort writing these tests and your whole team deserves to get the most benefit out of them. In this talk you’ll learn how to setup your Espresso tests to take programatic screenshots, and leverage the Robot pattern of testing for clean, readable, and maintainable tests. You’ll also learn guidelines on when it’s appropriate to write Espresso tests instead of Robolectric or Unit tests, and how to leverage mock data to make your Espresso tests run with Tesla-like speed.

I have architected the Espresso test setup for our Capital One Wallet Android team and helped execute our ongoing continuous integration efforts. We’ve seen a 4x+ speed improvement over Appium, have more maintainable tests, and now have visibility for anyone to look into our test coverage.


“Continuous Integration Tips & Tricks for Android”
This is a co-talk with Dan Jarvis, the tech lead for Capital One Wallet for Android.

Network Calls from Android Device to Laptop over USB via ADB

I’ve seen a few articles about using the “adb reverse” command which allows you to make specific network calls to your laptop over USB, but when explaining this concept to others, they had a hard time visualizing how it worked.  I’ve put together this post to help illustrate how this works and spotlight some use cases.

Android’s “adb reverse” command is available in Lollipop and higher versions of Android (Platform 21+) and it allows you to access a server running on your computer from your Android device over USB without any network (WiFi or Cellular).  This is done through a technique called a reverse proxy.

What’s a reverse proxy? (via Wikipedia)

A type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as though they originated from the proxy server itself.

Use Case 1 : Android -> Server running on laptop

Android Device (localhost:8080) -> Server running on Computer (localhost:8081)

adb reverse tcp:8080 tcp:8081

Screen Shot 2016-02-01 at 2.42.15 PM

Use Case 2 : Android -> WireMock on laptop -> Server accessible only on laptop (i.e. VPN)

Download the WireMock JAR and run it using the following command in a Terminal

java -jar wiremock-standalone-2.0.8-beta.jar --port=8081 --proxy-all="https://internal.myapp.com"

Android Device (localhost:8080) -> WireMock running on Computer (localhost:8081)

adb reverse tcp:8080 tcp:8081

This allows you to have your physical Android device access resources that are only available through your laptop.

When you’re done, turn off all reverse proxy port mappings:

adb reverse --remove-all

Sources:

Contactless Payments on Capital One Wallet for Android!

It’s been super hard to not share this info as I’ve done presentations on Host Card Emulation (HCE) presentations, but on October 14th the feature I’ve been leading Android development efforts on launched! Capital One Wallet – Google Play Store. This is a project I’ve been a part of for almost a year and it’s so cool to see it in the wild and right along side of Android Pay, Samsung Pay and the rest. It supports Visa and Mastercard and is pretty awesome. Capital One was the first bank in the US to support contactless payments in an Android app and it’s super exciting to have been a part of that.

I tried to do my with presentations but it always killed me that I wasn’t able to share what we were doing. I did feel like I was able to explain how HCE works on Android, but wasn’t able to give much more info at the time. Check out my presentation video and slides from Droidcon NYC.

Tap to Pay Screen
Tap to Pay
Payment Sent Screen
Payment Sent