So far, we have designed one fairly significant app and a dozen or more mini apps. Some we designed for tablets, but we designed most of them on the Nexus 5 phone. Also, most of the screenshots in this book have been on the Nexus 5 emulator.
Of course, in the real world, our apps need to work well on any device and must be able to handle what happens when in either portrait or landscape view (on all devices).
Furthermore, it is often not enough for our apps to just work and look OK on different devices. Often, our apps will need to behave differently and appear with a significantly different UI based on whether the device is a phone, a tablet, or in the landscape/portrait orientation.
Take a look at this screenshot of the BBC news app running on an Android phone in the portrait orientation. Look at the basic layout, but also note that the categories of news (TOP STORIES, WORLD, and UK) are all visible and allow the user to scroll down so that they can see more categories or swipe to the left or right between the stories within each category.
We will see how we can implement a swiping/paging UI using the ImagePager and FragmentPager classes in Chapter 20, Paging and Swiping. For now, the purpose of the diagram is not so much to show you the specific UI features, but to allow you to compare it with the next screenshot. Look at the exact same app running on a tablet in the landscape orientation:
Note that the stories (data layer) are identical, but the layout (the view layer) is very different. The user is not only given the option to select categories from a menu of tabs at the top of the app, but they are also invited to add their own tabs through the + Add Topics option.
The point of this image, again, is not so much the specific UI or even how we might implement one like it, but more that they are so different they could easily be mistaken for totally different apps.
Android allows us to design real-world apps like these, where not only is the layout different for varying device types/orientations/sizes, but so is the behavior. The Android secret weapon that makes this possible is Fragments.
Note
Google says
A Fragment represents a behavior or a portion of user interface in an activity. You can combine multiple Fragments in a single activity to build a multipane UI and reuse a Fragment in multiple activities.
You can think of a Fragment as a modular section of an activity, which has its own lifecycle, receives its own input events, and which you can add or remove while the activity is running (sort of like a subactivity that you can reuse in different activities).
A Fragment must always be embedded in an activity, and the Fragment's lifecycle is directly affected by the host activity's lifecycle.
We can design multiple different layouts in different XML files, and we will do so soon. We can also detect things such as device orientation and screen resolution in code so that we can then make decisions about layouts dynamically.
Let's try this out and then we will take a look at Fragments.