[NO-TICKET] Update dependencies and sample project to use ViewBinding #2
Conversation
|
👋 @emeruvia Let me know if you need any help. |
…ds a generic ViewBinding parameter for the user to inject the generated ViewBinding file. This gives the option for users wanting to use ViewBinding a failsafe way of doing so, while keeping the regular ComponentView class untouched. - Create a example-viewbinding module, which showcases how to use ComponentViewBinding - Remove kotlin-extensions. This turns off kotlin synthetics - Update library compileSdkVersion 29 -> 31 - Update library buildToolsVersion 29.0.3 -> 30.0.3 - Update library dependencies, recyclerview updated 1.1.0 -> 1.2.1 - Remove JCenter in favor of mavenCentral - Update gradle version 4.0.1 -> 4.0.2
emeruvia
force-pushed
the
feature/viewbinding
branch
from
f6e7e63 to
ac33fe0
Compare
|
Hi @flopshot 👋 With this PR, I've also an Let me know what you think! |
| * This forces any class implementing the ComponentViewBinding to add the respective ViewBinding file. | ||
| */ | ||
| abstract class ComponentViewBinding<Component: com.seannajera.dkouple.Component, ViewBinding>( | ||
| view: View | ||
| ) : ComponentView<Component>(view) { |
There was a problem hiding this comment.
question Is there a reason the library would want to force someone to use ViewBinding over other view inflating methods?
| import com.seannajera.dkouple.DKoupleView | ||
| import com.seannajera.dkouple.FactoryView | ||
|
|
||
| @SuppressLint("NonConstantResourceId") |
There was a problem hiding this comment.
nice-to-have AGP 8 will break the code generation feature of DKouple (they keep delaying this change so they might delay it further, but one should assume this time it will happen). This won't break the reflection based layout id lookup from the annotation at runtime in the adapter nor will it break a non-generated factory.
I've never profiled the annotation reflection for performance, but any performance hit was necessary to make the code generation work as well as to make the api look nicer.
Now that annotations won't work for that use case, it would be nice to redesign DKouple to not use them. I'd love to explore using KSP instead which would be WAY easier to maintain than an annotation processor.
This could be a part of a larger/separate issue.
With Kotlin synthetics being deprecated, sooner or later we will want to update our projects to use ViewBinding instead.
This PR updates the sample project to use ViewBinding instead of Kotlin synthetics. It also updates the library dependencies.