Develop Reference

What are the advantages of adding a fragment via XML vs programmatically?

From the Android documentation it's not very clear to me which are the advantages and practical use cases of adding fragments via XML compared to adding them programmatically.
Do both methods allow sending data from the activity to the fragment and back using Bundle?
Can both methods behave similarly in the activity lifecycle?
Some short examples or references will surely help.

Both the methods have only slight difference. If you add fragment in XML, then you are first loading or creating it then you will get its instance and vice-versa for the other approach.
Also, programmatically adding fragment gives you advantage of changing its attributes dynamically whereas you have fixed values if you add it from XML.
Not that much major difference it has.

With FragmentContainerView and using the android:name or android:class, you can avoid the boiler plate code of instantiating the fragment only when savedInstanceState is null or when it is not already added.
If you do that programmatically, you need to make sure that you only add the fragment if it is not already added to the activity by checking:
if (getSupportFragmentManager().findFragmentByTag(CUSTOM_TAG) != null)
{
// You can also easily add animations or pass custom data.
getSupportFragmentManager().beginTransaction().add(R.id.container_view, YourFragment.newInstance(data), CUSTOM_TAG).commit();
}
Programmatically doing it gives you advantages of passing custom data, adding it when you actually need it. In case of layout method, it will be instantiated when the activity's layout gets inflated. But many times, we don't need to add a fragment immediately, adding it programmatically would be a better option in that case.

No difference at all. Android has a system for instantiating objects from XML, but it's always interchangeable with actually executing constructors and the methods to add children. The difference is convenience: The XML system allows you to easily link other resources and it has features to help with passing the right parameters.

Is every activity/fragment's xml implicitly wrapped around with a FrameLayout?

Let's say in an activity's xml it's using a LinearLayout as its root layout. And the activity during runtime wants to show a dialog/dialog fragment. Wouldn't the activity's xml have to be implicitly wrapped around with a FrameLayout for this to work due to needing to control the Z axis of views? Like you open the activity's xml and you see LinearLayout. However, behind the scenes, it's wrapped in a FrameLayout. Is this correct?

No, it's not.
It's complicated, and I'm honestly unable to properly explain it, but every Activity is placed in its own Window. Every Dialog attached to that Activity uses the Activity's Window to display itself.

Assistance needed Understanding Android fragment addition during onCreate

I just need help cleaning up some information that doesn't make sense to me, with use cases if possible.
WHAT I UNDERSTAND:
With fragments in android, I understand that if you plan on replacing them you need to have a container view, preferably a FrameLayout, and add the initial fragment to the container during the activities onCreate method. But there is one thing that continues to not make sense to me.
WHAT I DON'T UNDERSTAND AND NEED HELP WITH:
What rules are there regarding where/how the container view is set up, if there are any. Android Developers site makes it look like the container view needs to be it's own XML layout file, but it doesn't say that and I have seen examples on here with FrameLayouts nested inside of your typical layout files, but they are all specific uses and I need to understand the rules of setting a container up.

There are no rules. You just need any ViewGroup -- position and size it however you want. When you add the Fragment into it, it will behave just as if you'd created the Fragment's View manually, and called yourViewGroup.addView(fragmentView).
FrameLayout is typically used just because it makes a good container with no real behavior (you just give it a size and position and let the fragment fill that container).
There's absolutely no need to make the container view its own layout file. In fact, if you want the Fragment to take over the content view of the entire Activity, you could even just add the Fragment to the Activity using the ID android.R.id.content.

Should accessing views done from onStart or onActivityCreated method?

I have read several documents about this but still fail to conclude where should I write my codes to set some values in textviews/edittext ...
what i have read and seen in video tutorials is, both onStart and onActivityCreated methods get called with different actions (like after fragment initiated, or orientation changed etc.). Moreover, both of them get called after Activity's onCreate method, which means views are available from both Fragment methods.
Anybody can give me some advise regarding this?
(p.s. Currently I put all codes accessing xml views inside onStart, and my application is running without any issue)

I don't know of any potential problems with accessing your layout's views in onStart or onActivityCreated.
Personally, I usually set references to my layout's views and set initial values in a fragment's #onViewCreated(). This is the first opportunity after the layout has been inflated that you have to access a layout's children. The View that was inflated is passed as a parameter so you even have direct access to the parent layout object if you needed it for some reason.
According to the fragment lifecycle onActivityCreated() will be called next and then onStart(). All of these will be executed in that same order when a fragment is returned from the back stack -- so it seems to be personal preference.

Fixed view through various activities in Android

How do you implement a fixed view through various activities in Android 2.1 upwards? By fixed I mean that the view should retain its state when the activity changes.
In particular, I'd like to have an Admob AdView on top of every activity without reloading the ad every time the app starts a new activity.

I don't think it is possible using different activities. But you could use only one activity and split your screens through multiple fragments inside this activity and adding/removing them while keeping your fixed view untouched.

This is not possible. The Activity is the basis of the app's user interface, and every View must live within the Activity's parent ViewGroup. Since every Activity must be created when it is initially launched, every View that lives inside the Activity must be inflated and attached to the Activitys layout.
What you could do instead is pass the information required to instantiate the specific admob View to the next Activity with an Intent.