[epoxy-paging] Support building multiple models for each item

Currently, PagedListEpoxyController allows you to return one EpoxyModel<*> per item, as enforced by this method:

abstract fun buildItemModel(currentPosition: Int, item: T?): EpoxyModel<*>

This prevents an item from being “split up” or multiplexed into multiple models.

Introducing support for this would be perfect for an “endless scrolling feed” like use case. We’d need to figure out how to accurately report back the number of models, and to map an item to a model.

[ganfra]

Any progress on this? I’d love to have this support 😃

[elihart]

I don’t mind changing the API, especially if it is not a hard thing for people to adjust to when they upgrade.

The multiplexed model is interesting - but I am hesitant because it doesn’t create a clear delineation of usage within the paged controller. Also models are complex and nesting them can lead to all sorts of other issues to solve (what does setting an onBind listener on the model do, what does the parent model id do, etc )

I like yigit’s ideas to solve it entirely within the paged controller. I would vote for breaking backwards compatibility however we need to create an ideal API for this going forward. Although the ideas for how to support backwards compatibility (with a default implementation) also sound reasonable to me - nothing stands out as being best.

The idea of returning a list of models to map to an item in the list makes sense. But I’m not clear on what you mean by using an instance map and reusing the same model in multiple places? The model doesn’t really hold state when bound, so it should be fine to reuse it, but it needs to have a unique id.