The current implementation of the FirebaseRecyclerViewAdapter uses a single constructor argument to inflate the correct layout file. It would be better to use the parameter 'viewType' in the method onCreateViewHolder(ViewGroup, int). This makes it possible to use different layout files instead of only the one-and-only layout file. From the documentation:
Adapter.getItemViewType(int)
Unlike ListView adapters, types need not be contiguous. Consider using id resources to uniquely identify item view types.
The default implementation of Adapter.getItemViewType(int) could return the current contractor argument to remain backwards compatible.
Thanks for the idea. We definitely want to add support for multiple view
types/segmented views to the adapters. But we haven't made up our mind yet
how to expose this functionality, so that it's both idiomatic for Android
and easy for beginners.
On Mon, Feb 29, 2016 at 9:38 PM ndefeijter [email protected] wrote:
The current implementation of the FirebaseRecyclerViewAdapter uses a
single constructor argument to inflate the correct layout file. It would be
better to use the parameter 'viewType' in the method
onCreateViewHolder(ViewGroup, int). This makes it possible to use different
layout files instead of only the one-and-only layout file. From the
documentation:Adapter.getItemViewType(int)
http://developer.android.com/reference/android/support/v7/widget/RecyclerView.Adapter.html#getItemViewType(int)
Unlike ListView adapters, types need not be contiguous. Consider using id
resources to uniquely identify item view types.The default implementation of Adapter.getItemViewType(int)
http://developer.android.com/reference/android/support/v7/widget/RecyclerView.Adapter.html#getItemViewType(int)
could return the current contractor argument to remain backwards compatible.—
Reply to this email directly or view it on GitHub
https://github.com/firebase/FirebaseUI-Android/issues/86.
Just to indicate the impact of the proposed change:
diff --git a/library/src/main/java/com/firebase/ui/FirebaseRecyclerAdapter.java b/library/src/main/java/com/firebase/ui/FirebaseRecyclerAdapter.java
index fb5ab83..e2351c4 100644
--- a/library/src/main/java/com/firebase/ui/FirebaseRecyclerAdapter.java
+++ b/library/src/main/java/com/firebase/ui/FirebaseRecyclerAdapter.java
@@ -171,7 +171,7 @@ public abstract class FirebaseRecyclerAdapter<T, VH extends RecyclerView.ViewHol
@Override
public VH onCreateViewHolder(ViewGroup parent, int viewType) {
- ViewGroup view = (ViewGroup) LayoutInflater.from(parent.getContext()).inflate(mModelLayout, parent, false);
+ ViewGroup view = (ViewGroup) LayoutInflater.from(parent.getContext()).inflate(viewType, parent, false);
try {
Constructor<VH> constructor = mViewHolderClass.getConstructor(View.class);
return constructor.newInstance(view);
@@ -191,6 +191,11 @@ public abstract class FirebaseRecyclerAdapter<T, VH extends RecyclerView.ViewHol
populateViewHolder(viewHolder, model, position);
}
+ @Override
+ public int getItemViewType(int position) {
+ return mModelLayout;
+ }
+
I thinks it remains easy for beginners since they can use the existing constructor that sets the value of mModelLayout :-) i.e. the existing API remains the same.
+1
i definitely agree, what use of RecyclerView without multi ViewType support? It is useless without it.. For example different type of chat from sender and recipient, or file attach or video attach? Are you suggesting us using setVisible visible and gone? Which will lead us to out of memory problem? The powerfull of recyclerView is the memory management. Without it, it is no use..
@ndefeijter I think this could be a good feature, especially if we can maintain backwards compatibility. Would you mind submitting a pull request?
@ndefeijter whoops sorry I was hasty there. We still need to figure this one out on iOS as well so not ready for Pull Requests, but thanks for the implementation idea!
@bliveinhack @faruqy87 - I too wanted to be able to have multiple view types. I was able to get around it by overriding onCreateViewHolder and returning the abstract ViewHolder instead of super.onCreateViewHolder(parent, viewType);
I do still think that it would be awesome to have this be supported in the library itself
@samtstern Can we have some documentation on this? Is this available right now?
@ndefeijter I went through your code, can you clarify how you manage different viewHolders? If we have multiple viewTypes, we need multiple viewholders too right?
If you want to use the change in #189 you should override this method:
@Override
public int getItemViewType(int position) {
return mModelLayout;
}
I am going to close this issue since the feature is there. We don't plan to expand it any further right now as it risks making this library out of sync with iOS.
Here's a detailed answer I wrote about how to implement multiple view types. It was a headache to trying and get write so I hope this will help you
Most helpful comment
This is the way I did it:
https://medium.com/chanse-games-developers/firebaserecycleradapter-with-multiple-viewtype-31b622d9ef5a#.u1hup6152