Static Fragments vs. Dynamic Fragments

Question

There is a big difference in using fragments through XML or dynamically through java code, depending on which you chose the main difference will be on how the user experiences the flow of the app.

TLDR: the below characteristics are shared both by fragments instatiated through XML and dynamically with java code (through FragmentManager API), but the Java code allows you to change, add, remove each fragment in runtime, allowing for a flexibility that would be impossible otherwise.

But to answer your question:

1 - Maintainability - about the same, you use the android:name attribute to define the fragment class you want to use VS using:

// get fragment manager
FragmentManager fm = getFragmentManager();

// add fragment
FragmentTransaction ft = fm.beginTransaction();
ft.add(R.id.your_placehodler, new YourFragment());
// alternatively add it with a tag
// trx.add(R.id.your_placehodler, new YourFragment(), "detail");
ft.commit();

In the case of only one transaction, there is barely any effort either way.

2 - Compatibility: about the same, both are frequently used by developers everywhere

3 - Performance, the one time inflation process could be a little faster but they are essentially even.

4 - UX: here depending on your needs, there could be no difference or a huge one.

So what's this big difference between XML or "dynamic fragments"?

Fragments instantiated through direct XML inflation cannot be dynamically managed on runtime through FragmentManager.

As an example, this means that once you inflate the fragment/layout you cannot send it to backstack and quickly bring another one upfront. Dynamic management of fragments can be used to give that fast single-flow experience inside one multipurpose activity to the user that is impossible to get if you are jumping from one activity to the next.

After the initial FragmentTransaction above, you have the absolute freedom to reuse the same layout container for other fragments very quickly

// replace
FragmentTransaction ft = fm.beginTransaction();
ft.replace(R.id.your_placehodler, new YourFragment());
ft.commit();

// remove
Fragment fragment = fm.findFragmentById(R.id.your_placehodler);
FragmentTransaction ft = fm.beginTransaction();
ft.remove(fragment);
ft.commit();

"So why do we have XML instantiated fragments? We should ban them right now!"

Not so fast, if for example your purpose is simply to have a multi-pane window/layout in your app that won't change too much during its lifetime (ie. if you can stick with that layout until dismissing the activity) xml inflation would have no drawbacks and depending on the amount of fragments you could be spared a lot of boilerplate FragmentTransactions code.

Another important use case could be to simply be prepared for the use of a different device Configuration such as screen size, or different screen orientation (like when using the app both on tablets and phones portrait/landscape), XML is a simple solution for providing a different layout for each of these (and other) device configurations.

Sources: link

link