DEV Community: Tiago Loureiro

Meet the Jetpack Splashscreen API: a definitive guide for splash screens in Android

Tiago Loureiro — Sat, 10 Jul 2021 22:09:07 +0000

Splash screens, also called launch screens, are the screens shown by the app as it loads, during the app's startup. They exist to provide a momentary brand exposure or improve the user experience by showing a preview of the app as it starts, which can reduce the user's perceived load time.

Branded and preview splash screens as in Material Design docs

On many projects I've worked on, in addition to showing the splash screen, we had to animate the transition between splash and first app screen. Depending on the animation type and how we're showing the first app views, we can have jank or a perceivable delay between the animations. So, we have to choose the right approach accordingly to the use case.

In this article you'll see how animated splash screens are created in Android and how this should be done now that we have Jetpack's Core SplashScreen, which backports Android 12 SplashScreen API back to Android Marshmallow (API 23).

Suppose we have to implement the following branded splash screen for an Android app:

Click to see the design on Figma

Note that we start with a brand image, fade it out and then begin a slide down transition in the start screen. This use case will let us exercise multiple techniques in splash screen display, despite having simple transitions in the design. The animations must run sequentially and a long delay or jank between them is not acceptable.

Simple things first

Let's start simple: showing what happens in Android when you don't set up a splash screen. After creating an 'Empty Activity Project' in Android Studio, the main activity layout was adjusted to have the same design as the start screen reference. Nothing was made regarding the splash screen.
This is how it's displayed up to API level 30:

As we didn't add nothing to set up a splash screen yet, a black screen is shown while the main activity is loading.

Important: On an Android 12, a static branded splash screen was automatically displayed, using a centered app icon without any effort at all. Nice improvement!

Automatic static splash screen on Android 12

To repeat this step, clone the following branch in Github's repo: github.com/tgloureiro/animated_splashscreen_android/tree/step1_no_splash

Showing a splash screen (Old way)

The traditional way of defining a splash screen in Android, is setting a window background to the the activity being launched. As the content is not attached to it yet, the window background is fully visible while the activity is loading. After it loads, content view is set inside the onCreate() method and it's views starts being rendered.

Therefore, to show the splash screen we have to set up the window background in the theme being used by the activity:

/res/values/themes.xml
<resources xmlns:tools="http://schemas.android.com/tools">
    <!-- Base application theme. -->
    <style name="Theme.AnimatedSplashScreen" 
        parent="Theme.MaterialComponents.DayNight.NoActionBar">
        <!-- Drawable to be rendered in window's background 
             while the activity is being loaded -->
        <item name="android:windowBackground">
            @drawable/your_splashscreen_drawable
        </item>
    </style>
</resources>

If we need the splash screen to have a logo centered over some background drawable, we can use a LayerDrawable, that allows us to specify a list of drawables that is drawn in the order they're declared. In this example, we have a flat colored background with the logo centered in the screen. The use of android:gravity informs the platform to center the second drawable in the middle of the screen.

/res/drawable/splash_screen.xml
<?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:drawable="@drawable/splash_background"/>
    <item android:gravity="center" 
        android:drawable="@drawable/splash_logo" />
</layer-list>

For the splash background, we can use any type of drawable. For this example, we'll use a solid color. The color can be specified directly in the layer list, instead of pointing to another Drawable as we did here

/res/drawable/splash_screen.xml
<?xml version="1.0" encoding="utf-8"?>
<shape
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:shape="rectangle">
    <solid android:color="@color/blue" />
</shape>

This is the old way of doing a splash screen and it's recommended up to API Level 22, the ones not covered by the new Core Splash Screen API.

Fading out the logo

There's an easy way of implementing the splash screen's fade out after activity loading: we can have the illusion of a logo fade out making a cross-fade between the splash screen and the screen background without the logo. We can do it using a TransitionDrawable. A transition drawable allows us to define two drawable layers and easily cross-fade between them using the startTransition(int) method.

/res/drawable/splash_transition.xml
<?xml version="1.0" encoding="utf-8"?>
<transition 
    xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:drawable="@drawable/splash_screen" />
    <item android:drawable="@drawable/splash_background" />
</transition>

We have to perform the following tasks:

Check if the splash screen was not displayed, otherwise we just set content view
Get a reference to the window background and start the crossfade transition
Launch a coroutine and after waiting for the animation duration, set the content view

MainActivity.kt
class MainActivity : AppCompatActivity() {
  ...
  override fun onCreate(savedInstanceState: Bundle?) {
      super.onCreate(savedInstanceState)
      // Checks if the splash screen was displayed before
      // ->SavedInstanceState is not null after recreation!
      val splashWasDisplayed = savedInstanceState != null
      if(!splashWasDisplayed){
          // 1 - Start fading out the logo
          (window.decorView.background 
              as TransitionDrawable).startTransition(
                  logoCrossFadeDurationMillis
              )
          // 2 = As we can't register a listener to be 
          // notified when the transition drawable finishes,
          // launches a coroutine that blocks while animation
          // is being performed and sets the content view
          lifecycleScope.launch {
              // Time between the animations
              delay(logoCrossFadeDurationMillis.toLong()
                + spacingAfterFadeDurationMillis)
              window.decorView.background = 
                AppCompatResources.getDrawable(
                    this@MainActivity,
                    R.drawable.splash_background
                )
              setContentView(R.layout.activity_main)
          }
      }else{
          // Splash was shown before, no need to animate it.
          // 1 - Updates the window background (if needed)
          window.decorView.background = 
            AppCompatResources.getDrawable(
              this,R.drawable.splash_background
            )
          // 2 - Sets the content view instantly
          setContentView(R.layout.activity_main)
      }
  }
  ...

Check how it is rendered in a phone:

To repeat this step, clone the following branch in Github's repo: github.com/tgloureiro/animated_splashscreen_android/tree/step2_fade_out_splash

Showing the splash screen using Core SplashScreen API

The Core Splash Screen API provides a way of defining the elements we have in the Splash Screen. To setup a splash screen, you have to do the following steps:

1- Setup a style with Theme.SplashScreen as a parent, in themes.xml

themes.xml
    ...
    <style name="Theme.AppSplash" parent="Theme.SplashScreen">

    </style>

2- Setup windowSplashScreenBackground, windowSplashScreenAnimatedIcon as the background and the centered logo in the screen

themes.xml
    ...
    <style name="Theme.AppSplash" parent="Theme.SplashScreen">
        <item name="windowSplashScreenBackground">@drawable/your_background_drawable</item>
        <item name="windowSplashScreenAnimatedIcon">@drawable/your_icon_drawable</item>
    </style>

3- Setup the theme to be displayed in activity after the splash screen

themes.xml
    ...
    <style name="Theme.AppSplash" parent="Theme.SplashScreen">
        <item name="windowSplashScreenBackground">@drawable/your_background_drawable</item>
        <item name="windowSplashScreenAnimatedIcon">@drawable/your_icon_drawable</item>
        <item name="postSplashScreenTheme">@style/your_activity_theme</item>
    </style>

4- In build.gradle, change your compileSdkVersion to "android-S" (to be changed to apiLevel 31 with the release of Android 12) and include the library in dependencies.

build.gradle

...
android {
    compileSdkVersion "android-S"
    ...
}
...
dependencies {
    ...
    implementation 'androidx.core:core-splashscreen:1.0.0-alpha01'
}

5- Finally, in the MainActivity (or the entry point for your app) you just have to call installSplashScreen() before setContentView()

MainActivity.kt
...
 override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        installSplashScreen()
        setContentView(R.layout.activity_main)
    }
}

Very straightforward, huh? With these simple steps you'll be showing your splash screen from API23 to Android12.

Core SplashScreen API + Animations

In Android 12, the logo itself can be animated using AnimationDrawable or AnimatedVector. The AnimationDrawable works similar to a classical animation which you have to represent
frame by frame and duration for each one. AnimatedVectorDrawable let's you describe your animation that will be interpolated by the framework.

The backported version of the Core Splash Screen API doesn't support animations on the logo yet. But we can implement a fadeout animation after splash's exhibition and I'll show how to implement it using this API.

We have to perform the following tasks:

Check if the splash screen was not displayed, otherwise we manually set the theme and the content view
Install the splash screen and listen for the ExitAnimation event
Get a reference to the the logo, fade it out, remove the splash and set content view after it finishes

MainActivity.kt
class MainActivity : AppCompatActivity() {
    companion object{
        const val splashFadeDurationMillis = 300
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val splashWasDisplayed = savedInstanceState != null
        if(!splashWasDisplayed){
            val splashScreen = installSplashScreen()
            splashScreen.setOnExitAnimationListener { 
                splashScreenViewProvider ->
                // Get logo and start a fade out animation
                splashScreenViewProvider.iconView
                    .animate()
                    .setDuration(
                        splashFadeDurationMillis.toLong()
                    )
                    .alpha(0f)
                    .withEndAction {
                        // After the fade out, remove the 
                        // splash and set content view
                        splashScreenViewProvider.remove()
                        setContentView(R.layout.activity_main)
                    }.start()
            }
        }else{
            setTheme(R.style.Theme_AnimatedSplashScreen)
            setContentView(R.layout.activity_main)
        }
    }
}

Check how it is rendered in a phone:

To repeat this step, clone the following branch in Github's repo: github.com/tgloureiro/animated_splashscreen_android/tree/step3_core_splash_api_fade_out

Showing the splash screen using Core SplashScreen API with Jetpack Compose

The splash steps are pretty much the same, except we use Compose's setContent{} instead of setContentView(int). That's it.

The challenge here is to replace the start screen animation, originally made using MotionLayout, with one made using Compose. We can use an initially invisible AnimatedVisibility Composable and make it visible in the first pass using a LaunchedEffect. Making it visible will start the animation as described in the widget.

MainActivity.kt
fun StartScreen() {
    var visible by remember { mutableStateOf(false) }

    Scaffold(
        content = {
            Box(
                modifier = Modifier
                    .background(
                        colorResource(id = R.color.blue)
                    )
                    .fillMaxSize(),
            ) {
                AnimatedVisibility(
                    visible = visible,
                    enter = slideInVertically(
                        initialOffsetY = {
                            // Slide in from top
                            -it
                        },
                        animationSpec = tween(
                          durationMillis = 
                          MainActivity.splashFadeDurationMillis,
                        easing = LinearEasing
                    )
                    ),
                ) {
                    Column(
                        verticalArrangement = 
                            Arrangement.Center,
                        horizontalAlignment = 
                            Alignment.CenterHorizontally,
                        modifier = Modifier
                            .padding(
                                0.dp, 
                                0.dp, 
                                0.dp,
                                0.dp
                            )
                            .background(
                                colorResource(
                                    id = R.color.blue
                                )
                            )
                            .fillMaxSize()
                    ) {
                        Text(
                            stringResource(
                                id = R.string.start_screen_title
                            ),
                            fontSize = 36.sp,
                            modifier = Modifier.padding(
                                bottom = 
                                dimensionResource(
                                    R.dimen.start_content_title_margin_bottom
                                    )
                                ),
                            color = Color.White,
                            fontWeight = FontWeight.Bold
                        )
                        Box(
                            modifier = Modifier
                                .height(
                                    dimensionResource(
                                        R.dimen.start_content_size
                                        )
                                    )
                                .width(dimensionResource(
                                    R.dimen.start_content_size
                                    )
                                )
                                .clip(
                                    RoundedCornerShape(
                                        8.dp
                                    )
                                )
                                .background(color = Color.White)
                        )
                    }
                }
            }
            LaunchedEffect(true) {
                visible = true
            }
        }
    )
}

Check how it is rendered in a phone:

To repeat this step, clone the following branch in Github's repo: github.com/tgloureiro/animated_splashscreen_android/tree/step4_core_splash_jetpack

Final thoughts

The new Jetpack Core Splashscreen API provides a default way to create splash screens back to API23, with useful mechanisms we can use to know whether the loading ended and a way to continue showing the splash if we want to do additional work after starting the activity. The results are similar to what we had before, with the benefit of reduced boilerplate and compatibility with new Android versions.

Kotlin Multiplatform vs Flutter: Which One to Choose for Your Apps

Tiago Loureiro — Tue, 20 Apr 2021 15:40:49 +0000

Kotlin Multiplatform and Flutter are two of the hottest multi/cross-platform app frameworks and are maturing quite fast. Both help you to reuse code when developing apps for Android and iOS. However, these platforms are very different and serve distinct purposes. Having worked with both, I'm going to share what I consider to be each one's strengths and weaknesses.

Kotlin Multiplatform Mobile (KMM)

Kotlin is a great choice for developing mobile apps. Its conciseness, simplicity, and expressivity allow you to write correct and readable code effortlessly. Kotlin is the suggested language if you are starting a new native Android Project. Hence, if you have to target Android devices, you will probably end with the Android business logic written in Kotlin. Now, imagine being able to put your Android's business logic code, almost untouched, inside your iOS project as an iOS Framework. KMM is the best tool to do this right now and is being used by companies like VMware, Philips, and Netflix.

In KMM, you have a shared folder that is completely reused between platforms. Most of the business logic will be platform-independent. But, when you need to write code that depends on native/system libraries, you can count with KMM's expect/actual keywords.

With this mechanism, a common source set defines an expected declaration, and platform source sets must provide the actual declaration that corresponds to the expected declaration. This works for most Kotlin declarations, such as functions, classes, interfaces, enumerations, properties, and annotations.

Curious for how it works? Look at this code:

// Shared (Common)
expect fun randomUUID(): String

// Android
import java.util.*
actual fun randomUUID() = UUID.randomUUID().toString()

// iOS
import platform.Foundation.NSUUID
actual fun randomUUID(): String = NSUUID().UUIDString()

(Available in kotlinlang.org/docs)

Very straightforward, right? This way, the randomUUID() function can be used from reused code (common code), with the correct implementation being provided for each platform during compilation. Then, common code is provided for each platform as an Android module or iOS Framework.

Flutter

Flutter is a cross-platform framework to target iOS and Android with a single codebase. Google calls it a "UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop". One of the superpowers of Flutter is that you can design almost any interaction or animation and have it running the same way in Android and iOS. No need to make special adjustments or to recreate the designed user interface using native platforms. For those who are looking to innovate in UI space or don't need to make strong use of native features, Flutter is a strong choice.

To write Flutter apps, you need to program in Dart. Dart is a C/Javascript/Java-like programming language, that may be very familiar if you have previous contact with some of these languages. New features like sound null safety makes Dart even closer to Kotlin and Swift. But make no mistake: to have modern language features like sealed classes, inline classes you may need to use code generators (Take a look at Remi Rousselet's Freezed as an example of generated code in Flutter).

Flutter is very easy to use and has a really fast hot reload. It is nice to see your mobile UI rendered in almost real-time in an emulator/simulator as you code. It's not the best choice if you depend heavily on native features that don't have an existing library, because otherwise you may have to spend a lot of time making plumbing code for Flutter's platform channel. Another weakness is that the native UI components are recreated in Flutter's engine. This means that if a new OS version is released with new UI components, you will have to wait until Flutter catches up to use the newest resources.

My experience with KMM and Flutter in a real world project

Yes, you're reading right. I worked with KMM for shared business logic between iOS and Android + Flutter for UI in a real-world app, that is yet to be launched. That way, we unified our low-level network code and business logic between platforms with KMM, leaving Flutter with only the UI layer of the app. I will detail the design decisions and how everything went in a next post.

Which one should I choose? Summary:

Kotlin Multiplatform Mobile may be a good choice if...

Already have existing native-specific code to be reused.
You care about having the most updated native components and want to have a 100% native look and feel on every new OS version.
You want to incrementally share code between platforms on an existing codebase.
You don't need to publish a desktop or web version of your app.
You don't want to depend on Flutter engine's implementation on each platform.
Your project isn't going to be released very soon, or you don't mind about KMM being in alpha status right now.
Your app is strongly tied to multi-thread or it has background processing needs.

Beware: KMM is currently in alpha and the APIs may change until it hits stable. Kotlin native memory management is being replaced (important for iOS). You will need to study how it handles memory management, concurrency and immutability to correctly implement multiplatform code for now. Check: https://kotlinlang.org/docs/native-concurrency.html#global-variables-and-singletons

Flutter may be a good choice if...

You are in a small team and don't have resources for two native UI codebases.
Your app depends mostly on simple API and database calls, a common use case in mobile apps. In this scenario, you can avoid writing Flutter's Platform Channel code as you won't need to interact with native code.
Your app has a custom UI or you are innovating in UI space.
You target Web and Desktop besides Mobile and want to have a working solution for these platforms right now.

Updating your Android toolbox: what should I learn for Android development in 2021?

Tiago Loureiro — Tue, 20 Apr 2021 13:40:09 +0000

This week marks the first beta release of Jetpack Compose. Seeing those platform changes happening, I curated recommended technologies, libraries, and frameworks to be used in new projects, based on my previous experience, gut feelings, and everything that is being released right now. For now, I'm citing the topics and later each one will become a thorough and independent article in this blog.

Kotlin

Kotlin is an exciting programming language designed to be concise and expressive. It's Google's recommended programming language for Android since 2019 and has great tooling support on Android Studio. Kotlin allows the programmer to write safer code and android apps written in Kotlin are 20% less likely to crash (compared to old Java versions), thanks to features like type and null safety. It combines aspects of object-oriented and functional programming paradigms to allow the programmer to write better code.

Access https://developer.android.com/kotlin/first to start learning Kotlin-first Android development.

Android Jetpack

Historically, Android wasn't an opinionated platform, regarding app architecture and modularization. Things like backward compatibility, navigation, state management, and app lifecycle were error-prone and slowed app development. Hence, the Android team decided to create a suite of libraries to help developers write code that follows best practices, with less boilerplate, and is consistent across Android versions and devices.

Some of the libraries, like Jetpack's LiveData and Databinding were a first step towards declarative UI. They're now being replaced with better alternatives like Compose UI and Flow, and albeit they're practically alpha, it's not recommended anymore to be used in new projects.

Beware: You're about to meet some Android Studio bugs and Compose UI tooling issues while using Android Studio Canary. But that's ok, they're expected to be polished throughout the year and aren't blocking the work.

These are the up to date, recommended Jetpack libraries to be used in new projects:

1. Jetpack Compose

Jetpack Compose is a declarative, modern approach for building user interfaces in Android and is intended to replace the old way of doing Android UI. It allows you to build UI without the need to mutate the views whenever data changes.

"In Compose's declarative approach, widgets are relatively stateless and do not expose setter or getter functions."

This means that the UI observes a state and all the screen is regenerated based on any changes on this state. The smartness here is that Compose knows which view must be updated, and only redraws the necessary portion of the screen, avoiding excessive calculations.

It has special tooling available in Android Studio preview, like smart editor features and Compose UI preview.

Get started on https://developer.android.com/jetpack/compose

2. ViewModel

One of the most important concepts needed to develop an Android App is the concept of the lifecycle. In the platform, every main building block has a lifecycle that is controlled mainly by the operating system. So, your app isn't really creating an Activity or a Fragment by itself, it is asking the OS to provide an instance of one or another. When the system has a memory pressure, it starts releasing resources and a part (or the whole) of your app may be destroyed.

"Doing the right work at the right time and handling transitions properly make your app more robust and performant. For example, good implementation of the lifecycle callbacks can help ensure that your app avoids:

Crashing if the user receives a phone call or switches to another app while using your app.

Consuming valuable system resources when the user is not actively using it.

Losing the user's progress if they leave your app and return to it at a later time.

Crashing or losing the user's progress when the screen rotates between landscape and portrait orientation."

To understand why ViewModel was proposed and how it works, just look at the lifecycle of a ViewModel side by side with the Activity lifecycle.

ViewModel survives configuration changes and is only released when the Activity is finished. Another important usage of a ViewModel, is when you need to share state between Fragments. A ViewModel can outlive each of the Fragments, with its scope bound to the lifecycle of the enclosing Activity.

The ViewModel name comes from an architectural pattern called MVVM (Model-View-ViewModel). Architectural patterns are ways of organizing your code to achieve higher maintainability of your software in the long run. Different patterns arise accordingly to the task being executed, platform, team's size, and other characteristics of the project. I intend to discuss these architectural topics on this blog in the future.

Learn how to create and use a ViewModel in https://developer.android.com/topic/libraries/architecture/viewmodel

3. Room

Using relational databases is an important part of developing applications. Android traditionally has good support for SQLite, a lightweight database manager. SQlite is very useful for persisting and organizing non-volatile data, but to use it you have to face some challenges. It's low-level APIs demands a lot of the developer's time to be used and maintained:

"There is no compile-time verification of raw SQL queries. As your data graph changes, you need to update the affected SQL queries manually. This process can be time-consuming and error-prone."

"You need to use lots of boilerplate code to convert between SQL queries and data objects."

The Room persistence library was created as an abstraction layer that allows developers to have compile-time verification of SQL queries, annotations to reduce boilerplate code, and tools to ease database migrations.

Example of a User Data Access Object with its annotations. Note that insert and delete annotations didn't require writing SQL queries by hand.

@Dao
interface UserDao {
    @Query("SELECT * FROM user")
    fun getAll(): List<User>

    @Query("SELECT * FROM user WHERE uid IN (:userIds)")
    fun loadAllByIds(userIds: IntArray): List<User>

    @Query("SELECT * FROM user WHERE first_name LIKE :first AND " +
           "last_name LIKE :last LIMIT 1")
    fun findByName(first: String, last: String): User

    @Insert
    fun insertAll(vararg users: User)

    @Delete
    fun delete(user: User)
}

Room's training on developer.android.com: https://developer.android.com/training/data-storage/room

4. Paging v3

Whenever you have lots of data coming from a data source, be it an API or a database, usually some kind of pagination is needed to meet speed and bandwidth requirements, for instance. With pagination, only a subset of the data is served (and rendered), and the user can ask for more data later if needed.

"The components of the Paging library are designed to fit into the recommended Android app architecture, integrate cleanly with other Jetpack components, and provide first-class Kotlin support. The Paging library includes the following features:

In-memory caching for your paged data. This ensures that your app uses system resources efficiently while working with paged data.

Built-in request deduplication, ensuring that your app uses network bandwidth and system resources efficiently.

~~Configurable RecyclerView adapters that automatically request data as the user scrolls toward the end of the loaded data.~~ (Recycler view isn't needed anymore on Jetpack Compose 🥳)

First-class support for Kotlin coroutines and Flow, as well as LiveData and RxJava.

Built-in support for error handling, including refresh and retry capabilities."

The following diagram illustrates how Paging fits into the typical architecture of an Android application. Now that we have Jetpack Compose, the PagingDataAdapter is not needed anymore, a composable function watches PagingData state on ViewModel.

Paging v3 library documentation: https://developer.android.com/topic/libraries/architecture/paging/v3-overview

5. Navigation

In the beginning, the Android team created the Activity.

Before Android 3.0 (Honeycomb), the typical android app worked swapping activities and asking for third-party activities to be displayed by the operating system. With the arrival of Android tablets, this abstraction wasn't sufficient anymore. Usually, a tablet can show master and detail views simultaneously, and rewriting the whole app for tablets wasn't an option. Hence, Fragments were created with the mission to be autonomous and combined within Activities, which acted as a wrapper for one or more fragments. The navigation now was mainly changing between app fragments. Any app that has more than one screen needs some type of navigation system, even if done manually without any tooling help.

Navigation on Android isn't a simple task. Managing aspects like the up button™ and back button™, deep linking, fragment transactions and animated transitions, fragment arguments, and a plethora of specificities can be hard. Jetpack Navigation helps to implement navigation in a correct and principled way.

New: On Jetpack Compose, you can project your UI without using Fragments, View, and XML files. Everything is done on Kotlin, including navigation with NavHost and NavController.

Learn to use Navigation with Compose in https://developer.android.com/jetpack/compose/navigation

Hint: The documentation doesn't include the imports needed to complete the training. As navigate(route:String) is an extension function (not included by default in NavController), you may need to add the following import:

import androidx.navigation.compose.navigate

When using popUpTo(route:String), you need to add the second argument inclusive: Boolean that isn't cited in the official documentation. So your code will look like this:

// Pop everything up to the "home" destination off the back stack before
// navigating to the "friends" destination
navController.navigate(“friends”) {
    popUpTo("home") { inclusive = false }
}

// Pop everything up to and including the "home" destination off
// the back stack before navigating to the "friends" destination
navController.navigate("friends") {
    popUpTo("home") { inclusive = true }
}

6. Hilt (Jetpack)

Hilt is a dependency injection library for Android that reduces the boilerplate of doing manual dependency injection in your project. Doing manual dependency injection requires you to construct every class and its dependencies by hand, and to use containers to reuse and manage dependencies.

1.Why dependency injection (DI)?

R. DI makes unit testing easier, as it allows the injection of test doubles instead of implementations. Also, it helps reduce coupling, because it forces the developer to program for an interface, instead of an implementation.

2.Why coupling is bad?

R. Because the code you make today will have to be changed, adapted, maintained by someone (or yourself). When your code is tightly coupled, refactors are hard and any small change may break your system.

3. Does DI cause any adverse effects?

R. Debugging can be harder, because of all the indirections caused by the presence of a dependency injection system. Many DI frameworks have a steep learning curve, a considerable barrier to beginners.

Hilt provides a standard way to use DI in your application by providing containers for every Android class in your project and managing their lifecycles automatically. Hilt is built on top of the popular DI library Dagger to benefit from the compile-time correctness, runtime performance, scalability, and Android Studio support that Dagger provides.

Hilt documentation: https://developer.android.com/training/dependency-injection/hilt-android