Forem: Daniele Bottillo

Dark Mode: three Lint checks to help

Daniele Bottillo — Tue, 14 Apr 2020 10:43:06 +0000

Implementing Night Mode in Android is pretty straightforward: you have a theme with attributes and you can just define those attributes in the values-night qualifier and that's it. Five minutes and you are done. Well...

Most likely, reality is different: you have a project 4-5 years old, you don't even have a second theme, you have been using hardcoded colors #FFFFFF everywhere, maybe at times you felt brave and used instead a reference color @color/white . And maybe some other times you had to tint something programmatically with your friend ContextCompat.getColor(context, R.color.white)to tint that icon that comes from an API.

So now your code is polluted with things that will be hard to migrate to night: you have white defined directly, as a reference and in code. Guess what, white is not white in night mode anymore :)

And even if you have a brand new project, how do you make sure someone in future will not do the same, how do you enforce that night mode is implemented in every commit/PR? That's where Lint checks come in to help us!

Most of Android developers are familiar with Lint, but just as a refresh, Lint is a static analysis tool which looks for different types of bugs; you can find out more at https://developer.android.com/studio/write/lint.

Android comes with some Lint checks already made for you, but you can extend them and add your own! Here I'm going to show you how to add three Lint checks to your project: one to detect the usage of a direct color (eg. #FFFFFF), one to detect if you have defined a color and its night mode equivalent, and one to check all those color's name that may be problematic (eg. white, red, green).

I’ve already wrote a post about writing a custom Lint rule (https://dev.to/dbottillo/how-to-write-a-custom-rule-in-lint-23gf) so I'm going to assume you know how to write one and focus on the specific content of the three rules.

The first two rules are heavily inspired from Saurabh Arora's post: https://proandroiddev.com/making-android-lint-theme-aware-6285737b13bc

Direct Color Detector

The first rule is very simple: you shouldn't use any hardcoded color values like #FFFFFF.
Let's do a bit of TDD and write a test to validate what we want from the Lint rule:

    @Test
    fun `should report a direct color violation`() {
        val contentFile = """<?xml version="1.0" encoding="utf-8"?>
                <View 
                        xmlns:android="http://schemas.android.com/apk/res/android"
                        android:id="@+id/toolbar"
                        android:background="#453344"
                        android:foreground="#667788"
                        android:layout_width="match_parent"
                        android:layout_height="wrap_content" />"""
        TestLintTask.lint()
                .files(TestFiles.xml("res/layout/toolbar.xml", contentFile).indented())
                .issues(DIRECT_COLOR_ISSUE)
                .run()
                .expect("""
                    |res/layout/toolbar.xml:5: Error: Avoid direct use of colors in XML files. This will cause issues with different theme (eg. night) support [DirectColorUse]
                    |                    android:background="#453344"
                    |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    |res/layout/toolbar.xml:6: Error: Avoid direct use of colors in XML files. This will cause issues with different theme (eg. night) support [DirectColorUse]
                    |                    android:foreground="#667788"
                    |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    |2 errors, 0 warnings""".trimMargin())
    }

That's a lot to get through, let's break it down:

    val contentFile = """<?xml version="1.0" encoding="utf-8"?>
                <View 
                        xmlns:android="http://schemas.android.com/apk/res/android"
                        android:id="@+id/toolbar"
                        android:background="#453344"
                        android:foreground="#667788"
                        android:layout_width="match_parent"
                        android:layout_height="wrap_content" />"""

So, here we are defining the content of an hypothetic XML file containing a view tag with few attributes, both background and foreground contain an hardcoded color so we should expect two violations for both of them.
Next, we can build a test lint task, which is a class lint provides to test your test files:

    TestLintTask.lint()
                .files(TestFiles.xml("res/layout/toolbar.xml", contentFile).indented())

With .files() you can simulate to pass a number of files to lint. Think of them like all your project's file, in this case I'm just passing a fake res/layout/toolbar.xml whose contentFile is the xml we defined in the previous section.

    TestLintTask.lint()
    .files(TestFiles.xml("res/layout/toolbar.xml", contentFile).indented())
    .issues(DIRECT_COLOR_ISSUE)

With .issues you can pass a number of issues lint will use to perform the detection, in this case:

    val DIRECT_COLOR_ISSUE = Issue.create("DirectColorUse",
            "Direct color used",
            "Avoid direct use of colors in XML files. This will cause issues with different theme (eg. night) support",
            CORRECTNESS,
            6,
            Severity.ERROR,
            Implementation(DirectColorDetector::class.java, Scope.RESOURCE_FILE_SCOPE)
    )

So this is how you can create a new issue in Lint: DirectColorUse is the id of the issue, then there is a brief description and an explanation, followed by category, priority, severity and the implementation. The DirectColorDetector.kt file is the one responsible for detection. If you try to run the test of course it will fail since this file doesn't exist yet. Let’s create an empty one so we can run the test:

    class DirectColorDetector : ResourceXmlDetector() {
    }

Finally at the end of the test we have:

    TestLintTask.lint()
    .files(TestFiles.xml("res/layout/toolbar.xml", contentFile).indented())
    .issues(DIRECT_COLOR_ISSUE)
    .run()
    .expect("""
                    |res/layout/toolbar.xml:5: Error: Avoid direct use of colors in XML files. This will cause issues with different theme (eg. night) support [DirectColorUse]
                    |                    android:background="#453344"
                    |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    |res/layout/toolbar.xml:6: Error: Avoid direct use of colors in XML files. This will cause issues with different theme (eg. night) support [DirectColorUse]
                    |                    android:foreground="#667788"
                    |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    |2 errors, 0 warnings""".trimMargin())

run() makes the Lint task running and expect is a convenient method of the TestLintTask to assert what's the outcome of running Lint on those files. Here we are expecting those two violations about the background and the foreground values. Of course if you run this test it will fail since we haven't actually implemented DirectColorDetector yet. Let's do that:

    class DirectColorDetector : ResourceXmlDetector() {

        override fun getApplicableAttributes(): Collection<String>? = listOf(
                "background", "foreground", "src", "textColor", "tint", "color",
                "textColorHighlight", "textColorHint", "textColorLink", 
                "shadowColor", "srcCompat")

        override fun visitAttribute(context: XmlContext, attribute: Attr) {
            if (attribute.value.startsWith("#")) {
                context.report(
                        DIRECT_COLOR_ISSUE,
                        context.getLocation(attribute),
                        DIRECT_COLOR_ISSUE.getExplanation(TextFormat.RAW))
            }
        }
    }

Extending ResourceXmlDetector means we have a chance to do something when Lint is going through XML files, and through overriding some methods we can perform our check. Here we are using getApplicableAttributes() to notify Lint that the detector should be running on those attributes of any XML file. In the visitAttribute we have a chance to look at the attribute value and if it starts with # it means we can report a violation. You can do that by using the context (which is NOT the Android context but the Lint context) and call report on it with the values of the DIRECT_COLOR_ISSUE defined before.

Here we go! Now if you run the test it will be green.

Missing Night Color

This check is about having a color defined without a night version. And as we did before, let's first write a test to validate our assumption:

    @Test
    fun `should report a missing night color violation`() {
        val colorFile = TestFiles.xml("res/values/colors.xml",
                """<?xml version="1.0" encoding="utf-8"?>
                <resources> 
                    <color name="color_primary">#00a7f7</color>
                    <color name="color_secondary">#0193e8</color>
                </resources>""").indented()
        val colorNightFile = TestFiles.xml("res/values-night/colors.xml",
                """<?xml version="1.0" encoding="utf-8"?>
                <resources> 
                    <color name="color_primary">#224411</color>
                </resources>""").indented()
        TestLintTask.lint()
                .files(colorFile, colorNightFile)
                .issues(MISSING_NIGHT_COLOR_ISSUE)
                .run()
                .expect("""
                    |res/values/colors.xml:4: Error: Night color value for this color resource seems to be missing. If your app supports night theme, then you should add an equivalent color resource for it in the night values folder. [MissingNightColor]
                    |                <color name="color_secondary">#0193e8</color>
                    |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    |1 errors, 0 warnings""".trimMargin())
    }

Pretty straightforward, the color color_secondary doesn't have a night definition so it should be reported. Let's have a look at the new Issue:

    val MISSING_NIGHT_COLOR_ISSUE = Issue.create("MissingNightColor",
            "Night color missing",
            "Night color value for this color resource seems to be missing. If your app supports night theme, then you should add an" +
                    " equivalent color resource for it in the night values folder.",
            CORRECTNESS,
            6,
            Severity.ERROR,
            Implementation(MissingNightColorDetector::class.java, Scope.RESOURCE_FILE_SCOPE)
    )

This is similar to the previous one, of course we have a different id, description and explanation. I'm re-using the same category, priority and severity but feel free to define your own based on your needs. Last is the implementation that points to a new detector called MissingNightColorDetector:

    class MissingNightColorDetector : ResourceXmlDetector() {

        private val nightModeColors = mutableListOf<String>()
        private val regularColors = mutableMapOf<String, Location>()

        override fun appliesTo(folderType: ResourceFolderType): Boolean {
            return folderType == ResourceFolderType.VALUES
        }

        override fun getApplicableElements(): Collection<String>? {
            return listOf("color")
        }

        override fun afterCheckEachProject(context: Context) {
            regularColors.forEach { (color, location) ->
                if (!nightModeColors.contains(color))
                    context.report(
                            MISSING_NIGHT_COLOR_ISSUE,
                            location,
                            MISSING_NIGHT_COLOR_ISSUE.getExplanation(TextFormat.RAW)
                    )
            }
        }

        override fun visitElement(context: XmlContext, element: Element) {
            if (context.getFolderConfiguration()!!.isDefault)
                regularColors[element.getAttribute("name")] = context.getLocation(element)
            else if (context.getFolderConfiguration()!!.nightModeQualifier.isValid)
                nightModeColors.add(element.getAttribute("name"))
        }
    }

Ok, this is way more complicated than the previous one! The reason is that for this specific detection, we can't report violations straight away: Lint is going through all project's files as if it was a tree. That means that while it's visiting the res/values/colors folder we don't know anything yet about the res/values-night/colors which is probably going to be visited later on. So, in this case I'm memorising all the res/values/colors in a map of color name and location (we need the location to know where the violation is in the file) and all the night colors, then throw a detection at the end of the project evaluation if they don't match. Let's do it step by step:

    private val nightModeColors = mutableListOf<String>()
    private val regularColors = mutableMapOf<String, Location>()

    override fun appliesTo(folderType: ResourceFolderType): Boolean {
        return folderType == ResourceFolderType.VALUES
    }

    override fun getApplicableElements(): Collection<String>? {
        return listOf("color")
    }

The first two are just internal variables to store the list of night mode colors and the map of colors/location for the regular colors. appliesTo lets you specify that, among all the xml files, you are only interested in the ResourceFolderType.VALUES so it will skip drawables, layouts, etc. Finally in the getApplicableElements() we are telling Lint to call this rule only for the tag color since we don't care about style, bool, etc..

    override fun visitElement(context: XmlContext, element: Element) {
        if (context.getFolderConfiguration()!!.isDefault)
            regularColors[element.getAttribute("name")] = context.getLocation(element)
        else if (context.getFolderConfiguration()!!.nightModeQualifier.isValid)
            nightModeColors.add(element.getAttribute("name"))
    }

visitElement is the method that we can use when the color tag is visited, here it first checks the folder configuration (eg. default or night). If it's default we add name and location to the map of regular colors, if it's night we just save the color name in the night mode colors list.

    override fun afterCheckEachProject(context: Context) {
        regularColors.forEach { (color, location) ->
            if (!nightModeColors.contains(color))
                context.report(
                        MISSING_NIGHT_COLOR_ISSUE,
                        location,
                        MISSING_NIGHT_COLOR_ISSUE.getExplanation(TextFormat.RAW)
                )
        }
    }

Finally with the afterCheckProject we have another chance to report a violation after the whole project has been visited, here we can loop through all the regular colors and if we don't find the equivalent in the night mode colors list, we can report a violation. Please pay attention to the location parameter in the report method: we are basically telling Lint where the violation occurred in the file.

Non Semantic Color

The third check is a bit more specific based on the project, but the idea here is that color names like white or red shouldn't be used. There is a high probability that white is not white in night and that red is maybe red but not that specific red in night. It would be better to use semantic color: instead of red use maybe error and instead of white use surface. So let's write a new test:

    @Test
    fun `should report a non semantic color violation`() {
        val contentFile = """<?xml version="1.0" encoding="utf-8"?>
                <View 
                        xmlns:android="http://schemas.android.com/apk/res/android"
                        android:id="@+id/toolbar"
                        android:background="@color/white"
                        android:foreground="@color/red"
                        android:layout_width="match_parent"
                        android:layout_height="wrap_content" />"""
        TestLintTask.lint()
                .files(TestFiles.xml("res/layout/toolbar.xml", contentFile).indented())
                .issues(NON_SEMANTIC_COLOR_ISSUE)
                .run()
                .expect("""
                    |res/layout/toolbar.xml:5: Error: Avoid non semantic use of colors in XML files. This will cause issues with different theme (eg. night) support. For example, use primary instead of black. [NonSemanticColorUse]
                    |                    android:background="@color/white"
                    |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    |res/layout/toolbar.xml:6: Error: Avoid non semantic use of colors in XML files. This will cause issues with different theme (eg. night) support. For example, use primary instead of black. [NonSemanticColorUse]
                    |                    android:foreground="@color/red"
                    |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    |2 errors, 0 warnings""".trimMargin())
    }

This is very similar to the first test that we wrote, so I'm not going through the details, we are expecting two violations because background is using @color/white and foreground is using @color/red.

    val NON_SEMANTIC_COLOR_ISSUE = Issue.create("NonSemanticColorUse",
            "Non semantic color used",
            "Avoid non semantic use of colors in XML files. This will cause issues with different theme (eg. night) support. " +
                    "For example, use primary instead of black.",
            CORRECTNESS,
            6,
            Severity.ERROR,
            Implementation(NonSemanticColorDetector::class.java, Scope.RESOURCE_FILE_SCOPE)
    )

Again, nothing new here, it's just a new issue definition for NonSemanticColorUse, let's jump to the detector:

    class NonSemanticColorDetector : ResourceXmlDetector() {

        override fun getApplicableAttributes(): Collection<String>? = listOf(
                "background", "foreground", "src", "textColor", "tint", "color",
                "textColorHighlight", "textColorHint", "textColorLink", 
                "shadowColor", "srcCompat")

        override fun visitAttribute(context: XmlContext, attribute: Attr) {
            if (checkName(attribute.value)) {
                context.report(
                        NON_SEMANTIC_COLOR_ISSUE,
                        context.getLocation(attribute),
                        NON_SEMANTIC_COLOR_ISSUE.getExplanation(TextFormat.RAW))
            }
        }

        private fun checkName(input: String): Boolean {
            return listOf("black", "blue", "green", "orange", 
                          "teal", "white", "orange", "red").any {
                input.contains(it)
            }
        }
    }

This detector is very similar to the first detector about hardcoded colors: we just define which attributes we are interested in and with the visitAttribute you can check the attribute value and if it contains any of black,blue,green,etc.. we report the violation. I also want to mention that this will work for images as well: if you have something like app:srcCompat="@drawable/ic_repeat_black_24dp" it will report and for a good reason! If you don't tint that image then it may not work in night.

Conclusion

With the three new lint checks if you now run Lint you will find them in the reports:

Of course, this is a starting point, you can decide to go through them and fix all of them in one go or just have a sanity check on how far you are to fix all the potential issue while implementing night mode. My suggestion is to make them not an error in the beginning, otherwise it will fail all your builds, and turning them into error only when you have fixed all of them. Turning them into error helps prevent new code and feature to be added to the project without night mode in mind preventing that to go into the build.

Tip: you can suppress them as you do with any other lint rule:

    <com.google.android.material.floatingactionbutton.FloatingActionButton
            android:id="@+id/button"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            app:srcCompat="@drawable/ic_repeat_black_24dp"
            tools:ignore="NonSemanticColorUse" />

Finally, you can find a full implementation on one of my app here: https://github.com/dbottillo/MTGCardsInfo/commit/9bfd1e051f5c264cb7b5316efd50c6af9723b922

Happy coding!

How I made my legacy app modular - part 2

Daniele Bottillo — Mon, 09 Sep 2019 21:06:45 +0000

This is part two of https://dev.to/dbottillo/how-i-have-modularized-my-legacy-app---part1-4mde.

In part 1, I've shown how to move from one big module to three:

The idea behind these three modules is that we can start to move our codebase in three directions:

everything that is shared across modules should be moved to core (eg. util extensions, app constants)
everything that is app level configuration should be moved to app (eg. dagger configuration, navigation)
everything that is related to one feature should have its own module as a sibling of legacy:

The reason behind this approach is that we can move code away from legacy which will force us to think about the dependencies of feature: being a sibling of legacy means that we can't access anything inside legacy so we have to move those dependencies either to core or app.

A good example of this approach of creating siblings of legacy is the extraction of a small feature on my own project: the about page of the app.

It's a small screen with few buttons, a title, some texts and a box with the libraries used inside the app; it makes the perfect example of how to extract it considering that it has very few dependencies on legacy.

Let's first create the gradle module for the about module feature:

feature_about/build.gradle
feature_about/src/main/AndroidManifest.xml
feature_about/src/main/kotlin/com/dbottilo/mtgsearchfree/

That's it! The last folder will contain all the logic for the module. To make the module "alive" we need to add its definition to the settings.gradle:

include ':legacy', ':core', ':app'
include ':feature_about'  <- add this

So now syncing the project will make the feature_about module available in Android Studio. Let's start moving the AboutActivity which is inside the legacy module:

move 
legacy/src/main/kotlin/com/dbottilo/mtgsearchfree/about/AboutActivity.kt
to
feature_about/src/main/kotlin/com/dbottillo/mtgsearchfree/about/AboutActivity.kt

Move also all the drawables that are used from AboutActivity from legacy to feature_about.

eg: move 
/legacy/src/main/res/drawable-hdpi/library_icon.png
to
/feature_about/src/main/res/drawable-hdpi/library_icon.png

Right, so AboutActivity is now out of legacy, exciting! But this is also where the problem starts: what if you have a drawable that is shared with the rest of the application? or a dimension?

There are two options to handle those cases:

move the shared resources into core
duplicate the resources from legacy

I don't think there is a generic solution that works here, it really depends on the specific use case. I would advice to move dimensions like base_margin to core, whilst I would prefer to duplicate things like specific drawables so that the module has full control over that.

Right, next step is to update the manifest because the AboutActivity is not visible anymore in legacy: we can move it from the legacy manifest to the about module one:

File: app/src/main/AndroidManifest.xml

<application>
   ...
   <activity android:name=".ui.about.AboutActivity"/> <- remove
   ... 
</application>
File: feature_about/src/main/AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest
    package="com.dbottillo.mtgsearchfree.about"
    xmlns:android="http://schemas.android.com/apk/res/android">
    <application>
        <activity android:name=".AboutActivity"/>
    </application>
</manifest>

The extraction is completed! Almost…because probably inside the legacy module somewhere we must have something like:

startActivity(this, AboutActivity::class.java)

but AboutActivity is no longer visible in legacy module. Here is where the app module comes into play, we need to wire the navigation between modules now. The difficulty comes from the fact that the only module that has visibility to all the features is app but we need to find a way to call one module from its sibling. My personal solution around navigation is to define an interface in core called Navigator:

file: core/src/main/kotlin/com/dbottillo/mtgsearchfree/Navigator.kt

interface Navigator {
    fun openAboutScreen(origin: Activity)
}

which is visible from all the modules and have the implementation in app:

file: app/src/main/kotlin/com/dbottillo/mtgsearchfree/Navigator.kt

class AppNavigator : Navigator {
override fun openAboutScreen(origin: Activity) {
        origin.startActivity(Intent(origin,
                            AboutActivity::class.java))
    }
}

And in each module we can inject Navigator whose implementation doesn't really matter at feature module level: the important part is that they have a class to request to move between screens, the actual implementation is at runtime from the app module.

We are almost there! I just mentioned "inject Navigator", so how do we achieve that? how does Dagger work? It's actually quite simple!

Let's first create a Dagger module in the about module:

file: feature_about/src/main/kotlin/com/dbottillo/mtgsearchfree/dagger/AboutModule.kt

@Module
abstract class AboutModule {
    @ActivityScope
    @ContributesAndroidInjector(modules = [(BasicAboutModule::class)])
    abstract fun contributeAboutActivityInjector(): AboutActivity
}
@Module
class BasicAboutModule

We also need to create an AppModule Dagger module to provide the navigator dependency:

file:
app/src/main/kotlin/com/dbottillo/mtgsearchfree/dagger/AppModule.kt

@Module
class AppModule {
    @Provides
    @Singleton
    fun provideNavigator(): Navigator {
        return AppNavigator()
    }
}

And now we can add both modules to the app component:

@Component(modules = [
    AndroidSupportInjectionModule::class,
    AppModule::class,
    AboutModule::class])
interface AppComponent : AndroidInjector<DaggerApplication> {
}

And that's it! Now Dagger knows how to provide dependencies inside the about module. Of course this is a very simple example as it doesn't have any API request or database, so the module is very simple but is a good starting point :)

If you want to see the real commit behind this story: https://github.com/dbottillo/MTGCardsInfo/commit/a9a8059838d2886ed02eb61602953fe83a96c460

As for part 1, in the real code legacy module is actually called MTGSearch and the complexity of that commit is slightly higher than the one described here.

Happy modularisation!

Patterns in Kotlin: Abstract Factory

Daniele Bottillo — Tue, 04 Jun 2019 12:06:22 +0000

The Abstract Factory Pattern intent is to provide an interface to create families of related or dependent objects without specify their concrete classes.

For examples: let's imagine that you have to integrate with a chat SDK in your application. Maybe in your company, you have decided to use a specific SDK but haven't started the integration on the backend yet, also they may change to another SDK at some point, who knows!
At the same time, you know the app requirements, you have the designs, you know, for example, that you have multiple channels and each channel contains multiple messages, from your user and other people.
Wouldn't be nice to separate the actual concrete implementation of the chat from the UI? At the end of the day, both the UI and your users don't care much about which SDK you are going to use :)

Your application should be independent of how channels and messages are created and composed. And ideally your application should be configured with any chat SDK. Because no matter which SDK you are going to use, your application will need to have channels and messages.

There is another reason on this separation: testing. You don't want to spawn a real channel with real messages during unit tests! Yon can fake your chat making it just another provided through this pattern.
It can also speed up development: at the beginning, when you don't know how a specific SDK will look like, you can start defining the interface and have a fake chat implementation until the real one will come in.

First, let's define how the Chat should look like in the application:

interface Chat {
    fun getChannels(): List<Channel>
    fun getMessages(channelId: Long): List<Message>
}
data class Channel(val id: Long, 
                   val name: String, 
                   val users: List<User>)
data class Message(val id: Long, 
                   val text: String)
sealed class User {
    object Self: User()
    class Other(val name: String): User()
}

On a chat object, we are expecting to be able to get all its channels and to fetch messages for a specific channel. A channel also contains all the users who can be the user using our application Self and all Other participants. Great!

It's important to point out that we shouldn't think about any specific implementation, this interface is modelled based on our use case, any specific chat implementation will have to expose the data in this exactly way.

Now that we know how a Chat look like, let's define the factory to create one:

abstract class ChatFactory {
   abstract fun getChat(): Chat
}

The factory requires for now just one method to generate a Chat instance at runtime.

Each concrete factory will have to generate a specific instance of a Chat:

class FakeChatFactory: ChatFactory() {
    override fun getChat() = TODO()
}
class SDKChatFactory: ChatFactory() {
    override fun getChat() = TODO()
}

Using this pattern, now it's very easy to switch implementations, you can swap a factory with another one! For example, let's try to create a FakeChat:

class FakeChatFactory: ChatFactory() {
    override fun getChat() = FakeChat()
}
class FakeChat: Chat {
        override fun getChannels(): List<Channel> {
            return listOf(Channel(id = 1, 
                                  name = "First Channel", 
                                  users = listOf(User.Self, User.Other("Tom"))))
        }
        override fun getMessages(channelId: Long): List<Message>{
            return listOf(Message(id = 1, text = "Hello"),
                          Message(id = 2, text = "How are you?"))
        }
}

Nice, of course this is a FakeChat so everything is fake :) But as you can see, we can easily pretend to have a chat with some data or we can use this FakeChat to create an instance of a Chat for testing purposes, to validate different scenarios for example.

When using the factory, the caller doesn't really know where the data is coming from, which specific implementation we are using at runtime.
Furthermore, in a more complex scenario, each specific implementation is tightly coupled within itself: you can't have a mix of real channels and fake messages for example. Each concrete implementation is forced to provide data that matches the chat interface definition.

So now at runtime we can do:

val channels = FakeChatFactory().getChat().getChannels()
print(channels)

which will print:

[Channel(id=1, name=First Channel, 
         users=[User$Self@31befd9f, User$Other@1c20c684])]

Integrating a real Chat SDK will require to implement a specific chat interface (eg. TwilioChatFactory) which will create the Chat object based on that specific SDK implementation.

Bonus point: another common approach in the Abstract Factory Pattern is to specific the type while creating the factory:

abstract class ChatFactory {
   abstract fun getChat(): Chat

    companion object {
        inline fun <reified T : Chat> create(): ChatFactory =
        when (T::class) {
            FakeChat::class -> FakeChatFactory()
            SDKChat::class  -> SDKChatFactory()
            else            -> throw IllegalArgumentException()
        }
    }
}

So now instead of having to know exactly the name of each factory, you can just specific which type of chat:

ChatFactory.create<FakeChat>().getChat().getChannels()
ChatFactory.create<TwilioChat>().getChat().getChannels()

To recap, the Abstract Factory Pattern should be used when:

a system should be independent of how its products are created, composed and representers
a system should be configured with one of multiple families of products
a family of related products objects is design to be used together and you need to enforce this constraint
you want to provide a class library of products, and you want to reveal just their interfaces, not their implementation

How to write a custom rule in Lint

Daniele Bottillo — Tue, 05 Mar 2019 08:36:23 +0000

At my team at Deliveroo, we have recently decided to start using Google Truth instead of Hamcrest for test assertion but considering the number of unit tests in the codebase, migrating all the tests to Truth it’s almost impossible.
We’ve decided instead to have both libraries in the project and use Truth for new tests and do the conversion when touching an existing one. Furthermore, we also wanted to be notified about using Hamcrest when issuing a pull request in order to avoid reviewer to have to check this manually.

So we’ve decided to write a custom lint rule in order to detect an Hamcrest import and report it as a warning and because we are using Danger (https://github.com/danger/danger) it also reports on pull request which exactly what we want.

In order to write a custom lint rule, we need to create a module that contains the rule and import it in every module where you want to enforce the rule.

Let’s start with creating the lint module: in Android Studio just create a new folder called lint-rules and add a build.gradle file inside:

file: lint-rules/build.gradle
apply plugin: 'java-library'
apply plugin: "kotlin"

dependencies {
    compileOnly "com.android.tools.lint:lint-api:26.3.1"
    compileOnly "org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.3.21"
    testImplementation "com.android.tools.lint:lint:26.3.1"
    testImplementation "com.android.tools.lint:lint-tests:26.3.1"
    testImplementation "com.google.truth:truth:0.42"
}

Nothing strange here, the module is a Kotlin library and we have defined dependencies for lint, Kotlin and Google Truth (more on this later). We also need to add the module to settings.gradle in order to have it available for the rest of the project:

file: settings.gradle
include ':app'
include 'lint-rules'

So now that we have defined the module, we can add code to it :) First we need to create an IssueRegistry class, which is how lint let you inject your own issue check to the command:

file: lint-rules/src/main/java/IssueRegistry.kt
class IssueRegistry : com.android.tools.lint.client.api.IssueRegistry() {
    override val issues: List<Issue>
        get() = listOf()

    override val api: Int = com.android.tools.lint.detector.api.CURRENT_API
}

An IssueRegistry needs to expose two things: the list of issues to check and the current api value, lint documentation about the api value suggest just to return the current value so we can just focus on the list of issues.

What is an Issue in Lint? The best way to look at this, is to check the create method documentation on the Issue class:

/**
 * Creates a new issue. The description strings can use some simple markup;
 * see the [TextFormat.RAW] documentation
 * for details.
 *
 * @param id the fixed id of the issue
 * @param briefDescription short summary (typically 5-6 words or less), typically
 * describing the **problem** rather than the **fix**
 * (e.g. "Missing minSdkVersion")
 * @param explanation a full explanation of the issue, with suggestions for
 * how to fix it
 * @param category the associated category, if any
 * @param priority the priority, a number from 1 to 10 with 10 being most
 * important/severe
 * @param severity the default severity of the issue
 * @param implementation the default implementation for this issue
 * @return a new [Issue]
 */

That’s pretty straightforward! So we need an id, some text for the description and the explanation, a category, a priority, a severity and the actual implementation. Let’s then create a new IssueHamcrestImport:

val IssueHamcrestImport = Issue.create("HamcrestImport",
        "Hamcrest is deprecated",
        "Use Google Truth instead",
        CORRECTNESS,
        5,
        Severity.WARNING,
        TODO()
)

And that’s our Issue! So now we can return a list containing that issue but we still need to fill the TODO() section with the actual implementation.
But at least the registry is finished now:

file: lint-rules/src/main/java/IssueRegistry.kt
class IssueRegistry : com.android.tools.lint.client.api.IssueRegistry() {
    override val issues: List<Issue>
        get() = listOf(IssueHamcrestImport)

    override val api: Int = com.android.tools.lint.detector.api.CURRENT_API
}

val IssueHamcrestImport = Issue.create("HamcrestImport",
        "Hamcrest is deprecated",
        "Use Google Truth instead",
        CORRECTNESS,
        5,
        Severity.WARNING,
        TODO()
)

The last parameter of the Issue.create (or TODO()) it’s an implementation of the detector api, so let’s create a new detector:

file: lint-rules/src/main/java/HamcrestNamingPatternDetector.kt
class HamcrestNamingPatternDetector : Detector(), Detector.UastScanner {

}

But what’s exactly a Detector? Again, let’s have a look at the documentation:

/**
 * A detector is able to find a particular problem (or a set of related problems).
 * Each problem type is uniquely identified as an [Issue].
 *
 * Detectors will be called in a predefined order:
 *
 *  1.  Manifest file
 *  2.  Resource files, in alphabetical order by resource type
 *      (therefore, "layout" is checked before "values", "values-de" is checked before
 *      "values-en" but after "values", and so on.
 *  3.  Java sources
 *  4.  Java classes
 *  5.  Gradle files
 *  6.  Generic files
 *  7.  Proguard files
 *  8.  Property files
 */

Interesting, so a Detector is an object that can find problems in any of those files/sources. For our current use case we are interested into imports of sources classes but luckily we don’t have to parse manually all the files, lint is already doing that for us! We just need to specify what we are interesting in:

override fun getApplicableUastTypes() = listOf(UImportStatement::class.java)

Ok wait a moment, what’s UAST? Let’s have another look at the documentation:

* UAST is short for "Universal AST" and is an abstract syntax tree library
* which abstracts away details about Java versus Kotlin versus other similar languages
* and lets the client of the library access the AST in a unified way.

Wow, that’s amazing! It means that we don’t have to parse the file ourselves and we can just use the already defined UElement:

public interface UImportStatement : org.jetbrains.uast.UResolvable, org.jetbrains.uast.UElement {

That does provide use already all the imports. Wonderful!
OK now we need to define the actual detector implementation:

class HamcrestInvalidImportHandler(private val context: JavaContext) : UElementHandler() {
    override fun visitImportStatement(node: UImportStatement) {
        node.importReference?.let { importReference ->
            if (importReference.asSourceString().contains("org.hamcrest.")) {
                context.report(IssueHamcrestImport, node, context.getLocation(importReference), "Forbidden import")
            }
        }
    }
}

So Lint can offer us a UElementHandler that lets you visit different things like Class, Enum, Field, etc.. But here we are interested just in imports so we can override

override fun visitImportStatement(node: UImportStatement)

and then inspect the importReference to see what does it contains, if it contains org.hamcrest. then we can report the issue in the JavaContext object using the IssueHamcrestImport that we’ve created earlier.
The full implementation of the detector is:

class HamcrestNamingPatternDetector : Detector, Detector.UastScanner(){
    override fun getApplicableUastTypes() = listOf(UImportStatement::class.java)

    override fun createUastHandler(context: JavaContext) = HamcrestInvalidImportHandler(context)
}

class HamcrestInvalidImportHandler(private val context: JavaContext) : UElementHandler() {
    override fun visitImportStatement(node: UImportStatement) {
        node.importReference?.let { importReference ->
            if (importReference.asSourceString().contains("org.hamcrest.")) {
                context.report(IssueHamcrestImport, node, context.getLocation(importReference), "Forbidden import")
            }
        }
    }
}

And now back to our Issue definition, we can replace the TODO() with the actual detector:

val IssueHamcrestImport = Issue.create("HamcrestImport",
        "Hamcrest is deprecated",
        "Use Google Truth instead",
        CORRECTNESS,
        5,
        Severity.WARNING,
        Implementation(HamcrestNamingPatternDetector::class.java,
                EnumSet.of(Scope.JAVA_FILE, Scope.TEST_SOURCES))
)

Notice here that we can define the scope using an enumeration so you can define on which type of file you want to act on (JAVA_FILE also contains Kotlin files).

One thing missing is subscribing our custom registry to lint:

end of file: lint-rules/build.gradle
jar {
    manifest {
        attributes('Lint-Registry-v2': 'IssueRegistry')
    }
}

Finally we can add the custom lint check module to the module that we want to enforce the check:

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    ...all other dependencies...
    lintChecks project(":lint-rules")
}

And if you run ./gradlew lint on a project that contains tests using Hamcrest, now you should see something like this:

One more thing, I’ve mentioned in the beginning the Truth dependency for the lint rules module because we can also write tests for our registry and detector:

class IssueRegistryTest {

    @Test
    fun `check explanation for hamcrest import is correct`() {
        val output = IssueRegistry().issues
                .joinToString(separator = "\n") { "- **${it.id}** - ${it.getExplanation(TextFormat.RAW)}" }

        assertThat("""
        - **HamcrestImport** - Use Google Truth instead
        """.trimIndent()).isEqualTo(output)
    }
}

and

class HamcrestImportDetectorTest {

    @Test
    fun `should not report imports that are not hamcrest`() {
        TestLintTask.lint()
                .files(TestFiles.java("""
            package foo;
            import foo.R;
            class Example {
            }""").indented())
                .issues(IssueHamcrestImport)
                .run()
                .expectClean()
    }

    @Test
    fun `should warning about hamcrest import`() {
        TestLintTask.lint()
                .files(TestFiles.java("""
          package foo;
          import org.hamcrest.MatcherAssert.assertThat;
          class Example {
          }""").indented())
                .issues(IssueHamcrestImport)
                .run()
                .expect("""
          |src/foo/Example.java:2: Warning: Forbidden import [HamcrestImport]
          |import org.hamcrest.MatcherAssert.assertThat;
          |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          |0 errors, 1 warnings""".trimMargin())
    }
}

The TestLintTask class lets us test our detector creating an in-memory file so we can assert the output of the check.

That’s it! You can find a working implementation on Github: https://github.com/dbottillo/Blog/tree/hamcrest_lint

How I made my legacy app modular - part 1

Daniele Bottillo — Mon, 21 Jan 2019 11:12:01 +0000

We all have been there. Whatever is the team getting bigger or your app becoming old, there is a point at which to scale up the development of your Android application you start to consider how to modularize the codebase.

When you reach that point things start to become messy, you may start to think to ditch Gradle in favour of Bazel, or you may think to apply one of the many suggestions on how to create modular apps. But then what about app bundles? and instant app? maybe even dynamic feature? Dagger anyone? More importantly, what about a strategy that works for your own app and your own team? The really question is, how do you move from a monolithic app to anything that can scale up and have more than one module?

You can't definitely do that over night, even for a small application because things will be broken and overlooked, so I would recommend to take a more step by step approach.

Having to tackle this process for the big app of my daily job, I've decided to first modularize a small open source app of my own. It's an application to browse cards for a collectible card game called Magic The Gathering (https://github.com/dbottillo/MTGCardsInfo ). The app is fairly small: less than 10 activities, lots of logic around the database with 1k daily active users so I thought it could have been a good use case to learn the process.

So where to start from? First we should consider the structure of the modules that we want to have, I think the easiest structure is having three modules called app, legacy and core :

app is the top level module that it's generating the APK of your project, the idea is that app knows everything below and ideally should contain only the application class which in the beginning can live in any other module
core is a library module that contains everything that needs to be shared across modules, eg. api model, util classes, etc.. .
legacy is your current codebase, it lives below app and above core, the reason for this is that ideally your legacy module will be converted in many siblings modules that have core below and will provide your features to your app module

There are alternatives to this approach, for example you can think of creating core above legacy and pull out code from it but I don't think it's a good idea: if core is above legacy then if you move one class from legacy to core then its dependencies will still be available (remember that each module can still access everything from a module below) so it will not help you to untangle any dependency really.

In the beginning I recommend to make all your modules android modules so it's easier to migrate (in the future you can think of removing the android dependency from them). I also suggest to create a config-android.gradle to import in every other module to share the android configuration, the setup should look something like this:

app/src/main/AndroidManifest.xml
app/build.gradle
app/src/main/java/… → empty
legacy/src/main/AndroidManifest.xml → existing manifest
legacy/build.gradle → existing gradle file
legacy/src/main/java/… → all your existing codebase
core/src/main/AndroidManifest.xml
core/build.gradle
core/src/main/java/… → empty
build.gradle → generic configurations across modules
settings.gradle → project configuration
config-android.gradle → shared android configuration across modules

Let's have a look into the details of each file.

File: app/src/main/AndroidManifest.xml

<manifest package="com.dbottillo.mtgsearchfree.app" 
   xmlns:android="http://schemas.android.com/apk/res/android" 
   xmlns:tools="http://schemas.android.com/tools">
    <application        
           android:name="com.dbottillo.mtgsearchfree.MTGApp"
           android:icon="@drawable/ic_launcher"                   
           android:label="@string/app_name"         
           android:theme="@style/MTGSearchTheme">
    </application>
</manifest>

Nothing particular here, the manifest is pretty much empty, it just refers the Application class that at the moment lives in the legacy module. One consequence of moving application here is that it requires to also move the icon @drawable/ic_launcher to the app src directory as well.

File: app/src/build.gradle

apply plugin: 'com.android.application'
apply from: '../config-android.gradle'
android {    
   defaultConfig {        
      applicationId 'com.dbottillo.mtgsearchfree'        
   }
   signingConfigs {       
      debugConfig { ... }
      releaseConfig { ... }
   }
   buildTypes{
       debug {          
           applicationIdSuffix ".debug"            
           versionNameSuffix "_dev"            
           signingConfig signingConfigs.debugConfig            
           debuggable true
       }
       release {            
           debuggable false            
           signingConfig signingConfigs.releaseConfig        
       }
   }
}
dependencies {    
    implementation project(':MTGSearch')
    // dependencies
}

apply from lets you import the content of another .gradle file, I'm going to go through the details later, for now you can see that some info regarding android are missing (min sdk, target sdk, etc..). That's because they are defined in this other gradle file, this file then just specify thing that are related to the app module. Note that this is the module that you need to use in order to create an APK or run the app on a device.

File: core/src/main/AndroidManifest.xml

<manifest    
    package="com.dbottillo.mtgsearchfree.core"     
    xmlns:android="http://schemas.android.com/apk/res/android">
</manifest>

The manifest of core is empty, which at this stage makes sense because the module is empty and therefore no activity, service, etc.. are defined in this module.

File: core/build.gradle
apply plugin: 'com.android.library'
apply from: '../config-android.gradle'
dependencies{    
    // dependencies
}

As the manifest, even the gradle file is quite minimal: it's defined as an com.android.library and it inherits the android configuration.

File: build.gradle
buildscript {
    repositories {        
         google()        
         mavenCentral()        
         maven { url "https://maven.google.com" } 
         jcenter()    
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.2.1'        
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.3"
    }
}
allprojects {    
    repositories {        
         google()        
         mavenCentral()        
         jcenter()        
         maven { url "https://maven.google.com" }
     }
     dependencies {
         // your dependencies
     }
}
File: settings.gradle
include ':legacy', ':core', ':app'

In the root build.gradle you can define all the repository and dependencies for your other modules and in settings.gradle all the modules available, this is quite a straightforward gradle configuration.
More interesting is the config-android.gradle:

apply plugin: 'kotlin-android'
apply plugin: 'kotlin-android-extensions'
apply plugin: 'kotlin-kapt'
android {    
    compileSdkVersion 28    
    buildToolsVersion '28.0.3'
    defaultConfig {       
          minSdkVersion 21        
          targetSdkVersion 28        
          versionCode 101        
          versionName "3.6.0"    
    }
    buildTypes {        
          release {}        
          debug {}   
    }
}
androidExtensions {    
     experimental = true
}
kapt {    
     useBuildCache = true
}

As I mention earlier, this gradle file is shared across modules so it's defining all those property across them, it's just an easier way to handle changes: otherwise every time you want to bump the version code, for example, you need to do it in every module.

For the legacy module, build.gradle and AndroidManifest.xml are pretty much the same: the legacy/build.gradle file needs to import config-android.gradle and change the the plugin from application to library. It is also required to remove the definition of the application class from the AndroidManifest.xml since it's not defined in the app module.

I think this is the minimal amount required to move from one module to three modules! The next steps are to move the application class to the app module and then to disentangle dependencies when moving classes from legacy to core. Will write about those steps in the next parts :)

If you want to check real code, you can look at the commit of the application that I've mentioned in the beginning: https://github.com/dbottillo/MTGCardsInfo/commit/6ec4a1bd72d79fe13f0b7c602a56aeca32a8c43e
Bear in mind that legacy is actually called MTGSearch and because the project is an actually real project, the complexity of each file is slightly bigger than the one described here.

Kotlin sealed classes: how to test them with Truth

Daniele Bottillo — Tue, 16 Oct 2018 14:14:11 +0000

In my team at Deliveroo we've recently introduced Truth library for unit testing and we are very pleased with it: we like the syntax, the readability and the extendability.
For example when dealing with sealed classes, unit test are not really the best; let's assume to have a very simple sealed class:

sealed class Food {
    class Pizza(val slices: Int): Food()
    class Sushi(val pieces: Int): Food()
}

In a typical unit test, if you want to test that some food is pizza and have 4 slices, you could write something like this:

@Test
fun `food is pizza and have 4 slices`() {
    val underTest = getFood()

    assertThat(underTest is Food.Pizza).isTrue()
    assertThat((underTest as Food.Pizza).slices).isEqualTo(4)
}

That's not elegant! Using is and as makes the code ugly and less readable and until Kotlin Contracts are stable there is no much that we can do to improve unless we create a custom subject. The idea is to extend Truth to have a more fluent syntax:

assertThat(underTest).isPizza(slices = 4)

That would make more sense! Let's see how to create this custom assertion, Truth requires two components: a subject and a subject factory. The subject is where the assertion lives and the factory is used to expose your custom subject:

class FoodSubject(metadata: FailureMetadata, actual: Food) : Subject<FoodSubject, Food>(metadata, actual) {}
fun food(): Subject.Factory<FoodSubject, Food> {
    return Subject.Factory<FoodSubject, Food> { metaData, target -> FoodSubject(metaData, target) }
}

The constructor of the subject is where you receive the target of your test actual:Food and inside the subject you can define your own assertion:

fun isPizza(slices:Int) {
    if (actual() !is Food.Pizza) {
        failWithoutActual(Fact.simpleFact("expected to be a Pizza!"))
    } 
    val target = actual() as Food.Pizza
    if (target.slices != slices) {
        failWithActual(Fact.simpleFact("expected to be have '$slices' slices but have '${target.slices}' instead"))
    }
}

The actual() method returns the food test object on which you can check whatever you are interesting in, in this case the method is testing that the type is Pizza and that the number of slices are the same. To use this method from the unit test you can do this:

@Test
fun `food is pizza and have 4 slices`() {
    val underTest = generateFood()

    assertWithMessage("food should be pizza with 4 slices")
            .about(food())
            .that(underTest)
            .isPizza(slices = 4)
}

That's very close to what we wanted in the beginning! But there is still one small improvement that we can do it. The about(food()).that(underTest) can be extracted to an utility method in the subject definition:

fun assertThat(@Nullable food: Food): FoodSubject {
    return assertAbout(food()).that(food)
}

This will change the test to:

@Test
fun `food is pizza and have 4 slices`() {
    val underTest = generateFood()
    assertThat(underTest).isPizza(slices = 4)
}

Which is exactly what we want :)

You can find the full example of GitHub: https://github.com/dbottillo/Blog/tree/truth_assertion

Happy testing!

RxJava, a story about delay and schedulers

Daniele Bottillo — Sat, 30 Dec 2017 13:05:41 +0000

RxJava is a beast. It has a very high learning curve but it lets you do complicated things in very few lines of code which comes with a price: you need to understand how the internal works otherwise it will bite you very hard!

Recently I found a very strange behaviour with the delay operator.

Let’s assume to have an observable that we want to delay before it finishes:

Single.fromCallable {
   Thread.sleep(DELAY)
   "done!"
} 
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.doOnSubscribe {
   view.showText("started!")
}
.doOnSuccess {
   view.showText(it)
}.subscribe()

Nothing strange here, we have a callable that will wait for a delay before returning the “done!” string.

But we can write a better version with the delay operator:

Single.fromCallable {
   "done!"
}
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(Schedulers.io())
.delay(DELAY, TimeUnit.MILLISECONDS)
.doOnSubscribe {
   view.showText("started!")
}.doOnSuccess {
   view.showText(it)
}
.subscribe()

Seems legit, we have removed that ugly Thread.sleep() inside fromCallable and now we use the delay operator, nice!

But if you run that code it will crash badly:

io.reactivex.exceptions.OnErrorNotImplementedException: 
Only the original thread that created a view hierarchy can touch its views.

Wait what? it seems that is trying to update the view in the wrong thread! I usually check the documentation in this case but it’s not very helpful:

http://reactivex.io/documentation/operators/delay.html

It doesn’t mention anything about threads. But what you can do is to go inside the implementation!

So if you follow the delay operator from code you will get to:

/**
* Delays the emission of the success signal from the current Single by the specified amount.
* An error signal will not be delayed.
*
* Scheduler:
* {@code delay} operates by default on the {@code computation} {@link Scheduler}.
* 
* @param time the amount of time the success signal should be delayed for
* @param unit the time unit
* @return the new Single instance
* @since 2.0
*/
@CheckReturnValue
@SchedulerSupport(SchedulerSupport.COMPUTATION)
public final Single delay(long time, TimeUnit unit) {
    return delay(time, unit, Schedulers.computation(), false);
}

Wait, it says that by default it operates on the computation scheduler! That’s it, delay is changing the scheduler back to computation so we are trying to update the view from the wrong thread.

Luckily there is another method that we can use:

public final Single<T> delay(final long time, final TimeUnit unit, final Scheduler scheduler)

Perfect, we can rewrite our code using this alternative delay operator:

Single.fromCallable {
   "done!"
}
.subscribeOn(Schedulers.io())
.delay(DELAY, TimeUnit.MILLISECONDS, AndroidSchedulers.mainThread())
.doOnSubscribe {
   view.showText("started!")
}
.doOnSuccess {
   view.showText(it)
}
.subscribe()

You can notice that now you don’t need to specify ObserveOn anymore because we are choosing the thread in the delay operator.

You can find a working example on my github: https://github.com/dbottillo/Blog/blob/rxjava_delay

Happy Rxjava!

How to unit test your RxJava code in Kotlin

Daniele Bottillo — Fri, 16 Jun 2017 17:26:54 +0000

In a typical MVP architecture you have different layers: a repository/network client to fetch data, a view with attached a presenter that will call an interactor to proxy the request to the repository/network layer. And if you use RxJava you probably will return an observable from the repository layer, subscribe to it in the presenter layer and the interactor will decide which thread will the request be executed.

That’s pretty common, I would also argue that it’s better to have two different models: one for the response from the network and one for the UI. The benefit of two separated models is usually to prevent changes across the entire code base: if the server changes the response you can just map the new one to the UI model and the entire view/presenter layer doesn’t need to change at all. It’s also nice to have different name fields between the two layers so you don’t need to choose the names based on the API definition. For example I think image is a better name than backdrop_path for the example that I’m gonna show you soon.

The main point of this post is to show you how to write an interactor that fetches data from a client on a thread and returns an observable on the main thread.
Let’s imagine to have a network client that fetches a list of movies, the response from the network is:

class MoviesResponse(val page: Int, 
                     val total_results: Int, 
                     val total_pages: Int, 
                     val results: List<MovieResponse>)

class MovieResponse(val id: String, 
                    val title: String, 
                    val backdrop_path: String, 
                    val overview: String, 
                    val release_date: String)

It’s pretty simple, a MoviesResponse contains the number of results, the number of pages, the current page and a list of movies; each movie contains an id, a title, a backdrop path, an overview and a release date.

On the UI side we are just interested in showing a list of movies in a list, so we are expecting a title, a description and an image:

data class Movie(val title: String, val text: String, val _image: String){
    val image: String
        get() = "http://www.base.url/$_image"
}

So let’s write an interactor that call the network client, retrieve the MoviesResponse and returns an observable with a list of Movie objects.

class MoviesInteractor(val client: MoviesClient) {

    fun requestTopMovies(): Observable<List<Movie>> {
        return client.fetchMovies()
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .map {
                    it.results.map {
                        Movie(it.title, it.overview, it.backdrop_path)
                    }
                }
    }

}

The MoviesInteractor is expecting a MoviesClient, which has one function:

fun fetchMovies(): Observable<MoviesResponse>

If you are using Retrofit, it supports Observable out of the box (adding a plugin), so I will not focus on that right now. Assuming that client.fetchMovies() returns an observable of MoviesResponse, then the interactor can map this response to the list of Movies with this code:

.map {
    it.results.map {
        Movie(it.title, it.overview, it.backdrop_path)
    }
}

It’s very easy with Kotlin to achieve this, because the map operator of RxJava returns the instance of MoviesResponse which has a property ‘results’ that contains a list of MovieResponse. So for each MovieResponse we need to create a correspondent Movie object and luckily Kotlin has a built-in function map that let you map the object MovieResponse to a list of movies, so the ‘it’ instance inside the map function refers to a MovieResponse.

The rest of the interactor defines to observeOn the main thread and subscribe on another thread to avoid blocking the main thread.
Let’s see how to test this:

    @Mock
    lateinit var client: MoviesClient

    internal lateinit var underTest: MoviesInteractor

    @Test
    fun `when movies are requested, should call client and return response`() {
        val movieResponse = MoviesResponse(0, 0, 0, listOf(
                MovieResponse("id1", "title1", "/backdrop1", "Overview1", "release date1"),
                MovieResponse("id2", "title2", "/backdrop2", "Overview2", "release date2")))
        Mockito.`when`(client.fetchMovies()).thenReturn(Observable.just(movieResponse))

        val result = underTest.requestTopMovies()

        val testObserver = TestObserver<List<Movie>>()
        result.subscribe(testObserver)
        testObserver.assertComplete()
        testObserver.assertNoErrors()
        testObserver.assertValueCount(1)
        val listResult = testObserver.values()[0]
        assertThat(listResult.size, `is`(2))
        assertThat(listResult[0].title, `is`("title1"))
        assertThat(listResult[0].image, `is`("http://www.base.url/backdrop1"))
        assertThat(listResult[0].text, `is`("Overview1"))
        assertThat(listResult[1].title, `is`("title2"))
        assertThat(listResult[1].image, `is`("http://www.base.url/backdrop2"))
        assertThat(listResult[1].text, `is`("Overview2"))
    }

In the test we are mocking the response of the client, when the client is called then we return a fake observable that contains a MoviesResponse with two movies. To test the observable we can use the TestObserver class which let you test the content of your subscription: we can check that is complete, no errors occurred and that the value is a list of movies.

If you try to run that test you will likely to run into this error:

Caused by: java.lang.RuntimeException: Method getMainLooper in android.os.Looper not mocked. See http://g.co/androidstudio/not-mocked for details.

It’s a quite cryptic error message, but the reason behind is that your interactor is trying to execute the client call in a different thread than the main thread. During a test execution we are actually not interested in this behaviour, we just want to make sure that the client is called and mapped back to our UI model.
To fix the error message you can add this in your setup method:

RxJavaPlugins.setIoSchedulerHandler { Schedulers.trampoline() }
RxJavaPlugins.setComputationSchedulerHandler { Schedulers.trampoline() }
RxJavaPlugins.setNewThreadSchedulerHandler { Schedulers.trampoline() }
RxAndroidPlugins.setInitMainThreadSchedulerHandler { Schedulers.trampoline() }

Those four lines of code let you specify which thread to use for the Io Scheduler, Computation Scheduler, new thread scheduler and the initial main thread scheduler for android; basically you are forcing all of them to use the same thread! But what is a trampoline? From the documentation:

/**
 * Creates and returns a {@link Scheduler} that queues work on the current thread to be executed after the
 * current work completes.
 *
 * @return a {@link Scheduler} that queues work on the current thread
 */

That exactly what we are interested in! We want to the work to be done synchronously because it’s not the job of this unit test to check that we are using different threads. I would also argue that you don’t need to test the different thread behaviour because you are using a library (RxJava) and from my point of view, testing a library is pointless.

That looks great, but you need to put those 4 lines of code in each setup method of each file and it seems quite ripetitive. I would suggest to create a rule that can be added in each tests that need this behaviour:

class RxImmediateSchedulerRule : TestRule {

    override fun apply(base: Statement, d: Description): Statement {
        return object : Statement() {
            @Throws(Throwable::class)
            override fun evaluate() {
                RxJavaPlugins.setIoSchedulerHandler { Schedulers.trampoline() }
                RxJavaPlugins.setComputationSchedulerHandler { Schedulers.trampoline() }
                RxJavaPlugins.setNewThreadSchedulerHandler { Schedulers.trampoline() }
                RxAndroidPlugins.setInitMainThreadSchedulerHandler { Schedulers.trampoline() }

                try {
                    base.evaluate()
                } finally {
                    RxJavaPlugins.reset()
                    RxAndroidPlugins.reset()
                }
            }
        }
    }
}

Now instead of the four lines of code in the setup, we can just add a rule:

@Rule @JvmField var testSchedulerRule = RxImmediateSchedulerRule()

And that’s it! The complete implementation of the interactor and its test:

class MoviesInteractorTest {

    @Rule @JvmField
    val rule = MockitoJUnit.rule()!!

    @Rule @JvmField var testSchedulerRule = RxImmediateSchedulerRule()

    @Mock
    lateinit var client: MoviesClient

    internal lateinit var underTest: MoviesInteractor

    @Before
    fun setUp() {
        underTest = MoviesInteractor(client)
    }

    @Test
    fun `when top movies are requested, should call client and return response`() {
        val movieResponse = MoviesResponse(0, 0, 0, listOf(
                MovieResponse("id1", "title1", "/backdrop1", "Overview1", "release date1"),
                MovieResponse("id2", "title2", "/backdrop2", "Overview2", "release date2")))
        Mockito.`when`(client.fetchMovies()).thenReturn(Observable.just(movieResponse))

        val result = underTest.requestTopMovies()

        val testObserver = TestObserver<List<Movie>>()
        result.subscribe(testObserver)
        testObserver.assertComplete()
        testObserver.assertNoErrors()
        testObserver.assertValueCount(1)
        val listResult = testObserver.values()[0]
        assertThat(listResult.size, `is`(2))
        assertThat(listResult[0].title, `is`("title1"))
        assertThat(listResult[0].image, `is`("https://image.tmdb.org/t/p/w342/backdrop1"))
        assertThat(listResult[0].text, `is`("Overview1"))
        assertThat(listResult[1].title, `is`("title2"))
        assertThat(listResult[1].image, `is`("https://image.tmdb.org/t/p/w342/backdrop2"))
        assertThat(listResult[1].text, `is`("Overview2"))
    }
}

class RxImmediateSchedulerRule : TestRule {

    override fun apply(base: Statement, d: Description): Statement {
        return object : Statement() {
            @Throws(Throwable::class)
            override fun evaluate() {
                RxJavaPlugins.setIoSchedulerHandler { Schedulers.trampoline() }
                RxJavaPlugins.setComputationSchedulerHandler { Schedulers.trampoline() }
                RxJavaPlugins.setNewThreadSchedulerHandler { Schedulers.trampoline() }
                RxAndroidPlugins.setInitMainThreadSchedulerHandler { Schedulers.trampoline() }

                try {
                    base.evaluate()
                } finally {
                    RxJavaPlugins.reset()
                    RxAndroidPlugins.reset()
                }
            }
        }
    }
}

class MoviesInteractorImpl(val client: MoviesClient) {

    override fun requestTopMovies(): Observable<List<Movie>> {
        return client.fetchMovies()
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .map {
                    it.results.map {
                        Movie(it.title, it.overview, it.backdrop_path)
                    }
                }
    }

}

Kotlin by examples: Class and Properties

Daniele Bottillo — Tue, 21 Feb 2017 15:46:26 +0000

I've been using Kotlin in the last few months and I'm very pleased with it! For people who don't know it, it's a language built by JetBrains (the company behind IntelliJ hence Android Studio) which compiles to the same JVM bytecode of Java.

It's a very modern and nice language which can be used along side Java files so doesn't require to convert an entire project.

In this blog post I'm gonna show you how to write in Kotlin what you usually write in an Android/Java project and why writing code with Kotlin is faster and nicer :=) .

Let's start with a standard definition of a class in Java:

public abstract class Car {
    private String name;
    Car(String name){
        this.name = name;
    }
}
public class Ford extends Car{
    private String model;
    private String color;

    Ford(String model, String color){
        super("Ford");
        this.model = model;
        this.color = color;
    }
}
Ford focus = new Ford("Focus", "blue")

Pretty standard Java classes, we have a base abstract class called â€˜Car' and a proper class â€˜Ford' which extends Car.
In Kotlin the same code would be:

abstract class Car(val name: String)

class Ford(val model: String, val color: String) : Car("Ford")

val focus = Ford("Focus", "Blue")

So the 15 java lines of code are just 3! In Kotlin you define constructors inline in the class definition and you have getters and setters for free based on the visibility of the fields (more on this later).
The â€˜extends' keyword of Java is replaced by just a â€˜:' and you can also inline the constructor of the abstract class (in this case: Car(“Ford”) ).

Ford focus = new Ford("Focus", "blue")
focus.getName()    -> java way
val focus = Ford("Focus", "Blue")
focus.name         -> kotlin way

Constructors and also methods support default values, something that Java can't do:

class Ford(val model: String, val color: String = "Blue") : Car("Ford")
val focus = Ford("Focus")
println(focus.color)          -> prints Blue

It's also possible to have named field in the creation of an object, which solve one of the main problem of Java in my opinion: to understand the meaning of the fields used to create a new object.
So let's imagine a Book class in Java with one parameter as a string:

Book book = new Book("George")

What is “George ? is the author? the name of the book? the owner of the book? In Kotlin you can do this:

Book book = new Book("George")     -> Java
val book = Book("George")          -> Kotlin like Java
val book = Book(author="George")   -> more expressive way

Definitely better!

In Kotlin you can add the keyword â€˜data' at the beginning of a class, if you do, the compiler will add these methods for “free”:

equals()/hashCode() pair,
toString() of the form "Ford(name=Ford, model=Focus)",
componentN()
copy()

So with just one keyword you are getting a lot of code for free! I want to show you what componentN() functions means because it's something that you can't do in Java. The idea is that you can destruct the declaration of your class:

val focus = Ford("Focus", "Blue")
val (model, color) = focus
println("$model and $color")   -> this will print: "Focus and Blue"

Also the copy method is very useful to create another object from a previous one:

val focus = Ford("Focus", "Blue")
val yellowFocus = focus.copy(color = "Yellow")

In Kotlin a property can be var or val. You can think about val as a final field in Java (so it can't be modified) and var a mutable property which cannot be null, if you want to have a mutable nullable property you need to define with “? expression:

var mutable = "mutable"
val immutable = "immutable"
mutable = "changed"                    -> 'it compiles'
immutable = "changed"                  -> 'doesn't compile'
var mutableCanBeNull: String? = null   -> 'can be null'

You can safely access a property that can be null with the keyword â€˜?':

var mutable = "mutable"
println(mutable.legnth)                 -> 'print 7'
var mutableCanBeNull: String? = null
println(mutableCanBeNull?.length)       -> 'does not crash! print null'

In Android most of the time you need to wait callbacks from the framework to create objects, which means they need to be defined null until the framework is ready and then every time you use those objects you need to check if it's not null.

Kotlin solves this problem with the lateinit keyword for var properties:

lateinit var name: String     -> 'without lateinit it does not compile'
name = "Tom"
println(name.length)

Please note that you don't need to do â€˜name?' but just “name' because the lateinit keyword tells the compiler that you are gonna fill the property before using it!

That's it for now! In the next post I will talk about function definitions, return types, callback and static fields.