Hi. Very nice write up on your blog.

I agree that the activity shouldn’t contain UI implementation details. But one important detail that I found quite difficult to give enough importance on this type of article, and apparently you missed it too (my bad), is that the library auto-generates the code FOR ANY CLASS during compile time (could be fragment, could be from a FrameLayout, could be from some Presenter class). With that, the code shown on this article (and the sample on GitHub), are only that. Sample usages.

Building from the given sample, nothing stop a developer to create a `public View createContentView()` method and have separate decorators for `RecyclerViewInstigator` (which would have the code shown in the sample activity), `ViewPagerInstigator`, etc. With that approach the Activity code would only have the 1 line of code setContentView(createContentView());`.

An example of that is our app (not open source) we have a PresenterDecorator (using Mortar from Square)with all the UI and an ActivityDecorators to capture some activity specifics.

The main idea of this library is how easily you can decouple responsibilities from one central class to any number of decorators you want. How you organize that is up to each developer