Hi everyone. It's been a while, a long, long while. I haven't published a blog in what feels like forever.

Honestly, it's not that I stopped writing. I just kept feeling like what I had wasn't quite ready to put out. So here we are, finally breaking that streak.

If you don't know already, I've started a new venture: Mobrio Studio, where I'm building FretPractice. It's built on Compose Multiplatform, and I figured writing about that platform choice might add some value to the community.

If you know me, you might think that's an obvious answer, I'm pretty loud about KMP. But trust me, it wasn't that straightforward. Read on.

My Take on Kotlin, KMP, and Compose Multiplatform

Kotlin

I've been a Kotlin advocate for a long time. Wrote books on it 8 years ago, and more than half my blog posts are Kotlin-related in some way. Safe to say I'm a fan, you wouldn't be wrong to call it love.

Kotlin Multiplatform

Same story here. When it comes to sharing business logic across platforms, KMP has no real competition. No other technology lets you write code in one language and ship it natively, compiled to native binaries, as libraries across platforms. Yes, you can do something similar with C++ or even Rust via FFI, but the added complexity only makes sense when you need low-level control for performance or security. For regular business logic sharing, KMP is the best choice, full stop.

One honest caveat though: KMP has a steep learning curve for production apps. If you're going this route, make sure you have a senior engineer on the team who actually knows the ropes.

Compose Multiplatform

Here's where things get nuanced.

I love Compose as an Android developer, it makes life genuinely easier. Yes, it has its quirks, and understanding Declarative UI takes some time to click, but once it does, Compose is great. And the Android team keeps improving it (keep an eye on Compose Styles if you haven't already).

That said, I've always had a strong preference for native UIs. Native means fewer platform-check conditionals cluttering your UI logic, a more intuitive feel per platform, and better performance.

Here's the thing about Compose Multiplatform: while KMP compiles to native binaries (LLVM on iOS/macOS, JVM bytecode on Android, minified JS on web), Compose Multiplatform can't do the same, it has to handle drawing itself (note, your app still does compile to native binaries, it just now has an added engine to draw ui). On iOS, for example, SwiftUI talks directly to Core Animation and Metal. Compose Multiplatform has to go through Skiko first, which then delegates to Metal. That extra layer isn't free, it costs performance.

The tradeoffs get broader as you add more target platforms. On Web with Wasm/JS, you give up standard web features like per-screen URLs and SEO. On Desktop, you're no longer shipping a native app per platform, you're shipping a JVM app.

So no, I've never been as enthusiastic about Compose Multiplatform as I am about Kotlin or KMP. My position on shared UI has always been skeptical.

Flutter

Contrary to what some might expect, I actually like Flutter. It lets you move fast, and for most apps that don't have heavy native dependencies, it's a solid choice. The learning curve is short and intuitive regardless of your background, that's genuinely hard to replicate.

If someone asks me to pick between Flutter and Compose Multiplatform for a standard CRUD app with no special constraints, I'd probably go Flutter. Even with my feelings about Dart.

So Why Compose Multiplatform for FretPractice?

The short answer: it's still the best fit for where I am right now, one developer, moving fast, building something that needs to ship.

But here's why it's not a simple answer.

FretPractice isn't just another focus or practice timer app. It's a music app. It needs DSP logic to accurately detect notes in real time. It'll have DRM for AI-generated music. It'll include DAW features - stem splitting, editing, production. And down the line, it needs to talk to hardware over Bluetooth and Wi-Fi.

That rules out Flutter entirely. The native dependencies are too deep.

But building fully native UIs for 8 platforms (Android, iOS, JVM Desktop, Web, watchOS, Wear OS, Android TV, Apple TV), is simply not feasible for a solo developer trying to actually launch something. So Compose Multiplatform is the pragmatic next-best choice.

Despite all the tradeoffs I laid out, it still inherits KMP's biggest strength: wiring in native code while sharing business logic efficiently. And the one KMP learning-curve caveat I mentioned? Doesn't apply when you're the one building it.

Also worth noting: if you structure your project well, replacing Compose Multiplatform UI with native UI later, while keeping the shared KMP logic intact is a much smaller lift than rewriting the whole thing from scratch.

That's the bet I'm making.

And that's really the point of this post, the "right" platform choice doesn't exist in a vacuum. It depends on what you're building, who's building it, and what constraints you're working within. If you're building a CRUD app solo and need to ship fast, maybe Flutter is your answer. If you have a team and the time, maybe full native is worth it. For me, right now, with FretPractice, Compose Multiplatform is the call that makes sense.

Anyway, it feels good to be writing again. I've got a lot more to share as FretPractice takes shape, the architecture decisions, the DSP work, the multiplatform quirks I run into along the way. If any of that sounds interesting, stick around.

In this post, as the title suggests, I'll discuss why one shouldn't emit View States (or as some people prefer to call it Resource nowadays) from Repository, and why is it Anti-Pattern IMO. While discussing that, this post will also address why returning LiveData from Repository doesn't make sense.
So let us get started by understanding each of the layers in an Android app, and their purposes/function.
Note: I'm not advocating structuring your project by layer here, in-fact I prefer structuring by feature. However, the layers are still there within feature-based modules or packages (in case of monolithic apps).

Layers in a typical Android App

There can be multiple layers in an Android app, however, 3 of them are most significant.

• UI
• Presentation
• data

Now, we can divide each of these layers into smaller sub-layers, for example, data layer can be divided into cache and remote sub-layers, but let's focus into these 3 major layers, and try to understand their purpose and functionality.

data Layer

As the name suggests, this layer is supposed to be dealing with all data fetching, caching, storing, manipulating, and all other data related operations. In the earlier days of Android, we used to have DataModels in this layer, which in most cases were a single class, dealing directly with DB or DAO and Remote / Network. As we, Android Developers worldwide started becoming more and more cautious about the separation of concern and clean code, we realized that we need to separate out cache and remote.
That's when the concept of Repository came up. Yes, the concept of Repository isn't tied to MVVM architecture, and you can still use it (and you should) with any other arch pattern you use, including MVP.
So, what is the responsibility of a Repository? Simple, manage all data transactions, decide on when to fetch the data from remote and when to fetch it from the cache, etc. Ideally, a Repository should come with DataStores, based on your requirement, you can have RemoteDataStore or CacheDataStore or both. A RemoteDataStore should contain all the logic to fetch data from remote APIs, if you're using Retrofit in your app, RemoteDataStore is where you call the API interface. Similarly in CacheDataStore, you put all local storage related logic. One thing to note here is that the names are nonsubstantial IMO, I know a lot of good people who prefers to call it NetworkManager instead of RemoteDataStore, and in my opinion, there's nothing wrong with it.
TLDR about data layer: It contains Repository, which should contain only data-transaction related code. Now Repository in turn might have dependencies on Remote/Network and Cache/Local DataStore(s).
Now let us discuss the next layer - the presentation layer.

Presentation Layer

Presentation is where you keep your business, i.e. the business logic. If you follow MVP, then you have your presenter here, if you follow MVVM, then you have your ViewModel here, one thing to note here is that ViewModels are also used multiple other architectures, including MVI, etc. So, as the goal of this post is to discuss ViewState and LiveData, let us assume, you have ViewModel here.
So, what is the purpose of ViewModels? a common answer is to hold the business logic, but actually, that's not all, if you ever think, why is it called ViewModel, instead of Presenter with Stream or something like that, then it becomes clear; along with a place to keep your Business logic, a ViewModel should also maintain the ViewState or State (or as some people prefer to call it - Resource).
Now, what is a ViewState? A View state is nothing but a simple POJO or data class, which will hold the current state of the View, and ideally, a View should render the exact ViewState.

UI Layer

The UI layer is where you should keep your UI designs and ViewState rendering logic. Ideally, the UI layer should subscribe to the presentation layer, to get updated ViewState, and render it, and pass the UI events (such as click) to the presentation layer. This layer consists of Activities, Fragments, custom Views, etc.

What's wrong in emitting State from Repository

The are multiple reasons why you shouldn't emit States from Repository, we'll look at the two most important points here (IMO).

1. As we discussed above, it is ViewModel's job to maintain the State. The data layer should never be aware of anything related to the view or ViewState (for eg. whether view state is loading or showing error or success etc.) the data layer should only be caring about fetching and storing data, nothing more, nothing less. Moreover, if ViewModels emit State / ViewState / Resource, then it's more likely that you might end up having at least some part of business logic in the Repository, as you'd generally want the states to be based on business logic.
   So, it's evident enough that Repository, which is part of the data layer, should never be emitting ViewState.
2. As your app grows and becomes more complex, you might separate the data layer as a separate module. Also, you might wanna re-use a Repository from multiple ViewModels, for example, you have a Repository, say UserProfileRepository that manages UserProfile which is mostly used in the profile page, now you have a subscription page, where you need UserProfile again, so if you copy the same code to SubscriptionRepository then there'll be redundancy, rather you might wanna call both SubscriptionRepository and UserProfileRepository from SubscriptionViewModel and map/flatMap the data according to your business logic. Now, if you have Repositories emitting States / Resources / ViewState, using multiple Repositories would get more complex for you.

Why LiveData in Repository doesn't make Sense

To understand why LiveData in Repository or the data layer doesn't make sense, we need to understand what is LiveData and why was it created. LiveData wasn't created to replace Rx or Coroutines, it was created as a simple reactive state-change wrapper. You'd publish updates from one end, and would subscribe to it from the other end. The main reason why they created LiveData was to remove subscribing and cleanup complexities from View/UI layer. Generally, we want to subscribe to Stream in Activity/Fragment/View, and we need to remember to dispose of the subscriptions when the View is destroyed. Sometimes we also want to avoid receiving updates when our View (Activity/Fragment/View) is in background. Now all these are possible with Rx or Flow or any other full-fledged streaming mechanism, but that was a little complex and a lot of boilerplate, which can lead to human mistakes. Moreover, generally in these cases, we don't want heavy modifications/operations on the data (such as flatMap/map, etc.), since the data here is basically the state, and it's ready to be rendered. So, Google created a lightweight reactive stream called LiveData. Now, if you return/use LiveData in the data layer, that means you're restricting the possibility to map/flatMap the data at the presentation layer, unless you use MutableLiveData at multiple layers, and over-complicate your codebase. Also, if you ever have written unit tests with LiveData, then you are probably aware, that test classes you either need to implement a TaskExecutor or you need to use InstantTaskExecutorRule, which tells the LiveData that the observation is in Main Thread. This clearly indicates that LiveData observations are always in Main Thread. That's expected behavior when you're subscribing to the LiveData from your UI/View layer, but do you really want that in your presentation/data layers? Yes, there can be hacks or even ad-hoc mechanisms to have the observation run on other threads, but does it make sense to overcomplicate things when there's plenty of other options?

TLDR

Don't use LiveData in the data layer, which includes Repository, and don't emit ViewState/State/Resource from Repository.

There is a very thin lining of difference between Service Locator (in short SL) and Dependency Injection (in short DI). Most people get confused with these terms, even I was confused with them for so long. Even more so for Android Developers, most of us often get in dilemma whether to use Koin or Dagger in their project. In this blog, I'll try to answer the questions regarding SL and DI, and will try to define them using simple terms, and will also compare Dagger and Koin for Android environment so that you can make the decision your self. But if you ask me for a one-sentence answer on whether to use Dagger or Koin in your project, my answer will be "it matters".

The goal of this blog isn't to show how to use Koin or Dagger, rather the goal is to clear the area around the DI and SL concepts, and comparing and differentiating Dagger and Koin so that it's easy for you to decide which one is best suited for your project.

Inversion of Control (IoC)

First thing first, all of this DI and SL comes from the IoC principle, so let us understand the IoC principle first. IoC or Inversion of Control or Dependency Inversion is the D of SOLID principles. We'll not go to all the bookish definitions, what IoC says is, in short, a class that is using a dependency shouldn't create it, rather than should be provided the dependency with. So, instead of creating the dependant class first, and then let the dependant class create the dependency, the dependency class should be created and provided to the dependant by a third party.

What are Dependency and Dependant?

As we discussed a class shouldn't create its own dependencies, the question comes what exactly is a dependency? Let us take some real-life examples to answer that. If you're following MVVM architecture pattern in Android, you might access the ViewModel class from Activity / Fragment / View. So, your view (Activity / Fragment / View) class depends on that ViewModel instance, so the ViewModel instance is dependency and the view (Activity or Fragment or View) class is the dependant.

What's Dependency Injection (DI)?

Dependency Injection is a pattern/principle that provides a way to incorporate IoC. It says the dependency should be injected to the dependant. You can take the word 'inject` to its literal meaning here, much like the injections in real life, in DI, the dependant doesn't know how the dependency would come or from where, it just uses the dependency when it needs, and a third party injects that dependency right after the dependant instance is created.
In DI, it's important that a class should never know where the dependency comes from, or should never request for the dependency itself (if you don't know where it's coming from, you can't request as well).

Note: DIP and DI aren't the same thing. DIP means Dependency Inversion Principle, while DI means Dependency Injection, which is a way of incorporating DIP.

What's Service Locator (SL)?

Just like DI / Dependency Injection, Service Locator is also a pattern/principle that provides a way to incorporate IoC/DIP, just that SL isn't as strict as DI. It also says the dependency should be provided to the dependant, but in contrary to DI, here the dependant class can request for the dependency in various forms. This can give a big benefit - for example, the dependant class can request for the dependency only when it needs to use it.

Is Constructor Injection a type of Service Locator (SL)?

I believe yes since, with Constructor Injection, the class explicitly asks for the dependency to be passed down to it while creating the instance, which contradicts the DI principle. DI says the dependant should never ask for the dependency in any form or manner.

So is Constructor Injection a bad practice?

Quite the contrary, you should rely on Constructor Injection whenever possible. It makes it more readable and keeps it free from framework interference, for example, if you change the DI framework for your project tomorrow, you won't need to make changes to the dependant class, as its dependencies are passed down the constructor, it'd be same for any DI/SL framework you use.
Moreover, Constructor Injections make it easy for you to test. In my opinion, while writing Unit tests, it's easy to provide the dependencies with Constructor Injection, than with any other methods.
Also, note here, Constructor Injection is not DI per se, but it is definitely an implementation of IoC.

What is Dagger?

Most of Android Developers confuse DI with Dagger. If you casually ask an Android developer, "Hey, do you use DI", more than often you'll get answers like "(no we don't / yes we) use dagger". That sums up how much popular Dagger became in the Android community lately, that. people mixup DI with Dagger. So what is Dagger? Dagger is a framework that helps you implement DI. the difference between DI and Dagger is the same as between DI and Dagger is similar to that of Car and Rolls Royce Phantom.
What Dagger does is that it lets you annotate dependencies of your class with @Inject annotation (from JSR330), so it can proactively provide those dependencies for you to the dependant class.
Now, it's worth noting here that Dagger or any other DI/SL framework for that matter doesn't know how to create instances of those dependencies, you'll have to tell that to the framework, for Dagger, we generally do that in a module file, or sometimes even in the dependency class with @Provides annotation.
So what happens when you annotate a dependency with @Inject but Dagger doesn't know how to create that instance? The answer is simple, your build will fail. To understand why we need to understand how dagger works.

How Dagger works?

We can't explain everything in Dagger in a single post, but here I'd try to give a brief idea of how Dagger code generation works.
Dagger uses annotation processing to generate necessary code, that'll inject the dependency in your dependant class. To explain it further, let us say you have an Activity/Fragment, and you are trying to inject your RecyclerView.Adapter to that Activity/Fragment, so you annotated adapter variable in your Activity/Fragment with @Inject, so when you build the code, annotation processing will take place, and Dagger will generate a file named like ActivityName_MembersInjector, let us consider the Activity/Fragment is named as HomeScreen, the injector class name would be HomeScreen_MembersInjector. Now if you navigate to that generated file, you'll see that it has a dependency on a Provider<T> for the adapter, so if we consider your adapter's name is HomeAdapter, then HomeScreen_MembersInjector would have a dependency on Provider<HomeAdapter>.
Now the question is how Dagger will get the provider instance to pass it on to the injector? The answer is simple, for every @Provides annotation you write, Dagger generates a Provider class for that dependency.
So if Dagger can't find a Provider class for any dependency while generating the code, it'll fail the build.

What's Koin then and how it works?

Koin is another library enabling IoC, it relies on SL pattern rather than DI. Koin utilizes Kotlin's delegation system for providing the dependencies, rather than generating code do to that. With Koin you'll write something like val adapter: HomeAdapter by inject(), basically you'll use a function named inject(), which in turn uses Koilin's lazy delegation. Kotlin's lazy delegation allows you to instantiate a val property (final variable) when it's first used, so if you declare a variable, and use lazy delegation to initialize it, and never use the variable, at runtime, the variable will never be initialized.
So, what happens with Koin's inject() delegation, is that the class asks for the dependency when it needs at the runtime and then, in turn, Koin searches if you mentioned how to create that dependency in a Koin module, provides the dependency if you did, or throws a RuntimeException if you didn't (there's a solution for that though).

Is DI possible Manually?

Absolutely, it requires a lot of effort though to get proper DI manually. What does Dagger do? It generates the code that does the DI, so obviously DI is possible manually, however, think of the volume of code Dagger generates, I'm not sure you'd like to write all that code yourself for every class and all of its dependencies.

What should I do then DI or SL and Dagger or Koin?

The correct answer depends on your team and project size and requirements. Both DI and SL have their fair share of advantages and disadvantages. However, there's one type of SL, that you should always prefer to use whenever possible, that is Constructor Injection (strictly my opinion).
You can use Constructor Injection with both Dagger and/or Koin, so irrespective of the framework you use, it enables you to use IoC / DIP easily. In other words, Constructor Injection helps you achieve KISS.

For Dagger vs Koin, again the choice depends on multiple factors including your project size and requirements, but here are a few pointers that can both be in advantage or disadvantage based on your project/requirement.

• Koin resolves the dependencies at runtime whereas Dagger resolves them at compile time. Now, if you look at it, doing it at runtime might be in your favor, especially if you want your dependencies to be loaded lazily, however, as I pointed out before this can sometimes lead to unwanted surprises and even crashes. If you use Koin or any other SL, you need to have tests in place to make sure there are no surprises. Thankfully Koin provides a gradle task along with a test mechanism to do just that.
• Dagger/Hilt provides a way to automatically bind your Dynamic Feature modules, however with Koin, you need to manually bind them as the modules get downloaded.
• Dagger also has the option of providing dependencies lazily, with it's Lazy wrapper, but with Lazy as well, Dagger automatically resolves the dependencies at compile time to generate providers, so you're safe. Many people believe that Lazy is a way to do SL with Dagger.
• One common argument we get against Dagger is "The ugly public lateinit var", this can be easily avoidable with Constructor Injection for the most part, only for the Framework classes, you'll need this. Now, it's your decision whether you want to avoid Dagger for this or you'd consider it as a tradeoff.

To conclude, we can say the choice between DI and SL or Dagger and Koin is much like a choice between Statically Typed Languages (like Kotlin) and Dynamic Languages (like Python, etc.) none of these are bad, and both have their fair share of advantages or disadvantages, however, either one is better suited in a given scenario, while the other one might be better suited in some other scenario.

Disclaimer: Most of this post is based on my understanding, and my opinions. Also, it's worth noting here, that some good people believe Constructor Injection is DI, not SL, I wrote here what I believe to be appropriate.

Ever thought organizing test cases in Android are cumbersome? For instance, you have a function and there are 3 scenarios you want to test, for example, for 3 different inputs, it's supposed to return 3 different outputs, and you want to test this behavior, now what we mostly do in Android and JUnit 4 is create 3 different functions and name the functions like

fun `test functionName should return output1 for input1`()

If the target class has 10 more functions then, assuming you'll want to test each function in multiple scenarios, this Test class may end up with about 25-30 more such test cases, but there's no way to group them.
Let me be more specific about what I want, I still want all those tests within a single file, because they cover a single class that I'm testing, but I want to group all the test cases for a single function together, this way it's easy to find issues if something is broken.

If you're from web / JavaScript background, then you probably already know what I mean, and probably experienced it first hand. What I'm talking about is grouping of test cases like it's done in Jasmine or RSpec or even Cucumber's Gherkin for the matter. If you're not familiar with the above-mentioned test frameworks, you can refer to the cover image of this post to get an idea about how it'll look.

Well, it's now possible in Android, thanks to JUnit5 and JetBrains' Spek.

I was first introduced to Spek about two years ago by my dear friend Adit Lal and using it for personal projects ever since. Let me be honest with you, writing test cases with Spek is pure joy, it provides you two different styles of DSL (more on it later), and you can use your preferred one to write and better organize your test cases. The catch, however, is setup. As you might already know, JUnit5 doesn't support Android (or vice-versa) out-of-the-box, and Spek being the JUnit5 test framework (for Kotlin/JVM), you first need to set up JUnit 5 in your project, following which you need to setup Spek.

Since Spek setup isn't a straightforward process and getting frustrated is pretty easy here, I'll first show here how to setup Spek and JUnit 5, before discussing on writing test cases with Spek. If you want to skip the setup part, you can directly jump here

Setting up Spek and JUnit5 in your Android Project

We'll be using Spek 2.x, and we'll need to install the official Spek Framework plugin for that. You can get it here: https://plugins.jetbrains.com/plugin/10915-spek-framework. Install it and then restart your IDE (Android Studio or IntelliJ IDEA). Below is a screenshot from Android Studio -> Preferences -> Plugins (for Mac) after installing the plugin.

Once you've installed and restarted the IDE, we can proceed towards configuring your project for Spek and JUnit5.
First, we'll need to add JUnit5 and JaCoCo BuildScript dependencies and Spek Maven repo to your project level build.gradle file as shown below.

// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
  ext.kotlin_version = "1.3.72"
  repositories {
    google()
    jcenter()
  }
  dependencies {
    classpath "com.android.tools.build:gradle:4.0.0-beta04"
    classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    classpath "de.mannodermaus.gradle.plugins:android-junit5:$android_junit5_version"
    classpath "org.jacoco:org.jacoco.core:$jacoco_version"
    // NOTE: Do not place your application dependencies here; they belong
    // in the individual module build.gradle files
  }
}

allprojects {
  repositories {
    google()
    jcenter()
    maven { url "https://dl.bintray.com/spekframework/spek-dev" }
  }
}

task clean(type: Delete) {
  delete rootProject.buildDir
}

I'm using Kotlin version 1.3.72, in Android Studio 4 - Beta 4. The versions of Junit5, JaCoCo, and Spek are specified in gradle.properties file as follows.

spek_version=2.1.0-alpha.0.14+a763c30
android_junit5_version=1.5.2.0
junit5_runner=0.2.2
jacoco_version=0.8.1

Next, we'll move to app level build.gradle file.
Apply the JaCoCo and JUnit5 plugin as shown below.

apply plugin: 'jacoco'
apply plugin: 'de.mannodermaus.android-junit5'

After that, we need to set up InstrumentationRunner, paste the following inside defaultConfig, inside your android block.

testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
testInstrumentationRunnerArgument "runnerBuilder", "de.mannodermaus.junit5.AndroidJUnit5Builder"

Then to set up Spek2 Test Engine and event logging, paste the following code inside android block.

testOptions {
  junitPlatform {
    filters {
      engines {
        include 'spek2'
      }
    }
    jacocoOptions {
      // here goes all jacoco config, for example
      html.enabled = true
      xml.enabled = false
      csv.enabled = false
    }
  }
  unitTests.all {
    testLogging.events = ["passed", "skipped", "failed"]
  }
}

Almost done, we just need to add the dependencies now, copy and paste the following inside dependencies block.

//kotlin-stdlib-jdk8 required
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"
// assertion
testImplementation "org.jetbrains.kotlin:kotlin-test:$kotlin_version"
// spek2
testImplementation "org.spekframework.spek2:spek-dsl-jvm:$spek_version"
testImplementation "org.spekframework.spek2:spek-runner-junit5:$spek_version"
testImplementation "org.jetbrains.kotlin:kotlin-reflect:$kotlin_version"
androidTestImplementation 'androidx.test.espresso:espresso-core:3.2.0'
androidTestImplementation 'com.android.support.test:runner:1.0.2'
androidTestImplementation "de.mannodermaus.junit5:android-test-core:1.0.0"
androidTestRuntimeOnly "de.mannodermaus.junit5:android-test-runner:1.0.0"

And we're all done.

Don't forget to add implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version", even though you may have implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version", if you skip the jdk8 dependency, you'll encounter the following issue

java.lang.ClassNotFoundException: kotlin.streams.jdk8.StreamsKt · Issue #622 · spekframework/spek

I get java.lang.ClassNotFoundException: kotlin.streams.jdk8.StreamsKt when running Spek Framework plugin v2.0.0-IJ2018.3 in IntelliJ IDEA 2018.3.3 And my tests runs are green while they shouldn&#39...

GitHubspekframework

Also, you'll need to set target and source compatibility to jdk8, you can do that by pasting the following inside android block in your app level build.gradle.

compileOptions {
  sourceCompatibility JavaVersion.VERSION_1_8
  targetCompatibility JavaVersion.VERSION_1_8
}

kotlinOptions {
  jvmTarget = '1.8'
}

Writing Organised Test Cases with Spek

So, we're done setting up Spek, now it's time to write Tests, but what to test? I'm not following TDD here, as that's an entire topic on its own. What I want to say is that I already have the code I want to write tests on, and it's the following

package dev.rivu.mvijetpackcomposedemo.moviesearch.data.remote

//imports

class RemoteMovieDataStore(private val movieApi: MovieApi) : MovieDataStore {
    override fun getMoviesStream(searchQuery: String): Flowable<List<Movie>> {
        return Flowable.error(UnsupportedOperationException("Can't get stream from Remote"))
    }

    override fun getMovies(searchQuery: String): Single<List<Movie>> {
        return movieApi.searchMovies(searchQuery)
            .map { movieResponse ->
                movieResponse.movies
                    .map { movie ->
                        Movie(
                            imdbID = movie.imdbID,
                            poster = movie.poster,
                            title = movie.title,
                            type = movie.type,
                            year = movie.year
                        )
                    }
            }
    }

    override fun addMovies(movieList: List<Movie>): Completable {
        return Completable.error(UnsupportedOperationException("Can't add to Remote"))
    }

    override fun getMovieDetail(imdbId: String): Single<MovieDetail> {
        return movieApi.getMovieDetail(imdbId)
            .map {
                MovieDetail(
                    actors = it.actors.split(
                        ", ",
                        ignoreCase = true
                    ), // Jesse Eisenberg, Rooney Mara, Bryan Barter, Dustin Fitzsimons
                    awards = it.awards, // Won 3 Oscars. Another 171 wins & 183 nominations.
                    boxOffice = it.boxOffice, // $96,400,000
                    country = it.country, // USA
                    dVD = it.dVD, // 11 Jan 2011
                    director = it.director, // David Fincher
                    genre = it.genre, // Biography, Drama
                    imdbID = it.imdbID, // tt1285016
                    imdbRating = it.imdbRating, // 7.7
                    imdbVotes = it.imdbVotes, // 590,040
                    language = it.language, // English, French
                    metascore = it.metascore, // 95
                    plot = it.plot, // As Harvard student Mark Zuckerberg creates the social networking site that would become known as Facebook, he is sued by the twins who claimed he stole their idea, and by the co-founder who was later squeezed out of the business.
                    poster = it.poster, // https://m.media-amazon.com/images/M/MV5BOGUyZDUxZjEtMmIzMC00MzlmLTg4MGItZWJmMzBhZjE0Mjc1XkEyXkFqcGdeQXVyMTMxODk2OTU@._V1_SX300.jpg
                    production = it.production, // Columbia Pictures
                    rated = it.rated, // PG-13
                    ratings = it.ratings.map {
                        MovieDetail.Rating(
                            source = it.source,
                            value = it.value
                        )
                    },
                    released = it.released, // 01 Oct 2010
                    response = it.response, // True
                    runtime = it.runtime, // 120 min
                    title = it.title, // The Social Network
                    type = it.type, // movie
                    website = it.website, // N/A
                    writer = it.writer, // Aaron Sorkin (screenplay), Ben Mezrich (book)
                    year = it.year // 2010
                )
            }
    }

    override fun addMovieDetail(movie: MovieDetail): Completable {
        return Completable.error(UnsupportedOperationException("Can't add to Remote"))
    }
}

It's basically the remote implementation of DataStore interface of a Movie Search app, it has a dependency, a MovieApi instance, `MovieApi here is a Retrofit API interface as follows (if you're unfamiliar with Retrofit then consider this as a simple interface).

interface MovieApi {

    @GET("/")
    fun searchMovies(
        @Query("s") query: String,
        @Query("type") type: String = "movie",
        @Query("apikey") apikey: String = BuildConfig.ApiKey
    ): Single<MovieSearchResponse>

    @GET("/")
    fun getMovieDetail(
        @Query("i") imdbId: String,
        @Query("apikey") apikey: String = BuildConfig.ApiKey
    ): Single<MovieDetailResponse>
}

And, here's the DataStore interface, that our RemoteMovieDataStore implements

interface MovieDataStore {
    fun getMoviesStream(searchQuery: String): Flowable<List<Movie>>

    fun getMovies(searchQuery: String): Single<List<Movie>>

    fun addMovies(movieList: List<Movie>): Completable

    fun getMovieDetail(imdbId: String): Single<MovieDetail>

    fun addMovieDetail(movie: MovieDetail): Completable
}

So now as we have the code ready, let's get on with it and start writing test cases. As we already know, RemoteMovieDataStore depends on a `MovieApi` instance, so to write test cases for RemoteMovieDataStore, we either need to have a fake implementation of MovieApi or we need to mock it, here we are going to mock. A lot of developers are against mock, and to be honest, they're quite right, if you use mocking incorrectly it can become a pain, but it's a very useful tool as well. I completely agree with what Donn Felker said in this tweet chain below.

Donn Felker on Twitter

“Mock objects are useful ... Mock libraries are useful ...Mocking during tests is useful ... ... when used the correct way. Don’t accidentally get rid of something good just because it was used incorrectly (or you didn’t understand it). Use it correctly, or don’t use it.”

Twitterdonnfelker

I'll be using mockito and mockito-kotlin, you can use mockK as well if you like that.

Just like usual JUnit tests, we will be writing our test cases inside the test directory of your module. So, go inside test directory, go on and create the same package structure as your target class (here dev.rivu.mvijetpackcomposedemo.moviesearch.data.remote), and then create a new Kotlin file, let's name it RemoteMovieDataStoreSpecTest.
We will now declare a class of the same name inside the file and extend Spek, just like the below.

class RemoteMovieDataStoreSpecTest : Spek({
    //test cases go here
})

Once you paste the above code in the file, you should be able to see a green arrow in your IDE, just like the ones you see in regular JUnit test cases, below is the screenshot for your reference.

If you try and run the test cases now, it should fail with a message like test framework quit unexpectedly.
Now, before writing the tests, we need to create the mock as well as an instance of the target class, right? Creating mock is same as before, just paste the following inside the curly braces.

val movieApi: MovieApi = mock()

I kept it as val and outside of any initialization block because I want to create the mock instance once, and I believe, it's not really necessary to create a new mock instance for every single test, rather we can use whenever(..).thenReturn(..) for stubbing differently for each scenario or test case as we deem right.
Now since the mock dependency is ready, let's create the target class (RemoteMovieDataStore) instance. Generally, in JUnit4, we create the target class instance inside a function annotated with @Before which is called before each of the functions with @Test annotation is called. Most of the time, we use that function solely for variable initialization. With Spek, if you don't need a setup block solely for initializing variables, Spek provides you with a delegation called memoized, it works pretty much like lazy delegate in Kotlin, only that instead of initializing the variable first time it's used like lazy, a memoized variable will be initialized before running each of the test-cases in the group where the variable is declared. However, you might still want a setup block, for example, when you want to setup RxJava with your TestScheduler or more precisely when you want to set up something using RxJavaPlugins, or to start observing to LiveData, etc., for those scenarios, you can use beforeEachTest in Spek, it works all the same like @Before, within the block/group you defined it.

Now, for writing the test cases, we need to choose which DSL style to use. As I said earlier, Spek offers two styles of DSL for writing test cases, namely Specification which is also used in Jasmine and RSpec (also known as describe -> context -> it and Gherkin. You can use either/both of them, however, I strongly suggest don't mix them in a single project, rather use only one style throughout a project, for different projects you can use different ones. I'll be discussing both of them here, basically, I'll write the same tests using both the styles and you can decide for yourselves which one works for you better. First, we'll see the Specification style, I personally like this style better.

Using Specification style in Spek to write test cases

The first test I'll be writing is for the function getMovies as you can see in the implementation above, it expects a query, will call searchMovies method from MovieApi, map the response object to data layer model class, and will pass on downstream. If there's a network error or if the Single returned from searchMovies method emits an error, it should also emit the same error.
So, there are 2 scenarios here as below

1. movieApi.searchMovies emits error
2. movieApi.searchMovies emits data

Below is the group of test cases I wrote respecting both the scenarios.

describe("#${RemoteMovieDataStore::getMovies.name}") {

    context("movieApi emits error") {

        val error = Exception("some error")

        beforeEachGroup {
            whenever(
                movieApi.searchMovies(
                    query = anyString(),
                    type = anyString(),
                    apikey = anyString()
                )
            )
                .thenReturn(
                    Single.error(error)
                )
        }

        it("should emit the same error, wrapped in Single") {
            val testObserver = remoteDataStore.getMovies("").test()
            testObserver.assertError(error)
        }
    }

    context("movieApi emits data") {

        val dummyResponse = dummyMovieSearchResponse

        val dummyMovieList = dummyResponse.movies.map {
            Movie(
                imdbID = it.imdbID,
                poster = it.poster,
                title = it.title,
                type = it.type,
                year = it.year
            )
        }

        beforeEachGroup {
            whenever(
                movieApi.searchMovies(
                    query = anyString(),
                    type = anyString(),
                    apikey = anyString()
                )
            )
                .thenReturn(
                    Single.just(dummyResponse)
                )
        }

        it("should return the same error, wrapped in Single") {
            val testObserver = remoteDataStore.getMovies("").test()
            testObserver.assertValue(dummyMovieList)
        }
    }
}

describe is the group that contains all the test cases for the method getMovies, inside describe there are two sub-groups I defined with context, in the first subgroup, we tested the error scenario, and in the second subgroup, we tested the success scenario.

So, to break it down, describe and context is for grouping and/or subgrouping of test cases, and we can perform assertions inside it. However, I'd like to note here that it's not mandatory to have context inside describe, you can directly have it block inside your describe block and perform assertions, if you feel you don't need a context blog, I've done it for some methods as well, where there are no multiple scenarios to test.

Below is the whole RemoteMovieDataStoreSpecTest (with test cases for all the methods in RemoteMovieDataStore) for your reference.

package dev.rivu.mvijetpackcomposedemo.moviesearch.data.remote

import com.nhaarman.mockitokotlin2.mock
import com.nhaarman.mockitokotlin2.whenever
import dev.rivu.mvijetpackcomposedemo.moviesearch.data.datafactory.dummyMovieDetail
import dev.rivu.mvijetpackcomposedemo.moviesearch.data.datafactory.dummyMovieDetailResponse
import dev.rivu.mvijetpackcomposedemo.moviesearch.data.datafactory.dummyMovieSearchResponse
import dev.rivu.mvijetpackcomposedemo.moviesearch.data.model.Movie
import io.reactivex.rxjava3.core.Single
import org.mockito.ArgumentMatchers.anyString
import org.spekframework.spek2.Spek
import org.spekframework.spek2.style.specification.describe


class RemoteMovieDataStoreSpecTest : Spek({

    val movieApi: MovieApi = mock()
    val remoteDataStore by memoized { RemoteMovieDataStore(movieApi) }

    describe("#${RemoteMovieDataStore::getMoviesStream.name}") {

        it("should return Flowable.error with UnsupportedOperationException") {
            val testObserver = remoteDataStore.getMoviesStream("").test()
            testObserver.assertError(UnsupportedOperationException::class.java)
        }
    }

    describe("#${RemoteMovieDataStore::addMovies.name}") {

        it("should return Completable.error with UnsupportedOperationException") {
            val testObserver = remoteDataStore.addMovies(listOf()).test()
            testObserver.assertError(UnsupportedOperationException::class.java)
        }
    }

    describe("#${RemoteMovieDataStore::addMovieDetail.name}") {

        it("should return Completable.error with UnsupportedOperationException") {
            val testObserver = remoteDataStore.addMovies(listOf()).test()
            testObserver.assertError(UnsupportedOperationException::class.java)
        }
    }

    describe("#${RemoteMovieDataStore::getMovies.name}") {

        context("movieApi emits error") {

            val error = Exception("some error")

            beforeEachGroup {
                whenever(
                    movieApi.searchMovies(
                        query = anyString(),
                        type = anyString(),
                        apikey = anyString()
                    )
                )
                    .thenReturn(
                        Single.error(error)
                    )
            }

            it("should emit the same error, wrapped in Single") {
                val testObserver = remoteDataStore.getMovies("").test()
                testObserver.assertError(error)
            }
        }

        context("movieApi emits data") {

            val dummyResponse = dummyMovieSearchResponse

            val dummyMovieList = dummyResponse.movies.map {
                Movie(
                    imdbID = it.imdbID,
                    poster = it.poster,
                    title = it.title,
                    type = it.type,
                    year = it.year
                )
            }

            beforeEachGroup {
                whenever(
                    movieApi.searchMovies(
                        query = anyString(),
                        type = anyString(),
                        apikey = anyString()
                    )
                )
                    .thenReturn(
                        Single.just(dummyResponse)
                    )
            }

            it("should return the same error, wrapped in Single") {
                val testObserver = remoteDataStore.getMovies("").test()
                testObserver.assertValue(dummyMovieList)
            }
        }
    }

    describe("#${RemoteMovieDataStore::getMovieDetail.name}") {

        context("movieApi returns error") {

            val error = Exception("some error")

            beforeEachGroup {
                whenever(movieApi.getMovieDetail(imdbId = anyString(), apikey = anyString()))
                    .thenReturn(
                        Single.error(error)
                    )
            }

            it("should return the same error, wrapped in Single") {
                val testObserver = remoteDataStore.getMovieDetail("").test()
                testObserver.assertError(error)
            }
        }

        context("movieApi returns data") {

            val dummyResponse = dummyMovieDetailResponse

            val dummyMovieDetail = dummyMovieDetail

            beforeEachGroup {
                whenever(movieApi.getMovieDetail(imdbId = anyString(), apikey = anyString()))
                    .thenReturn(
                        Single.just(dummyResponse)
                    )
            }

            it("should return the same error, wrapped in Single") {
                val testObserver = remoteDataStore.getMovieDetail("").test()
                testObserver.assertValue(dummyMovieDetail)
            }
        }
    }
})

Using Gherkin style in Spek to write test cases

So, we already learned Specification style, now let's see the Gherkin style. We'll be refactoring the first test case we wrote into Gherkin style as follows.

Feature("#${RemoteMovieDataStore::getMovies.name}") {

    Scenario("movieApi emits error") {

        val error = Exception("some error")

        beforeEachGroup {
            whenever(
                movieApi.searchMovies(
                    query = anyString(),
                    type = anyString(),
                    apikey = anyString()
                )
            )
                .thenReturn(
                    Single.error(error)
                )
        }

        lateinit var testObserver: TestObserver<List<Movie>>

        When("remoteDataStore.getMovies is called") {
            testObserver = remoteDataStore.getMovies("").test()
        }

        Then("should emit the same error, wrapped in Single") {
            testObserver.assertError(error)
        }
    }

    Scenario("movieApi emits data") {

        val dummyResponse = dummyMovieSearchResponse

        val dummyMovieList = dummyResponse.movies.map {
            Movie(
                imdbID = it.imdbID,
                poster = it.poster,
                title = it.title,
                type = it.type,
                year = it.year
            )
        }

        beforeEachGroup {
            whenever(
                movieApi.searchMovies(
                    query = anyString(),
                    type = anyString(),
                    apikey = anyString()
                )
            )
                .thenReturn(
                    Single.just(dummyResponse)
                )
        }

        lateinit var testObserver: TestObserver<List<Movie>>

        When("remoteDataStore.getMovies is called") {
            testObserver = remoteDataStore.getMovies("").test()
        }

        Then("should emit the same data, mapped") {
            testObserver.assertValue(dummyMovieList)
        }
    }
}

So, now we've Feature instead of describe, Scenario instead of context and then we have an additional block When, inside where you need to perform the method call you're testing, then finally do the assertions in Then, if you have multiple assertions to perform for a given method call in a particular scenario, while using the Specification style we can have all of them inside it, but in Gherkin style it's recommended to have each of the assertions separately in Then blocks.

Wrapping Up

So, that's all about Spek, we have covered setup, initializations, and then we learned about two different DSL styles Spek offers for writing test cases. Hope you liked it. You can find them all inside this demo project I'm building with Jetpack-Compose: https://github.com/RivuChk/Jetpack-Compose-MVI-Demo, that project is still WIP.
Please share your feedback/suggestions in the comments section

I'm giving and taking interviews for a long time now (obviously giving interviews for a longer time than taking interviews), I gave interviews to a few big startups/companies (I now work at one of them 😉), I also took a lot of interviews (currently I'm taking ~2 interviews every working day), I also talked to a few experts in Android domain I know personally about their interview experiences and a few of my friends who are regularly taking interviews (both in my organization and outside). So, I'm gonna summarise them here to help you make a better-informed decision on your interview rounds/policies/technics.

Before starting, let's agree on something. We do interviews to check the following, not to test if they can be a successor of Alan Turing.

• Is the candidate a good fit for the team culturally? (Mostly done in Bar Raiser / Management / HR rounds)
• Are they good at communication? (again, mostly done in Bar Raiser / Management / HR rounds)
• Is the candidate good / can be good at the Day to Day job they'll have to do here if selected? (Main purpose of Tech Rounds)

Now that we agreed on what we check for in the interviews, let us now focus on what exactly that day to day job is.

So, I'm in the Software Development industry for almost a decade now, currently working as a Sr. Software Engineer (Android) at BYJU'S (India's biggest Ed-Tech startup).

So, what do I do in my day to day job? Or, let's say, what do most of the Sr. Developers / Sr. Engineers in the Android domain do in their Day to Day job (let's talk about Product based companies/startups)?The answer is that we all develop features, sometimes we work alone in a feature, sometimes we with a team on a feature, sometimes we develop MVP (not Model-View-Presenter, Minimal Viable Product) apps, and sometimes we lead a small team of developers developing an MVP / Feature, and sometimes we fix bugs (yes, it's sometimes not most of the times, if you do proper Unit Testing).
Now, when we write code, how much Data Structure do we need? Well obviously we do sorting and searching, so yes, we use Data Structure, but how much concise decision do we need to make that requires Data Structure knowledge? Confused with the question!?, let's put it the other way, what do we write when you're sorting a list? Mostly the below.

list.sortedBy {
    it.property
}

Same for search, we use the Language / Library / Framework defined algorithms for our tasks, we don't write those algorithms ourselves. Now what the regular optimizations we perform on your algorithms for which we believe we need DS rounds? The list is below

• Try to avoid nested loops
• Instead of having multiple loops back to back, if things can be done in a single loop and that won't affect the cleanliness then use a single loop
• Try to run a loop as much less as you can

Now, tell me how much DS knowledge do you need to make these decisions? You just need an understanding of what is Time Complexity, that's all you need to know. I'm sure backend devs or developers working on System Programming does a lot more than these and really require high skills in DS. Also, in Android, if you're building something like LeakCanary or if your day to day work includes working extensively in Annotation processors / Compiler optimizations, I can understand you need really good Data Structure skills, this also explains why companies like Microsoft / Google needs to have extensive DS rounds.

But, if the job role of the candidate is to work on an Android app, no matter how big/complex the project is, you don't need much Data Structure knowledge, you just need a regular understanding of Time Complexities and how to optimize them.

A popular argument I hear when I present the above logic is, then how to check the candidate's skills properly, frameworks may change any day and for good programmers, it's easy to pick up any framework. Another opinion is there are only so many good questions you can ask in a framework, also asking a well-experienced candidate to explain the difference between Activity and Fragment is not a good choice either. The thing is I'll not oppose these arguments, rather I agree to all these arguments totally, I'm here to give an opinion that will answer to these arguments / give a better alternative. Here comes the second and crucial part of this blog - Design Patterns.
Now, let's re-run the exercise. What do we do in our day to day work? we develop features, sometimes we work alone in a feature, sometimes we with a team on a feature, sometimes we develop MVP (Minimal Viable Product) apps, and sometimes we lead a small team of developers developing an MVP / Feature, and sometimes we fix bugs, sometimes we also refactor / re-architecture old codebase.
So, let's say you're building an MVP (Minimal Viable Product), while coding, you need to move faster, you can't spend a huge time on discussing and deciding the architecture, but you also need to keep future scope in mind, i.e. in near future, it might be taken forward as a product, and then you'd want to re-use what you're building now, rather than writing everything from scratch. To do that you need to be very good about Architectures / Architecture patterns.
Forget about choosing Architecture for MVP or for feature, or even refactoring old codebase, we don't get that opportunity every day, that's actually our dream work right. But there are few decisions we make every day, below is a non-exclusive list.

• Should we use Dagger or Koin for this project?
• Should this class be Singleton?
• Should I use @Singleton annotation for this dependency or @FeatureScope?
• Should I create an interface for this class?
• Should I use Mocking / Faking for this test?
• Should I create a new callback interface or add a method to the existing one?

Now think what knowledge/skill we use most to make those decisions every day? Is that Data Structures? No, DS is no way related to this. This is nothing else but Design Patterns. I'm not saying if you know Design Patterns you'll never need to have discussions before making those decisions, but Design Patterns / Design Principle knowledge will help you immensely take a logical decision. Not for the above-mentioned list of decisions, but Design Principles / Design Patterns are required for numerous day to day Programming jobs, irrespective of platform.

I recently gave an online talk about Android Architecture Patterns, there as well, I started with discussing SOLID principles, because of their close relation with every Architecture Pattern. If you look close enough to any Architecture / Architecture pattern, you will find most of the part if that architecture is inspired by some Design Pattern.

Dive into Android Architectures

https://speakerdeck.com/rivuchk/arch-patterns-in-android

YouTube

So, to answer the arguments we started this part with, we can replace Data Structure rounds with intensive Design Pattern rounds, so that we don't have to depend only on the frameworks for evaluating the candidate if a person is good with Design Pattern, they're generally good with programming as a whole and should be able to keep pace with changes in framework or pickup another framework if it needs to be. Just like in DS round, you can come up with complex custom made problems to test DS skills of a candidate, in Design Pattern rounds as well, you can give a problem to the candidate and let the candidate solve that using Design Pattern knowledge/skills, this way you'll subtly evaluate the analyzing / problem-solving skills of the candidate as well.
Another thing you can do (a lot of startups are already doing this), is give the candidates an assignment, to develop an app over a given problem statement (for example ask them to build an app to show a list of Trending Repositories from GitHub), also if the candidate already has some interesting project and willing to share, you can consider evaluating that as well. Do this before any of the interview rounds, that way you can evaluate candidate's Android skills firsthand and save both the panel's and candidate's time as well.

I would like to mention here something I noticed lately while taking interviews. Most of the candidates say they follow MVVM, LiveData, etc. because Google recommends them. That's great right, earlier there were very few who were even interested in Architectures right? No, if you go a bit deeper and ask them questions on not how to set up your project with MVVM, but how they work or theory behind a component of the said Architecture, most of the candidates get stuck there. I believe that's not a result of not-updating yourself, but rather a result of not giving care to the basics - Design Patterns, once you understand Design Patterns properly, it'll be easier for you to get the theory behind every component of any Architecture.
So, I'd like to end this post requesting all my fellow developers/interviewers to set up a common practice to have Design Patterns, especially for senior roles. Can we agree? Let me know in the comments section.

Note: This article was published back in May, 2019, just after Jetpack Compose got announced in Google IO. A lot changed since then, including all the APIs discussed here. And you no longer need to fork AOSP, just to use Compose.

During Google IO 2019, The Android team announced Jetpack Compose, a Kotlin based, unbundled UI toolkit for writing declarative/reactive/functional UI code.

Now, what do we mean by saying declarative/reactive/functional UI code? Instead of writing tough to read, bloated XML files for UI and invoking them with id/tag in Java/Kotlin code, we will be writing self explanatory UI code in Java/Kotlin files itself in Reactive/Functional Programming Style, along with the behavior.

Jetpack Compose isn't yet ready for production, not even in Alpha / Beta, it's in development and if you want to check it out you need to fork the AOSP project, and need to use a special Android Studio.

So, why do we care to check it now? Why not wait for it being atleast in Alpha? The answer is Jetpack Compose will disrupt the way we presently structure code and build architecture, we will need to think in different ways since we will no longer be able to get view instance and will not be able to update UI based on Async operations in current ways, we have to follow different approaches. Gues what, we got sufficient time in our hand to figure out how to structure our code and architecture around Jetpack Compose, before it goes production ready, but in order to do so, we first need to understand how Jetpack Compose works, how to apply themes / styles, how to maintain state, and how to update view states based on async operations / network response, which we will be discussing in this series, so that once we get strong grips on Jetpack Compose, we can start thinking on architectures and code patterns.

For detailed instructions on how to fork AOSP and setup Android Studio, please visit: https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/ui/README.md

So, you are interested in Jetpack Compose and already set up everything, what more are we waiting for? Let's get started.

The @Composable functions

The API is literally named after it, Composable functions are building blocks / smallest units of building UI in Jetpack Compose.
Yes, you read it right, say goodbye to creating numbers of Classes and XML Layout files and attribute-sets.

You just need to write simple Kotlin functions, returning Unit, to design your UI and annotate them with @Composable, withing this function, you can use pre-existing @Composable functions like DSL, these pre-existing composable functions can be again created by you or can be shipped with Jetpack Compose API, or any other plugin/library for that matter.

For instance, take the below example.

@Composable
fun Buttons(onClick: ()->Unit) {
    Button(onClick = onClick, text = "Button 1")
    Button(onClick = onClick, text = "Button 2")
}

This is a Composable function, which in turn calls another Composable function - Button (from package androidx.ui.material) twice to display two buttons in the screen.
I can now write another composable function as follows and call the Buttons function.

@Composable
fun ButtonsDemo(onClick: () -> Unit) {
    Text(text = "Text 1")
    Buttons(onClick)
}

This Composable function ButtonsDemo() will display one text and two button components in the screen when called.

As you've already noticed, the Composable functions can have parameters, based on your requirements, but are not expected to return any value.

Set Content to Activity

So, we've created composables based on our UI requirements, now it's time to display them inside the Activity.

While using XML, we call setContentView(R.layout.layout_name) or setContentView(viewInstance) to display a view instance / layout resource to the screen, with Jetpack Compose, we need to call setContent and pass a @Composable lambda to it, from where we can call the @Composable functions, like the below example.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContent {
        Text(text= "Hello World")
    }
}

Below is the definition of setContent extension function.

fun Activity.setContent(composable: @Composable() () -> Unit) =
    setContentView(FrameLayout(this).apply { compose(composable) })

It basically creates a FrameLayout, composes our @Composable lambda and thus all @Composable functions within it and draws it inside the FrameLayout for display.

So, our Hello World application is done. Now, let us wrap the text in our custom Composable, as follows.

class SimpleActivity : Activity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            CustomText(text = "Hello World")
        }
    }
}

@Composable fun CustomText(text: String) {
    Text(text = text, style = +themeTextStyle { h4 })
}

Should work like a charm, right? Wrong, as soon as you install the app and start the Activity, you'll get this crash: https://stackoverflow.com/q/56050892/4284706, workaround? You just need to put your composable inside a CraneWrapper and a Theme, just as follows.

class SimpleActivity : Activity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            CraneWrapper { 
                MaterialTheme { 
                    CustomText(text = "Hello World")
                }
            }
        }
    }
}

@Composable fun CustomText(text: String) {
    Text(text = text, style = +themeTextStyle { h4 })
}

Run it now, and it'll work as expected.

Now, why does that happen? Why do we need the CraneWrapper? As said by Ragunath Jawahar, Romain Guy and Leland Richardson in compose channel of Kotlinlang Slack, the CraneWrapper is a Composable, that hosts the compose tree with help of AndroidCraneviewgrants access to the Context, Density, FocusManager and TextInputService implicitly to all of its children, without CraneWrapper the composables doesn't gets access to these resources thus throws exception causing your app to crash.

Note: I believe (also hinted by the Google team working on Jetpack Compose), in future we will probably not need to use CraneWrapper, as they will fix this soon enough, by probably adding CraneWrapper inside setContent {} or otherwise.

Style it your way

So, we created Hello World app and created+used our first custom Composable, now let's take one more step forward, how to define your own styles / text styles / theme? Let's figure it out together.

Generally, with our present structure, we define Themes and Styles in a XML file and keep it inside styles folder, and to use it we refer it from the manifest file (to set default theme for an Activity), and from Views in XML, to set a style to that particular view, sometimes we also call them from Java/Kotlin file and pass it to an instance of a view.

Defining and using styles/themes are easier with Jetpack Compose, more over a brilliant use of Kotlin receiver types ensure that the IDE suggest you available styles / textstyles when using them. In the last example, I used MaterialTheme (which comes along with the ui-material module of Compose) as the default theme for the activity, I also used h4 from MaterialTheme and applied it to Text inside CustomText, as CustomText was used inside MaterialTheme, all the styles inside MaterialTheme became available to it, thanks to function composing, and then we just used the h4 text style from it.

Enough of contexts, now let's get hands dirty and define our new Custom Theme.

val primary = Color(0xFF021AEE.toInt())
val primaryText = Color(0xFFEE0290.toInt())
val secondary = Color(0xFFD602EE.toInt())
val white = Color(0xFF26282F.toInt())
val black = Color(0xFFFFFFFF.toInt())

@Composable
fun CustomTheme(@Children children: @Composable() () -> Unit) {
    val colors = MaterialColors(
        primary = primary,
        secondary = secondary,
        surface = white,
        onSurface = black
    )
    val textStyles = MaterialTypography(
        h1 = TextStyle(fontFamily = FontFamily("RobotoCondensed"),
            fontWeight = FontWeight.w100,
            color = primaryText,
            fontSize = 96f),
        h2 = TextStyle(fontFamily = FontFamily("RobotoCondensed"),
            fontWeight = FontWeight.w100,
            color = primaryText,
            fontSize = 60f),
        h3 = TextStyle(fontFamily = FontFamily("Eczar"),
            fontWeight = FontWeight.w500,
            color = primaryText,
            fontSize = 48f),
        h4 = TextStyle(fontFamily = FontFamily("RobotoCondensed"),
            fontWeight = FontWeight.w700,
            color = primaryText,
            fontSize = 34f),
        h5 = TextStyle(fontFamily = FontFamily("RobotoCondensed"),
            fontWeight = FontWeight.w700,
            color = primaryText,
            fontSize = 24f),
        h6 = TextStyle(fontFamily = FontFamily("RobotoCondensed"),
            fontWeight = FontWeight.w700,
            color = primaryText,
            fontSize = 20f)
    )
    MaterialTheme(colors=colors, typography = textStyles) {
        val value = TextStyle(color = black) // set default textstyle when not specified
        CurrentTextStyleProvider(value = value) {
            children()
        }
    }
}

That's it, we created our own custom Theme, now in order to use it in the last example, we just need to make the below changes.

class SimpleActivity : Activity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            CraneWrapper {
                CustomTheme {
                    CustomText(text = "Hello World")
                }
            }
        }
    }
}

@Composable fun CustomText(text: String) {
    Text(text = text, style = +themeTextStyle { h4 })
}

That's right, we just need to call CustomTheme from the activity, instead of MaterialTheme and everything else will be taken care of.

Update: No XML Syntax

As Suggested by Romain Guy in the comments section, XML Syntax is going away, and we shouldn't use that with Jetpack Compose, so I updated all the code here with DSL syntax and asking all of you to not use the XML syntax, rather use it the way it is, a DSL.

While invoking @Composable functions, if you're getting compile time error saying: "Stateless function shouldn't be invoked" then, you need to add the below lines in module level build.gradle inside android block. This is a temporary workaroud, until the team ships a proper fix.

tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).configureEach { compile ->
    compile.kotlinOptions.freeCompilerArgs +="-P"
    compile.kotlinOptions.freeCompilerArgs += "plugin:androidx.compose.plugins.kotlin:syntax=FCS"
}

So you're interested in functional programming and want to learn it, great. In case you are still confused about whether to use/learn functional programming or not and what benefits it'll serve to you / your performance overall, then let's get it sorted and get rid of your confusion first.

Why Functional Programming?

Every developer like me, who are from OOP background gets a FOMO (Fear to Move Out) to start on functional programming.
If we want to describe the benefits of functional programming in one sentence then it'll say "Functional Programming helps you write pragmatic, less error-prone and concurrency ready (without any extra effort) code".
How? Let us start answering this by knowing what functional programming is.

What is Functional Programming

Functional programming is a programming paradigm in which we try to bind everything in pure mathematical functions style.
Credit - https://www.geeksforgeeks.org/functional-programming-paradigm/

Many people say functional programming is a replacement of Object Oriented Programming and they're very different. However, in my opinion, you can think of functional programming not as a replacement but as an evolution of OOP.
Both FP and OOP rely on Abstraction and Polymorphism however instead of Inheritance in OOP, FP puts its bet on Composition (explained later in the series). Another big difference between OOP and FP is that in OOP we rely mostly on classes and properties of those classes, however, in functional programming having properties in classes other than data (POJO) classes (or in simpler words having global variables) is strongly discouraged, what is done instead is, we use more Pure Functions and Immutability and pass data from one function to another.
The objective here is to stay as close to mathematics as possible.
So, if you can consider functions similar to an immutable hashmap, where a particular parameter always makes the function return the same value and avoid state change, then the concurrency problem is automatically solved.

Even if you don't want to follow FP, you can still use the four concepts below to make your program scalable.

FP Concepts

Still here? That means you're now determined to learn Functional Programming, so let's get started.
Every programming paradigm stands on top of few basic concepts, for example, to learn Object Oriented Programming (OOP), you've to learn basic concepts underlying it such as Inheritance, Polymorphism, Abstraction etc. Similarly, to learn Functional Programming, you first need to learn four basic concepts of functional programming as listed below, please note that even if you don't want to follow FP, you can still use the four concepts below to make your program scalable.

• Immutability
• Pure Functions
• Lambda
• High-Order Functions

So lets with them.

Immutability

The concept of Immutability says, that a variable should return the exact same value when accessed at different times. This might sound similar to Constants, they are in fact similar to some extent, but it's not entirely the same.
Let us take a look at below code to understand.

data class MyData(val someValue1: String, val someValue2: String)

fun processUpdatedData(myData: MyData) {
    ....
}

val myData = MyData("V1", "V2")
processUpdatedData(myData.copy(
    someValue2 = "Updated value"
))

In the above example, myData is an immutable variable, but when we need to use an updated value, we are using the copy constructor to get an updated instance of the MyData class, where the actual variable myData still holds the same value.
In Java, the String class is immutable, but you can still modify a String variable, what is done here is that whenever you modify a String variable in Java, it internally uses the copy constructor, sets the updated value in a new instance of String, and updates the register (internal pointer) for your variable to point to the new location in memory where the updated instance resides. While the old value still resides in memory at its old place. Now, if you're thinking of memory efficiency, then let me tell you java did that to improve memory efficiency only. So every String variable in Java, which has the exact same value, resides in the same memory location, if you modify one variable among them, that particular variable will just start pointing to some other memory location with the updated value.
So, that was about the concept of immutability and how Java used immutability to increase memory efficiency, how to implement them in your code in Kotlin? Let's find out.
Unlike Java, Kotlin provides you easy ways to use immutability, and unlike other functional languages, Kotlin doesn't enforce immutability, but it encourages you to use Immutability.
For your variable, you can use val instead of var, and please don't use any hacks to change the value of the val variable as you like, val just works like final variable in Java, it doesn't guaranty immutability, it's solely on the developers hand whether to respect immutability or not, as Kotlin uses getters and setters for variable access, a developer can always bypass immutability by using a custom getter, and please don't do that, please use a var instead of you really need such operations.
Kotlin also provides support for immutable collections, in fact by default all collection objects are immutable (like List, Map, Set etc.), if you need to modify them after creation, you can use the mutable variant of these collections (eg. MutableList, MutableSet, MutableMap etc.).

Pure Functions

The idea behind Pure Functions is that functions with their parameter should be cache-able, in order to get better performance, to achieve this, functions need to resemble their mathematical counterpart, that is, a function f should return the exact same value y when x is passed as parameter, in mathematical notation f(x) = y should always be true. Another important thing is a function shouldn't use/modify anything outside its scope.
Let's take an example.

fun power(number: Int, exponent: Int): Int {
    var result = 1
    if (exponent < 0) {
        throw Exception("Negative value of exponent isn't supported, passed $exponent")
    }
    for(i in 1..exponent) {
        result = result * number
    }
    return result
}

In the above program, function power() would always return the same value for a given combination of number and exponent also, this function doesn't access or modify anything out of it's scope thus the power() is a Pure Function.

Side Effects

When a function (presumed Pure Function) accesses or modifies anything out of it's scope, then that function is considered having Side Effects.
For example if we add a log / println in the above function (the power() function), then it'd not be Pure anymore and would be considered having Side Effects, and that log/println would be the said Side Effect.

Lambda

Lambda are often referred as anonymous functions, Lambda (uppercase Λ, lowercase λ) is actually 11th letter in Greek alphabet and often used in mathematics to denote functions. That's where the term lambda came from into programming.
So, what are they exactly? With lambda you can write a function like a mathematical expression, using a pair of curly braces and an arrow notation (->).
Kotlin being a Functional Language, and treating Functions as it's first class citizen, gives you freedom to assign a lambda to a variable and even pass them to another function (that's where the High-Order Function comes into picture, discussed in the next section).
Let's consider the below example.

val power = {number: Int, exponent: Int ->
    var result = 1
    if (exponent < 0) {
        throw Exception("Negative value of exponent isn't supported, passed $exponent")
    }
    for(i in 1..exponent) {
        result = result * number
    }
    result
}

println(power(10,2))
println(power.invoke(10,3))

So, in the above example, the power is a variable as well as a function at a time, or it's better to say, that the power is a variable, which holds a function. The lambda, started and ended with the pair of curly braces, inside that, before the arrow notation (->), we provided the name and types of for the parameters, and the function body after ->.
The lambda returns the value last line, in this case it'll return the value of result.
A lambda function can be invoked like an usual function or also by calling invoke().
To denote a variable would contain a lambda, you can use (PARAMETERS)->RETURN_TYPE, replacing PARAMETERS with list of parameters, and RETURN_TYPE with the return type of the function/lambda.
So, as we learned a bit about Lambda, let's move towards it's close relative - High-Order Function.

High-Order Functions

The name High-Order Function implies that these are functions which have higher order / higher class, than the usual functions. This is in fact to some extent correct. Those functions, which take other functions as parameter or returns another function are called High-Order Function, and here's where lies a strong coupling of Lambda and High-Order Function.
Basically, High-Order Functions take Lambda(s) as parameter, or return a Lambda.
Below are two examples of High-Order Functions.

fun applyToNumberIfPositive(number: Int, lambda: (Int)->Int): Int {
    return if(number>0) lambda(number) else number
}

fun getSquareFunction(): (Int)->Int {
    return {number ->
        number*number
    }
}

The first one is a high-order function, which expects a lambda as parameter, whereas the second one is a high-order function which returns a high-order function.
We can invoke them as follows.

applyToNumberIfPositive(5, {
    number ->
    number*2
})
getSquareFunction().invoke(2)
getSquareFunction()(4)
//We can also invoke them together.
applyToNumberIfPositive(10, getSquareFunction())

We could invoke both the High-Order functions together, as the applyToNumberIfPositive function expects a lambda with signature exactly same as the getSquareFunction function returns.
Cool, isn't it?

Wrapping Up

So, in this post, we learned about basics of Functional Programming and it's underlying concepts, i.e. Immutability, Pure Functions, Side Effects, Lambda and High-Order Functions.
Most important of all, we crossed FOMO to finally begin learning Functional Programming.
But these are just beginning, to properly learn Functional Programming, one must also learn Typed FP and Category Theory, which are covered in the next post of this series.

In the next article of this series, we will discuss Typed FP and Category Theory and will see how to use Arrow for Type FP in Kotlin