Before we get any deeper into using Fragments with Android Studio we need to clear up a messy but vital topic - the support library.
A number of the newer features in Android are supported on older versions by the use of a support library that has to be compiled into the project. If you decide to support earlier versions of Android then the support library will make your app a bit bigger than it needs to be on the latest version of the operating system.
However, the cost of not using the support library is that your app won't work on early Android versions, those prior to Android 3, Honeycomb. Most programmers decide that the support library is worth the inconvenience of larger code so as to enable one runtime package to work on the widest possible Android devices.
Other programmers make the argument that using native code in the OS, i.e. not using the support libraries, results in a smaller and better app.
All of this said, there is the small matter that the support library seems to implement Fragments better than the OS and there are features that are implemented in the support library and not the OS.
Google seems to recommend using the support library in preference to native support. While it is difficult to get a definitive answer on this point, there are places in the documentation where using the support library is considered best practice and most of the official examples make us of it.
Overall using the support library seems like the best option for the near future at least.
To use the support library you have use imports like
You don't have to change your AppCompatActivity class, as suggested in the documentation, because it already inherits from FragmentActivity or one of its child classes that support other newer features such as ActionBarActivity. You can use the AppCompat support library with the v4 support library and they work together well.
In the remainder of this and other chapters we will use the support library. You can easily change to native OS support and most of the examples should work. The one thing you cannot do is mix support library Fragments and native OS Fragments. The problem is that Android Studio has a tendency to use both the native and the support library versions in the code that it generates. If something isn't working then the first thing you should always check is that the imports are consistent cross different Java classes in your program.
When you use the New, Fragment command the code generated automatically uses the support library:
If you want everything to work you need to make sure that you use the support library when you include Fragments in other code.
A Fragment can create a UI either in code or by inflating an XML Layout.
Using code gives you a dynamic UI and using XML gives a static UI. The overall principles are the same, but there are some differences of implementation.
The Basic Activity Template can base its UI on a Fragment. It creates a class file and an XML file and places the Fragment in the content_main.xml file.
Once you have a Fragment based on an XML file you can edit its UI in the Designer.
You can also edit the Fragment as a component within other layouts using the Designer.
If you want to add additional Fragments you can do the job with the New,Fragment command - which creates a class file and optionally an XML file.
If you want to support Android systems before Honeycomb you need to make use of the support libraries. This involves making two changes to your code and importing the support libraries.
Even if you don't want to support Android systems before 3.0, it is still advisable to use the support library as it is considered best practice and it has features not in the native Fragment implementation.
The two ways of getting a Fragment into a UI are in principle the same, but in practice there are some important differences between static and dynamic Fragments and we need to understand them.