Question

I’m implementing a fragment hierarchy similar to the one described in Fragments (Android Developers).

In adition in tablets in portrait the app should behave as in the second case. My problem is to handle the transaction from an orientation to other.

The first idea I considered was:

• From landscape-to-portrait:When the activity A goes to portrait: Remove the fragment B to the view. Start activity B for result passing the propper values for recover the original fragment B state
• From portrait-to-landscape: When the activity B goes to portrait. finishes (with the fragment 2 status in the result). The activity A with the result restores and adds the fragment B to its layout.

But this solution is pretty complex and I think it provably is not a nice idea. The alternative solution I have considered is only to have an Activity. That activity layout is:

<FrameLayout>
    <LinearLayout>
       <Fragment A>
       <Fragment B>
    <Slot>

For small devices:

• The app removes the fragment B and when a item is selected add to the backstack the fragment to the “Slot”

For tablets:

• Using fragmentTransactions the fragment B is moved from Its position to the “Slot” using the backstack to behave properly to the orientation changes

I think the second option sounds better but, is the correct way of doing this?

Thanks

Answer 1

If you want my advice, I’d say it depends on way too much factors. I think you should stick with what you find manageable enough. It depends too on how complex your app’s screen flow is.

Keeping it in one activity is, for me, a good idea if you don’t have that much fragments to manage. An advantage of this approach is that you don’t need to fiddle around with the life cycle of two different activities.

Anyway, finding the implementation complex is in a way an indicator that what you’re planning won’t be manageable for you in the future.

Hope that helps!