I am trying to use Room with compose and kotlin. I know there is compability issue with

kapt

and

compose

and so that it throws

backend IR

error. But now in build gradle file i removed below line and it worked.

buildFeatures {
        compose true
}

Now even removing this line I am able to call compose function and load ui. So, what does this line means and its purpose.

IIRC, I believe that you will find that you cannot recompose your UI. It renders initially, but changes in the states of models and stuff will not cause the UI to change.

I believe what Mark says is correct. Keep in mind that it should be possible to put your Room (or rather, kapt-dependent) code in a module that does not enable Compose, but enables kapt, and your Compose code in a different module that depends on that module. Per this comment on the YouTrack issue: https://youtrack.jetbrains.com/issue/KT-34583#focus=streamItem-27-3901882.0-0 I haven't tried this myself, but it sounds likely to work.

I managed to use Room in my playground app by putting room in a different module, it seems to work in this respect https://github.com/fluxtah/memset

Nice. 👍

@Mark Murphy I wrote this piece of code in mainActivity.

MaterialTheme {
    val value = +state { 0 }
    Column {
        Greeting(value.value.toString())
        Button(text = "Click", onClick = {
            value.value += 1
        })
    }
}

And on every click value is changing

try moving that logic into a

@Composable

function and see what happens (or is it in a

@Composable

function already?)

It is already in setContent

no, I mean pulling it out into a separate function:

MaterialTheme {
  renderGoodStuff()
}

@Composable
fun renderGoodStuff() {
    val value = +state { 0 }
    Column {
        Greeting(value.value.toString())
        Button(text = "Click", onClick = {
            value.value += 1
        })
    }
}

Yeah, write now I tried this also and it is working

🤷 OK, then I guess I do not know what that

buildFeatures

is enabling -- sorry!

Your example works because on every change the whole tree will be recomposed. You will notice heavy performance issues if you keep the compiler disabled. It's also not possible to conditionally call composables without the compiler.

@Manuel Wrage Yes, you are right. I got this error

java.lang.IllegalStateException: Expected a group start

when disabled the compose feature.

Yeah, depends on how much you wanna modularize, too. Ground rule (for now, while they're working on fixing the incompatibility), as long as you don't have kapt and Compose enabled in the same module, you should be good. In a larger project, I'd probably try to make sure JSON models (e.g. Moshi or kotlinx.serialization or whatnot) aren't exposed out of any kind of repository layer, and so to keep them in their own module would make some sense to me. But if you wanna modularize by feature more, then you'd maybe have repositories as part of a feature (a

UserRepository

in the users module, for instance), so … I guess it just depends on preference. 😛

@amar_1995 personally I would add them in a separate module, if you want to use the same model you could put that model also in its own module so it can be shared with data and maybe

:net

module but again this is personal, @sindrenm makes some great points about modularisation, at my company we tend to modularise by feature so often we have an

api

counterpart such as

feature-search

could have a

search-api

when we want to share its API functionality with other feature modules

Mark is right. I had an issue before where the UI did not recompose on state change just to find out that i missed enabling compose under buildFeatures.