DEV Community: Marcello Galhardo

N26 Path to Anvil

Marcello Galhardo — Fri, 05 Feb 2021 11:04:54 +0000

This post represents my personal experience while working at N26. I do not speak for the company nor by other employees.

N26 Android App current codebase has a million lines of code, 280+ modules, and 30+ engineers working in 4 different countries and different timezones in a mono repository. Our modules are divided into features and libraries, and we have been using "Sample Apps" for years now as our full app build time might take up to 20 minutes.

Today I will share a little about my story with Dagger inside the company, why we adopt Anvil, some of the challenges we faced, and how are the results so far.

Dagger, (oh, my)

N26 has a long history with Dagger. We have been using it for years, we developed our customizations and libraries on top of it, and many of our architectural decisions were made relying on Dagger features.

Dagger is excellent but comes with a price when used with Kotlin. The more we grew, the more we were charged. Stub generation issues, slow build time, increasing boilerplate to wire @dagger.Component, new joiners avoided touching the graphs due to complexity...

Looking for solutions, we found Hilt by Google. We enjoyed many of the ideas they proposed as the Monolithic Component and the testing philosophy. But the trade-off was not that good for us: a migration would be painful and would take months to years, to not say we did not appreciate the byte code manipulation and the extra KAPT processor.

Simultaneously, another solution appeared, which solved some of the same problems differently: Anvil.

Anvil is a Kotlin compiler plugin to make dependency injection with Dagger easier by automatically merging Dagger modules and component interfaces.

Sharpening your blade

To get an idea of how Anvil would affect us, we started with a set of experiments. The first one would be to wire a few modules while keeping backward compatibility without impacting any feature developer. In a matter of hours, we managed to conclude it. In a week, we had many modules using Anvil. We did not identify any expressive build time impact.

We were happy with the result. We decided to be more ambitious: we selected our code base's prominent monolith module to fully migrated to Anvil, and afterward, we broke this monolith apart into small libraries. It took us a few months to complete the goal, but we succeeded and did not identify any expressive build time impact, again.

To be sure we were on the right path, we mapped the relationship of a few of our most complex modules before and after adopting Anvil. For a matter of company's privacy, all text is blurred, but you can still see the positive impact by noting the arrows:

Finally, we decided to go full Anvil: we turned on Anvil's Dagger Factory generation in all modules that we could (20+ at the time). We identified build times improvements of ~50% for individual modules build times, ~10% for Sample Apps, and because Anvil does not rely on KAPT, we never saw any KAPT issue again on those modules.

Many improvements, but we believed we could take it further: let's take the good things from Hilt and bring it to Anvil.

Hilt to Anvil

We decided to adopt what we like from Hilt while using Anvil.

The first point was to provide a single monolith component, and for that, we started to merge the components and use Anvil's @ContributesTo to binding the modules instead. It took quite some time, it was challenging but it worked well.

The second one was to support some Jetpack Libraries. We started with FragmentFactory to leverage the constructor injector as much as possible. We created a @FragmentKey and used Dagger's multi-binding to wire everything. Here is how the code might look like:

@ContributesBinding(Singleton::class, FragmentFactory::class)
class MultibindingFragmentFactory @Inject constructor(
    private val map: Map<Class<out Fragment>, @JvmSuppressWildcards Provider<Fragment>>
) : FragmentFactory() {

    override fun instantiate(classLoader: ClassLoader, className: String): Fragment {
        val fragmentClass = loadFragmentClass(classLoader, className)
        return map[fragmentClass]?.get() ?: super.instantiate(classLoader, className)
    }
}

@Target(
    AnnotationTarget.CLASS,
    AnnotationTarget.FUNCTION
)
@Retention(value = AnnotationRetention.RUNTIME)
@MapKey
annotation class FragmentKey(val value: KClass<out Fragment>)

class Activity : AppCompatActivity() {

    private val component: MainComponent
        get() = TODO("Retrieve your Monolith Component")

    override fun onCreate(savedInstanceState: Bundle?) {
        supportFragmentManager.fragmentFactory = component.getFragmentFactory()
        super.onCreate(savedInstanceState)
    }
}

And now to wire your Fragment, you can simple:

@ContributesMultibinding(Singleton::class)
@FragmentKey(HomeFragment::class)
class HomeFragment @Inject constructor(
    // Dependencies goes here. :)
) : Fragment()

For more details around Fragments, check the official guide.

Having a Monolith Component and relying on Fragment's constructor injector means we can invoke any fragment from any place of our application, and things "will work". Scoping becomes intuitive for those classes. If you inject an object in the Fragment is a fragment scope, if you inject into the ViewModel is a view model scope. We also offer a SessionScope and Singleton scope.

For ViewModels a simple Provider<ViewModel> or AssistedInject, if you need an instance of SavedStateHandle, will do the trick.

And finally, testing: Anvil offers a replace module feature that is handful to provide new dependencies during tests. For that, we create helper modules called testing and we provide fake dependencies of those replacing the production modules. Developers that include the testing in their test classpath can automatically interact with our testing utilities (or create their own, if required). To be completely honest here, it is more of an ongoing process.

Conclusion

Anvil is a robust and straightforward solution. It does what it suppose to do and does it well. It benefits from a seamless synergy with Dagger, while not being opinionated and letting you decide how you integrate with other libraries (or not integrating it at all).

Also, the fact it does not rely on KAPT is a tremendous advantage for large projects and should be kept in mind while deciding between Anvil or Hilt. I'm delighted with the overall experience, and I enjoy seeing how many feature developers started to migrate away from KAPT to Anvil proactively:

Finally, as you can see above, many of the Hilt's features can be implemented in Anvil. However, it is vital to keep in mind Anvil is not a silver bullet. It is essential to have people in your team that understand Dagger and Dependency Injection to build the integrations you might need.

Update 2021.02.25

As many people reached out asking advice on how to implement some Hilt features (e.g., ViewModelScope, SavedStateHandle, and others), I created a small showcase project.

Update 2021.03.19

Updated MultibindingFragmentFactory example and showcase project to use new @ContributesMultibinding from Anvil 2.2.0.

Credits

Thanks to Maria Chietera, Rafael Araujo, Tiago Cunha, Fabio Carballo, and Stojan Anastasov proofread review! 🔍

And a special thank you to Ralf Wondratschek for early feedback and creating Anvil! 🔪

If you like my posts, follow me on Twitter: @marcellogalhard

Cover Picture by Lucy and the Anvil.

Humble Views, Proud ViewModels

Marcello Galhardo — Mon, 01 Feb 2021 07:44:37 +0000

The Android Community has long advocated that Activities and Fragments were views - but this perception has changed over time. For good. Let's dive deep into how to design views and view models, how they wire to a LifecycleOwner, and how this can positively impact your's app testability.

To better describe how to build humble views we will be developing an elementary Sign-Up form with an email, a password text field and two buttons: a cancel that pops the user's back stack and a sign up that creates an account and moves the user to the home screen.

"Fragment is not your View" - Juliano Moraes

Heads-up: this article expects you to be familiar with Dependency Injection (but no particular framework), Coroutines, Fragment, and View Binding. I won't use Jetpack's ViewModel, but the code here is entirely compatible. I will not cover any other aspects outside humble Views and ViewModels.

Views

Views represent your UI. They can be written in code or, the most common way, using XML. Android views can not have a custom constructor as they must be created by the OS using reflection when inflating it from XML, during a configuration change, or process death.

Views should not be aware of your architecture decisions. If you use MVP, MVC, MVVM, or MVI is irrelevant for a well-designed view.

Views are hard to test and require an Instrumentation or Robolectric environment, which makes them slow. For that reason, we might want our views to be a Humble Object.

class SignUpView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null
) : ConstraintLayout(context, attrs) {

    private val binding = SignUpViewBinding.inflate(LayoutInflater.from(context), this)

    var email: String
        get() = binding.email.text
        set(value) { binding.email.setText(value) }

    var password: String
        get() = binding.email.text
        set(value) { binding.email.setText(value) }

    var isSignUpEnabled: Boolean
        get() = binding.signUpButton.isEnabled
        set(value) { binding.signUpButton.isEnabled = value }

    var onSignUpClicked: () -> Unit = {}
    var onCancelClicked: () -> Unit = {}
    var onEmailChanged: (String) -> Unit = {}
    var onPasswordChanged: (String) -> Unit = {}

    init {
        binding.signUpButton.setOnClickListener { onSignUpClicked() }
        binding.onCancelClicked.setOnClickListener { onCancelClicked() }
        binding.email.doOnTextChanged { text, _, _, _ ->
            onEmailChanged(text)
        }
        binding.password.doOnTextChanged { text, _, _, _ ->
            onPasswordChanged(text)
        }
    }
}

What is going on with this ViewBinding?

In my View's XML root, I use a <merge> tag, and ViewBinding understands that: it provides me with an inflate function that attaches the view automatically to its parent.

ViewModels

ViewModel's are a lightweight representation of your UI. The ViewModel is responsible for coordinating any user interaction to any business model required. It may offer a one or two-way binding to let those business models interact with the GUI.

class SignUpViewModel(
  private val savedStateHandle: SavedStateHandle,
  private val scope: CoroutineScope,
  private val repository: SignUpRepository,
) {

  private val _navigation = Channel<Navigation>()
  val navigation = _navigation.receiveAsFlow()

  private val _toastMessage = Channel<ToastMessage>()
  val toastMessage = _toastMessage.receiveAsFlow()

  val email = savedStateHandle.getStateFlow<String>(scope, "email", "")

  val password = savedStateHandle.getStateFlow<String>(scope, "password", "")

  private val _isSignUpEnabled = savedStateHandle.getStateFlow<Boolean>(scope, "isSignUpEnabled", false)
  val isSignUpEnabled = _isSignUpEnabled.asStateFlow()

  init {
    email.collectIn(scope) { updateSignUpEnabled() }
    password.collectIn(scope) { updateSignUpEnabled() }
  }

  fun onSignUpClicked() {
    runCatching {
      // Try to parse e-mail and validate password. If yes, save.
      val email: String = // parse e-mail.
      val password: String = // verify if password is acceptable.
      repository.signUp(email, password)
    }.fold(
      onSuccess = { _navigation.sendIn(scope, Navigation.Push(SignUpRoutes.Home)) },
      onFailure = { _toastMessage.sendIn(scope, ToastMessage(R.string.generic_error)) },
    )
  }

  fun onCancelClicked() {
    _navigation.sendIn(scope, Navigation.Pop)
  }

  private fun updateSignUpEnabled() {
    // Naive logic to enable sign up.
    _isSignUpEnabled = email.isNotBlank() && password.isNotBlank()
  }
}

Why expose some flows as MutableStateFlow and others no?

Each field has a different requirement: two-way or one-way binding.

TextFields requires a two-way binding as we want to get updates when the user types a new content while preserving the ability to update its content whenever necessary. Exposing it as a MutableStateFlow allows us to move all sanitization logic to the view model (see onSignUpClicked) and ensure the View is as humble as possible.

The sign-up button state requires a one-way binding (see isSignUpEnabled) - only the ViewModel can change its state based in a validation logic.

Why not modeling my UI State as a single flow in the ViewModel?

The concepts here do not exclude a single view state, I believe they complement each other.

You can easily keep your view humble while modeling UI State as a single object on top of the ViewModel. In this case, the ViewModel would be responsible for handling the unidirectional data flow and doing the required diffs between each state emission within your bindings to enforce your UI is not being updated without demand. Therefore, let your view humble allow you to keep it agnostic of how you handle state, architecture decisions, and it enable you to test your ViewModel and classes above it as a unit very closely of how it would behave in the real world with a GUI: remember, the View is humble!

I will not cover these concepts here but for a better understanding of why you would like to model your UI State as a single sealed hierarchy and how to do it well, I highly recommend my friend's Stojan Anastasov post about the subject: Modeling UI State.

LifecycleOwner

The UI Controller. Usually, a Fragment responsible for a section of the screen. A LifecycleOwner is responsible to wire up a View to a ViewModel, delegate callbacks from the Android OS, handle configuration changes and more.

class SignUpFragment : Fragment() {

    // Retain the instance across configuration changes.
    private val viewModel by retain { entry ->
        val repository: SignUpRepository = // creates the repository
            SignUpViewModel(entry.savedStateHandle, entry.scope, repository)
    }

    // Creates your View and connects to the ViewModel.
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {
        val view = SignUpView(requireContext())

        // Bind the View and ViewModel
        view.onSignUpClicked = viewModel::onSignUpClicked
        view.onCancelClicked = viewModel::onCancelClicked
        viewModel.email.observeIn(viewLifecycleOwner, view::email::set)
        viewModel.password.observeIn(viewLifecycleOwner, view::password::set)
        viewModel.isSignUpEnabled.observeIn(viewLifecycleOwner, view::isSignUpEnabled::set)
        // Other binds you might need with the view...
        viewModel.navigation.observeIn(viewLifecycleOwner) { navigation ->
            // Handle navigation.
        }
        viewModel.toastMessage.observeIn(viewLifecycleOwner) { message ->
            // Handle toast message.
        }

        return view
    }
}

Testing

We designed our View as a Humble Object to let us quickly test both View and ViewModel. As you might have perceived, the ViewModel is straightforward to write tests as we do not depend on any Android related class.

class SignUpViewModelTest {

  private val scope = TestCoroutineScope()

  // A fake version of the data source to not cross boundaries like network and database.
  private val dataSource = TestDataSource()

  private fun createSut(): SignUpViewModel {
    return SignUpViewModel(SavedStateHandle(), scope, SignUpRepository(dataSource))
  }

  // Set up, tear down, other tests, etc...

  @Test
  fun `given email and password field is not blank when signing up then navigate to the home` {
    // Arrange Phase
    val sut = createSut().apply {
      email = "my.fake.person@gmail.com"
      password = "8S#@2LAaB_.NJh(Y"
    }
    var actualNavigation: Navigation? = null
    scope.launch { sut.navigation.collect { actualNavigation = it } }

    // Act Phase
    sut.onSignUpClicked()

    // Assert Phase
    val expectedNavigation = Navigation.Push(SignUpRoutes.Home)
    assertThat(actualNavigation).isEqualTo(expectedNavigation)
  }
}

As the view is a humble object, there is nothing much to test on it. However, we might want to ensure that the UI behaves as expected when the ViewModel changes its attributes. For example:

class SignUpViewTest {

  @Test
  fun `given sign up is disabled then the button should not be clickable`() {
    launchViewInFragment { SignUpView(requireContext()) }
      .onView { it.isSignUpEnabled = false }

    onView(withId(R.id.signUpButton))
      .check(matches(not(isEnabled())))
  }
}

Conclusion

It is relatively easy to see that View's, in Android, are strongly tied to the concept of their functionality. Humble View's is a way to create a clear separation between them and the Android Framework aiming for scalability, readability, and maybe the most essential point, testing.

In this article, we applied Humble Object pattern and MVVM concepts to create the circumstances that would allow developers to test View's and ViewModel's with ease even when they are strongly tied conceptually. Additionally, understanding that the LifecycleOwner is not your View will help you to ensure your code is highly testable.

Other than testing, projects that use this approach can easily compose more complex View's, and ViewModel's, from smaller objects. Lastly, this approach fit with Jetpack's Compose: replace the View with a @Composable and reuse the ViewModel!

Happy Coding! 😎

Helper functions & credits!

I used Retained library to keep the state of the ViewModel in configuration changes. I also published all the helper functions as Github GISTs, so you can use them as you please.

Special thanks to Maria Chietera, Tiago Dávila, Rafael Araujo, Tiago Cunha, Felipe Pedroso, and Stojan Anastasov proofread review! 🔍

If you like my posts, follow me on Twitter: @marcellogalhard

Cover Photo by Francesco Ciccolella.