While I do agree that DataBinding is wonky combined with using it in XML, I am somewhat skeptical of your views on ViewModels.

Google have been trying to make developers less reliant on a single GodActivity architecture. By retaining information in the ViewModel and instead in the Activity callbacks this succeeds in decoupling code from the Activity, thus aids in making your UI layer separate from your data layer. I agree they shouldn’t have named it ‘ViewModel’ rather something else, because it does a lot more than only retaining view state. It is however much simpler to use for new devs as it makes things easier to understand than nonConfigurationInstance and isFinishing() shenanigans.

You mentioned headless retained fragments — sure it is simple to use, but at what point is the fragment only a view meant to only show information to the user, and at what point does it become a medium to store information? What I mean by this is , of course, that you are abusing fragments and using them outside of their purpose which should be to only display information to the user. You said the AAC ViewModel is only a retained object, I can say that in this case, the “Fragment” is not really a fragment, but only used to retain information.

This debate can go on, and I do agree with a lot of your points, however, Google have to make compromises regarding implementations of design patterns. What I mean by this is that there will always be small deviations from the norm, and that will be the cause for discourse. AAC MVVM isn’t 100% MVVM according to the design, but it gets really darn close.

I also agree that they shouldn’t have forced ViewModels on us by deprecating other things, but in the end this is the best way to force a streamlined approach for new devs to begin programming, and also to set a standard for new Android projects to come.