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

[OrhanTozan]

[ValCanBuild]

Hello @NahroTo can you please expand on why this is worse and what your recommendation would be?

[OrhanTozan]

@ValCanBuild The readme gives the following example for databinding:

public class SongItem extends BindableItem<SongBinding> {

    public SongItem(Song song) {
        this(song);
    }    

    @Override public void bind(SongBinding binding, int position) {
        binding.setSong(song);
    }

    @Override public int getLayout() {
        return R.layout.song;
    }
}

, but the compiler asks me to override the initializeViewBinding method. Why would I need to have viewbinding code in a project where I only use databinding? Am I doing something wrong? Because otherwise the readme is obviously outdated.

[ValCanBuild]

Are you using groupie-viewbinding or groupie-databinding ? The readme contains a warning about using it with data binding https://github.com/lisawray/groupie#warning-if-using-this-with-databinding

As of the latest gradle plugin versions, databinding actually uses viewbinding internally, so you are using viewbinding even if you didn't know it.

[OrhanTozan]

Well I can't use groupie-databinding since it's marked as deprecated, otherwise I would use it. The thing is, why do you ask databinding users to implement the onintiailizeViewBinding if the library can do itself with DataBindingUtil? (Which I assumed it already did before, so why the negative change?)

[ValCanBuild]

I understand your frustration. groupie-viewbinding cannot do it itself, though, because it would mean it would need to depend on databinding.

We didn't want non-databinding users, who used viewbinding, to needlessly have databinding included in their apps this way so this was the tradeoff we settled on.

[OrhanTozan]

https://github.com/lisawray/groupie/pull/325#discussion_r382949772 I found the comment where the decision was made. I think this was a bad decision, and a good example of where duplication would be better than the bad abstraction. Just make BIndableItem to two different classes again.
This is was a step backwards of the library, just because viewbinding was added, at the cost of databinding users 🙁.

[OrhanTozan]

@ValCanBuild I will try to set up a PR today that will improve this

[jpelgrim]

I completely agree with @NahroTo on this point. Why do data binding users have to add unnecessary code? Can't we keep the groupie-databinding library for users who don't want to switch to groupie-viewbinding? Or asked otherwise, why does com.xwray.groupie.databinding.BindableItem need to be deprecated? Can't it live side by side of com.xwray.groupie.viewbinding.BindableItem?

@NahroTo did you ever come around creating that PR?

[OrhanTozan]

@jpelgrim No sorry, I never actually got to finish that PR. I chose to keep using AndroidX's ListAdapter (with multiple ViewTypes if necessary) over Groupie instead.

[Zhuinden]

Looking at this issue, I'm inclined to agree. If DataBindingUtil can figure out the binding type, then it should at least be invoked automatically for users. I do see that the original intention was to push everyone over to the viewbinding artifact instead of the databinding artifact, but there's no real reason for someone to use only databinding or use only viewbinding, they can co-exist in a project? 🤔

So I'll try to look into this.

[jpelgrim]

Hi @Zhuinden did you look into this already? Can I help?

[Zhuinden]

A bit late, but I've undeprecated groupie-databinding with no change.

It will no longer be marked deprecated in the next release.

Consider it undeprecated.

[jpelgrim]

For reference this was done in commit 818e4c4