Fragments: How do I compose the final, screen size dependent, layout of my application?
The question is ultimately about if there are any defacto standards or Google recommendations on how to implement the below question.
I have recently started to have a closer look at the Fragments concept in Android. I do get the idea of it (or at least I think I do) and I also see the need for it. I have no trouble understanding the technicalities behind the implementation of my fragments. What I seem to have problems understanding, though, is how to compose the final layout of my application, so that it automagically works on a large tablet as well as a small smartphone?
I have my list fragment (e.g. MS Outlook-inbox-list) and I have my detail view fragment (e.g. MS Outlook-email-preview). On a tablet I would naturally like to show these two fragments in a single activity, but on a smart phone I would like to show them in two different activities while there isn't necessarily room for both of them on a single activity.
How do I go about to solve this?
Do I have to implement three activities in my application (the all-in-one tablet activity and the two separate, smart-phone specific activities)? But how can the application then decide on which implementation to use (1 or 1+1)?
Usually my activities play the role of the 'controller' (according to the MVC paradigm) but, as of the above question, I would have three controllers. Which construction would play the role of the root controller? Should I write a 'master activity' (without UI) which programmaticaly tries to decide which device it lives on and then call the suitable fragments activity accordingly? But then; how can I - in a well defined manner - find out what type of device (tablet/handset) my application is running on?
I guess I could post some of my code but I don't think it would clarify my problem any further as it's more a question of architectural choices than implementation specific. Cheers, dbm
Do I have to implement three activities in my application (the all-in-one tablet activity and the two separate, smart-phone specific activities)?
No, probably only two. One is responsible for loading the ListFragment and, if there is room, the detail fragment. The other only loads the detail fragment -- this activity would be started by the first one if the user taps on a list entry and the detail fragment is not displayed by the first activity.
Usually my activities play the role of the 'controller' (according to the MVC paradigm) but, as of the above question, I would have three controllers.
IMHO, with fragments, the fragment is your controller. Activities are an orchestration layer determining which fragments are visible and handling cross-fragment events.
But then; how can I - in a well defined manner - find out what type of device (tablet/handset) my application is running on?
The simplest solution in many cases is to drive it by layout XML resources.
For example, in my above recommendation, the first activity could have two different versions of, say, main.xml. One (res/layout/main.xml) loads just the ListFragment. The other (say, res/layout-large-land/main.xml) loads the ListFragment and the detail fragment, or loads the ListFragment and a FrameLayout container for a dynamic detail fragment (one you would define via a FragmentTransaction). The activity itself determines whether it is managing two fragments or one by determining if the second fragment (or its FrameLayout "slot") exists in the inflated main.xml. That way, if you change your layout rules in the future (e.g., res/layout-sw600dp-land/main.xml), your Java code does not need to change.
There is nothing stopping you from using Configuration and DisplayMetrics to try to make decisions in the Java code as well.