The Need for UI Flexibility

You might imagine that a list-detail application consists of two activities: one managing the list and the other managing the detail view. Pressing on 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 8.2).

Figure 8.2  Ideal list-detail interface for varying screen widths

Ideal list-detail interface for varying screen widths

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.

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 built to provide this flexibility. An activity’s views may change at runtime, but the code to control those views must live inside the activity. As a result, activities are tightly coupled to the particular screen being used.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.238.86.122