ViewBinding support #325

nashcft · 2020-02-22T01:18:04Z

This pull request is for discussion in #322

Create library-viewbinding module for ViewBinding support
Create example-viewbinding module for example application using library-viewbinding

I created these modules based on library-databinding/example-databinding.

nashcft · 2020-02-22T01:23:12Z

build.gradle

    ext.sdkVersion = 28
    ext.minimumSdkVersion = 14
-    ext.databinding_version = '3.2.0'
+    ext.databinding_version = '3.5.3'
+    ext.viewbinding_version = '3.6.0-rc03'


I separated library version for ViewBinding from one for DataBinding because DataBinding above 3.6.0 needs the dependency of ViewBinding library (androidx.databinding:viewbinding).
I think databinding_version and viewbinding_version can be merged when 3.6.0 stable has been released.

3.6.0 has now been released

Thanks for the heads up! I already updated the version of viewbinding at 1aace20.

I did not update the version of databinding because of the class declaration change of ViewDataBinding [1][2], but should I also update it to 3.6.0 and merge the variables databinding_version and viewdatabinding_version to one in this pull request?
When I briefly checked behavior of the example app with Android Gradle Plugin 3.5.3 using library-databinding with databinding libraries 3.6.0, no apparent problem was found.

[1] https://androidx.tech/artifacts/databinding/databinding-runtime/3.5.3-source/androidx/databinding/ViewDataBinding.java.html
[2] https://androidx.tech/artifacts/databinding/databinding-runtime/3.6.0-source/androidx/databinding/ViewDataBinding.java.html

nashcft · 2020-02-22T01:33:50Z

library-viewbinding/src/main/java/com/xwray/groupie/viewbinding/BindableItem.java

+ *
+ * @param <T> The ViewBinding subclass associated with this Item.
+ */
+public abstract class BindableItem<T extends ViewBinding> extends Item<GroupieViewHolder<T>> {


I think it is OK that the names BindableItem and GroupieViewHolder is same as the corresponding classes in library-databinding because they have different package path. If Adding some prefix is preferable, it seems consistent to me that adding it to the classes in both modules.

ViewBinding and DataBinding both are supposed to co-exist in a project.
There is a possibility of them being used in the same file (kotlin file with multiple Item class definition)
In such cases, one of the class usage will have to be fully qualified, because of the same name.
I also understand that renaming BindableItem is not a good idea for the existing users.

Thanks for your review :)

As I commented below, BindableItem<T extends ViewBinding> should work not only with ViewBinding classes but also with DataBinding classes. So if an app which enables both DataBinding and ViewBinding want to use groupie with its extension library, depending only on library-viewbinding satisfies its demand and collision of class name will not happen.

binding library extension to be used

DataBinding only groupie-databinding

ViewBinding only groupie-viewbinding

Both DataBinding and ViewBinding groupie-viewbinding

This can probably work the other way around.

binding library extension to be used

ViewBinding only groupie-viewbinding

Both DataBinding and ViewBinding groupie-databinding

We will need to update BindableItem<T extends ViewDataBinding> to BindableItem<T extends ViewBinding> in the groupie-databinding artifact.

But we still need to change the abstract method

@NonNull protected abstract T initializeViewBinding(@NonNull View view);

to

@NonNull protected T initializeBinding(@NonNull View view) { return DataBindingUtil.bind(view) }

This should be overridden with custom implementation when using ViewBinding.

We will need to update BindableItem<T extends ViewDataBinding> to BindableItem<T extends ViewBinding> in the groupie-databinding artifact.

This requires the users of groupie-databinding to update Android Gradle Plugin >= 3.6.0 (alpha11) after the update of groupie including ViewBinding support, but I think this may be OK if announcing that the update includes breaking change 👀
In this case, we don't have to add another module, and what to do is to change groupie-databinding to support all of above use-case.

But we still need to change the abstract method ... This should be overridden with custom implementation when using ViewBinding.

This change cannot pass compile because T does not always extends ViewDataBinding, so the user should always override initializeViewBinding even if they use only DataBinding.

This change cannot pass compile because T does not always extends ViewDataBinding, so the user should always override initializeViewBinding even if they use only DataBinding.

In a project with hundreds of Item classes, It will be a nightmare.

Yes, so I don't think adding the consideration to ViewBinding to existing groupie-databinding is good idea and I'd like to add new library (= groupie-viewbinding in this pull request) for the support to both ViewBinding and DataBinding because new library with new feature will not cause breaking change for users of the existing library.
If you are also concerned with the migration from DataBinding-only to both DataBinding and ViewBinding, and you don't want to change existing Item classes extending current BindableItem, then we have no other choice than to use reflection to get bind method from type parameter T. I want to avoid using reflection if possible.

nashcft · 2020-02-22T02:03:53Z

library-viewbinding/src/main/java/com/xwray/groupie/viewbinding/BindableItem.java

+    @NonNull
+    protected abstract T initializeViewBinding(@NonNull View view);


Added an abstract method for providing ViewBinding instance as @lkishor suggested in #322 .

nashcft · 2020-02-22T10:12:55Z

I realized that library-viewbinding should support DataBinding as well as ViewBinding, because from 3.6.0 ViewDataBinding implements ViewBinding so subclasses of ViewDataBinding are assignable to the type parameter of public abstract class BindableItem<T extends ViewBinding> ....

Current library-viewbinding does not work well with DataBinding because I removed a method call of ViewDataBinding#executePendingBindings from BindableItem. I will fix this soon.

lkishor · 2020-02-22T15:42:40Z

library-viewbinding/src/main/java/com/xwray/groupie/viewbinding/BindableItem.java

+        if (binding instanceof ViewDataBinding) {
+            ((ViewDataBinding) binding).executePendingBindings();
+        }


This will certainly help users who want to use both DataBinding and ViewBinding.
The only downside I see here is, even though the user wants to only use ViewBinding, he will still have to add data-binding as a dependency for this code to even compile.
What are your thoughts?

Oh, I didn't check that case. Thank you for the pointing :)
Hmm... how about changing dependency declaration for databinding-runtime and databinding-common from compileOnly to implementation? This allows the user to use groupie-viewbinding artifact without enabling DataBinding in their build.gradle.

Changing to implementation could solve the compile issue.
But this still adds two extra dependencies databinding-runtime, databinding-common (for users only using ViewBinding), just because we library authors chose to implement it this way.
And no one loves extra dependency, It will come up as another issue later:

Why the heck did I get DataBinding when I add library-viewbinding to my project?

I'm sorry for late reply.

Indeed the dependencies to data binding libraries are redundant for the users only using View Binding, but these are necessary for this library to care about all possible use cases for the safety.
As I commented above, <T extends ViewBinding> accepts the classes generated by Data Binding, which are subclasses of ViewDataBinding, because ViewDataBinding implements ViewBinding since 3.6.0. This means even if we don't intend to support Data Binding in groupie-viewbinding and don't add the implementation pointed in this comment thread, users CAN use this library with Data Binding, and sometimes it doesn't work (for detail, see the pages listing below).

https://stackoverflow.com/questions/53043412/android-why-use-executependingbindings-in-recyclerview

https://medium.com/androiddevelopers/android-data-binding-recyclerview-db7c40d9f0e4

https://developer.android.com/topic/libraries/data-binding/generated-binding

I prefer that the APIs of libraries are designed to prevent wrong usage because API definition is the only way to force its usage, and it is impossible to implement to exclude ViewDataBinding and its subclasses in compile time when considering the implementers of ViewBinding, so I added the consideration for Data Binding in the new library to support Data Binding as a special variation of View Binding.

I rather we do not force databinding on users who want to use viewbinding. I appreciate you wanting to code the library defensively but I think it's more accurate to have most users of this library not get an extra dependency just because some users might need it.

@nashcft I still think this should be removed in order to merge this PR.

DataBinding APIs are needed even when the user enables only ViewBinding

aoben10 · 2020-03-23T15:09:59Z

@ValCanBuild Do you know when this will be merged?

ValCanBuild

First off - massive thanks for your work on this @nashcft. Apologies for the late review, but the time I can spend on Groupie has sadly been reduced this year.

Now, for the review. Apologies, I am asking for quite a bit.

Can you please update the Readme with an example of how to use Groupie with ViewBinding?
In view of modernizing the examples could you convert the example-viewbinding project to Kotlin?

It seems to me that with ViewBinding 3.6.1 we would no longer need the databinding support would we? Anyone who uses databinding 3.6.0+ in their project should just end up using the viewbinding variant instead?

If the above is true, then please deprecate all classes in library-databinding with comments for people to switch to viewbinding and we'll end up removing it in a few versions.

ValCanBuild · 2020-03-26T13:49:58Z

build.gradle

@@ -7,10 +7,11 @@ def testResultsDir = "${rootProject.buildDir}/test-results"
 buildscript {

    ext.kotlin_version = '1.3.60'
-    ext.android_plugin_version = '3.5.2'
+    ext.android_plugin_version = '3.6.0'


please make this 3.6.1

udpated 🚀 (1c9774e)

ValCanBuild · 2020-03-26T14:00:45Z

build.gradle

    ext.sdkVersion = 28
    ext.minimumSdkVersion = 14
-    ext.databinding_version = '3.2.0'
+    ext.databinding_version = '3.5.3'
+    ext.viewbinding_version = '3.6.0'


this to 3.6.1 too please

udpated 🚀 (1c9774e)

ValCanBuild · 2020-03-26T14:08:54Z

example-viewbinding/build.gradle

+dependencies {
+    implementation project(':library-viewbinding')
+    implementation project(':example-shared')
+    implementation "androidx.appcompat:appcompat:1.0.2"


for this to be a more up to date example, please use all latest library versions here

updated ✅(98caac2)

ValCanBuild · 2020-03-26T14:13:17Z

library-viewbinding/src/main/java/com/xwray/groupie/viewbinding/BindableItem.java

+        if (binding instanceof ViewDataBinding) {
+            ((ViewDataBinding) binding).executePendingBindings();
+        }


I rather we do not force databinding on users who want to use viewbinding. I appreciate you wanting to code the library defensively but I think it's more accurate to have most users of this library not get an extra dependency just because some users might need it.

NitroG42 · 2020-03-26T15:26:33Z

Would there be any way to drop ?

    override fun getLayout(): Int {
        return R.layout.mylayout
    }

and use instead:
MyLayoutBinding.inflate(view)

I know that is probably difficult but I think this is wht makes the viewbinding library great.

nashcft · 2020-03-28T12:33:14Z

Welcome back and thanks for your review, @ValCanBuild :)

It seems to me that with ViewBinding 3.6.1 we would no longer need the databinding support would we? Anyone who uses databinding 3.6.0+ in their project should just end up using the viewbinding variant instead?

DataBinding can be used with the ViewBinding support if keeping the implementation we are discussing on this thread. In example-viewbinding we use both DataBinding and ViewBinding, and it works well. Of course using only DataBinding with the ViewBinding support also works.
But, I'm not sure we have to deprecate library-databinding APIs and remove DataBinding support in the future version. Maybe the discussion from this comment is related.

nashcft · 2020-03-29T11:08:28Z

@NitroG42
Thanks for your suggestion, but it seems better to discuss it as another topic because dropping Item#getLayout means breaking change of the existing API in core module and it affects other classes 👀

Would you mind creating a new issue about the suggestion?

ValCanBuild · 2020-03-30T10:03:05Z

README.md

 ```

+Groupie also has a support module for Android's [view binding](https://developer.android.com/topic/libraries/view-binding). This module also supports Android data binding, so if your project uses both data vinding and view binding, you don't have to add the dependency on the data binding support module. [Setup here.](#view-binding)


spelling correction "uses both data vinding and view binding".

See, the way it's laid out here basically means that you no longer need to use the data-binding module if using gradle plugin 3.6.0. This is why I'm saying we should deprecate it soon.

OK, now I got your point. Thanks for your patience.

ValCanBuild · 2020-03-30T10:03:57Z

README.md

+Groupie also has a support module for Android's [view binding](https://developer.android.com/topic/libraries/view-binding). This module also supports Android data binding, so if your project uses both data vinding and view binding, you don't have to add the dependency on the data binding support module. [Setup here.](#view-binding)
+
+### Note:
+`groupie-viewbinding` can also be used for the project using only data binding, but in this case the version of Android Gradle Plugin must be 3.6.0 or more.


correct to:
groupie-viewbinding can also be used for projects using only data binding when using Android Gradle Plugin 3.6.0 or higher

ValCanBuild · 2020-03-30T10:04:28Z

README.md

 ```

 Groupie includes a module for Kotlin and Kotlin Android extensions. Never write a ViewHolder again—Kotlin generates view references and Groupie uses a generic holder. [Setup here.](#kotlin) 

 ```gradle
-implementation "com.xwray:groupie:2.7.0"
-implementation "com.xwray:groupie-kotlin-android-extensions:2.7.0"
+implementation "com.xwray:groupie:$groupie_version"


Hah - thats sensible. Should've done it ages ago rather than manually updating it 😂

ValCanBuild · 2020-03-30T10:04:58Z

README.md

+}
+```
+
+Because ViewBinding does not have the util class that can generate an arbitrary bindng like `DataBindingUtil` for DataBinding, you need to override ` initializeViewBinding` to generate the instance of specified binding:


bindng -> binding

ValCanBuild · 2020-03-30T10:06:20Z

README.md

 ```

+Groupie also has a support module for Android's [view binding](https://developer.android.com/topic/libraries/view-binding). This module also supports Android data binding, so if your project uses both data vinding and view binding, you don't have to add the dependency on the data binding support module. [Setup here.](#view-binding)


See, the way it's laid out here basically means that you no longer need to use the data-binding module if using gradle plugin 3.6.0. This is why I'm saying we should deprecate it soon.

ValCanBuild · 2020-03-30T10:07:23Z

example-viewbinding/src/main/java/com/xwray/groupie/example/viewbinding/CarouselGroup.kt

+  private val carouselItem: CarouselItem
+
+  init {
+    this.adapter = adapter


Can you please reformat this whole example project to use an indentation of 4 to keep it in line with the other ones?

ValCanBuild · 2020-03-30T10:15:04Z

library-viewbinding/src/main/java/com/xwray/groupie/viewbinding/BindableItem.java

+        if (binding instanceof ViewDataBinding) {
+            ((ViewDataBinding) binding).executePendingBindings();
+        }


@nashcft I still think this should be removed in order to merge this PR.

ValCanBuild

But, I'm not sure we have to deprecate library-databinding APIs and remove DataBinding support in the future version

We don't have to but we should since library-databinding will no longer be necessary since library-viewbinding will end up being all a databinding or viewbinding user needs to use. I rather we don't support something that is no longer required or best practise to use.

Please remove the databinding dependency of library-viewbinding and I can approve. Few other minor comments as well - mostly on Readme

ValCanBuild · 2020-03-31T09:22:30Z

Massive thanks again for the quick work on the feedback @nashcft . I've now merged this and I'll create a new release later this week.

nashcft added 4 commits February 22, 2020 09:21

Update Android Gradle Plugin and DataBinding to 3.6.0

15b660d

Create groupie-viewbinding module

c3b919b

Create example-viewbinding module

528a852

Fix dependencies

85c813f

nashcft commented Feb 22, 2020

View reviewed changes

nashcft added 4 commits February 22, 2020 19:15

Consider when subclass of ViewDataBinding is assigned to type parameter

d6d1739

update example

ebe204d

Fix variable name

a4abbf4

Fix warning

d2e4b05

aoben10 approved these changes Feb 22, 2020

View reviewed changes

lkishor reviewed Feb 22, 2020

View reviewed changes

nashcft added 2 commits February 23, 2020 08:56

compileOnly -> implementation

a4798c7

DataBinding APIs are needed even when the user enables only ViewBinding

Android Gradle Plugin 3.6.0 stable

1aace20

ValCanBuild requested changes Mar 26, 2020

View reviewed changes

nashcft added 3 commits March 28, 2020 15:02

Update AGP and viewbinding version to 3.6.1

1c9774e

Update libraries for example-viewbinding

98caac2

Convert Java files in example-viewbinding to Kotlin

494d6ad

Update README

b633c45

ValCanBuild reviewed Mar 30, 2020

View reviewed changes

ValCanBuild requested changes Mar 30, 2020

View reviewed changes

nashcft added 6 commits March 30, 2020 21:02

fix indent

fecc5f6

fix README

b0570d7

Remove dependencies to data binding libraries

38bc233

Deprecate all classes in library-databinding

3e39a11

Add a note about view binding support with data binding

e14db41

remove extra white space

5ea1f1d

ValCanBuild merged commit 4b970b0 into lisawray:master Mar 31, 2020

nashcft deleted the viewbinding_support branch March 31, 2020 09:31

zsoltvilagos mentioned this pull request Apr 2, 2020

Fixed groupie-viewbinding BindableItem.bind method's JavaDoc #334

Merged

OrhanTozan mentioned this pull request Jul 30, 2020

BindableItem for databinding only got worse just in favour of ViewBinding... Please remove the redundant initializeViewBinding method for databinding only. #349

Closed

binding library	extension to be used
DataBinding only	`groupie-databinding`
ViewBinding only	`groupie-viewbinding`
Both DataBinding and ViewBinding	`groupie-viewbinding`

binding library	extension to be used
ViewBinding only	groupie-viewbinding
Both DataBinding and ViewBinding	groupie-databinding

		@NonNull
		protected abstract T initializeViewBinding(@NonNull View view);

		```

		Groupie also has a support module for Android's [view binding](https://developer.android.com/topic/libraries/view-binding). This module also supports Android data binding, so if your project uses both data vinding and view binding, you don't have to add the dependency on the data binding support module. [Setup here.](#view-binding)

ViewBinding support #325

ViewBinding support #325

Conversation

nashcft commented Feb 22, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nashcft Feb 27, 2020 • edited Loading

Choose a reason for hiding this comment

nashcft Feb 22, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nashcft commented Feb 22, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aoben10 commented Mar 23, 2020

ValCanBuild left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NitroG42 commented Mar 26, 2020 • edited Loading

nashcft commented Mar 28, 2020

nashcft commented Mar 29, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ValCanBuild left a comment

Choose a reason for hiding this comment

ValCanBuild commented Mar 31, 2020 • edited Loading

nashcft Feb 27, 2020 •

edited

Loading

nashcft Feb 22, 2020 •

edited

Loading

NitroG42 commented Mar 26, 2020 •

edited

Loading

ValCanBuild commented Mar 31, 2020 •

edited

Loading