MOTODEV Blog

[#1]

Here in the San Francisco Bay Area, the seasons have turned to fall. Schools are in session, football is on TV (both American football and futbol), and apples are in season. One of my favorite snacks this time of year is apples with peanut butter, or maybe almond butter.

While I eat my apples, I think a lot about design and engineering. We can engineer solid, reliable, high-performing products, but without good design, no one would use them. Or, we can stay up late creating beautiful, functional designs, but without engineering, they remain on the drawing board. The two go together like – you guessed it.

So I’d like to talk a bit about the design and engineering of one of the most commonly used features of Android Honeycomb tablet apps, fragments.

Fragments can change size or position according to orientation or screen size, or appear in multi-pane or single-pane layouts on different devices, using the Android Compatibility Library. Each fragment can start its own thread or AsyncTask to do background work. So fragments come in quite handy.

But fragments present several challenges. One of those is how to handle fragment layouts when orientation changes on a tablet. Briefly, you can stretch, stack, swipe, hide, or slide.

In this post, I’ll talk about hiding a fragment when orientation changes to portrait, while giving the user a button to restore it. This is the approach used by the Honeycomb Gmail app, and is especially useful when you want your application to run on tablets of different sizes, like the 7-inch and 10-inch tablets currently on the market.

In Gmail, when you read an email message in landscape, you see a typical two-pane layout, with the list on the left.

In portrait, the content of the email message displays at full screen, with an arrow button at top left.

Tapping the button displays the list, while you can swipe left to see the full email message.

Hiding a fragment, with a button to restore it, is a graceful way to handle the orientation change. It adds liveliness and movement, makes the content easy to read, leaves the user in control, and works across tablets of different sizes. This pattern is both Functional and Beautiful (I’ll talk more about this Functional/Beautiful stuff at Android Open).

Use this pattern when one fragment has content that is best viewed at full screen, and you want the content to be easily viewed in both orientations and on tablets of different sizes.

At this point, you’re probably wondering about the implementation. It involves using FragmentTransaction and animated fragment transitions, so I’ll talk about that in another post, coming soon.

For more interesting UI patterns that create a sense of ease and fun, or more implementaton details on this one, join me for my talk at Android Open on October 10. (But if you can’t make it, we’ll be recording it as an online webinar shortly after.)

See you soon,
Suzanne

Suzanne Alexandra
Android Technology Evangelist
@suzalex

Speaking at
Android Open, Oct 9-11, San Francisco, California, USA
AnDevCon II, Nov 6-9, San Francisco, California, USA

[#2]

 I am sort of curious.

1 ) Most google demos finds fragments by its ID if the fragment is already been created in xml.

So if we take that approach, the way we show fragments is by hiding it and showing it since the fragments are already created.

2) There are also examples provided by google where you can create the fragment with a constructor and inflate it. This acts weird by the way like getActivity() returns null if it is called with in that fragment.

So If i take the first approach I have to hide and show the fragments. So why does not google provide hooks to the fragments like onHide or onShow so that we can handle things properly instead if doing the clean up ourselves with functions that we implement and call explicitly.