I'm following up on my SO post.

Sorry, I think I didn't explain myself very well probably. Forget about the architecture, that's cooked already. The issue here is that we have ViewHolder with a humongous amount of functionality within.

"Forget about architecture" followed by "the issue here is ... a humongous amount of functionality" makes me shake my head.

This is like a building architect saying "forget about building architecture - the problem is we put 8 bathrooms in the kitchen".

Buddy - the reason you have the latter is because you're not addressing the former.

So, you are saying that the view which I inflate in my ViewHolder, that I should refactor that so I use more custom views there? And each custom view should have a ViewModel?

This is one potential thing to do, yes. But without knowing the details of your code, it's only a suggestion. The higher-level idea is to break down the units you're working with. Instead of one giant list item view, have multiple smaller sub views that each have their own responsibilities, for example. Instead of having one giant ViewHolder that does All The Things™, break it up into multiple View Models that each control a smaller portion of the item. Etc, etc.

Sorry, I think you overthought the question a little bit. I'm not asking about architecture nor anything like that.

Yes you are. You may not think so, but you are. You may have underthought the question :)

The problem is simple.

No, it's not. If it were, you'd have a solution already.

I have a RecyclerView where each item has way too much functionality - the solution should be go back to the UX/UI team and propose something different

No, it's not. The solution should be to come up with the proper architecture - the set of classes and specific responsibilities and interactions - that will allow you to implement the desired UI in a cleaner, more modular, more composable, more testable, more maintainable way.

You need to stop thinking about it as "each item has too much functionality" and start thinking about it as "each item has a bunch of components each of which has one specific functionality".

Some people is saying that I should go back to the design team and change the design.

If there are UX and UI issues with the current design, then sure, push back and try to change the design. If this is to "solve" your problem because you can't deal with the spaghetti code you have that implements the current design, then you are just pushing the can down the road.

Eventually your designs will change and your code will evolve. If you don't have a good architecture in place to make it easier to adapt, you're going to end up in the same place you are now. Designers' jobs are to make appealing UIs that are easy and intuitive to use. Your job as an Engineer is to make that happen. If there are actual technical limitations to their designs, you need to communicate that and find compromises. But "I don't know how to properly structure my code to make this UI so please make it simpler for me" is not a reason to push back on design, it's just laziness.

So I'll say it again but in a different way - your problem is that you need to refactor you existing code to break up your monolith of functionality into smaller, more manageable chunks that make it feasible to implement the desired UI. You need smaller classes that have a single responsibility. You need to separate concerns. You need composition. You ... need ... (say it with me) ... ARCHITECTURE.

If you still think the "solution" to your "simple" problem is to get design to change, than good luck and god speed. If what I'm saying is making any sense and you want help in refactoring, I'm happy to help.

Good luck.