Today's #AndroidDev #Protip by +Bruno Oliveira is about creating and adding your Fragments correctly.

Configuration changes are a part of life. When they happen, your Activity might be destroyed and re-created. Setting a fixed orientation for your Activity in your app's manifest (or adding "orientation" to your configChanges) doesn't mean you are safe from this: many other configuration changes are possible.

Now, when your Activity is destroyed and re-created as a result of a configuration change, your Fragments will also be destroyed and re-created. Then all you have to do is add them again, and you're all set, right?

Wait! If you are creating Fragments at run-time (as opposed to statically defining them in a layout file), here is where you have to be careful: when your Activity is being created for the first time, you should add your Fragments in onCreate(). However, when your Activity is being re-created, the framework will add your Fragments back to the Activity as they were before it was destroyed, so it's an error to add them again.

How can you detect whether or not you should add a Fragment in onCreate()? Easy: just check the savedInstanceState argument. If it's null, you should add the fragment. If not, don't add the fragment (it's already there). Example:

public class MyActivity extends Activity {
    protected void onCreate(Bundle savedInstanceState) {
        // Only add fragment if this is the initial Activity creation
        if (savedInstanceState == null) {
            FragmentManager fragmentManager = 
            FragmentTransaction fragmentTransaction = 
            ExampleFragment fragment = new ExampleFragment();
            fragmentTransaction.add(, fragment);
        } else {
            // Don't add the fragment!
            // (and use savedInstanceState to restore Activity state)

If you fail to include this check, you might end up in a very strange state where you have overlapping Fragments in the same container. 

That's all for today's protip! For more information on Fragments, see the Fragments API Guide at and our training lesson at
Vladimir Bjelakovic's profile photoBilly Leigh's profile photoByron Jones's profile photoPaul Parenko's profile photo
John P.
Nice! This is how I've always handled it, it's good to know that this is the correct way to do it.
+Sirack Hailu No, you can optionally add a tag to fragments if you need to keep track of them. 
What about when replacing fragments? Similar check code needed?
What if I a tab, it creates a fragment and this fragment will then create another fragment, if this fragment pop back or recreated, they are overlanpped. So does it mean i have to check null on savedinstance even on a fragment oncreate method ? 
+Michael Vogt Yeah, if your have fragments added at all to an activity. Replace is just an easy remove/add methods put together. 
Nice article. However I am still upset that google made the while development a lot harder with fragments. There are so many gotchas its not funny. For example you can only modify fragments when called from Activity.onResumeFragments rather than from onResume. Also the fact that getActivity can return null (eg in cases where you are doing things in an asynctask doesn't help either). 
+Rainer Burgstaller It's up to you to use them or not. I think they are a great addition and make development, especially for multiple screens, a lot easier. There are some things that you should be careful about but it's worth it.
+Zhelyazko Atanasov we both agree that they are a useful addition. However, IMHO they could have made the usage a lot easier, i.e. the usage of Fragments is far from easy. Look at the weird bit of code where you have to check in onCreate whether you came from a new launch or from a re-launch. If you know about it, its not a big deal, however, for newcomers to the platform, this is a neck breaker and produces weird issues that are difficult to debug!
IMHO they should have removed some of the features in order to reduce complexity. e.g. the fact that you can use non-visual Fragments to retain your instance state feels like an arbitrary hack. Just because you can do it with fragments does not mean that you SHOULD use the fragment architecture. They simply should have introduced some other functionality which specifically serves that feature. This would probably have been simpler to learn and understand.

So enough of the ranting :)

I personally do use Fragments but getting to know all the nuts and bolts is difficult and reduces the approachability of android.
On one hand this is good for professionals like us, on the other hand its painful and expensive for newcomers.
+Rainer Burgstaller I disagree with you. It's not hard. But I do think a little more documentation and examples would have helped :-)
Nice tutorial.But how to pass an object when instantiating the fragment from activity?
Add a comment...