It seems that there is not going to be support for...

# ksp

[agrosner]

It seems that there is not going to be support for databinding with ksp.

Is there a community effort to make a ksp compliant version?

We have a large app with a few modules that are in databinding and won’t be redone or removed for quite some time.
We want to use Anvil for its ability to skip kapt and generate dagger factories purely through kotlinc. However, we lose that ability to do (and must go back on KAPT) when our modules include the databinding compiler (and actually use it more than converting to viewbinding).

[agrosner]

if not a community effort, is the source code for the databinding compiler public? I may look into replicating its generated code functionality if its not a crazy lift

[wasyl]

I’d be very interested to know if you find a way to use KSP with DataBinding. I think decision to not support KSP with DataBinding is a poor one, and I think Yigit/Google underestimates effort it takes to migrate applications to Compose in the real world. And that’s ignoring the fact that many apps don’t need to be migrated because they’re also in maintenance mode.
Already KAPT causes tremendous issues for us with caching and build times alone 😕

Rant over, DataBinding source code is public but I’m not sure how easy it would be to fork it, as it’s connected to AGP and AS a lot: https://cs.android.com/androidx/platform/frameworks/data-binding

[agrosner]

ah thank you for the link.
yeah exactly. our app is pretty large with a lot of features in maintenance mode while we build out new versions of existing features. but having ksp in those legacy ones will just make everyone more productive based on build times alone!

[yigit]

hey, sorry about this.
It is a very large effort so i don’t think it can be done as a community effort.

We don’t take this decision lightly but it is a lot of work and prioritizing it over other stuff is really difficult, knowing that it is not the future (same goes for any View related stuff)

Furthermore, the way i look at “maintenance apps” is that they won’t bother to migrate to KSP if they don’t bother to migrate to compose. Maybe I’m wrong.

My only concern was if KAPT gets removed, then we would have to do something. That doesn’t seem like in the horizon. And if ever becomes the case, it is likely a better option to spend resources on keeping KAPT working than migrating databinding to KSP

[agrosner]

Thanks Yigit for the response!

Furthermore, the way i look at "maintenance apps" is that they won't bother to migrate to KSP if they don't bother to migrate to compose. Maybe I'm wrong.

I’m speaking in terms of maintenance “modules”. We still have to build and cache them. From clean, buildSrc changes, or cache invalidations, it then has to rerun kapt, stubs, etc. So moving to KSP in these modules would be ideal even if the source code is not changing (and dont think it would even need to).

t is a very large effort so i don't think it can be done as a community effort.

Not sure if I agree with this statement. Get enough support from companies with legacy module apps, or just a couple of bright individuals who can reverse engineer (with the source) probably could whip up something that works for 95% of use cases. Maybe im an optimist 😄

My only concern was if KAPT gets removed, then we would have to do something. That doesn't seem like in the horizon.

true. I dont see that either. theres wayyy too many projects im sure will have KAPT until the end of Android.

[yigit]

it is really difficult.
aside from actual # of code changes, KSP and KAPT has subtle differences and they are not always trivial to foresee/fix. Sometimes, it is an actual fix (e.g. KSP getting better nullability information) that breaks existing code that should’ve been broken (so requiring developer to do something on a maintenance project).
Not saying it is not doable, definitely is but it is a lot of headcount that can be spent on better areas.
Note that, the bar for us to put something on the maintenance mode is very high because people usually pick first party solutions due to the long term support guarantees. Which is also why we keep it working (it is still a lot of work due to never ending gradle changes) but that is minimum we have to do. Migrating to KSP and making it faster unfortunately doesn’t make the cut.