DEV Community: Peter Chege

Effortlessly Managing API Keys and Secrets in your android app using the secrets Gradle Plugin

Peter Chege — Mon, 27 Nov 2023 14:08:56 +0000

Introduction

Hello guys 👋👋, welcome back to another article, in our previous article we discussed
how to navigate the obstacles of Navigation Compose.
In this article, we'll learn how to effortlessly manage our API Keys and secrets in our android project using
the secrets Gradle Plugin

Normally when working in our android projects we find ourselves consuming different kinds of APIs which
probably need API Keys to be accessed. Normally we'd want to exclude these API Keys from our version control
for security purpose, so what we do is include the given API Key in our local.properties file generated
by Android Studio which is by default excluded from version control. However, reading from this file in
our project sometimes involves some boilerplate code in our build scripts. Some of the boilerplate would
look something like this

// Read API_KEY for build file 
val API_KEY: String = gradleLocalProperties(rootDir).getProperty("API_KEY")

// Include it as a build field in your build variants
...

So to deal with this issue the Google team came up with a plugin called the Secrets Gradle Plugin
that abstracts that build logic for us and does everything for us behind the scenes. The need for this plugin
arose when they noticed developers need to hide their Maps API Keys when working with Google Maps in their
android projects

Using the secrets plugins is simple... Just add the plugin to your project and apply it to your app module then
it will read from your local.properties file. The read variables will be included in your generated BuildConfig class at
compile time. For more information on customization check our their README.md

Thank you for reading and I hope you learnt something new until next time .....Bye.

Navigating the obstacles of Navigation Compose

Peter Chege — Fri, 08 Sep 2023 16:41:46 +0000

Introduction

Hello guys 👋👋, welcome back to another article, in our previous article
we
discussed how to inspect network traffic using the Chucker dev extension in android.
In this article, I will show you a trick that can save you time when dealing with the nuisances of Navigation Compose

If you've used navigation compose, you may have noticed how sometimes it can
be a headache because it lacks compile time type safety, hence sometimes when
you navigate to a given route, your app crashes.This problem has led to the creation of
type safe navigation libraries like compose destinations, voyager etc.
This can reduce your productivity as may spend time to debug the crash.
Basically, to prevent the reoccurrence such crashes, we should abstract our
navigation definitions through state hoisting. Don't understand what this
means ....read on

Basically, state hoisting is practise in Jetpack Compose where we only expose
state and functions that modify the state to the composable.This results to
having 2 versions of one composable, Stateless and a stateful one.For more
information and the benefits of this practise,
read this article
by me

How we navigate In Jetpack Compose

Normally we navigate in compose by passing the navigation logic to the
onClick lambda where its needed as shown below

Button(
    modifier = Modifier.fillMaxWidth(),
    onClick = {
        navController.navigate(route="login")
    }
) {
      Text(text = "Login")

    }

The problem with this approach is that when if the NavHost where this navController
is defined does not have a route called "login", the app will crash. Normally if
you have one NavHost this won't be the issue since there is only one instance
of the navController(Unless you create a new one in your composable), but when
your app has a bottom Nav bar that requires its own NavHost, this approach can
become an issue since now you have multiple navControllers

Solution

To solve this issue, we can define all necessary navigation definitions in
our NavHost via explicit lambdas or extension functions to the NavController
class. This way we know what NavController has a route definition as shown below

val navController = rememberNavController()

NavHost(
    navController = navController,
    startDestination = Screens.DASHBOARD_SCREEN
    ) {
        composable(route = Screens.LOGIN_SCREEN) {
            LoginScreen(
                navigateToDashBoard = navController::navigateToDashBoard,
                navigateToSignUpScreen = navController::navigateToSignUpScreen,
            )

        }
        composable(route = Screens.SIGNUP_SCREEN) {
            SignUpScreen(
                navigateToLoginScreen = navController::navigateToLoginScreen,
            )
        }
        composable(route = Screens.DASHBOARD_SCREEN) {
            DashboardScreen(
                navigateToLoginScreen = navController::navigateToLoginScreen,
            )
        }
    }

This way we can pass the navigation functions to the composables without explictly
having to define the navigation logic each time we need it. If we get the navigation
logic right top level, we won't need to worry about getting it right when actually
navigating to the various screens.

Once again this won't help much if you have 1 NavHost you will see its benefits if
you have a bottom App Bar in your application

I hope this tricks helps you build better apps using Jetpack compose.
Don't forget to clap for this article and leave a comment for any questions

While you are at it, you can follow my GitHub
profile to see some projects this in concept in practice

Debug and inspect your network requests in android using the Chucker dev extension with Retrofit or Ktor Client

Peter Chege — Fri, 08 Sep 2023 16:40:33 +0000

Introduction

Hello guys 👋👋, welcome back to another article, in our previous article we discussed
how to run migrations in android while also testing them .
In this article, we'll learn how to inspect and debug our network requests in android using the chucker dev extension

As an android developer, we normally usually interact with backend servers via REST APIs.Normally we use
http client libraries like Retrofit and Ktor client. The chucker dev extension gives us an interface that
can help us see all the information about all the requests and responses like the JSON payload and response status codes
etc. In this article we'll see how we can add the extension when using either Retrofit or Ktor client

Add the necessary dependencies

The chucker dev extension is available on GitHub

To start we'll add the necessary dependencies in our build.gradle.kts (App Module) as shown below


    dependencies {
        ... other dependencies
        debugImplementation ("com.github.chuckerteam.chucker:library:3.5.2")
        releaseImplementation ("com.github.chuckerteam.chucker:library-no-op:3.5.2")
    }

The library has 2 variants namely a debug and release implementation. The release implementation is used to disable the
interface window
in production builds of your app so your users can not see the http activity associated with the given app.

After that, we'll proceed in 2 ways depending on the http client you are using

1. Retrofit

When using retrofit, we'll add the following interceptor to our Retrofit instance like shown below


    @Provides
    @Singleton
    fun provideHttpClient(@ApplicationContext context: Context): OkHttpClient {
        return OkHttpClient.Builder()
            .addInterceptor(
                ChuckerInterceptor.Builder(context = context)
                    .collector(ChuckerCollector(context = context))
                    .maxContentLength(length = 250000L)
                    .redactHeaders(headerNames = emptySet())
                    .alwaysReadResponseBody(enable = false)
                    .build()
            )
            .build()
    }

    @Provides
    @Singleton
    fun provideUserApi(
        client: OkHttpClient,
        networkJson:Json,
    ): BloggerApi {
        return Retrofit.Builder()
                .baseUrl(Constants.BASE_URL)
                .client(client)
                .addConverterFactory(
                networkJson.asConverterFactory("application/json".toMediaType()),
                )
                .build()
                .create(BloggerApi::class.java)
    }

In the example above, we are creating an okhttp client that adds the chucker extension as an interceptor. We then provide
that client to the Retrofit instance. In the example above, I am using Dagger hilt

That's really it for installing it using Retrofit.
When you run your app, you should see a notification on your device that will log all different network requests that the
app makes as the user navigates through the app.

2. Ktor Client

To set up chucker using the ktor client,we'll first create http client factory like shown below

class HttpClientFactory {

    fun create(engine: HttpClientEngine) = HttpClient(engine) {

        install(ContentNegotiation) {
            json(
                Json {
                    prettyPrint = true
                    isLenient = true
                    ignoreUnknownKeys = true
                }
            )
        }

        install(DefaultRequest) {
            header(HttpHeaders.ContentType, ContentType.Application.Json)
            header("x-api-key",Constants.API_KEY)

        }

        expectSuccess = true
        addDefaultResponseValidation()
        if (BuildConfig.DEBUG) {
            install(Logging) {
                logger = Logger.DEFAULT
                level = LogLevel.ALL
            }
        }
    }
}

Then we'll then add the following in our app's network Module


    @Provides
    @Singleton
    fun provideChuckerInterceptor(@ApplicationContext context: Context): ChuckerInterceptor {
        return ChuckerInterceptor.Builder(context)
            .collector(ChuckerCollector(context))
            .maxContentLength(250000L)
            .redactHeaders(emptySet())
            .alwaysReadResponseBody(false)
            .build()
    }

    @Provides
    @Singleton
    fun provideHttpClientEngine(chuckerInterceptor: ChuckerInterceptor): HttpClientEngine = OkHttp.create {
        addInterceptor(chuckerInterceptor)
    }


    @Provides
    @Singleton
    fun provideHttpClient(engine: HttpClientEngine): HttpClient = HttpClientFactory().create(engine)

With that you're set to go.
When you run your app, you should see a notification recording all your http activity

I hope this helped you and made debugging your network requests easier

How to migrate your database in android with Room while also testing your migrations

Peter Chege — Tue, 23 May 2023 20:10:06 +0000

Introduction

Hello guys 👋👋, welcome back to another article, in our previous article we discussed
how to run instrumented tests on CI(Github Actions) with firebase test lab.
In this article, we'll learn how to make migrations to our database when our data schema changes

If you're a backend developer or rather have interacted with databases at scale, you're probably familiar
with the concept of migrations especially with relational databases like MySQL or PostgresSQL.

What are migrations

Database migrations, also known as schema migrations, database schema migrations, or simply
migrations, are controlled sets of changes developed to modify the structure of the
objects within a relational database. Migrations help transition database schemas from
their current state to a new desired state, whether that involves adding tables and
columns, removing elements, splitting fields, or changing types and constraints.

Why migrations

When you building app that stores its data on a remote server, the data is probably stored on a database.
As you continue building your app, the needs of the app change over time which i.e more data needs to be stored or
removed. Whatever the case, migrations help us make us adjust our database to keep it updated with the latest data needs

Room in android

In android, we usually use the room library to interact with an SQLite database to model our data for offline
capabilities.As an android developer when you're working on a project then you make changes to an entity data class and
run the app it will probably crash that if you had installed a previous version of the app that had some data in the
database. You will probably see an error message saying that room cannot validate the data integrity .....etc.
A solution to this is to delete the app on your emulator/physical device and install it again. This will automatically
delete the data and the crash will go away. This works but what if your app has active users who have data stored,if you ship
the app to production and the users download the new version they will experience crashes before even they are able to
interact with the app. Migrations will help us avoid such scenarios

How to get started with migrations

For this article I prepared a small project to demostrate this concept
You can find it on GitHub here.

The project has 2 branches

before-migration - This is before we apply the migration
after-migration - This is after we apply the migration

The project is a simple app that lists people.The project uses Koin for DI as it is lightweight. For the sake of simplicity, I added a button that
will automatically generate the data for us and display it to simulate the addition of a person
The data class of the Person entity is as follows

@Entity(tableName = "person")
data class PersonEntity(
    @PrimaryKey
    val personId:String,
    val firstName:String,
    val lastName:String
)

Suppose we would like to add a field called email, we could add it then run our app but as mentioned earlier
the app will crash if there was existing data. To modify the data class we will just add the email field as shown
below

@Entity(tableName = "person")
data class PersonEntity(
    @PrimaryKey
    val personId:String,
    val firstName:String,
    val lastName:String,
    @ColumnInfo(defaultValue = "N/A")
    val email:String,
)

We add the ColumnInfo annotation to define a default value since this is a new field so that room can resolve it to the
default value when the email is not found.

To start applying the migration, we modify the Database class as follows


// Database before migration 
@Database(
    entities = [
        PersonEntity::class,
    ],
    version = 1,
    exportSchema = true
)
abstract class RoomMigrationAppDatabase : RoomDatabase() {
    abstract val personDao: PersonDao;
}

// Database after migration
@Database(
    entities = [
        PersonEntity::class,
    ],
    version = 2,
    exportSchema = true,
    autoMigrations = [
        AutoMigration (from = 1, to = 2)
    ]
)
abstract class RoomMigrationAppDatabase : RoomDatabase() {
    abstract val personDao: PersonDao;
}

As you can see we increment the database version, then we add the autoMigrations block to migrate the database
N/B: Make sure you have exportSchemas=true and have a schemas directory under your app module so that room can
generate the necessary SQL for your database.The schemas will help us when testing the database migrations

That's just about it really.

Note that this is a simple migration, for a real world app you'd probably need more complex migrations.
Check the android documentation here
for such.

Testing our migrations

Migrations are sensitive concept and if not done right could lead to a lot of crashes amongst your users if not done
correctly. That is why we will test our migrations to ensure they run correctly

Before we start make sure you add the following the build.gradle.kts (App Module)

android {
    ....
    sourceSets {
        // Adds exported schema location as test app assets.
        getByName("androidTest").assets.srcDir("$projectDir/schemas")
    }
}

Note I'm using kotlin DSL, if you are using groovy make sure to confirm the syntax.
Above, we are just making sure the exported schemas are used test assets in the androidTest sourceSet

Then we add the room testing dependency

    dependencies {
        ..... Other dependencies
        androidTestImplementation("androidx.room:room-testing:2.5.1")
    }

Then create a Migration class in the normal source set and add the following

class Migrations {

    companion object {
        val M1_2: Migration = Migration(startVersion = 1, endVersion = 2) { database ->
            database.execSQL("ALTER TABLE person ADD COLUMN email TEXT")
        }
    }
}

This will be used to test the migration by executing the given SQL, in the example above we are adding
the email field to the person table

After that we create MigrationsTest.kt under the androidTest sourceSet and add the following code

@RunWith(AndroidJUnit4::class)
class MigrationsTest {


    private val TEST_DB = "room-migration-app-test"

    @get:Rule
    val helper: MigrationTestHelper = MigrationTestHelper(
        InstrumentationRegistry.getInstrumentation(), RoomMigrationAppDatabase::class.java
    )


    @Test
    fun migrate1To2() {
        val db = helper.createDatabase(TEST_DB, 1)
        db.close()
        helper.runMigrationsAndValidate(TEST_DB, 1, true, Migrations.M1_2)
    }
}

Above, we first declare a migrationTestHelper rule for the test case. The room testing library has a MigrationTestHelper
class to help us test migrations.In the test case, we define we want to test the migration from version 1 to 2
The test case will first create the database at version 1 then migrate it to version 2 as per the SQL we define above.

If the test case passes, your migration was successful.You can now proceed with your app

Its worth noting that when you modify your entity data classes, you should just keep on incrementing the database version
while also adding tests to validate those migrations before shipping your app to users

For more information, check the official documentation here

Also don't forget the code from the snippets above is available here

I hope you enjoyed the article and learnt something new.

I hope to see you next time, bye. 👋👋👋

Running Instrumented Tests on Github Actions with Firebase Test Lab

Peter Chege — Mon, 08 May 2023 19:21:23 +0000

Hello guys welcome back to another article, In the previous article we learnt about generating UI state
in android.
In today's article we will learn how to run instrumentation tests on GitHub actions via
Firebase Test Lab

Normally when we set up CI/CD pipelines we usually follow 3 general steps
namely: Build,Test and Deploy.
In android development we have different type of tests

Unit Test
Instrumented Test

Unit Test usually run on the JVM and only test a single portion of your code
i.e a class or a function

Instrumentation tests usually run on an android device (Physical or Emulator).These
tests usually need specify android components to run hence the need for an android
device

On a CI/CD platform like github actions running unit tests is usually straight foward since
you just setup the JDK and run the gradle command as shown below

on:
  push:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Set up JDK
        uses: actions/setup-java@v1
        with:
          java-version: 11
      - name: Cache gradle
        uses: actions/cache@v1
        with:
          path: ~/.gradle/caches
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }}
          restore-keys: |
             ${{ runner.os }}-gradle-    

      - name: Run Unit Tests with Gradle
        run: ./gradlew test

But when it comes to instrumented test it is a bit tricky because we don't have a android emulator
on our CI server.While there are a few solution to this like using this
action on a macOS runner

The solution I am about share makes it so easy

In comes Firebase Test Lab

As per the description
, Firebase Test Lab is a cloud-based app testing infrastructure that lets you test your app on a range of devices and configurations,
so you can get a better idea of how it'll perform in the hands of live users.

Assuming you have an android project in which you have instrumented tests already written you can proceed

1. Setup a firebase project

For this you need to set up you android app with a firebase project
For more info on how to get started check here

2. Set up your firebase Test Lab Service Account

For use to use the firebase test lab services we need a service account file to help the service
authenticate us.
To do that we need to go to the Google cloud console
here and create a service account (Every firebase project is
essentially a Google cloud project). To create a service account to be used in a CI system
check here (In the example above they use Jenkins
but the same can be used with github actions)

3. Build your androidTest Apk

Once you have defined a device configuration, you should now build and androidTest apk. The androidTest apk
packages all of our tests defined in the androidTest source set into an apk that will be used to
execute the tests. The androidTest apk is usually upload to firebase test lab and the apk is executed
in the cloud.

4. Define a device configuration

For use to execute the apk we need a device. We need to specify some device configuration to test firebase test lab
what kind of device we want our apk to run on. Note that you can run your tests on multiple different types
of devices just to make sure you app runs correctly in different devices

To define a device configuration we create a YAML file in the root of our project
e.g android-device.yml

In there we add the following

android-pixel-4:
  type: instrumentation
  app: app/build/outputs/apk/debug/app-debug.apk
  test: app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk
  device:
    - model: redfin
      version: 30
      locale: 'en'
      orientation: portrait

In the above example we create a device configuration called android-pixel-4 with the following settings :

The app- key are a path to the actual debug apk
Test - Path to the android test apk
device - Device specific settings
- Model - Device ID of a device supported on firebase test lab. For more device options check here
- Version - Version of the android OS
- Locale -
- Orientation - Orientation of the device when the tests run

5 : Run our tests

Now we are done with the setup, let's run our tests
To run our tests on our workflow add the following to your workflow file
We use this action
to access the firebase test lab APIs in our CI environment

      - name: Build App with Gradle
        run: ./gradlew build

      - name: Build Android Test APK
        run: ./gradlew assembleAndroidTest

      - name: Run Android tests on Firebase Test Lab
        uses: asadmansr/Firebase-Test-Lab-Action@v1.0
        with:
          arg-spec: 'android-device.yml:android-pixel-4'
        env:
          SERVICE_ACCOUNT: ${{ secrets.FIREBASE_TEST_LAB_SERVICE_ACCOUNT }}

The arg-spec specifies the device we defined in the android-device.yml appended with the device
settings. We then put the service account in our GitHub action secrets and reference it in the file

If all is good we should see our test results in the firebase console like this

Troubleshooting

If for some reason you workflow fails at the firebase test lab stage, check the log messages, they can help in
deciphering the problem but here are a few possible causes :

You wrongly configured the service account i.e. you gave the wrong permissions when creating the service account. Go over the instructions again
You probably defined a wrong path to your apks
The tests probably were uploaded but failed, Check your tests
You passed a model id for your device configuration

I hope you liked this article and I hope it helped you run your instrumentation test more reliably on your CI workflow

For the example project I used here you can find it on GitHub
here

You can also follow me on github and twitter

See you next time 👋👋

Generating UI state in android for jetpack compose using sealedX library

Peter Chege — Sun, 07 May 2023 16:20:51 +0000

Hello guys, welcome back .In the previous article,
we learnt about stateful and stateless composables
and how to use them. In this article, we are going to learn how to generate UI states to avoid repetition

In android, we normally wrap our UI state in data classes to have a single point of reference when is comes to
modifying the state. A common type of state we use when building our app is as shown below


data class HomeScreenState(
        val msg: String = "",
        val posts: List<Post> = emptyList(),
        val success: Boolean = false,
        val errorMessage: String = "",
        val isLoading: Boolean = false,


        )
private val _state = mutableStateOf(HomeScreenState())
val state: State<HomeScreenState> = _state

The data class above wraps all our UI state in one class.The state here is for a screen that
fetches data from a remote API and displays the result on the screen. If your app is mostly presentational and
depends on data from remote APIs, Then most of your screen states look like this.
These types of data classes become repetitive, and we don't like repetitive code so what should we do ?

IN comes the sealedX library

SealedX is a kotlin library by github_skydoves
that generates data classes based of a given input. This library helps us prevent those repetitive data classes by
generating them for us at build time. The library uses KSP to generate the necessary code for us

How do we use it ?

First of all make sure to follow the installation steps defined in the project readme
As you may have already read, there are 2 annotations ExtensiveSealed and ExtensiveModel

ExtensiveSealed is an annotation that is used to anotate the sealed interface for our general UI state
The most common example something like this

sealed interface UiState {
  data class Success(val data: Extensive) : UiState
  object Loading : UiState
  object Error : UiState
}

When fetching data for a screen these are usually the 3 states we work with

The ExtensiveSealed annotation usually takes an array of parameters for the classes that need UI state to be generated
as shown below

@ExtensiveSealed(
    models = [
        ExtensiveModel(HomeScreen::class),


    ]
)
sealed interface UiState {
data class Success(val data: Extensive) : UiState
object Loading : UiState
object Error (val message:String): UiState


data class HomeScreen(
    val posts:List<Post>
)

Above the HomeScreen data class contains the expected data which is passed to the Extensive generic type
Note : The keyword Extensive is from the library and is used as a placeholder for the given data class
provided in the models array.

The ExtensiveModel keyword takes a class definition as an argument and is passed
as an element to the models arrays in the ExtensiveSealed annotation

So what this does it generates a sealed Interface for each ExtensiveModel declaration like below


public sealed interface HomeScreenUiState {
    public data class Error(
    public val message: String,
    ) : HomeScreenUiState

    public object Loading : HomeScreenUiState

    public data class Success(
        public val `data`: HomeScreen,
    ) : HomeScreenUiState
}

The name of the sealed interface will be name of the class passed to the ExtensiveModel appended with the name of the general
sealed interface e.g. HomeScreen + UiState = HomeScreenUiState

If you pass an array of 3 ExtensiveModel instances , 3 sealed interfaces will be generated
and so on

Once you have declared you finshed declaring the ExtensiveSealed and ExtensiveModel, its now time to generate them
To generate the classes , just rebuild your project and you will see the generated classes in your project

Let's start using our generated classes



@HiltViewModel
class HomeScreenViewModel @Inject constructor(
    private val postRepository: PostRepository,
    ) : ViewModel() {

    private val _uiState = MutableStateFlow<HomeScreenUiState>(HomeScreenUiState.Loading)
    val uiState = _uiState.asStateFlow()


    init {
        getPosts()

    }


    private fun getPosts() {
        viewModelScope.launch {
            _uiState.value = HomeScreenUiState.Loading
            try {
                val response = productRepository.getAllProducts()
                _uiState.value = HomeScreenUiState.Success(data = HomeScreen(posts = response.posts))

            } catch (e: HttpException) {
                _uiState.value = HomeScreenUiState.Error(message = "Please check your internet connection")


            } catch (e: IOException) {
                _uiState.value = HomeScreenUiState.Error(message = "Server down please try again later")
            }
        }
    }

}

Above we just create our view model and fetch the data from our repository and store it into state
We then consume our state in our composable like this

fun HomeScreen(
navController: NavController,
navHostController: NavController,
viewModel: HomeScreenViewModel = hiltViewModel(),
) {
    val uiState = viewModel.uiState.collectAsStateWithLifecycle()

    HomeScreenContent(uiState = uiState.value)




}

fun HomeScreenContent(
    uiState:HomeScreenUiState
){
    Box(modifier = Modifier.fillMaxSize()) {
        when (uiState) {
            is ProductsUiState.Loading -> {
                // show something when loading


            }
            is ProductsUiState.Error -> {
                // show the error message


            }
            is ProductsUiState.Success -> {
                // show the posts

            }

        }
    }
}

Above we just consume the data and show something based on the current state
I am using 2 composable. The reason is explained in this previous article
here

Limitations of this library

Currently, the library has a bug where when you try to define more than one sealed interfaces with the library it will append combine all the states from all the sealed interface instances annotated with the ExtensiveSealed keyword into the generated files hence it will cause a compilation error if you declare the same state in more than one instance I opened an issue in the repo hoping it will be fixed but until then try to only declare one instance annotated with the ExtensiveSealed

N/B: Note this is only a solution for when it comes to data fetching for multiple screens. If your app has complex states
then this might not be ideal for your project

Thank you for reading and I hope you learnt something new until next time .....Bye see you next time

Stateful and stateless components in Jetpack compose

Peter Chege — Sun, 30 Apr 2023 14:08:02 +0000

Keep 2 versions of the same composable:Stateless and Stateful

What are stateful and stateless composables in Jetpack compose ?

A stateless component is a component that doesn't maintain any internal state.
It's purely a function of its inputs, meaning that the output of the component is solely determined by the props that are passed to it.
These components are also known as "dumb components" because they don't have any logic beyond rendering what
they're given.

On the other hand, a stateful component is a component that does maintain an internal state.
It's a function of its inputs as well as its own internal state.
Stateful components are also known as "smart components" because they have
logic beyond rendering what they're given. They can respond to user events,
perform complex calculations, and modify their own state, which can trigger a re-render of the component.

An example of a stateful Composable

@Composable
fun Counter() {
    var count by remember { mutableStateOf(0) }

    Column {
        Text("Count: $count")
        Button(onClick = { count++ }) {
            Text("Increment")
        }
    }
}

@Composable
fun HomeScreen(
    viewModel:HomeScreenViewModel = hiltViewModel(),
) {
    val posts = viewModel.posts.collectAsStateWithLifecycle()
    LazyColumn(
        modifier = Modifier.fillMaxSize()
    ){
        items(items =posts){ post -> 
            Post(post = post)
        }
    }
}

In the 1st composable the state is stored in the composable.
This is said to be stateful since the composable stores its current state

In the 2nd composable the state is stored in a viewModel. Normally this is what you
usually do in project

While this approach works fine there are a few issues that arise
They include

Testing: Testing stateful composables can be more difficult because they require you to manage and manipulate their internal state. This can make it harder to write tests that are reliable and cover all possible scenarios.
They break previews: Stateful composables cannot be easily previewed in
development mode since they for them to be initialized the need a customview model instance
which will in turn lead to a custom repository for the view model and custom mock data
for the data sources (local or remote etc)

What is the solution then ?

In comes stateless composables. As discussed earlier stateless composables do not manage state they simply get
state passed on to them. When the UI needs to make changes we can pass them to the necessary functions as parameters

But we will need to eventually instantiate the view model right ?

Yes. We will need 2 different versions of the same composable, A stateless and stateful one then
we use the stateless one for testing and previews.

Here's an example

An example of a stateful Composable

//Stateful version of the composable
@Composable
fun HomeScreen(
    viewModel:HomeScreenViewModel = hiltViewModel(),
) {
    val posts = viewModel.posts.collectAsStateWithLifeCycle()
    HomeScreenContent(posts = posts.value)
}

//Stateless version of the composable
@Composable
fun HomeScreenContent(
    posts:List<Post>
) {
    LazyColumn(
        modifier = Modifier.fillMaxSize()
    ){
        items(items = posts){ post -> 
            Post(post = post)
        }
    }
}

Above is the stateful and stateless version of the composable. It a good practice to prefix
the stateless composable with "Content" then pass it to the stateful version and pass the state
and the state modifiers functions for example in this case you could add a like post function and pass its
implementation to the HomeScreenContent composable.

NB: This should only to apply to screen level composables since the other composables in the
screen composable are already statelss

I recently learnt about this new concept and decided to share it
For more examples check how it was implemented in the following repos

Philip Lackner also did a video addressing the same issue
Video Link

I hope this article helped you in a way :)