You might imagine that a list-detail application consists of two activities: one managing the list and the other managing the detail view. Pressing a crime in the list would start an instance of the detail activity. Pressing the Back button would destroy the detail activity and return you to the list, where you could select another crime.
That would work, but what if you wanted more sophisticated presentation and navigation between screens?
Consider the possibility of CriminalIntent running on a large device. Some devices have screens large enough to show the list and detail at the same time – at least in landscape orientation (Figure 9.2).
Or imagine a user is viewing a crime and wants to see the next crime in the list. It would be better if they could select a different crime from the list without navigating back to the previous screen first. Going beyond the CriminalIntent app, common UI elements such as navigation drawers and bottom tab bars keep users on one “screen” while child views are swapped in and out.
What these scenarios have in common is UI flexibility: the ability to compose and recompose an activity’s view at runtime depending on what the user or the device requires.
Activities were not designed with this level of flexibility in mind. Activities control an entire window of your application, so one activity should be able to render everything your app needs to show onscreen at a time. As a result, activities are tightly coupled to the particular screen being used. So you could continue to keep all your UI code within activities, but as your apps and the screens within them become more complicated, this approach will become more confusing and less maintainable.