The documented Android fragment samples (FragmentBasics, NewsReader violate core principles of object oriented design. There are redundant conditionals to establish the currently showing view type, tightly coupling the FragmentActivity with the view types and fragment types. MainActivity is coupled to every class (including the XML):

One might be able to make the excuse for the authors that they are trying to “keep it simple,” or that readers might be confused. If this is the intent–I think readers can handle it; instead, it’s teaching bad programming practices that will result in less maintainable applications.
How can Fragments be implemented such that the views and fragments aren’t tightly coupled to the FragmentActivity?
Starting with the simpler FragmentBasics demo, gut
MainActivityas follows:Now its dependency diagram looks like this. You can now add all the
news_articlesview variants you’d like for different device types andMainActivitydoesn’t need to change.Add a new class
AbstractNewsViewProviderwhose sole responsibility is to determine which type of view (single or double pane) is being used for the given device. If you’re using Guice or RoboGuice for dependency injection, this would instead be a Provider method in your binding module.Add two new classes
SinglePaneNewsViewandDoublePaneNewsViewthat implementAbstractNewsViewas shown below. These two classes are responsible for the setup of the initial fragment(s) within the respective view type. They are also responsible for handling transitions between fragments, if any.You can find the complete source on Google code.