Android-cleanarchitecture: How to deal with complicated view?

[mufans]

one view can only hold single presenter, single usecase can only do single thing . But when the view or the business logic is too complicated ,its presenter must hold many usecase. when the logic between multiple usecase is very complicated , the code of presenter must be hard to maintain.
i want to reuse multiple usecase in multiple views without single presenter.
so , what should i do? Create combined usecase in domainlayer ( maybe not do single thing ) or use multiple useCase in presenter still?
And i wonder where the result data of single usecase should be place(the data used by other usecase later, or the status data) , the presenter?

[jpventura]

According to _Entity-Control-Boundary Pattern_, you may create use cases (or control objects, as originally named by Jacobson) that consume other use cases.

Too many use cases in a single presenter could lead to you a Good Anti-Pattern, but is up too you decide when you presenter is becoming a demigod.

Object calisthenics advocates your entities should not exceed 50 lines, but since Java is a garrulous language, 150 lines would be a good catch.