Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for databinding in list view items #34

Open
anas-ambri opened this issue Jun 17, 2015 · 3 comments
Open

Support for databinding in list view items #34

anas-ambri opened this issue Jun 17, 2015 · 3 comments

Comments

@anas-ambri
Copy link

First off, thanks for this library.

I was wondering what would be the best way to add support for databinding when using an ItemViewHolder with a recyclerview (or listview). I am thinking either making the onCreateViewHolder abstract, and creating two base classes, depending on whether one is using the databinding or not. The problem with this solution is that it would double the number of classes one can subclass.

What about adding a flag to the LayoutId annotation set to true when using databinding, and is false by default?

Thanks,

@ivacf
Copy link
Contributor

ivacf commented Jun 18, 2015

Hi, I haven't had a proper look at databinding yet but I don't think is gonna be easy to integrate. First thing is that the current structure of ItemViewHolder doesn't make sense if we use data binding. For example, the purpose of onSetValues() is to set the values in the views (i.e binding the data) so if we support databinding this method won't be needed or at least will need changing.

I don't think creating two base classes is a good option because, as you said, we would end up with too many base classes. The flag in the annotation is a better solution but I don't think it's enough.

I haven't thought about this properly yet but the way I see this being implemented is by having a different view holder (e.g. BindedItemViewHolder) with different methods that need to be implemented in order to bind the data. This is just a rough idea.

@anas-ambri
Copy link
Author

Hello. I agree that a lot of structure of ItemViewHolder will have to change, but onSetValues() will still be useful for data that either cannot be easily injected through the data binding, or simply to have the option to do in java side.

Maybe instead of onSetValues, you could have onSetAdditionalValues() in the case of the BindedItemViewHolder?

@ivacf
Copy link
Contributor

ivacf commented Jun 22, 2015

If we keep onSetValues it would have to be different to the current one.

My understanding is that databinding generates a class per layout based on your layout name. Then if, for example, you data item is an User you will have to call setUser() on the generated class. So both the name of the method and class will be different depending on your implementation.

For example:

ListItemBinding binding = DataBindingUtil.inflate(layoutInflater, R.layout.list_item, viewGroup, false);
binding.setUser(user);

ListItemBinding is a generated class, therefore the EasyAdapter won't have any idea that exist. What this means is that the EasyAdapter won't be able to perform the binding automatically because it doesn't know the name of the generated class. It could potentially pass the binding into onSetValues as a paramter of type Object and then the user would have to cast it and set the data. This is how it would look:

void onSetValues(User user, Object binding, ItemPosition itemPosition) {
    ListItemBinding listItemBinding = (ListItemBinding) binding;
    listItemBinding.setUser(user);   
}

This could be an option, however having that parameter of type Object is not very nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants