How would you go about supporting more than one ce...
# splitties
n
How would you go about supporting more than one cell type in RecyclerView? I would like to implement a data-driven approach that draws a different view according to what the current item of a list specifies.
l
Multiple ways. Manual way. Or using one of these libraries (unordered): - Epoxy (from Airbnb) - Groupie (from LisaWray) - RecylerView delegates AdapterDelegates (no ambiguity)
n
What do you mean “no ambiguity”?
l
I didn't remember the name of the author, but RecyclerView is easier to Google that common words like epoxy and groupie which have non technical meanings before being library names
n
Well, Groupie seems very nice… I guess creating the views with Splitties DSL is straight forward.
l
BTW, the author is looking for maintainers: https://twitter.com/lisawrayz/status/1160981822529892352
n
I like that it doesn’t impose on you to use custom Annotations, like Epoxy does.
l
Ah yes, also it won't slow your build down because of kapt 🙂
n
BTW, I did not spot the 3rd lib (there is some ambiguity, after all 😉 )
l
It's because I was wrong on the name. It's "AdapterDelegates": https://github.com/sockeqwe/AdapterDelegates
👍 1
n
Well, the
getLayout()
method in Groupie returns a LayoutRes, which is then inflated… I see no place to hook a view generated by Splitties DSL.
Copy code
// GroupAdapter.Java: 170
    @Override
    @NonNull
    public VH onCreateViewHolder(@NonNull ViewGroup parent, int viewType) {
        LayoutInflater inflater = LayoutInflater.from(parent.getContext());
        Item<VH> item = getItemForViewType(viewType);
        View itemView = inflater.inflate(item.getLayout(), parent, false);
        return item.createViewHolder(itemView);
    }
l
Should I respond "Me!" to Lisa and add the feature?
n
Well I guess we need a
getView()
alternative to
getLayout()
l
I'd start by forking and try to add it, or opening an issue.
n
OK. I’ll create a fork. I guess they will appreciate a PR more than opening an issue.
l
Probably 🙂 I'll be happy to review it if you want.
n
Hmm… This I do not like: “The Item class gives you simple callbacks to bind your model object to the generated fields. Because of Kotlin Android extensions, there’s no need to write a view holder.” Without an XML layout, we will have to manually code the ViewHolder. Or am I missing something?
l
Nope, you only need the type of your View, and you'll have all the properties. FYI, I made a Splitties module to have
ViewHolder
be generic and keep the type of the passed `View`: https://github.com/LouisCAD/Splitties/tree/master/modules/typesaferecyclerview