switch (message.getMessageType()) {
case ConstantUtils.IMAGE_MESSAGE:
if (images.size() == 1 || images.size() == 2) {
models.add(new ImgOneItemModel_().context(activity).mMessage(message).topic(topic).pic(images.get(0)));
} else if (images.size() > 2) {
for (int i = 0; i < 3; i++) {
imgModels.add(new ImgNormalItemModel_().id(images.get(i).hashCode()).context(activity).picList(images).pic(images.get(i)).index(i));
}
models.add(new MsgTextModel_().id(message.getMessageId().hashCode()).content(message.getMessageContent()).message(message));
models.add(new MsgImgModel_().models(imgModels).show(message.getMessageType() == ConstantUtils.IMAGE_MESSAGE));
} else {
}
break;
case ConstantUtils.VIDEO_MESSAGE:
models.add(new MsgTextModel_().id(message.getMessageId().hashCode()).content(message.getMessageContent()).message(message));
models.add(new MsgVideoModel_().id("MsgVideoModel_").mContext(activity).topic(topic).data(message).position(position));
break;
case ConstantUtils.AUDIO_MESSAGE:
break;
default:
models.add(new MsgTextModel_().id(message.getMessageId().hashCode()).content(message.getMessageContent()).message(message));
break;
}
models.add(new MsgFooterModel_().id("MsgFooterModel_").context(activity).message(message).topic(topic).isClick(commentIsClick));
error:
java.lang.IllegalStateException: The number of models used in this group has changed. The model count must remain constant if the same layout resource is used. If you need to change which models are shown you can call EpoxyMode#hide() to have a model's view hidden, or use a different layout resource for the group.
what should i do?
Model groups are meant to be static, not dynamic, like the error message explains.
Is there a reason you need to use a model group this complicated? What is the use case? Why can't you just add them like normal to a controller?
side note: you don't need to pass a context to a model like .context(activity). you can get the context off the view when it is bound
This problem has been occurred when I have multi controllers which are inside multi different fragments. When I scroll down on a fragment then I switch to another one by clicking the MenuItem on the navigation. The data is loaded on the new attached fragment and my application is crashed. I update my new items to controller by call controller.setData() function. This error doesn't occur regularly. It doesn't occur when I don't scroll the list down.
E/AndroidRuntime: FATAL EXCEPTION: main
Process: it.unical.mat.lifetune.dev, PID: 8731
java.lang.IllegalStateException: The number of models used in this group has changed. The model count must remain constant if the same layout resource is used. If you need to change which models are shown you can call EpoxyMode#hide() to have a model's view hidden, or use a different layout resource for the group.
at com.airbnb.epoxy.EpoxyModelGroup.createInconsistentModelCountException(EpoxyModelGroup.java:258)
at com.airbnb.epoxy.EpoxyModelGroup.iterateModels(EpoxyModelGroup.java:244)
at com.airbnb.epoxy.EpoxyModelGroup.handlePreBind(EpoxyModelGroup.java:131)
at com.airbnb.epoxy.EpoxyModelGroup.handlePreBind(EpoxyModelGroup.java:68)
at com.airbnb.epoxy.EpoxyViewHolder.bind(EpoxyViewHolder.java:49)
at com.airbnb.epoxy.BaseEpoxyAdapter.onBindViewHolder(BaseEpoxyAdapter.java:96)
at com.airbnb.epoxy.EpoxyControllerAdapter.onBindViewHolder(EpoxyControllerAdapter.java:10)
at com.airbnb.epoxy.BaseEpoxyAdapter.onBindViewHolder(BaseEpoxyAdapter.java:14)
at android.support.v7.widget.RecyclerView$Adapter.bindViewHolder(RecyclerView.java:6541)
at android.support.v7.widget.RecyclerView$Recycler.tryBindViewHolderByDeadline(RecyclerView.java:5484)
at android.support.v7.widget.RecyclerView$Recycler.tryGetViewHolderForPositionByDeadline(RecyclerView.java:5750)
at android.support.v7.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:5589)
at android.support.v7.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:5585)
at android.support.v7.widget.LinearLayoutManager$LayoutState.next(LinearLayoutManager.java:2231)
at android.support.v7.widget.LinearLayoutManager.layoutChunk(LinearLayoutManager.java:1558)
at android.support.v7.widget.LinearLayoutManager.fill(LinearLayoutManager.java:1518)
at android.support.v7.widget.LinearLayoutManager.onLayoutChildren(LinearLayoutManager.java:610)
at android.support.v7.widget.RecyclerView.dispatchLayoutStep2(RecyclerView.java:3719)
at android.support.v7.widget.RecyclerView.onMeasure(RecyclerView.java:3135)
at android.view.View.measure(View.java:18794)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:5951)
at android.widget.LinearLayout.measureChildBeforeLayout(LinearLayout.java:1465)
at android.widget.LinearLayout.measureVertical(LinearLayout.java:748)
at android.widget.LinearLayout.onMeasure(LinearLayout.java:630)
at android.view.View.measure(View.java:18794)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:5951)
at android.support.design.widget.CoordinatorLayout.onMeasureChild(CoordinatorLayout.java:719)
at android.support.design.widget.HeaderScrollingViewBehavior.onMeasureChild(HeaderScrollingViewBehavior.java:91)
at android.support.design.widget.AppBarLayout$ScrollingViewBehavior.onMeasureChild(AppBarLayout.java:1361)
at android.support.design.widget.CoordinatorLayout.onMeasure(CoordinatorLayout.java:789)
at android.view.View.measure(View.java:18794)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:5951)
at android.widget.LinearLayout.measureChildBeforeLayout(LinearLayout.java:1465)
at android.widget.LinearLayout.measureVertical(LinearLayout.java:748)
at android.widget.LinearLayout.onMeasure(LinearLayout.java:630)
at android.view.View.measure(View.java:18794)
at android.support.v4.widget.DrawerLayout.onMeasure(DrawerLayout.java:1060)
at android.view.View.measure(View.java:18794)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:5951)
at android.widget.FrameLayout.onMeasure(FrameLayout.java:194)
at android.support.v7.widget.ContentFrameLayout.onMeasure(ContentFrameLayout.java:139)
at android.view.View.measure(View.java:18794)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:5951)
at android.widget.LinearLayout.measureChildBeforeLayout(LinearLayout.java:1465)
at android.widget.LinearLayout.measureVertical(LinearLayout.java:748)
at android.widget.LinearLayout.onMeasure(LinearLayout.java:630)
at android.view.View.measure(View.java:18794)
at androi
The problem is solved when I didn't use Epoxy in other fragments.
@elihart Hey. I have this use case and I thought the model group would solve it:
View structure: Card -> Static Header view, Dynamic amount of detail rows.
I implemented it like this:
class ServiceGroup(models: List<EpoxyModel<*>>) : EpoxyModelGroup(R.layout.layout_service_card, models)
class ServicesController(private val resources: Resources) : TypedEpoxyController<List<Service>>() {
override fun buildModels(services: List<Service>) {
if (!services.isEmpty()) {
services.forEach { service ->
val rows = mutableListOf<EpoxyModel<*>>()
rows.add(
ServiceHeaderBindingModel_()
.id(service.stableId())
.service(service)
)
rows.addAll(service.localizedDetails(resources).map {
ServiceDetailBindingModel_()
.id(it.hashCode())
.detail(it)
})
ServiceGroup(rows).addTo(this)
}
}
}
}
It was working as expected, until I added same fragment multiple times and this exception was thrown.
What's the alternative for my use case?
Thanks.
Last time I checked by opening the same fragment again and again, it was crashing on the third time and when returning to the previous one. The only thing that is changed is I added sorting the list before adding (services.sortedBy { it.type }.forEach..). Why does it matter?
Could you please explain me how this works? What's the use case of EpoxyModelGroup if different model counts cannot be used?
I have the same crash on opening fragment for the third time. So weird, I didn't change the number of modelgroup children. Is it some issue with epoxy caching? A crash happens only for groups with multiple children
I am working on a big change to how model groups are implemented so that this limitation will no longer exist - hope to have it done in a week or so
Most helpful comment
I am working on a big change to how model groups are implemented so that this limitation will no longer exist - hope to have it done in a week or so