DEV Community: Ranil Wijeyratne

Functional interfaces: Self-loathing in Kotlin

Ranil Wijeyratne — Fri, 12 Jul 2019 12:19:47 +0000

This post is a copy from previous posts on Medium (initial, follow-up) But since I'm planning on deleting my Medium account I moved them here.

Kotlin is a wonderful programming language. After roughly 12 years of Java programming working with Kotlin felt like putting on glasses after years of squinting: there's so much to love.

But like with every relationship, some of the quirks you only discover later in your life together. After migrating more and more Java code to Kotlin code, I noticed something rather odd and frankly a bit annoying.

It's the way Kotlin handles functional interfaces.

Java 7: a blast from the past

Let's go back in time to a world without lambdas. It was terribly verbose!

interface JavaInterface {
    String doSomething(Item item);
}

String delegateWork(JavaInterface f) {
    return f.doSomething(item);
}

void doWork() {
    delegateWork(new JavaInterface() {
        @Override
        public String doSomething(Item item) {
            return "Item = " + item;
        }
    });
}

Java 8: Lambdas to the rescue!

Finally Java 8 gave us Lambdas and we could get rid of a lot of code and focus on what's important. Also we weren't forced to write our own functional interface for every simple function we could just use some that oracle provided such as: java.util.function.Function<T, R>

@FunctionalInterface
interface JavaInterface {
    String doSomething(Item item);
}

String delegateWork(JavaInterface f) {
    return f.doSomething(item);
}

String delegateOtherWork(Function<Item, String> f) {
    return f.apply(item);
}

void doWork() {
    delegateWork(item -> "Item = " + item);
    delegateOtherWork(item -> "Item = " + item);
}

Things were nice until you realised that even though you now had function types they still weren't first-class citizen in the language. Want proof? Guess how many "Types of Functions" had to be introduced in Java? One? Three? Five?

43!

Don't believe me, see for yourself: https://docs.oracle.com/javase/8/docs/api/java/util/function/package-summary.html

And if that's not enough for you, add jOOL to the mix and you have access to 35 more: https://github.com/jOOQ/jOOL/tree/master/jOOL/src/main/java/org/jooq/lambda/function
Because who wouldn't love coming across a method signature that looks like this:

Function5<String, String, String, String, String, Tuple3<String, String, String>> higherOrder(Function12<String, Integer, String, Object, Object, Object, BiFunction<String, Integer, String>, String, Integer, Long, String, Double, Optional<Tuple2<String, String>>>)

😜 side note: jOOL is actually quite a neat library, and worth checking out.

Kotlin help us!

Now let's add Kotlin to the mix. In Kotlin functions are first-class citizen. So no need to remember dozens of slightly different function types. You just need to remember Kotlin's Function Type Syntax:

(Parameter1Type, Parameter2Type, ParameterNType) -> ReturnType

That's it, that's all there's to it.

Trouble in paradise

So ok, why are we here, what's the problem?

As mentioned earlier, as I migrated more and more code from Java to Kotlin. I came across some issues when working with custom functional interfaces. Because sometimes you want that additional descriptiveness.

Let's go back to our Java 8 example

@FunctionalInterface
interface JavaInterface {

    String doSomething(Item item);
}

class JavaComponent {

    private Item item = new Item();

    String delegateWork(JavaInterface f) {
        return f.doSomething(item);
    }

    String delegateOtherWork(Function<Item, String> f) {
        return f.apply(item);
    }
}

Now let's use it from Kotlin code

delegateWork { "Print $it" }
delegateOtherWork { "Print $it" }

Nice this is great, just what we expected! Ok now let's migrate this JavaComponent class to Kotlin. Notice we've changed the java.util.function.Function<Item, String> to a Kotlin function type (Item) -> String

class KotlinComponent(private val item: Item = Item()) {

    fun delegateWork(f: JavaInterface): String {
        return f.doSomething(item)
    }

    fun delegateOtherWork(f: (Item) -> String): String {
        return f.invoke(item)
    }
}

Let's see what happens when we use these higher order functions from Java code.

delegateWork(item -> "Print: " + item);
delegateOtherWork(item -> "Print: " + item);

Nothing out of the ordinary as expected we can use the same lambda for both methods. Let's see what happens when we do what we'd expect in Kotlin:

delegateWork { "Print $it" }

Error: Kotlin: Type mismatch: inferred type is () -> String but JavaInterface was expected

What happened? It seems the compiler can't figure out that the signature of the lambda is the same as the functional interface method. https://kotlinlang.org/docs/reference/java-interop.html#sam-conversions

So we have to explicitly say what we expect:

delegateWork(JavaInterface { "Print $it" })

I think this is rather disappointing but it's not too bad. Now let's see what happens when we also migrate the interface to Kotlin:

interface KotlinInterface {
    fun doSomething(item: Item): String
}

class KotlinComponent(private val item: Item = Item()) {

    fun delegateWork(f: KotlinInterface): String {
        return f.doSomething(item)
    }

    fun delegateOtherWork(f: (Item) -> String): String {
        return f.invoke(item)
    }
}

When we use the KotlinComponent class from Java, as expected nothing changes, the lambdas remain exactly the same. What if we use it from Kotlin code:

delegateWork { "Print $it" }

Error: Kotlin: Type mismatch: inferred type is () -> String but KotlinInterface was expected

It seems the SAM conversion fails again. Now what if we just explicitly mention the Interface like we did before?

delegateWork(KotlinInterface { "Print $it" })

Error: Kotlin: Interface KotlinInterface does not have constructors

This didn't help either. We need to create an anonymous object to make it work:

delegateWork(object : KotlinInterface {
    override fun doSomething(item: Item): String {
        return "Print $item"
    }
})

Yikes! This feels like working with Java 7 all over again. Sadly this is because Kotlin doesn't yet support SAM conversion for Kotlin interfaces so we have to create this anonymous object. See also:
https://youtrack.jetbrains.com/issue/KT-7770
https://stackoverflow.com/a/43737962/611032

Alias time!

So how can we avoid these verbose anonymous objects and still use a custom name for the function? We use a type alias:

/**
 * Very helpful comment.
 */
typealias KotlinFunctionAlias = (Item) -> String

fun delegateAliasWork(f: KotlinFunctionAlias): String {
  return f.invoke(item)
}

So now we can pass in a lambda the way we'd expect and we still have the benefit of a custom name for the function.

delegateAliasWork { "Print $it" }

So all is is well then, case closed, time to go home. Unfortunately not quite.

Lost in translation

One minor issue with type aliases is that while you can name the function type, you cannot name the method name:

val iface: JavaInterface = JavaInterface { "Print $it" }
iface.doSomething(item)

val alias: KotlinFunctionalAlias = { item -> "Print $item" }
alias.invoke(item)
alias(item)

Choosing good names for the type alias and variable can mitigate the issue. Luckily we developers are great at naming things 😜

Type safety

The bigger issue is that while the type alias gives us a different name, they aren't really different types, so we're not actually type safe.

Let's look at a Java example with two functional interfaces that have the same method signature.

JavaInterface1 f1 = item -> "Print " + item;
JavaInterface2 f2 = item -> "Print " + item;
f1 = f2;

Error: java: incompatible types: JavaInterface2 cannot be converted to JavaInterface1

This is what we'd expect we don't want to mix apples and oranges here.

What happens if we do the same thing with our Kotlin type aliases? (I think you know where I'm going with this)

var f1: KotlinFunctionAlias1 = { item -> "Print $item" }
var f2: KotlinFunctionAlias2 = { item -> "Print $item" }
var f3: (Item) -> String = { item -> "Print $item" }
f1 = f2
f2 = f3
f1 = f3

This works fine, the compiler doesn't complain because like I mentioned they aren't actually different types. They're all simply: (Item) -> String

Solutions

So let's quickly recap the different ways we can deal with Kotlin's missing SAM conversion for Kotlin interfaces and their upsides and downsides

Leave functional interfaces as Java interfaces

+ Good Java interoperability
+ Support for custom method name
+ Type safe

- Need to prefix Kotlin lambda with interface name
- Additional parentheses needed
- Need to maintain Java code

Use a type alias for Kotlin function types

+ Good Java interoperability
+ Easy to use

- Not type safe
- No custom method name

Use inline classes

Another option we haven't yet discussed is the use of the experimental Kotlin inline classes. You could "wrap" a Kotlin Function with an inline class.

inline class KotlinInlineInterface(val doSomething: (Item) -> String)

fun delegateInlineWork(f: KotlinInlineInterface): String {
    return f.doSomething.invoke(item)
}

delegateInlineWork(KotlinInlineInterface { "Print $it" })

Even though this works, I don't thinks it's an appropriate way of using inline classes. Also Java interoperability isn't currently supported: https://kotlinlang.org/docs/reference/inline-classes.html#mangling

Always use Kotlin function types

Yes you could just use (ParamT) -> ReturnT types everywhere. Often that will be sufficient but as your application grows it might get harder to read and maintain and more error-prone.

Live with anonymous objects

Of course if you don't mind, you can just live with the anonymous objects, hope that someday Kotlin will support full SAM conversion and make use of the wonderful IDE integration to migrate your anonymous objects to lambdas

¯\(ツ)/¯

Jetbrains Feedback

There has been a short discussion on Reddit: https://www.reddit.com/r/Kotlin/comments/bipj0q/functional_interfaces_selfloathing_in_kotlin/

Since then I got a response from Roman Elizarov on the subject

// Detect dark theme var iframe = document.getElementById('tweet-1122951159482855424-980'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1122951159482855424&theme=dark" }

I tried the mentioned Kotlin compiler option:

// Gradle Kotlin DSL
tasks.withType<KotlinCompile> {
    kotlinOptions.freeCompilerArgs += "-XXLanguage:+NewInference"
}
// Gradle Groovy DSL
compileKotlin {
    kotlinOptions {
        freeCompilerArgs += "-XXLanguage:+NewInference"
    }
}

If you're more into other build systems, refer to Kotlin documentation (Maven / Ant) to see how to pass Kotlin compiler arguments.

Problem solved?

First let's see what happens when we use a Kotlin functional interface in Kotlin code:

fun delegateWork(f: KotlinInterface): String {
    return f.doSomething(item)
}

delegateWork { item -> "Print: $item" }

Error: Type mismatch: inferred type is (Nothing) -> TypeVariable(_L) but KotlinInterface was expected

What about explicitly specifying the interface?

delegateWork(KotlinInterface { item -> "Print $item" }

Error: Interface KotlinInterface does not have constructors

Bummer! We still need an anonymous object.

What about using a Java functional interface in Kotlin code?

fun javaInterface(f: JavaInterface) {
    val res = f.doSomething(item)
    output(res)
}

javaInterface { item -> "Print: $item" }

Finally: just what we expected. All is well, beer well deserved!

Patience young Jedi

If you're observant, you'll see this during the build:

w: ATTENTION!
This build uses unsafe internal compiler arguments:
-XXLanguage:+NewInference

This mode is not recommended for production use,
as no stability/compatibility guarantees are given on
compiler or generated code. Use it at your own risk!

So what does that mean? It means what it says here: this isn't really safe to use yet. But knowing JetBrains is working in that direction I'd suggest that we, for now, do things the following way (most favourable to least favourable)

Keep functional interfaces as Java code
Use type aliases for Kotlin function types (if you can live with potentially mixing apples and oranges)
Live with the anonymous objects

Thanks for reading. As always I'm open to criticism and feedback.

Securing data with BiometricPrompt

Ranil Wijeyratne — Sun, 19 May 2019 19:27:20 +0000

Before Android 9 Pie, your options to implement a fingerprint scanning dialog were:

Build your own from scratch
Copy Google's sample implementation
Use some unofficial library

Unfortunately neither of those options are great. Unless of course you have really specific UI requirements and need to build your own. But for most applications it's enough to have a generic dialog and it'd be great to have an official one.

Luckily, since Android 9 Pie, Google has introduced the BiometricPrompt that addresses this issue. Hopefully this post will help you integrate it.

In all fairness, there are some great existing blog posts on the matter. But kudos aside, the ones I came across lack some things, so I'm hoping this post will fill the gaps.

Mark Ellison's post is great but his example only works on Android 9 Pie and doesn't address encrypting data. Natig Babayev's post also shines, but it doesn't show how it could be encapsulated and also doesn't address encryption.

As always I welcome, and actually seek feedback, so feel free to comment critically.

The basics

Since most Android device manufacturers either struggle, or deliberately prevent, to upgrade their devices to newer Android versions, we're still forced to support older Android versions.

Luckily Google is doing the heavy lifting with their AndroidX libraries (formerly known as Support Library)

So first of all you'll need to add an additional dependency to make use of the Biometric Prompt on older Android versions.

implementation 'androidx.biometric:biometric:1.0.0-alpha04'

The basic components

The main class involved in the biometric prompt is, what a surprise, called androidx.biometric.BiometricPrompt. You can create an instance using its only public constructor:

/**
 * ...
 * 
 * @param fragmentActivity A reference to the client's activity.
 * @param executor An executor to handle callback events.
 * @param callback An object to receive authentication events.
 */
public BiometricPrompt(@NonNull FragmentActivity fragmentActivity,
                       @NonNull Executor executor, 
                       @NonNull AuthenticationCallback callback)

The third parameter: AuthenticationCallback is an abstract static class with three non-abstract methods, so technically we won't have to override any of them.

So for the sake of a simple "hello-world" prompt we can pass an anonymous object without overriding anything.

BiometricPrompt(fragmentActivity, executor, 
    object : BiometricPrompt.AuthenticationCallback() {})

Secondly we need to describe what the prompt looks like. That's where the BiometricPrompt.PromptInfo comes into play. It conveniently provides a builder class:

val cancelString = activity.getString(android.R.string.cancel)
BiometricPrompt.PromptInfo.Builder()
    .setTitle("Prompt Title") // required
    .setSubtitle("Prompt Subtitle")
    .setDescription("Prompt Description: lorem ipsum")
    .setNegativeButtonText(cancelString) // required
    .build()

That's all that can be configured. It should be quite self-explanatory. Only the Title and NegativeButtonText is required.

To launch the prompt, all we have to do is call the authenticate method.

val biometricPrompt = BiometricPrompt(...)
val promptInfo = BiometricPrompt.PromptInfo.Builder()...

biometricPrompt.authenticate(promptInfo)

left: BiometricPrompt on Android 7 Nougat / right: BiometricPrompt on Android 9 Pie

Encryption

In my opinion encrypting data is at the heart of using biometric authentication in the first place. So now that we have a working prompt we should look into it.

⚠️ Important Disclaimer ⚠️ I'm not an in depth security expert! The code and specifically the chosen encryption parameters, are based on Google's previously mentioned sample and merely adapted to the new BiometricPrompt.

Key & Cipher

To encrypt data we need a SecretKey and a Cipher.

fun createKey(): SecretKey {
  val algorithm = KeyProperties.KEY_ALGORITHM_AES
  val provider = "AndroidKeyStore"
  val keyGenerator = KeyGenerator.getInstance(algorithm, provider)

  val keyName = "MY_KEY"
  val purposes = KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
  val keyGenParameterSpec = KeyGenParameterSpec.Builder(keyName, purposes)
          .setBlockModes(BLOCK_MODE)
          .setEncryptionPaddings(PADDING)
          .setUserAuthenticationRequired(true)
          .build()

  keyGenerator.init(keyGenParameterSpec)
  return keyGenerator.generateKey()
}

fun getEncryptCipher(key: Key): Cipher {
  val algorithm = KeyProperties.KEY_ALGORITHM_AES
  val blockMode = KeyProperties.BLOCK_MODE_CBC
  val padding = KeyProperties.ENCRYPTION_PADDING_PKCS7
  return Cipher.getInstance("$algorithm/$blockMode/$padding").apply { 
    init(Cipher.ENCRYPT_MODE, key) 
  }
}

The main take away here is the setUserAuthenticationRequired(true) method call during key creation that:

Sets whether this key is authorized to be used only if the user has been authenticated.

By default, the key is authorized to be used regardless of whether the user has been authenticated.

This basically means: to use the key you have to provide a form of authentication, i.e. your fingerprint. For further explanation refer to the Android documentation 🔍

Since no key length is specified, Android uses a default key length: for AES this is set to 128 bits. For more information on cryptography on Android refer to the documentation 🔍

Using the cipher to encrypt

To encrypt data using the cipher just call its doFinal(byte[] input) method. For decryption later on, we need to keep hold of the cipher's initialization vector.

val clearTextData: ByteArray
val encryptedData: ByteArray = cipher.doFinal(clearTextData)

// save encrypted data & init vector: i.e. in shared preferences
val dat = Base64.encodeToString(encryptedData, Base64.DEFAULT)
val iv  = Base64.encodeToString(cipher.iv, Base64.DEFAULT)
sharedPreferences.edit {
    putString(ENCRYPTED_DATA, dat)
    putString(INITIALIZATION_VECTOR, iv)
}

Decryption

To decrypt the encrypted data you'll need

previously created SecretKey
previously used initialization vector
decryption cipher

fun getKey(): Key? {
  val keyStore: KeyStore = KeyStore.getInstance("AndroidKeyStore").apply { 
    load(null) 
  }
  return keyStore.getKey("MY_KEY", null)
}

fun getDecryptCipher(key: Key, iv: ByteArray): Cipher {
  val algorithm = KeyProperties.KEY_ALGORITHM_AES
  val blockMode = KeyProperties.BLOCK_MODE_CBC
  val padding = KeyProperties.ENCRYPTION_PADDING_PKCS7
  return Cipher.getInstance("$algorithm/$blockMode/$padding").apply { 
    init(Cipher.DECRYPT_MODE, key, IvParameterSpec(iv)) 
  }
}

Using the cipher to decrypt

This is quite straight forward and resembles the encryption call

val encryptedData: ByteArray = getEncryptedData()
val clearTextData: ByteArray = cipher.doFinal(encryptedData)

"Tink" different

Like I mentioned earlier I'm not an in depth security expert. For people like me (and others) Google created Tink with the goal of making encryption simpler and harder to misuse.

With Tink's Android flavor com.google.crypto.tink:tink-android:1.2.2 the whole encryption/decryption breaks down to this simpler and easier to understand code:

Config.register(TinkConfig.LATEST)

val keysetHandle = AndroidKeysetManager.Builder()
        .withSharedPref(activity, TINK_KEYSET_NAME, null)
        .withKeyTemplate(AeadKeyTemplates.AES256_GCM)
        .withMasterKeyUri(MASTER_KEY_URI)
        .build().keysetHandle

val aead = AeadFactory.getPrimitive(keysetHandle)
val encrypted = aead.encrypt("SECRET!".toByteArray(), null)
val cleartext = aead.decrypt(encrypted, null)

A lot of internals we've seen before are now hidden: Cipher, initialization vector, encryption parameters etc.

Unforunately the previously discussed flag setUserAuthenticationRequired is not set, and it's currently not possible to pass this AEAD (Authenticated Encryption with Associated Data) to the BiometricPrompt for "authentication".

I created an issue on Github for this. When there's news on the matter I'll write a follow-up post.

Tying things together

Now that we have a working prompt and understand how to encrypt data, we can tie the two together. Just pass the cipher required to en-/decrypt to the BiometricPrompt:

val promptCrypto = BiometricPrompt.CryptoObject(cipher)
biometricPrompt.authenticate(promptInfo, promptCrypto)

The CryptoObject you pass in, will be "unlocked" (remember the flag we set when creating the key) and passed on to the onAuthenticationSucceeded callback method of the previously seen AuthenticationCallback

override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
    super.onAuthenticationSucceeded(result)
    result.cryptoObject?.cipher?.let { cipher ->
        // encrypt or decrypt data with cipher
    }
}

Handling errors

Besides the succeeded callback method, there are two other callback methods for failed attempts:

onAuthenticationFailed "Called when a biometric is valid but not recognized". Probably not something you need to address because there's already a default animation implemented in the prompt.

onAuthenticationError "Called when an unrecoverable error has been encountered and the operation is complete. No further actions will be made on this object"

The error callback method provides int errCode, CharSequence errString that can be used to handle different errors and display feedback. For instance

override fun onAuthenticationError(errorCode: Int, 
                                   errorString: CharSequence) {
    super.onAuthenticationError(errorCode, errString)
    when (errorCode) {
        ...
        BiometricPrompt.ERROR_TIMEOUT -> // user fell asleep ;-)
        ...
    }
}

Refer to the Android documentation to see all available error codes.

Build for convenience

No even though there are lots of different errors that can be handled using the biometric prompt, I'd argue that in most cases you only want to deal with two cases. Either encryption/decryption works 👍 or it doesn't 👎

So why not implement a supporting class that provides convenience for the two cases and encapsulates everything we previously discussed. API Suggestion:

fun encryptPrompt(data: ByteArray,
                  failedAction: () -> Unit,
                  successAction: () -> Unit)

fun decryptPrompt(failedAction: () -> Unit,
                  successAction: (ByteArray) -> Unit)

So in the succeeded and error callbacks of AuthenticationCallback we can do the following:

Encrypt case

fun onAuthenticationSucceeded(result: AuthenticationResult) {
    super.onAuthenticationSucceeded(result)
    result.cryptoObject?.cipher?.let { resultCipher ->
        val iv = resultCipher.iv
        val encryptedData = resultCipher.doFinal(data)
        saveEncryptedData(encryptedData, iv)
        activity.runOnUiThread { successAction() }
    }
}

fun onAuthenticationError(errCode: Int, errStr: CharSequence) {
    super.onAuthenticationError(errCode, errStr)
    Log.d(TAG, "Authentication error. $errStr ($errCode)")
    activity.runOnUiThread { failedAction() }
}

Decrypt case

fun onAuthenticationSucceeded(result: AuthenticationResult) {
    super.onAuthenticationSucceeded(result)
    result.cryptoObject?.cipher?.let { cipher ->
        val encrypted = getEncryptedData()
        val decryptedData = cipher.doFinal(encrypted)
        activity.runOnUiThread { successAction(decryptedData) }
    }
}

fun onAuthenticationError(errCode: Int, errStr: CharSequence) {
    super.onAuthenticationError(errCode, errStr)
    Log.d(TAG, "Authentication error. $errStr ($errCode)")
    activity.runOnUiThread { failedAction() }
}

Usage

This should enable you to conveniently use the biometric prompt:

val promptManager = BiometricPromptManager(fragmentActivity)
promptManager.encryptPrompt(
    data = secureText.toByteArray(),
    failedAction = { showToast("encrypt failed") },
    successAction = { showToast("encrypt success") }
)

promptManager.decryptPrompt(
    failedAction = { showToast("decrypt failed") },
    successAction = { showToast("decrypt success: $it") }
)

Alternatives

Of course if you require a more detailed error handling or don't like this style you could also

use custom response codes and/or do everything in one callback method
add different callback actions (for different errors)
pass error code to failedAction

Issues

Unfortunately, I came across the following issue when using the AndroidX biometric prompt in a Fragment on Android 8 and earlier.

java.lang.IllegalStateException: FragmentManager is already executing transactions

According to others on Stackoverflow the issue seems to have been introduced with the newest alpha04 version

To "resolve" the issue: you can artificially delay the call with a Handler , or revert to version alpha03.

Handler().postDelayed({
        // launch biometric prompt for Fragment 
}, 0)

The complete code can be found on Github:

stravag / android-sample-biometric-prompt

Biometric Prompt Sample App

android-sample-biometric-prompt

Biometric Prompt Sample App

View on GitHub

Happy coding!