DEV Community: Mahendran

Using ViewModel-LiveData with Jetpack Compose

Mahendran — Mon, 12 Sep 2022 12:20:31 +0000

In this post I want to cover on where/how to make API calls on a Jetpack compose screen. In an essence the traditional UI system and and compose differs on where do we invoke the remote/async API vs how the data delivered to us. Following swim-lane diagram explains the overview of the data flow.

As we can see in the diagram, the ViewModel and inner layers don't differ. In other words, if you're using ViewModel with Android UI, only the UI classes will change and rest of the layers can be kept as it is.

Implementation

In compose, LiveData is consumed as state. To do so, add this dependency in build.gradle.

// https://maven.google.com/web/index.html?q=livedata#androidx.compose.runtime:runtime-livedata
implementation "androidx.compose.runtime:runtime-livedata:$compose_version"

One-off call

In the composable function, observe the data as state using LiveData#observeAsState extension.

Next, make API call using LaunchedEffect - for one time call, use Unit or any constant as key.

For UI, as usual - skim through the data and construct the UI. This example shows listing books.

@Composable
fun BooksScreen(
    viewModel: BookListViewModel = hiltViewModel<BookListViewModelImpl>()
) {
    // State
    val books = viewModel.books.observeAsState()

    // API call
    LaunchedEffect(key1 = Unit) {
        viewModel.fetchBooks()
    }

    // UI
    LazyColumn(modifier = modifier) {
        items(books) {
            // List item composable
            BookListItem(book = it)
        }
    }
}

User triggered - API calls

In case you want to execute the LaunchedEffect block again - such as force refresh, use a variable and conditionally update the key1 value. Remember every time when the key change, it'll invoke the API. So, keep in mind to not assign the value in render logic and put it behind user action.

@Composable
fun BooksScreen(
    viewModel: BookListViewModel = hiltViewModel<BookListViewModelImpl>()
) {
    // State
    val books = viewModel.books.observeAsState()
    var refreshCount by remember { mutableStateOf(1) }

    // API call
    LaunchedEffect(key1 = refreshCount) {
        viewModel.fetchBooks()
    }

    // UI
    Column() {
        IconButton(onClick = {
                        refreshCounter++
                   }) {
                        Icon(Icons.Outlined.Refresh, "Refresh")
                   }
        LazyColumn(modifier = modifier) {
            items(books) {
                // List item composable
                BookListItem(book = it)
            }
        }
    }
}

ViewModel implementation

ViewModel is an interface contract which exposes data through LiveData and has helper functions to carry out actions.

interface BookListViewModel {
    // Data
    val books: LiveData<List<Book>>
    // Operations
    fun fetchBooks()
}

The consuming classes shall refer the interface and the actual implementation will be an Android ViewModel. Wiring of this implementation to UI classes will be taken care by dependency injection.

Internally, the viewmodel implementation overrides the data variables to provide actual data. As for the operations, the viewModelScope ensures the API call lives within viewmodel's lifetime, and launches the remote operation.

Remember viewModelScope still executes in Main thread. Offloading the task to IO happens in repository layer.

class BookListViewModelImpl(private val repo: BooksRepository) : BookListViewModel {
    private val _books = MutableLiveData<List<Book>>()
    override val books: LiveData<List<Book>>
        get() = _books

    override fun fetchBooks() {
        viewModelScope.launch {
            _books.value = repo.fetchBooks()
        }
    }
}

Repo implementation

Repo executes a long running operation. In kotlin world, it is a suspend function runs in IO dispatcher context.

class BooksRepository {

    suspend fun fetchBooks() : List<Book> = withContext(Dispatchers.IO) {
        // Some API call
        // Parser logic
        val books = listOf<Book>()
        books
    }
}

Android Utility belt — Collection of dependencies for a greenfield project

Mahendran — Thu, 28 Oct 2021 16:12:51 +0000

Starting an android project will bring in a new set of challenges 👀 aka adding tons of Gradle dependencies.

Even though you use these dependencies in almost all your applications, you can't just grab them from the previous project because it might be an outdated version. By the time you find the latest version and add it to the project, you'd lose half the energy. Coming to the point!!

…

In this post, I composed a list of dependencies that I use in most of my projects. They're at the latest version when I write it(Oct 2021). For convenience, hyperlinked the maven central page so that picking the latest version is just a click away.

I highly recommend using this template project for greenfield projects. From DI/logger to instrumentation test everything has been perfectly set up. Though, the network dependencies are not present in the template. So, look up below and add dependencies as you see fit.

…

Network

OkHttp3

implementation(platform("com.squareup.okhttp3:okhttp-bom:4.9.2"))
implementation("com.squareup.okhttp3:okhttp")
implementation("com.squareup.okhttp3:logging-interceptor")

or

implementation 'com.squareup.okhttp3:okhttp:4.9.2'
implementation 'com.squareup.okhttp3:logging-interceptor:4.9.2'
testImplementation("com.squareup.okhttp3:mockwebserver:4.9.2")
implementation 'com.squareup.okhttp3:mockwebserver3:5.0.0-alpha.2'

📌okhttp-bom 📌 logging-interceptor

📌 mockwebserver 📌 mockwebserver3

…

Retrofit

implementation 'com.squareup.retrofit2:retrofit:2.9.0'

implementation 'com.squareup.retrofit2:converter-gson:2.9.0'
implementation 'com.squareup.retrofit2:converter-moshi:2.9.0'

implementation 'com.squareup.retrofit2:adapter-rxjava2:2.9.0'
implementation 'com.squareup.retrofit2:adapter-rxjava3:2.9.0'

📌 retrofit 📌converter-gson

📌 converter-moshi 📌 adapter-rxjava2

📌 adapter-rxjava3

Threading and dispatchers

Coroutines

implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.5.2'
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.5.2'
testImplementation 'org.jetbrains.kotlinx:kotlinx-coroutines-test:1.5.2'

📌coroutines-core 📌 coroutines-android

📌 coroutines-test

…

RXJava

  implementation 'io.reactivex.rxjava3:rxjava:3.1.2'    
  implementation 'io.reactivex.rxjava3:rxandroid:3.0.0'

📌 rxjava 📌rxandroid

Serialization

Moshi

implementation 'com.squareup.moshi:moshi:1.12.0'
implementation 'com.squareup.moshi:moshi-kotlin-codegen:1.12.0'

📌 moshi 📌moshi-codegen

…

GSON

implementation 'com.google.code.gson:gson:2.8.8'

📌 gson

Jetpack

Following dependencies are also available in Google maven.

Livedata / viewmodel

implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.3.1'
implementation 'androidx.lifecycle:lifecycle-livedata-ktx:2.3.1'

📌 viewmodel-ktx 📌 livedata-ktx

…

UI

implementation 'com.google.android.material:material:1.4.0'
implementation 'androidx.constraintlayout:constraintlayout:2.1.1'
implementation 'androidx.recyclerview:recyclerview:1.2.0'

📌 material 📌constraintlayout

📌 recyclerview

…

Fragment

implementation 'androidx.fragment:fragment-ktx:1.3.6'

📌 fragment-ktx

…

Navigation

implementation 'androidx.navigation:navigation-ui-ktx:2.3.5'
implementation 'androidx.navigation:navigation-fragment-ktx:2.3.5'


androidTestImplementation 'androidx.navigation:navigation-testing:2.3.5'

📌 navigation-fragment-ktx 📌navigation-ui-ktx

📌 navigation-testing

…

Room - DB

 def room_version = "2.3.0"

implementation "androidx.room:room-runtime:$room_version"
kapt "androidx.room:room-compiler:$room_version"
 // optional - Kotlin Extensions and Coroutines support for Room
implementation "androidx.room:room-ktx:$room_version"
// optional - Test helpers
testImplementation "androidx.room:room-testing:$room_version"

📌 room-ktx

Dependency injection

Dagger

Guide: https://developer.android.com/training/dependency-injection/dagger-android

// app level Gradle
apply plugin: 'kotlin-kapt'


{
    implementation 'com.google.dagger:dagger:2.39.1'
  kapt 'com.google.dagger:dagger-compiler:2.39.1'
}

📌 dagger

…

Hilt

Guide: https://developer.android.com/training/dependency-injection/hilt-android#groovy

// project level gradle
buildscript {
    dependencies {
        classpath 'com.google.dagger:hilt-android-gradle-plugin:2.39.1'
    }
}

// app level gradle
apply plugin: 'kotlin-kapt'
apply plugin: 'dagger.hilt.android.plugin'

dependencies {
    implementation "com.google.dagger:hilt-android:2.39.1"
    kapt "com.google.dagger:hilt-compiler:2.39.1"

    implementation 'com.google.dagger:hilt-android-testing:2.39.1'
}

📌 hilt-android 📌hilt-android-testing

Image loaders

Glide

implementation 'com.github.bumptech.glide:glide:4.12.0'

📌 glide

…

Coil

implementation 'io.coil-kt:coil:1.4.0'

📌 coil

Testing

testImplementation 'junit:junit:4.13.2'
androidTestImplementation 'androidx.test.ext:junit:1.1.3'
androidTestImplementation 'androidx.test.espresso:espresso-core:3.4.0'

testImplementation 'com.google.truth:truth:1.1.3'

📌 Google truth

Android — Instrumentation test with hilt & espresso

Mahendran — Thu, 21 Oct 2021 16:30:32 +0000

Testing in Android has been a pain from the beginning and there is no standard architecture setup to execute the frictionless test. As you know there is no silver bullet for all the snags. This piece of article covers how do you fake dependencies to your hilt-viewmodel and assert the same from fragment using espresso.

What do we achieve here?

Decoupled UI from navigation and real data source
Feed fake data to our viewmodel
A less flaky test since we control the data

-or- Explained in a single picture

Thanks: Mr. Bean - Art disaster

...

Testing strategy
Dependency overview
Test runner setup
Shared test fakes
Writing integration test
Instrumentation or UI tests
- Faking modules
- The HiltAndroidTest
Wrapup
Resources

...

Testing strategy

100% code coverage is a myth and the more you squeeze towards it, you end up with flaky tests. Provided the content is dynamic and involves latency due to API calls, it is simply hard to achieve. So, to what degree we should write tests?

credits: medium

Unit tests: Small & fast. Even with a large number of tests, there won't be much impact on execution time.
Integration tests: Covers how a system integrates with others. ex. How viewmodel works with the data source. Cover the touchpoints. Runs on JVM – reliable.
UI tests: Tests that cover UI interactions. In android, this means launching an emulator and running tests in it. Slow! dead slow!! So, write tests to assert fixed UI states. Wrapup at the end of the article should give a rough idea of execution time.

Here we cover how to write the integration and UI tests using hilt. Before the actual implementation, take a minute to read on test doubles (literally a very short article!). We'll be using Fakes in our tests. Keep in mind while coding:

Hilt resolves a dependency by its type. So, our code should refer to the *Fake*able dependency as interface.
Provide your dependency in module. So that the whole module can be faked along with dependencies. More on this is covered in faking modules section

...

Dependency overview

To recap from previous article, we have a fragment that requires a Profile (POJO) object which is provided through a ViewModel. DataRepository acts as a source of truth here and returns a profile. ProfileViewModel is unaware of the implementation of DataRepository and Hilt resolves it at compile time.

Adding to the existing implementation, we'll bring in our Fake data source FakeDataRepoImpl for tests. So, the rest of the post is about instructing Hilt to use FakeDataRepoImpl instead of DataRepositoryImpl.

Test runner setup

Add test dependencies to app level gradle file. This brings a HiltTestApplication and annotation processor to the project now. As we've seen in the scope section, HiltTestApplication will hold singleton component.

// File: app/build.gradle

dependencies {
    // Hilt - testing
    androidTestImplementation 'com.google.dagger:hilt-android-testing:2.38.1'
    kaptAndroidTest 'com.google.dagger:hilt-android-compiler:2.38.1'
}

Although HiltTestApplication is present in our app, it is not used in tests yet. This hookup is done by defining a CustomTestRunner. It points to the test application when instantiating the application class for instrument tests.

// File: app/src/androidTest/java/com/ex2/hiltespresso/CustomTestRunner.kt

import androidx.test.runner.AndroidJUnitRunner
import dagger.hilt.android.testing.HiltTestApplication

class CustomTestRunner : AndroidJUnitRunner() {

    override fun newApplication(
        cl: ClassLoader?,
        className: String?,
        context: Context?
    ): Application {
        return super.newApplication(cl, HiltTestApplication::class.java.name, context)
    }
}

And the final step is to declare the test runner in app/gradle file.

// File: app/build.gradle

android {

    defaultConfig {
    //  testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        testInstrumentationRunner "com.ex2.hiltespresso.CustomTestRunner"
    }

Shared test fakes

In android, there are Unit and Instrumentation tests. Although both identify as tests, they cannot share resources between them. Here, few places where tests will lookup for classes.

main source set - here we place the production code. Fakes have no place here
testShared source set - This is the recommended way to share resources. Create the below directory structure and place the FakeDataRepoImpl there.

// File: app/src/testShared/java/com/ex2/hiltespresso/data/FakeDataRepoImpl.kt

class FakeDataRepoImpl @Inject constructor() : DataRepository {

    override fun getProfile() = Profile(name = "Fake Name", age = 47)
}

The next step is to add this to test and androidTest source sets. In app level gradle file, include testShared source set to test sources.

// File: app/build.gradle

android {
        sourceSets {
        test {
            java.srcDirs += "$projectDir/src/testShared"
        }
        androidTest {
            java.srcDirs += "$projectDir/src/testShared"
        }
    }
}

Writing integration test

In the integration test, we'll verify data source and viewmodel coupling is proper. As seen in the testing strategy section, tests run faster if the emulator is not involved. Here, ViewModel can be tested without UI. All it needs is the DataRepository. In the last section, we placed the FakeDataRepoImpl in the shared source set. Let's manually inject it and assert the data.

// File: app/src/test/java/com/ex2/hiltespresso/ui/profile/ProfileViewModelTest.kt

@RunWith(JUnit4::class)
class ProfileViewModelTest {

    lateinit var SUT: ProfileViewModel

    @Before
    fun init() {
        SUT = ProfileViewModel(FakeDataRepoImpl())
    }

    @Test
    fun `Profile fetched from repository`() {
        assertThat("Name consumed from data source", SUT.getProfile().name, `is`("Fake Name"))
    }
}

💡 Why ProfileViewModel is instantiated manually instead of using Hilt?

This is the piece of HiltViewModelFactory which instantiates ProfileViewModel. The SavedStateRegistryOwner, defaultArgs are coming from Activity/Fragment that is marked with @AndroidEntryPoint. So, instantiating the viewmodel with hilt also brings in the complexity of launching the activity and testing the viewmodel from there. This will result in a slower test whereas viewmodel test can run on JVM like we did above.

public HiltViewModelFactory(
      @NonNull SavedStateRegistryOwner owner,
      @Nullable Bundle defaultArgs,
      @NonNull Set<String> hiltViewModelKeys,
      @NonNull ViewModelProvider.Factory delegateFactory,
      @NonNull ViewModelComponentBuilder viewModelComponentBuilder)

Instrumentation or UI tests

Instrumentation/UI tests run on emulator. For this project we'll assert whether the name in UI matches the one in (fake) data source.

In a real-world application, the data source is dynamic and mostly involves a web service. This means UI tests tend to get flaky. So, the ideal approach is to bring down the UI to have finite-states and map it to the ViewModel and fake it.

Example UI states :

UI when the network response has failed

UI when there are N items in the list vs the empty state.

Kotlin sealed classes are a good fit to design an FSM. The aforementioned use-cases are not covered here!! (and won't fall into a straight line to write an article). So, here is the blueprint on how do we inject our fake for ViewModel.

…

Faking modules

For instrument tests (androidTest), hilt is responsible for instantiating the ViewModel. So, we need someone who speaks Hilt's language. Create a fake module that will provide our FakeDataRepoImpl to the viewmodel.

// File: app/src/androidTest/java/com/ex2/hiltespresso/di/FakeProfileModule.kt

import dagger.hilt.android.components.ViewModelComponent
import dagger.hilt.testing.TestInstallIn

// Hey Hilt!! Forget about the ProfileModule - use me instead
@TestInstallIn(
    components = [ViewModelComponent::class],
    replaces = [ProfileModule::class]
)
@Module
class FakeProfileModule {

    @Provides
    fun getProfileSource(): DataRepository = FakeDataRepoImpl()

}

Notice the TestInstallIn annotation. Defining the replaces array will make the original ProfileModule replaced with FakeProfileModule. While building the component, hilt will replace the original module (and thus dependencies) and instantiate the ViewModel with the fake repo. Our UI will use the viewmodel and tests will assert the same.

…

The HiltAndroidTest

The final piece is to write a test that uses the faked component. All it needs is a couple of test rules and annotation from Hilt. Rest is generated!!

// File: app/src/androidTest/java/com/ex2/hiltespresso/MainActivityHiltTest.kt

@RunWith(AndroidJUnit4::class)
@HiltAndroidTest
class MainActivityHiltTest {

    @get:Rule(order = 0)
    var hiltRule = HiltAndroidRule(this)

    @get:Rule(order = 1)
    var activityRule: ActivityScenarioRule<MainActivity> =
        ActivityScenarioRule(MainActivity::class.java)

    @Test
    fun test_name_matches_data_source() {
        // Inject the dependencies to the test (if there is any @Inject field in the test)
        hiltRule.inject()
        Espresso.onView(ViewMatchers.withId(R.id.name_label))
            .check(
                ViewAssertions.matches(
                    Matchers.allOf(
                        ViewMatchers.isDisplayed(),
                        ViewMatchers.withText("Fake Name")
                    )
                )
            ))
    }
}

The rules are executed first before running the test. It ensures the activity has dependencies resolved before test execution.

HiltAndroidRule (order = 0) : First create components (singleton, activity, fragment, viewmodel) and obey the replace contract mentioned in previous step.
ActivityScenarioRule (order = 1): Launch the activity mentioned before each test

The espresso & hamcrest matchers are descriptive. In the view tree, it lookup for a view and assert whether it's visible and carries the text defined in fake data repo.

Wrapup

This article gave a blueprint for organizing the code in order to achieve component links in isolation. Apart from the hilt-related setup, this practice could benefit even the code that was built with manual injection. Just follow these key takeaways.

Always define the data source as interface. So that it can be faked/mocked for tests.
Make fragment / activity's UI controlled by the viewmodel. You don't have to fake the link here.
A viewmodel should emit finite states to the UI at any point of time. This state may be dictated by the data source or a reaction to user input in UI (eg. enabling a button based on content length)

…

In case you wonder about the execution time, here it is: 5ms vs 3.5 sec

…

Resources

How HiltViewModel is generated without a factory?

Mahendran — Wed, 06 Oct 2021 13:39:51 +0000

This is the second installment in the three-part series. To understand better, you can read part1 or open the github project to explore the code.

Part1: Android — Basic Hilt setup with viewmodel + fragment

Part2: How HiltViewModel is generated without a factory?

Part3: Fakes and espresso

...

Introduction

In a typical Android project creating a ViewModel with dependencies require us to provide an explicit viewmodel-factory. However, in the previous post Hilt was able to create one without all the boilerplate. This post covers the smoke and mirrors behind viewmodel instantiation with hilt.

As I write and revise the article, noticed it has a lot of moving parts. So, I tried to segregate it into four portions.

Dagger: Hilt is based on dagger, so this portion covers few dagger concepts
HiltViewModel: Hilt marks viewmodels with this annotation. What happens when you do this marking.
AndroidEntryPoint: A Fragment/Activity is called as AndroidEntryPoint in Hilt. This again bootstraps few things for us.
HiltViewModelFactory: It's better to read this at the very end.

...

🗡️ Stabbing with Dagger
- Providers & Factories
- Dagger binds
- Dagger map-multibindings
🎞️ Recap
🪡 HiltViewModel — annotation
🎯 AndroidEntryPoint
- Hilt_ProfileFragment — the generated fragment
- InternalFactoryFactory
🧩 Final piece - The HiltViewModelFactory
🍬 Wrap up

...

🗡️ Stabbing with Dagger

In order to understand the mechanics of Hilt, let's recall few Dagger components.

Providers & Factories

Our focus is on how the ViewModel is instantiated. So, this portion covers enough dagger to demonstrate a constructor injection. Let's see an example of how Car gets its Engine. Engine has no dependencies and car will need one Engine to work. The same can be written in code like this.

import javax.inject.Inject

// Hey Dagger! Create a factory for me, so that you can create my instances.
class Engine @Inject constructor() {
    fun start() { println("Engine.start") }
    fun stop() { println("Engine.stop") }
}

// Hey Dagger! Create a factory for me, so that you can create my instances.
// Also provide me with my dependencies.
class Car @Inject constructor(private val engine: Engine) {
    fun start() = engine.start()
    fun stop() = engine.stop()
}

...

For this piece to work, dagger generates Factorys. There are three things to remember here.

Factory is an interface defined in Dagger with only one getter to the target object.
A Factory can include Providers which can provide the dependencies for it. For example, Car factory will need a Provider for Engine.
Factory is extended from Provider. Which means Engine factory can act as a provider for car factory.

// source: Dagger
public interface Provider<T> {
    /**
     * Provides a fully-constructed and injected instance of {@code T}.
     */
    T get();
}

public interface Factory<T> extends Provider<T> {}

...

This is the overview of dagger-factory for Car & Engine usecase.

...

Engine_Factory is simple. It extends dagger Factory and returns new instance when get() is called.

import dagger.internal.DaggerGenerated;
import dagger.internal.Factory;

@DaggerGenerated
public final class Engine_Factory implements Factory<Engine> {
  @Override
  public Engine get() {
    return newInstance();
  }

  public static Engine newInstance() {
    return new Engine();
  }
  // redacted
}

Car_Factory needs an engine to create car. For this purpose, it needs a Provider which can get an engine for it. The car provider is defined as a constructor parameter and Dagger uses components & scopes to resolve it.

@DaggerGenerated
@SuppressWarnings({
    "unchecked",
    "rawtypes"
})
public final class Car_Factory implements Factory<Car> {
  private final Provider<Engine> engineProvider;

  // Engine provider will be set through dagger module/components
  public Car_Factory(Provider<Engine> engineProvider) {
    this.engineProvider = engineProvider;
  }

  @Override
  public Car get() {
    return newInstance(engineProvider.get());
  }

  public static Car newInstance(Engine engine) {
    return new Car(engine);
  }
}

...

Dagger binds


public class Circle extends Shape {
  // redacted
}

@Module
interface ShapeModule {

  @Binds
  public abstract Shape binds(Circle c);
}

Binds is a contract that tells dagger to return the argument in place of the return type. The above statement is to be read as "when Shape is requested, return Circle". This could work well for one-to-one mapping where the abstraction is only there to loosely couple the implementation.

Dagger map-multibindings

It is a common practice in programming where we keep a lookup registry and query an object by a unique key. Dagger map is the same, with a decoupled approach.

Map instance is scoped to component
Map elements are managed at compile time. That means multiple modules can contribute to the map without knowing about each other. In fact, they don't get the map instance to look up in the first place.
Map is an injectable dependency for the consumer. This consumer should have the knowledge about which key to lookup.

In the above example, whenever we need a Shape, Circle will be returned. What if I want a square?
Dagger multibinding can help with that.

@Binds
@IntoMap
@StringKey("circle")
public abstract Shape binds(Circle c);

@Binds
@IntoMap
@StringKey("square")
public abstract Shape binds(Square c);

@Component
public interface MyComponent {

   Map<String, Shape> getShapesRegistry();
}


// target class

MyComponent myComponent;

myComponent.getShapesRegistry().get("square") // Square
myComponent.getShapesRegistry().get("circle")

The above code places both Square and Circle in the component's map Map<String, Shape>. Target class shall request this map from component and access the instance using a key string.

🎞️ Recap

Dagger section should give some idea of what happens with constructor injection & multi-bindings. This will help us go through the hilt workflow quickly. Recalling few things from the previous article:

Sample project github
Viewmodel-fragment dependency graph

We'll cover the workings of HiltViewModel and AndriodEntryPoint in the rest of the article.

🪡 HiltViewModel — annotation

When we mark a ViewModel as HiltViewModel, Hilt creates a module and dagger factory for it. This factory is something we've seen briefly in dagger section. Our viewmodel requests for a data-repository and respective provider is placed in the factory.

@HiltViewModel
class ProfileViewModel @Inject constructor(
    private val repo: DataRepository
) : ViewModel()

generates

import dagger.internal.Factory;

@DaggerGenerated
public final class ProfileViewModel_Factory implements Factory<ProfileViewModel> {
  private final Provider<DataRepository> repoProvider;

  //redacted

  @Override
  public ProfileViewModel get() {
    return newInstance(repoProvider.get());
  }

  public static ProfileViewModel newInstance(DataRepository repo) {
    return new ProfileViewModel(repo);
  }
}

The factory resolves dependencies of the viewmodel. And it can create ProfileViewModel if someone requests it. The next step is to expose this factory to the outer layer. For this hilt generates a dagger module for each HiltViewModel. These modules will register themselves to Hilt's ViewModelComponent. Here, ViewModelComponent keeps a multibinding map of Map<String, ViewModel>. And the key is the fully qualified class name.

public final class ProfileViewModel_HiltModules {

  @Module
  @InstallIn(ViewModelComponent.class)
  public abstract static class BindsModule {

    @Binds
    @IntoMap
    @StringKey("com.ex2.hiltespresso.ui.profile.ProfileViewModel")
    @HiltViewModelMap
    public abstract ViewModel binds(ProfileViewModel vm);
  }
}

So, our viewmodel code is read as bind ProfileViewModel for ViewModel and register to the component's map (IntoMap) against the StringKey which is com.ex2.hiltespresso.ui.profile.ProfileViewModel.

...

Till now, we covered the viewmodel instantiation and how ViewModelComponent keeps track of ViewModels. This is the producer side of the equation and the consumption is covered in the rest of the article.

🎯 AndroidEntryPoint

Note: In this article run into Dagger Factory & ViewModel Factory. So, to avoid ambiguity - lets call ViewModel Factory as VMFactory.

In a traditional viewmodel usecase, fragment/activity (UI) takes responsibility to provide VMFactory if there is any dependency. This article covers how VMFactory instantiates viewmodel with dependencies.

...

Hilt augments the existing viewmodel framework by generating VMFactory for us. For this, it uses marker annotations AndroidEntryPoint and HiltViewModel.

AndroidEntryPoint is a Hilt annotation to mark an Activity or Fragment as a receiver of the dependency. So, things discussed here with fragment will work for activity as well.

...

Our ProfileFragment is extended from Fragment right? Only it is not!! hilt-android-gradle-plugin gradle plugin will generate a proxy fragment and set it as base for ProfileFragment. Here, what we see vs the one that goes into the APK.

@AndroidEntryPoint
class ProfileFragment : Fragment()

vs

class ProfileFragment : Hilt_ProfileFragment()

...

Hilt uses the generated fragment to hook up its HiltViewModelFactory. This VMFactory has access to the viewmodel component and the rest of the dependency graph. Following block diagram shows the components and relations. Let's go through each of them.

Hilt_ProfileFragment — the generated fragment

The generated fragment injects the dependencies through the member injector and overrides the default VMFactory with HiltViewModelFactory. ViewModelProvider will recognize the HiltViewModelFactory and use it to create ProfileViewModel. There are in-line comments in respective places for understanding the generated fragment.

public abstract class Hilt_ProfileFragment extends Fragment implements GeneratedComponentManagerHolder {

  public void onAttach(Context context) {
    inject();
  }

  public void onAttach(Activity activity) {
    // This will inject surface level dependencies (ex. sharedpreference 
    // or analytics client needed for reporting click etc.) 
    // used in view layer.
    inject();
  }

  protected void inject() {
    if (!injected) {
      injected = true;
      ((ProfileFragment_GeneratedInjector) this.generatedComponent()).injectProfileFragment(UnsafeCasts.<ProfileFragment>unsafeCast(this));
    }
  }

  // This method will be invoked by ViewModelProvider in case there is 
  // no explicit VMFactory is provided. Hilt uses this method to enroll its
  // HiltViewModelFactory with ViewModelProvider.
  @Override
  public ViewModelProvider.Factory getDefaultViewModelProviderFactory() {
    // DefaultViewModelFactories is a utility class that delegates calls to 
    // hilt generated viewmodel registry which created in previous section
    return DefaultViewModelFactories.getFragmentFactory(this, super.getDefaultViewModelProviderFactory());
  }
}

  // File: DefaultViewModelFactories.java

  /**
   * Retrieves the default view model factory for the activity.
   * <p>Do not use except in Hilt generated code!
   */
  public static ViewModelProvider.Factory getFragmentFactory(
      Fragment fragment, ViewModelProvider.Factory delegateFactory) {
    return EntryPoints.get(fragment, FragmentEntryPoint.class)
        .getHiltInternalFactoryFactory()
        .fromFragment(fragment, delegateFactory);
  }

InternalFactoryFactory

InternalFactoryFactory can is responsible for forwarding the ViewModelComponent builder and list of known hilt viewmodel names to the HiltViewModelFactory. Here, the ViewmodelComponent is a dagger component defined by hilt. We have already provided it with dependencies for ProfileViewModel.

public static final class InternalFactoryFactory {

    private final Application application;
    private final Set<String> keySet;
    private final ViewModelComponentBuilder viewModelComponentBuilder;

    private ViewModelProvider.Factory getHiltViewModelFactory(
        SavedStateRegistryOwner owner,
        @Nullable Bundle defaultArgs,
        @Nullable ViewModelProvider.Factory extensionDelegate) {
      ViewModelProvider.Factory delegate = extensionDelegate == null
          ? new SavedStateViewModelFactory(application, owner, defaultArgs)
          : extensionDelegate;
      return new HiltViewModelFactory(
          owner, defaultArgs, keySet, delegate, viewModelComponentBuilder);
    }
}

🧩 Final piece - The HiltViewModelFactory

HiltViewModelFactory is a subclass of ViewModelFactory. Responsibility of this class is to instantiate the given ViewModel. This block diagram explains the control flow

InternalFactoryFactory forwards the set of viewmodel names and a viewmodel component builder to HiltViewModelFactory through constructor. Now the HiltViewModelFactory has been created and await the consumer to call create.
Fragment/activity calls create to get instance of the viewmodel. Now, HiltViewModelFactory builds a viewmodel component from the existing builder and asks for a map of provider instances.
From there, it picks the matching provider and uses it to instantiate the viewmodel.
Delivers it to the ViewModelProvider

Code looks like this: HiltViewModelFactory holds a list of known hilt viewmodel names and hiltViewModelFactory and an optional delegateFactory. List of ViewModel names determine whether to use delegateFactory or hiltViewModelFactory.

public final class HiltViewModelFactory implements ViewModelProvider.Factory {
  private final Set<String> hiltViewModelKeys;
  private final ViewModelProvider.Factory delegateFactory;
  private final AbstractSavedStateViewModelFactory hiltViewModelFactory;

  // redacted

  @Override
  public <T extends ViewModel> T create(@NonNull Class<T> modelClass) {
    if (hiltViewModelKeys.contains(modelClass.getName())) {
      return hiltViewModelFactory.create(modelClass);
    } else {
      return delegateFactory.create(modelClass);
    }
  }
}

🍬 Wrap up

Hilt creates a Dagger Factory for the ViewModel. This contains the providers for the particular viewmodel's dependencies and a key that uniquely identifies it (fully qualified name). This is a registry step that holds info on a ViewModel's name and how to create it.
When a fragment is marked as AndroidEntryPoint, it will be set with a generated base class that takes care of injecting fields to the fragment.
However, ViewModel is a special case. So, hilt will try to provide a ViewModelFactory.
Above step is done with InternalFactoryFactory. It creates HiltViewModelFactory and passes on the component to it.
HiltViewModelFactory lookup in the registry (created in the first step) and instantiates the requested viewmodel.

📖 Resources

...

👨‍💻️

Feedback is welcome. Especially on the article template and keeping the context throughout the session.

How viewmodel survives configuration change?

Mahendran — Fri, 01 Oct 2021 18:17:34 +0000

Android ViewModel is one of the most helpful APIs exist in the ecosystem. It's a major release which changed how the Android apps built. Together with LiveData it decoupled the UI from business logic without much boilerplate. This post is about how the viewmodel is instatiated/cached/provided to the caller.

📝 API doc
- Factory
- ViewModelStore & ViewModelStoreOwner
- ViewModelProvider
🏗️Instantiation
- ViewModel without any constructor arguments
- ViewModel with dependencies
🤔 Few questions
- How ViewModel survives orientation change?
- How ViewModel is scoped to single Fragment?
- How unique is the key in ViewModelStore?
📒 Resources

📝 API doc

Before we get into specific usecases, let's see few key players in this flow.

...

Factory

Factory is an interface responsible for instantiating a viewmodel. It may or may not inject dependencies to the viewmodel.

...

ViewModelStore & ViewModelStoreOwner

ViewModelStore keeps a hashmap of String & ViewModel. Once instantiated, viewmodel is stored in it. ViewModelStoreOwner is an interface implemented by Activity/Fragment. Under the hood a ViewModelStore is used by fragment/activity to store the reference.

...

ViewModelProvider

ViewModelProvider is an umbrella object that coordinates Factory and ViewModelStore. Responsibility of this class is identifying the factory and caching viewmodel reference to ViewModelStore. There could be number of ViewModelProviders created in a fragment/activity. But when a viewmodel is requested, all of them will return the same instance. This is due to ViewModelStore's single source of truth nature.

🏗️ Instantiation

Note: Jetpack recommends viewModels / activityViewModels delegates to instantiate a ViewModel. However, for clarity this article will explain the usecases through ViewModelProvider instances.

ViewModel without any constructor arguments

This is a rare case where viewmodel doesn't need any dependency. To instantiate such basic viewmodel, create a ViewModelProvider with current activity/fragment reference and invoke get method with ViewModel's class.

val viewModel = ViewModelProvider(this) // Create reference wrt current fragment
                 .get(ProfileViewModel::class.java) // query for a ProfileViewModel

...

ViewModel with dependencies

Most common pattern with viewmodel is to pass constructor arguments (of data source) and do CRUD and emit events through LiveData. This can be done by creating a custom Factory and use it in place of default one. Internally, ViewModelProvider will use this factory to create the instance and store it to the viewmodelstore. Let's see how it's done.

Create a Factory which forwards constructor arguments to the ViewModel. This implements ViewModelProvider.Factory.

   class ProfileViewModel(private val repo: DataRepository) : ViewModel() { 

        class Factory(private val repo: DataRepository) : ViewModelProvider.Factory {
            override fun <T : ViewModel?> create(modelClass: Class<T>): T {
                return ProfileViewModel(repo) as T
            }
        }
   }

Inside the fragment/activity, create a factory instance. And pass it to ViewModelProvider.

val dataRepo = DataRepoImpl() // Data source
val factory = ProfileViewModel.Factory(dataRepo) // Factory
ViewModelProvider(this, factory).get(ProfileViewModel::class.java) // ViewModel

...

Interesting thing about the ViewModelProvider is after instantiating the ViewModel in the scope (activity/fragment) next time invoking it will return the same viewmodel. That is

ViewModelProvider(this).get(ProfileViewModel::class.java)

will return the ViewModel created in second step. The order of calls matterns here.

🤔 Few questions

How ViewModel survives orientation change?

This is not specific to ViewModel, but any retained object across activity recreation due to configuration change (orientation/locale). Android's activity (yes!! The original activity) has onRetainNonConfigurationInstance method which can pass around objects between old and recreated activity instances. getLastNonConfigurationInstance can capture the same in newly instantiated activity.

Catch is these methods are deprecated in favor of ViewModel which can achieve the same in a very graceful manner. To answer the question, ViewModelStore is passed between the activity instances.

How ViewModel is scoped to single Fragment?

When creating a Fragment with its scope, a nested ViewModelStore is created from its parent scope. This is applicable for Fragment inside an activity or even fragment. Few snippets to clarify things.

// FragmentManager.java
if (host instanceof ViewModelStoreOwner) {
    ViewModelStore viewModelStore = ((ViewModelStoreOwner) host).getViewModelStore();
    mNonConfig = FragmentManagerViewModel.getInstance(viewModelStore);
}

// FragmentManagerViewModel.java
final class FragmentManagerViewModel extends ViewModel {

  private final HashMap<String, ViewModelStore> mViewModelStores = new HashMap<>();

  @NonNull
    ViewModelStore getViewModelStore(@NonNull Fragment f) {
        ViewModelStore viewModelStore = mViewModelStores.get(f.mWho);
        if (viewModelStore == null) {
            viewModelStore = new ViewModelStore();
            mViewModelStores.put(f.mWho, viewModelStore);
        }
        return viewModelStore;
  }


 // Fragment.java

 // Internal unique name for this fragment;
 @NonNull
 String mWho = UUID.randomUUID().toString();
}

This is how it works,

Each fragment manager contains a FragmentManagerViewModel
FragmentManagerViewModel contains a map of string vs viewmodelstore
string in above step is UUID generated for each fragment and viewmodelstore is the one we've seen in API doc section.

How unique is the key in ViewModelStore?

From ViewModelProvider who puts viewmodels into the ViewModelStore. Key is just the CanonicalName of the ViewModel. So, it's purely based in class name. Since every fragment get its own store, it will not collide. Same makes it possible that fragments of the same activity to share viewmodels.

    private static final String DEFAULT_KEY =
            "androidx.lifecycle.ViewModelProvider.DefaultKey";

    @NonNull
    @MainThread
    public <T extends ViewModel> T get(@NonNull Class<T> modelClass) {
        String canonicalName = modelClass.getCanonicalName();
        if (canonicalName == null) {
            throw new IllegalArgumentException("Local and anonymous classes can not be ViewModels");
        }
        return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
    }

📒 Resources

Android — Basic Hilt setup with viewmodel + fragment

Mahendran — Fri, 01 Oct 2021 06:31:07 +0000

Hilt is a modern android DI framework for dependency injection. It is merely a wrapper around Dagger2. Forget dagger-android, hilt brings a lot to our plate. This article covers steps to add hilt to the project and use along with viewmodel-fragment.

Sample project used for this article is available in github.

...

💉 What are we injecting?
🔘 Little about scope
💻 Code it
- Build setup
- HiltAndroidApp setup (application context)
- Creating data source and modules
- Viewmodel setup
- Fragment setup
📖 Resources

💉 What are we injecting?

For this example, we're going to provide Profile (a POJO) to a fragment through ViewModel. For simplicity let's not use LiveData in here. This is how the dependency graph looks like.

🔘 Little about scope

Dependencies could be of different scope (how long it can be in memory/when it can be garbage collected). When we speak about the scope of a dependency, we can easily define it in terms of android components. Below is the oversimplified version of commonly used scopes.

A user session details should be available throughout the app (Singleton)
I have a tabbed screen and want to share some in-memory fields between fragments (Activity)
My data is bound to current screen/fragment. When it is destroyed purge the dependency as well (Fragment)
Associate my dependency with ViewModel. Depends on the viewmodel's scope (activity / fragment) let my dependency live (ViewModelScope)

For our use-case, we'll inject DataRepository to the viewmodel using hilt. And there are few improvements on creating viewmodel for the fragment. We'll see it end to end in the following section.

💻 Code it

Build setup

Like any framework we write less with hilt because most of the code is generated for us. For that purpose, we'll use hilt gradle plugin. And, hilt is expected to be used in multiple modules, so extract out the version to project level gradle file and use it in submodules.

// File: build.gradle

buildscript {
    ext {
        hilt_version = '2.38.1'
    }
    repositories {
        // redacted
    }
    dependencies {
        // redacted
        classpath "com.google.dagger:hilt-android-gradle-plugin:${hilt_version}"
    }
}

// File: app/build.gradle

plugins {
    id 'com.android.application'
    id 'kotlin-android'
    id 'dagger.hilt.android.plugin'
}

dependencies {
    // Hilt
    implementation "com.google.dagger:hilt-android:${hilt_version}"
    kapt "com.google.dagger:hilt-compiler:${hilt_version}"

    // Fragment / viewmodel
    def lifecycle = "2.3.1"
    implementation "androidx.lifecycle:lifecycle-viewmodel-ktx:${lifecycle}"
    implementation "androidx.lifecycle:lifecycle-livedata-ktx:${lifecycle}"
    implementation "androidx.fragment:fragment-ktx:1.3.6"
}

In the project level gradle we tell the build system to use hilt. And the app level gradle applies the plugin so that it can skim through our codebase and generate dependencies for us.

...

HiltAndroidApp setup (application context)

A singleton is expected to be alive through the app session. Here, the dependency lives with application. In order to tell hilt about the application scope, create and annotate application class with HiltAndroidApp.

import android.app.Application
import dagger.hilt.android.HiltAndroidApp

@HiltAndroidApp
class MyApp : Application()

Above step is needed because the application context is provided through generated application class. Make the project and inspect the contents of Hilt_MyApp class.

// generated source
DaggerMyApp_HiltComponents_SingletonC.builder()
          .applicationContextModule(new ApplicationContextModule(Hilt_MyApp.this))
          .build();

Above steps enables smoother injection of application context to RoomDB / SharedPreference - what not.

...

Creating data source and modules

Code speaks thousand words. Below code block shows resource and the data source.

// A resource
data class Profile(
    val name: String,
    val age: Int
)

// A simple interface which returns the resource. 
// This will help us mock the data source when executing tests.
interface DataRepository {

    fun getProfile(): Profile
}

// Simple implementation of data source
class DataRepoImpl : DataRepository {

    override fun getProfile(): Profile =
        Profile(name = "Bruce Wayne", age = 42)
}

From here, we'll work towards creating dependencies that can be recognized by Hilt.

First, annotate DataRepoImpl constructor with @Inject. This puts our class under Dagger/Hilt's radar.

class DataRepoImpl @Inject constructor() : DataRepository {

Second, create a module that can provide dependency to view model.

@InstallIn(ViewModelComponent::class) // Scope our dependencies
@Module
abstract class ProfileModule {

    // To be read as — When someone asks for DataRepository, create a DataRepoImpl and return it.
    @Binds
    abstract fun getProfileSource(repo: DataRepoImpl): DataRepository
}

...

Viewmodel setup

ViewModels can tell ask hilt to provide dependencies. A simple way to ask dependencies is to mark viewmodel with HiltViewModel annotation.

@HiltViewModel
class ProfileViewModel @Inject constructor(
    private val repo: DataRepository
) : ViewModel() {

    fun getProfile(): Profile = repo.getProfile()
}

Here we're doing constructor injection on viewmodel. Doing the same without Hilt will require a Factory which pass on the dependencies to the constructor. Reason is the lifecycle of the viewmodel is managed by a lifecycle owner like activity/fragment. Internal mechanics of this injection is covered in last section. On to the fragment...

...

Fragment setup

Fragment or activity is identified as AndroidEntryPoint in hilt. A fragment which is maked with AndroidEntryPoint will inject the dependencies without much boilerplate code. And this is our ProfileFragment which consumes the viewmodel.

@AndroidEntryPoint
class ProfileFragment : Fragment() {

    private val viewModel by viewModels<ProfileViewModel>()

    // redacted

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        // Here we go -- the profile resource is shown to the UI
        view.findViewById<TextView>(R.id.name_label)
            .text = viewModel.getProfile().name
    }
}

That's it!!

Nothing much changed, instead of creating a factory and use it in viewModels delegate we annotated with AndroidEntryPoint. And the resource is available to us and components are less coupled now.

📖 Resources

Designing a bottom navigation bar with Jetpack compose

Mahendran — Fri, 30 Jul 2021 19:32:12 +0000

Intro

This article covers the design aspect of the bottom navigation bar using Jetpack compose. We're looking at a simple composable with few customizable params for the icons. Take this as an approach doc for designing UI rather than an API guide. The result will look like this.

📐 Analysis
- Interactions
🏗️ Building the UI
- Animated icons:
- Row design
📖 Endnote:

📐 Analysis

Let's dissect this view and see how to build this.

This is a row with equal space around each icon
At a time only one icon can be selected
All the icons are of the same size except the selected one, which is at 1.5x
Row accounts for the larger icon as well and all the icons are vertically center aligned

Interactions

When an icon is selected, it scales up to 1.5x and changes its color to blue. And previously selected icon resets to 1x and goes back to grey color. This transition is not sudden and happens over a particular time.

🏗️ Building the UI

UI is straightforward here. Icons and a Row that holds them. So, the first step is to prepare a few ingredients to build the UI. Add material extended icons in Gradle dependency and pick some for the navbar.

private val navBarItems = arrayOf(
    Icons.Outlined.Home,
    Icons.Outlined.Send,
    Icons.Outlined.FavoriteBorder,
    Icons.Outlined.PersonOutline,
)

Choose two colors for selected and unselected state:

private val COLOR_NORMAL = Color(0xffEDEFF4)
private val COLOR_SELECTED = Color(0xff496DE2)

Define a base icon size. This will be scaled up to 1.5x when selected. Also, it's a good practice to make most of the properties configurable with default values. After all, we're dealing with functions here.

private val ICON_SIZE = 24.dp

...

Let's start with icons and build a row of them.

Animated icons:

From the icons aspect, it hoists its click to the parent and expects its parent to tell which state it should move to. The icon has one responsibility - to animate its color and scale when the properties are set. It doesn't know about its state. All it knows is to smoothly change the values.

Quick note about compose animation - it always tries to transition from the current value to the target value. Asking for the start value might lead to a jump in animations, which is avoided here. IMO compose team did it well here.

@Composable
fun AnimatableIcon(
    imageVector: ImageVector,
    modifier: Modifier = Modifier,
    iconSize: Dp = ICON_SIZE,
    scale: Float = 1f,
    color: Color = COLOR_NORMAL,
    onClick: () -> Unit
) {
    // Animation params
    val animatedScale: Float by animateFloatAsState(
        targetValue = scale,
        // Here the animation spec serves no purpose but to demonstrate in slow speed.
        animationSpec = TweenSpec(
            durationMillis = 2000,
            easing = FastOutSlowInEasing
        )
    )
    val animatedColor by animateColorAsState(
        targetValue = color,
        animationSpec = TweenSpec(
            durationMillis = 2000,
            easing = FastOutSlowInEasing
        )
    )

    IconButton(
        onClick = onClick,
        modifier = modifier.size(iconSize)
    ) {
        Icon(
            imageVector = imageVector,
            contentDescription = "dummy",
            tint = animatedColor,
            modifier = modifier.scale(animatedScale)
        )
    }
}

Animated icon composable holds two animatable values and is set to corresponding attributes. To interact with its parent, it exposes an onClick lambda. And animation target values are passed from the parent.

...

Before plug this into Row, try it out with a preview. As our icon is a dumb view, the preview will have unusual responsibilities. It toggles selection and updates the correct scale/color to the icon. On the other hand, a wrapper Composable could be built with a preset of selected/normal attributes and take a boolean to update the same. Again, it's a function.

@Preview(group = "Icon")
@Composable
fun previewIcon() {
    Surface {

        var selected by remember {
            mutableStateOf(false)
        }

        AnimatableIcon(
            imageVector = Icons.Outlined.FavoriteBorder,
            scale = if (selected) 1.5f else 1f,
            color = if (selected) COLOR_SELECTED else COLOR_NORMAL,
        ) {
            selected = !selected
        }
    }
}

Row design

From the requirements, the row is responsible for horizontally placing all the icons and update their scale/color based on selected index. It doesn't know how the icons react to it. In order to observe whether an icon clicked, it listens to the click and updates the selected index.

Apart from the above responsibilities, the row aligns icons as described in the analysis part. To remember which position is selected, it uses a mutable state. This will be updated on icon click and read before setting scale/color for the icons.

@Composable
fun BottomNavBar2(
    modifier: Modifier = Modifier,
    iconSize: Dp = ICON_SIZE,
    selectedIconScale: Float = 1.5f
) {
    var selectedIndex by remember {
        mutableStateOf(0)
    }

    Row(
        verticalAlignment = Alignment.CenterVertically,
        horizontalArrangement = Arrangement.SpaceEvenly,
        modifier = modifier
            .fillMaxWidth()
            .padding(vertical = 8.dp)
            .height(iconSize.times(selectedIconScale))
    ) {
        for ((index, icon) in navBarItems.withIndex()) {
            AnimatableIcon(
                imageVector = icon,
                scale = if (selectedIndex == index) 1.5f else 1.0f,
                color = if (selectedIndex == index) COLOR_SELECTED else COLOR_NORMAL,
                iconSize = ICON_SIZE,
            ) {
                selectedIndex = index
            }
        }
    }
}

Finally, put the bottom nav bar inside a preview and interact with it.

@Preview(group = "Main", name = "Bottom bar - animated")
@Composable
fun previewBottomNavBar2() {
    Surface {
        BottomNavBar2()
    }
}

📖 Endnote:

This navigation bar is a very basic implementation. It doesn't even have a callback setup for selection change. And icons are hardcoded. It is a good idea to use the material BottomNavigation as it is well tested and can interact with Snackbar and also has a FAB cradle. Use this as a quickguide on how to keep a view dumb and do state hoisting.

I created few shapes in Jetpack compose / Gist included

Mahendran — Fri, 09 Jul 2021 18:32:34 +0000

Sharing few of my jetpack-compose shapes here. Did path tracing and formed outline path.

Heart

🚀 - Gist

Tag

🚀 - Gist

Polygons

🚀 - Gist

Car

🚀 - Gist

👷 Tool set

Figma for path tracing : steps here
SVG path editor
Read about polar coordinates here

Jetpack compose - shape your views

Mahendran — Wed, 23 Jun 2021 20:42:15 +0000

Jetpack compose has an elegant way to cut out a Compose view into the desired shape. I'm covering few shapes that are available in the core compose lib and where do they differ.

All the shapes discussed here operate on views corners. So, before going through each, let's go through a basic building block called CornerSize.

...

📏 CornerSize
📐 Shapes
- 1. AbsoluteCutCornerShape
- 2. CutCornerShape
- 3. AbsoluteRoundedCornerShape
- 4. RoundedCornerShape
- 5. CircleShape
↔️ RTL - comparison
✂️ Cutting corners
- 1. Tags
- 2. TearDrop
- 3. Message bubbles
- 4. Stadium button
- 5. A half baked - House of El
- 6. Kryptonite
🛸 What’s next?

...

📏 CornerSize

CornerSize is an interface that provides an abstraction to define size in different units. Concrete implementation of this interface converts the given unit to pixels. This pixel value can be used in other parts like Shape for computation.

interface CornerSize {
    fun toPx(shapeSize: Size, density: Density): Float
}

DpCornerSize - allows defining corner cut in device-independent pixels. (DIP or DP)
PxCornerSize - Pixel to pixel conversion is a wrapper implementation to return float which is a pixel.
PercentCornerSize - Given a view size and percent, it takes min of height & width and computes the pixel size accordingly.
ZeroCornerSize - Object that returns zero pixels.

...

All the above classes are private and exposed through few convenient functions as seen below. So, be wary of using different units with CornerSize functions.

fun CornerSize(size: Dp): CornerSize = DpCornerSize(size)

fun CornerSize(size: Float): CornerSize = PxCornerSize(size)

fun CornerSize(/*@IntRange(from = 0, to = 100)*/ percent: Int): CornerSize =  PercentCornerSize(percent.toFloat())

📐 Shapes

All the shapes discussed here has common characteristics listed below:

Can cut specific corners or all at once
Corner unit size defined in CornerSize. That means it can take the corner size in the form of pixels, dps or percent.

1. AbsoluteCutCornerShape

With AbsoluteCutCornerShape, the resulting shape will have rough corners. It has four member fields (one for each corner). And has few convenience methods to ease out symmetric cuts.

class AbsoluteCutCornerShape(
    topLeft: CornerSize,
    topRight: CornerSize,
    bottomRight: CornerSize,
    bottomLeft: CornerSize
): CornerBasedShape

As you have noticed, the corners are defined in terms of left and right. We've moved away from using left-right and started using start-end long back to support right-to-left(RTL) locales. Why give it up here?

Absolute direction is still preferred in few places like cutting top-left of an image. That means, when you wrap a content that is RTL agnostic, use AbsoluteCutCornerShape to cut its corner.

Here, listed wrapper functions for Dp unit. Cut out the pixel & percent counterparts for brewity.


fun AbsoluteCutCornerShape(size: Dp) = AbsoluteCutCornerShape(CornerSize(size))

fun AbsoluteCutCornerShape(
    topLeft: Dp = 0.dp,
    topRight: Dp = 0.dp,
    bottomRight: Dp = 0.dp,
    bottomLeft: Dp = 0.dp
) = AbsoluteCutCornerShape(
    topLeft = CornerSize(topLeft),
    topRight = CornerSize(topRight),
    bottomRight = CornerSize(bottomRight),
    bottomLeft = CornerSize(bottomLeft)
)

...

2. CutCornerShape

CutCornerShape is a RTL friendly version of AbsoluteCutCornerShape (not a subclass). This will mirror corner cuts when used in RTL locales. It has the same helper functions defined in the former.

class CutCornerShape(
    topStart: CornerSize,
    topEnd: CornerSize,
    bottomEnd: CornerSize,
    bottomStart: CornerSize
) : CornerBasedShape(
    topStart = topStart,
    topEnd = topEnd,
    bottomEnd = bottomEnd,
    bottomStart = bottomStart
)

...

3. AbsoluteRoundedCornerShape

AbsoluteRoundedCornerShape cuts corner with a given radius. So, the cutout shape will have smoother edges. Also, it can cut only specific edges while leaving the others in square cut shape.

class AbsoluteRoundedCornerShape(
    topLeft: CornerSize,
    topRight: CornerSize,
    bottomRight: CornerSize,
    bottomLeft: CornerSize
) : CornerBasedShape(
    topStart = topLeft,
    topEnd = topRight,
    bottomEnd = bottomRight,
    bottomStart = bottomLeft
)

AbsoluteRoundedCornerShape is RTL agnostic like AbsoluteCutCornerShape. And the helper methods are same as in AbsoluteCutCornerShape.

...

4. RoundedCornerShape

RoundedCornerShape is an RTL-friendly version of AbsoluteRoundedCornerShape. Let's fast-forward to next shape.

class RoundedCornerShape(
    topStart: CornerSize,
    topEnd: CornerSize,
    bottomEnd: CornerSize,
    bottomStart: CornerSize
) : CornerBasedShape(
    topStart = topStart,
    topEnd = topEnd,
    bottomEnd = bottomEnd,
    bottomStart = bottomStart
)

...

5. CircleShape

CircleShape is an object of RoundedCornerShape that cuts circle. When setting the corner at 50%, it will naturally result in a circle. No need to explain the use-case in applications. Yeah... circular image view!!

    val CircleShape = RoundedCornerShape(percentage = 50)

↔️ RTL - comparison

This section summarizes the shapes that we discussed above. When a shape has cut only in right or left, we can see the difference between Absolute cuts and RoundedCornerShape / CutCornerShape.

So, I have placed four labels stick to the right side of the screen and corner is cut on the left side (or start of the RTL friendly shapes). When the shapes aligned to the right side the labels looks fine. However, when the device preference set to RTL (in developer options), the RTL friendly shapes mirrored themselves while the absolute layouts stick their noses to the edge.

...


@Preview(device = Devices.NEXUS_6P, showSystemUi = true)
@Preview(device = Devices.NEXUS_6P, locale = "ar", showSystemUi = true)
@Composable
fun RTLScreen() {
    MaterialTheme {
        Surface {
            Column(horizontalAlignment = Alignment.End) {
                SimpleButton(
                    text = "RTL Friendly",
                    shape = CutCornerShape(
                        topStartPercent = 50,
                        bottomStartPercent = 50
                    ),
                )

                SimpleButton(
                    text = "RTL Friendly",
                    shape = RoundedCornerShape(
                        topStartPercent = 50,
                        bottomStartPercent = 50
                    ),
                )

                SimpleButton(
                    text = "Absolute",
                    shape = AbsoluteCutCornerShape(
                        topLeftPercent = 50,
                        bottomLeftPercent = 50
                    )
                )

                SimpleButton(
                    text = "Absolute",
                    shape = AbsoluteRoundedCornerShape(
                        topLeftPercent = 50,
                        bottomLeftPercent = 50
                    )
                )
            }
        }
    }
}

@Composable
fun SimpleButton(text: String, shape: Shape) {
    Surface(
        shape = shape,
        color = color_orange,
        elevation = 4.dp,
        modifier = Modifier.padding(top = 20.dp)
    ) {
        Text(
            text = text,
            modifier = Modifier.padding(
                start = 24.dp,
                end = 8.dp,
                top = 6.dp,
                bottom = 6.dp
            ),
            fontWeight = FontWeight.Bold,
            color = Color.White
        )
    }
}

✂️ Cutting corners

In any application, there are practical use-case to draw few of these shapes below.

1. Tags

@Composable
fun ContentTag(color: Color, tagName: String) {
    Surface(
        shape = AbsoluteCutCornerShape(topLeftPercent = 50, bottomLeftPercent = 50),
        modifier = Modifier.padding(8.dp)
    ) {
        Box(
            modifier = Modifier
                .background(color)
                .padding(
                    start = MaterialTheme.typography.h6.fontSize.value.dp * 1.1f,
                    end = MaterialTheme.typography.h6.fontSize.value.dp / 2,
                    top = 4.dp,
                    bottom = 4.dp,
                )
        ) {
            Text(
                text = tagName,
                color = Color.White,
                style = MaterialTheme.typography.h6,
                fontWeight = FontWeight.W300,
                modifier = Modifier
                    .align(Alignment.Center)
            )
        }
    }
}

...

2. TearDrop

A TearDrop shape is basically a rounded rect that bends bottom right at 10% and others with 50%.

val TearDropShape = RoundedCornerShape(
    topStartPercent = 50,
    topEndPercent = 50,
    bottomEndPercent = 10,
    bottomStartPercent = 50
)

@Composable
fun TearDrop(modifier: Modifier = Modifier) {

    Surface(
        shape = TearDropShape,
        color = color_orange,
        modifier = Modifier
            .padding(24.dp)
            .size(60.dp)
    ) {
        Box(contentAlignment = Alignment.Center) {
            Text(text = "7", fontWeight = FontWeight.ExtraBold, fontSize = 30.sp)
        }
    }
}

3. Message bubbles

val IncomingMessage = RoundedCornerShape(
    topStart = 8.dp,
    topEnd = 8.dp,
    bottomEnd = 8.dp,
    bottomStart = 0.dp)

val OutgoingMessage = RoundedCornerShape(
    topStart = 8.dp,
    topEnd = 8.dp,
    bottomEnd = 0.dp,
    bottomStart = 8.dp)

@Composable
fun MessageBubble(
    text: String,
    isIncoming: Boolean,
    modifier: Modifier = Modifier,
) {

    Surface(
        shape = if (isIncoming) IncomingMessage else OutgoingMessage,
        color = if (isIncoming) color_green else color_blue,
        modifier = modifier.padding(8.dp)
    ) {
        Text(
            text = text,
            fontWeight = FontWeight.Light, fontSize = 12.sp,
            color = Color.White,
            modifier = Modifier.padding(8.dp)
        )
    }
}

...
MessageBubble("You have an incoming message", true)
MessageBubble("Cool!!", false, modifier = Modifier.align(Alignment.End))
...

...

4. Stadium button

@ExperimentalMaterialApi
@Composable
fun StadiumButton2(
    text: String,
    color: Color
) {
    Surface(
        shape = RoundedCornerShape(percent = 50),
        color = color,
        modifier = Modifier.padding(12.dp),
        onClick = {},
        indication = rememberRipple(),
        elevation = 4.dp

        ) {
        Text(
            text = text,
            style = MaterialTheme.typography.h6,
            color = Color.White,
            modifier = Modifier.padding(horizontal = 16.dp, vertical = 4.dp)
        )
    }
}

...

5. A half baked - House of El

@Composable
fun SupermanShape(color: Color, size: Dp) {
    Box(Modifier.rotate(45f)) {
        Surface(
            shape = AbsoluteCutCornerShape(topLeftPercent = 50),
        ) {
            Box(
                modifier = Modifier
                    .background(color)
                    .size(size)
            ) {
            }
        }
    }
}

...

6. Kryptonite

@Composable
fun Kryptonite(color: Color, size: Size) {
    Surface(
        shape = AbsoluteCutCornerShape(percent = 50),
        modifier = Modifier.padding(8.dp)
    ) {
        Box(
            modifier = Modifier
                .background(color)
                .height(size.height.dp)
                .width(size.width.dp)
        ) {

        }
    }
}

🛸 What's next?

Above shapes are basic and sharp cut corner or rounded rect. However, when looking at the Tag shape we can see the shape is not smooth around the edges. Since the shape is basically a path that cuts the rectangle, we can do complex path cuts or polish the above ones. A GenericShape has provision for the same, let's cover it in next article.

Android — Implementing LifecycleAwareTimer

Mahendran — Fri, 18 Jun 2021 16:05:49 +0000

Android CountDownTimer is good, but it can be better. This article covers few tweaks to the timer and in general how to decouple certain logic from activity.

📚 Background
👓 Reading between lines
⏲ CountDownTimer
⚙️ Implementation
🧹 Decluttering activity
- Registering to lifecycle
- Moving countdown timer
- Callbacks to the host
- Offhooking the observer
- Activity side implementation
📔 Endnote

📚 Background

CountDownTimer is a convenient API in android when it comes to implementing a timer. However, it lacks few features that have to be filled in by the host Activity /Fragment. Let's draft a user story.

❓ As a user, I should see a countdown timer that expires at an absolute time.

There are multiple ways to achieve this in Android. You can use any of the below APIs.

Coroutines-with-delay
Thread-handler-sleep
CountdownTimer

I'm picking the CountdownTimer, when we reach the end of the article, it'll be clear why we're not using the first two.

...

👓 Reading between lines

The user story says it should expire at an absolute time. Let's assume an offer will expire at 10:00 am. It will expire at 10 whether the activity is running or not. i.e timeout is not bound to the activity or fragment launch time. The timer is merely an attempt to highlight user that he has xx time left till expiry.

No need to explain what a timer is — for our use-case, it ticks per second.

...

⏲ CountDownTimer

CountDownTimer is a simple API that makes use of android's Handler.sendMessageDelayed to emit elapsed value in a given interval. This is an abstract class where we have to provide the implementation for the following methods:

onTick — once every xx-interval
onFinish — time out

   object: CountDownTimer(eta, interval) {
       override fun onTick(millisUntilFinished: Long) {}
       override fun onFinish() {}
   }

...

⚙️ Implementation

Implementing it in our activity/fragment is plain and simple. Compute eta and interval, create a timer, start it and update UI on each tick and then finish it when it's complete.


class OfferActivity: AppCompatActivity() {
    val expiresAt = // 10 am in millis
    var timer: CountDownTimer? = null

    fun onCreate() {
        startTimer()
    }

    private fun startTimer() {
        // If timer already running cancel it
        timer?.cancel()

        val eta = expiresAt - System.currentTimeMillis()
        val interval = 1000 // every 1 sec
        timer = object : CountDownTimer(eta, interval) {
            override fun onTick(millisUntilFinished: Long) {
                // oversimplified version
                timerLabel = "${millisUntilFinished/1000} seconds left"
            }

            override fun onFinish() {
                timerLabel = "offer expired"
            }
        }
        timer?.start()
    }

    fun onDestroy() {
        timer?.cancel()
    }
}

This is an okayish implementation, but it's flawed. Even when the app is in the background, the countdown still runs. So, naturally, like any android developer, we resort to lifecycle methods.


fun onPause() { 
    timer?.cancel() 
}

fun onResume() { 
    startTimer() 
}

This will work fine for one activity, but when we need the timer in multiple places, it just clutters the activity with a bunch of lifecycle methods, and missing one of them will end up in a timer that runs in the background or something that doesn't resume when activity is foreground. Fortunately, we have a way to remove this clutter with a delegate.

...

🧹 Decluttering activity

LifecycleObserver is an interface from androidx which can register to the activity lifecycle and act on behalf of it. This way, the activity will live clean, yet the concerned class can react to the activity lifecycle. In further sections, we'll create a wrapper for the countdown timer and register for lifecycle events.

Registering to lifecycle

class LifecycleAwareTimer(stopAt: Long, interval: Long)) {

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun onResume() {}

    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun onPause() {}

    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    fun onDestroy() {}
}

class OfferActivity: AppCompatActivity() {
    private fun startTimer() {
        // ... 
        lifecycle.addObserver(LifecycleAwareTimer(stopAt, interval))
    }
}

Now we have a skeleton of LifecycleAwareTimer which is connected to our activity and subscribed to lifecycle events. Next thing is to move our CountDownTimer to the wrapper.

...

Moving countdown timer

Create a CountDownTimer inside the wrapper and start/cancel it as per the lifecycle callback. Also, consider the case when the timer expires and don't start it.

class LifecycleAwareTimer(stopAt: Long, interval: Long) {

    private var timer: CountDownTimer? = null
    private val expired: Boolean
        get() = (stopAt - System.currentTimeMillis()) <= 0

    fun startTimer() {
        timer?.cancel()
        timer = null

        val eta = stopAt - System.currentTimeMillis()
        timer = object : CountDownTimer(eta, interval) {
            override fun onTick(millisUntilFinished: Long) {}
            override fun onFinish() {}
        }
        timer?.start()
    }

    fun discardTimer() {
        timer?.cancel()
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun onResume() {
        if (expired) {
            discardTimer()
        } else {
            startTimer()
        }
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun onPause() {
        timer?.cancel()
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    fun onDestroy() {
        discardTimer()
    }

So far, the timer connects to the activity and internally starts/cancels the countdown. But it doesn't deliver results to the host. Let's wire it up.

...

Callbacks to the host

Create a callback interface to update events from the underlying timer to the host activity and implement the same in Activity.

interface TimerCallback: LifecycleOwner {

    fun onTick(millisUntilFinished: Long)

    fun onTimeOut()
}

class OfferActivity : AppCompatActivity(), TimerCallback {
    fun onTick(millisUntilFinished: Long) { /** seconds ticking **/ }
    fun onTimeOut() { /** expired**/ }
}

LifecycleAwareTimer takes in the callback and delivers the result to it. Add the callback to the constructor argument and forward values to the activity.

class LifecycleAwareTimer(
    private val stopAt: Long,
    private val interval: Long,
    private val callback: TimerCallback
) {

    fun startTimer() {
        timer = object : CountDownTimer(eta, interval) {
            override fun onTick(millisUntilFinished: Long) {
                callback.onTick(millisUntilFinished)
            }

            override fun onFinish() {
                callback.onTimeOut()
            }
        }
        timer?.start()

...

Offhooking the observer

Since our TimerCallback is also LifecycleOwner, registering/unregistering for lifecycle can be done right within the LifecycleAwareTimer. It registers for a callback when created and removes itself when activity is destroyed or the timer is expired.

class LifecycleAwareTimer(
    private val stopAt: Long,
    private val interval: Long,
    private val callback: TimerCallback
) {

    init {
        callback.lifecycle.addObserver(this)
    }

    fun discardTimer() {
            timer?.cancel()
            callback.lifecycle.removeObserver(this)    
    }

    ...
    timer = object : CountDownTimer {
        override fun onFinish() {
                callback.onTimeOut()
                discardTimer()
            }
    }

    ...

    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    fun onDestroy() { discardTimer() }

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun onResume() {
        if (expired) {
            callback.onTimeOut()
            discardTimer()
        } else {
            // Try to resume timer
            startTimer()
        }
    }

Activity side implementation

Now pretty much the timer implementation is complete, let's have a look at the activity. It holds a timer reference (to avoid duplicate timers) initializes and starts it. Receives callback from onTick & onTimeOut.

// Activity

    private var timer: LifecycleAwareTimer? = null

    fun startTimer(){ 
       timer?.discardTimer()
       timer = LifecycleAwareTimer(stopAt, interval, this)
       timer?.startTimer()
    }

    fun onTick(millisUntilFinished: Long) { /** seconds ticking **/ }
    fun onTimeOut() { /** expired**/ }

📔 Endnote

This might look like an exaggerated version of the timer. But we have a lot of benefits with this approach:

Timer depends on LifecycleOwner which means, it can be used with both fragment and activity
Timer reacts to lifecycle without explicitly writing much at the host activity/fragment
When activity destroyed, the timer kills itself and unregister from lifecycle callbacks
Timer pauses when activity hits background and resumes or deliver timeout result when the host hits the surface back

Why didn't we use coroutine?
The same behavior can be emulated using a coroutine that dispatches to the Main thread. But a disadvantage is we'll end up owning the elapsed time computation. We still have to use the lifecycle callbacks to manage the coroutine job. And the coroutine itself will contain a while loop with delay and dispatch. When it comes to CountDownTimer, it dispatches messages at a given interval which is organic to the android system.

Comple code is available as gist.

🧑‍💻 Happy coding 🧑‍💻

Flow is non-blocking but the collector is not

Mahendran — Wed, 16 Jun 2021 07:11:47 +0000

Flow is an idiomatic way in kotlin to publish stream of values. While the flow itself suspendable, the collector will block the coroutine from proceeding further. Let's see with an example.

⛲ Flows

Let's create two flows — one finite and an infinite one. Both have a suspension point where they free up the thread 2s/1s. The flow builder creates a flow from a suspendable block and emits values with given delay.

fun finiteEmissions(): Flow<Int> = flow {
    repeat(3) {
        delay(2000)
        emit(it + 1)
    }
}

val random = Random(7659)
fun infiniteEmissions() = flow {
    while (true) {
        delay(1000)
        emit(random.nextInt(10, 100))
    }
}

🚰 Collecting the flow

When collecting the above flows in the same coroutine, you'll notice the infiniteEmissions collect statement blocks the next set of statements from running. Whole point of flow is every single element emitted without blocking the current thread. But we're not proceeding further in the coroutine. Why?

fun main() {
    runBlocking {
        infiniteEmissions().collect { logger.debug(it) }
        logger.debug("won't complete")
        finiteEmissions().collect { logger.debug("Finite: $it") }
        logger.debug("completed")
    }
}

10:23:18.018[main] 80
10:23:19.019[main] 36
10:23:20.020[main] 30
10:23:21.021[main] 11
10:23:22.022[main] 10
10:23:23.023[main] 36
>>> goes on

Reason is, the collect statement itself a suspend function and it will naturally block the current coroutine from within it is called.

public suspend inline fun <T> Flow<T>.collect(crossinline action: suspend (value: T) -> Unit): Unit =
    collect(object : FlowCollector<T> {
        override suspend fun emit(value: T) = action(value)
    })

So, how do we unblock the rest of the statements or collect the flows in parallel?

As usual — the launch coroutine builder. Launch starts a new coroutine without blocking the current one. Putting each collect statements in separate launch builder will unblock each other and collect them simultaneuosly.

runBlocking {
     launch {
         infiniteEmissions()
             .collect {
                 logger.debug(it)
             }
         logger.debug("won't complete")
     }   
     launch {
         finiteEmissions().collect { logger.debug("Finite: $it") }
         logger.debug("completed")
     }
}

10:53:3.003[main] 80
10:53:4.004[main] Finite: 1
10:53:4.004[main] 36
10:53:5.005[main] 30
10:53:6.006[main] Finite: 2
10:53:6.006[main] 11
10:53:7.007[main] 10
10:53:8.008[main] Finite: 3
10:53:8.008[main] completed
10:53:8.008[main] 36
10:53:9.009[main] 55
10:53:10.010[main] 96
>> goes on

Now both flows emits values in parallel and notice we're staying on same thread[main].

🙅 Cancelling the infinite flow

Cancelling flow means to cancel the coroutine which collects it. This is applicable for even for a coroutine which doesn't contain a flow-collect. launch builder returns a job which can be cancelled. Calling job.cancel() will terminate the underlying coroutine. For our example, to cancel the infinite flow once the second flow complete, do like this.

val job = launch {
    infiniteEmissions()
        .collect {
            logger.debug(it)
        }
    logger.debug("won't complete")
}
launch {
    finiteEmissions().collect { logger.debug("Finite: $it") }
    logger.debug("completed")
    job.cancel()
}

10:54:10.010[main] 80
10:54:11.011[main] Finite: 1
10:54:11.011[main] 36
10:54:12.012[main] 30
10:54:13.013[main] Finite: 2
10:54:13.013[main] 11
10:54:14.014[main] 10
10:54:15.015[main] Finite: 3
10:54:15.015[main] completed

🍬 Wrapup

This article covered collecting two flows in parallel. Like any other coroutine, launch will start them in parallel (not necessarily in new thread) and cancelled individually. To collect the flows in serial manner, no need for any special care — just collecting them from same coroutine would do it.

Kotlin playground

Play around it here

GraphQL backend — token expiry

Mahendran — Tue, 01 Jun 2021 18:23:08 +0000

In the previous post we covered authentication and role management. However, it assumed any invalid session to be a visitor instead of throwing 401—Unauthorized client error. This post covers the token expiry aspect of API call.

Let's start with coding part. Following block diagram explains the interaction between each component. As usual, we'll build the system bottom-up.

🎟 Token Service
⏲ Token Expiry Strategy
👮 Request Manager
🐞 More on error handling
📖 Resources

🎟 Token Service

To manage session and expire it, we need meta attributes other than just the token. So, let's beef up the token to a data class called SessionToken. This will hold created & last access timestamps in addition to the token itself.


data class SessionToken(
    val token: String,
    val created: OffsetDateTime,
    var lastAccess: OffsetDateTime = created
)

Our token service is a simple repository which abstracts CRUD on token. When user login-register, a new token generated and wrapped in SessionToken. For every web request made, the token updated with last access time. In case user logout or token expired, entry will be deleted.

Below is our simple implementation — we store our mock tokens as usual to keep our focus on expiry. The created time points to now() i.e we emulate like user logged in at the time of launch.


@Service
class TokenService {

    private val store = mutableMapOf<String, SessionToken>()

    init {
        store["token-buyer"] =
            SessionToken("token-buyer", OffsetDateTime.now())
        store["token-seller"] =
            SessionToken("token-seller", OffsetDateTime.now())
    }

    fun createToken() = SessionToken(
        token = UUID.randomUUID().toString(),
        created = OffsetDateTime.now()
    )

    fun peekToken(token: String?): SessionToken? = store[token]

    fun updateLastAccessTime(token: String) {
        // TODO: Token not found in store - fishy!!
        store[token]?.lastAccess = OffsetDateTime.now()
    }

    fun deleteToken(token: String?) {
        store.remove(token)
    }
}

⏲ Token Expiry Strategy

When it comes to expiry, it's always a good practice to abstract out the validation part and create functional interface to carry out the validation. This will help us plug-in different implementations in the system with little config change.

This brings us to a functional interface SessionExpiryStrategy which takes a SessionToken validate and return whether it is expired.


interface SessionExpiryStrategy {

    fun isSessionExpired(token: SessionToken): Boolean

}

An implementation is only good when explained with its implementations. We consider three different strategies for this.

Fixed lifespan : Session will expire after 30 days
Timeout : If user is not active for 3 minutes — logout
Extended Lifespan: If user is active during the 30th day, give him grace period in 3 minute window

@Component("fixed_time")
class FixedLifeSpanStrategy : SessionExpiryStrategy {
    // 30 days fixed lifespan
    val MAX_DURATION = 30 * 24 * 60 * 60
    override fun isSessionExpired(token: SessionToken): Boolean {
        val durationSinceLogin = ChronoUnit.SECONDS.between(
            token.created,
            OffsetDateTime.now()
        )
        return durationSinceLogin > MAX_DURATION
    }
}

@Component("timeout")
class TimeoutExpiryStrategy : SessionExpiryStrategy {
    // Logout after 3 minutes of inactivity
    const val MAX_DURATION = 3 * 60
    override fun isSessionExpired(token: SessionToken): Boolean {
        val durationSinceLastAccess = ChronoUnit.SECONDS.between(
            token.lastAccess,
            OffsetDateTime.now()
        )
        return durationSinceLastAccess > MAX_DURATION
    }
}

@Component("extended")
class ExtendedLifeSpanStrategy : SessionExpiryStrategy {
    private val timeoutExpiryStrategy = TimeoutExpiryStrategy()
    private val fixedLifeSpanStrategy = FixedLifeSpanStrategy()
    override fun isSessionExpired(token: SessionToken): Boolean {
        return if (fixedLifeSpanStrategy.isSessionExpired(token)) {
            // 30 days past, if user is in the mid of something try the timeout
            // to extend his session
            timeoutExpiryStrategy.isSessionExpired(token)
        } else {
            // 30 days not past yet Let him use the system
            false
        }
    }
}

Few Usecases:
As you can see in ExtendedLifeSpanStrategy, we can mix-match the implementations to tailor user experience. Let's say the buyer in our e-commerce website actively purchasing something and just before he makes payment, session expire due to 30 day lifespan — It would be frustrating. Three minutes added on each api call will alleviate the expiry.

If we want Seller account to logout on 3 minutes inactivity and a fixed timespan for Buyer, it can be achieved by picking strategy 'per role'.


val strategies = mapOf(
    BUYER to fixedTimeSpan,
    SELLER to timeoutStrategy
)

...

strategy[role].isSessionExpired(token)

We have a strategy and a tokenservice in place — let's move on to the final piece where we connect both.

👮 Request Manager

Before we move on to the logic, let's fix the 🐞 in user service. From now, it will return null role for unknown/expired tokens. Still, if there is no token present, session will be identified as VISITOR.


    fun identifyRole(token: String?): Roles? {
        return if (token == null)
            Roles.VISITOR
        else
            role[token]
    }

In the request manager, wire the expiry strategy as you see fit. We'll use qualifiers to inject different strategies that we implemented in last section.


    @Autowired
    @Qualifier("timeout")
//    @Qualifier("extended")
//    @Qualifier("fixed_time")
    private lateinit var tokenExpiryStrategy: SessionExpiryStrategy

     // Save the session info per request. Retrieve it throughout the request
    fun saveSession(request: HttpServletRequest) {
        // Retrieve auth token from request - if any
        val token: String? = request.getHeader(HEADER_TOKEN)

        // Identify role
        val role = userService.identifyRole(token)
        if (role == null) {
            broadcastTokenWipe(token)
            throw unauthorizedException()
        }

        // Handling users that need a session
        if (role != Roles.VISITOR) {
            val sessionToken = tokenService.peekToken(token)
            if (sessionToken == null || tokenExpiryStrategy.isSessionExpired(sessionToken)) {
                broadcastTokenWipe(token)
                throw unauthorizedException()
            }

            // punch-in to the token service
            tokenService.updateLastAccessTime(token!!)
        }

        request.setAttribute(
            KEY_SESSION, DummySession(
                role = role
            )
        )
    }

Added inline comments for clarity, again a walkthrough here. If role is null, throw exception. If session token is null or expired for non-VISITORs throw exception. In both cases wipe the token off the system.

So, what do we throw? — 401 response.

   private fun unauthorizedException() = HttpClientErrorException.create(
        HttpStatus.UNAUTHORIZED,
        "",
        HttpHeaders.EMPTY,
        ByteArray(0),
        Charsets.UTF_8
    )

If the session is valid, update the last access time in token service to support TimeoutStrategy.

🐞 More on error handling

In case, the session is timeout, don't let the request proceed further to protect resources. i.e break the chain in request filter.


@Component
class DummyRequestFilter : OncePerRequestFilter() {

    @Autowired
    private lateinit var requestManager: DummyRequestManager

    override fun doFilterInternal(
        request: HttpServletRequest,
        response: HttpServletResponse,
        filterChain: FilterChain
    ) {
        try {
            // Feed the request to request manager for session preparation
            requestManager.saveSession(request)

            // Resume with request
            filterChain.doFilter(request, response)
        } catch (e: HttpClientErrorException) {
            response.sendError(e.rawStatusCode, e.statusText)
        }
    }
}

In dummy request filter, once per request check whether the token is valid. If so, resume the chain, otherwise catch and propogate the 401 error code to the client.

🐛 That's it 🐛

🚀 Run it!

curl 'http://localhost:8080/graphql' \
  -H 'x-auth-token: token-random-one' \
  -H 'Content-Type: application/json' \
  --data-raw '{"query":"mutation {addProduct}","variables":null}' \
  --compressed

{"timestamp":"2021-06-01T18:28:55.325+00:00","status":401,"error":"Unauthorized","path":"/graphql"}

curl 'http://localhost:8080/graphql' \
  -H 'x-auth-token: token-seller' \ 
  -H 'Content-Type: application/json' \
  --data-raw '{"query":"mutation {addProduct}","variables":null}' \
  --compressed

{"data":{"addProduct":"dummy-product-id"}}

📖 Resources

Github repo
GraphQL playground — http://localhost:8080/graphiql

DEV Community: Mahendran

Using ViewModel-LiveData with Jetpack Compose

Implementation

One-off call

User triggered - API calls

ViewModel implementation

Repo implementation

Android Utility belt — Collection of dependencies for a greenfield project

Network

OkHttp3

Retrofit

Threading and dispatchers

Coroutines

RXJava

Serialization

Moshi

GSON

Jetpack

Livedata / viewmodel

UI

Fragment

Navigation

Room - DB

Dependency injection

Dagger

Hilt

Image loaders

Glide

Coil

Testing

Android — Instrumentation test with hilt & espresso

Contents

Testing strategy

Dependency overview

Test runner setup

Shared test fakes

Writing integration test

Instrumentation or UI tests

Faking modules

The HiltAndroidTest

Wrapup

Resources

How HiltViewModel is generated without a factory?

Introduction

Contents

🗡️ Stabbing with Dagger

Providers & Factories

Dagger binds

Dagger map-multibindings

🎞️ Recap

🪡 HiltViewModel — annotation

🎯 AndroidEntryPoint

Hilt_ProfileFragment — the generated fragment

InternalFactoryFactory

🧩 Final piece - The HiltViewModelFactory

🍬 Wrap up

📖 Resources

👨‍💻️

How viewmodel survives configuration change?

📝 API doc

Factory

ViewModelStore & ViewModelStoreOwner

ViewModelProvider

🏗️ Instantiation

ViewModel without any constructor arguments

ViewModel with dependencies

🤔 Few questions

How ViewModel survives orientation change?

How ViewModel is scoped to single Fragment?

How unique is the key in ViewModelStore?

📒 Resources

Android — Basic Hilt setup with viewmodel + fragment

Contents

💉 What are we injecting?

🔘 Little about scope

💻 Code it

Build setup

HiltAndroidApp setup (application context)

Creating data source and modules

Viewmodel setup