Develop Reference

ViewBinding - How to switch/choose layout dynamically (<include>)?

I was planning on having two layout versions for the profile fragment, one for new user and one for logged in user.
How would I dynamically switch/choose the necessary layout in the Fragment's onCreateView() method?
The most straight-forward idea that comes to mind is to use two <include> layouts and hiding one of them in onCreateView() depending on variables. But I was wondering if there is a smarter approach.
Current layout xml:
The main content is inside the second FrameLayout and I'd like to have two versions to choose from.
<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".ui.MainActivity">
<ImageView
android:id="#+id/profile_monk_head_imageview"
android:layout_width="match_parent"
android:layout_height="200dp"
android:contentDescription="#string/profile_monk_image_content_desc"
android:src="#drawable/monk_head" />
<androidx.core.widget.NestedScrollView
android:layout_width="match_parent"
android:layout_height="wrap_content">
<!-- This is what I want to switch out -->
<FrameLayout ... >
</androidx.core.widget.NestedScrollView>
</FrameLayout>

Use DataBindingUtil version inflate if layoutId is unknown in advance ( a.k.a dynamic binding). Otherwise, use the generated Binding's inflate method to ensure type-safe inflation.
Crosslink reference

Is it legal to use a static fragment inside another fragment?

Is it legal to use a static fragment inside another fragment.
I just want to reuse an old fragment and add some design to it.
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:id="#+id/fragment_container"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="#000" >
<fragment
xmlns:android="http://schemas.android.com/apk/res/android"
android:name="com.example.android.camera2video.Camera2VideoFragment"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:id="#+id/camera_fragment">
</fragment>
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="Hello from another fragment"
android:layout_centerInParent="true"
android:textColor="#ffffff"
android:textSize="18sp"/>
</RelativeLayout>

You shouldn't do this. It is explicitly called out as something that won't work in the documentation about nested Fragments:
Note: You cannot inflate a layout into a fragment when that layout includes a <fragment>. Nested fragments are only supported when added to a fragment dynamically.
See https://developer.android.com/about/versions/android-4.2.html#NestedFragments
Create a container to hold that Fragment instead and add it programmatically using the parent Frament's FragmentManager returned by getChildFragmentManager.

Yes, that's fine. Now doing a transaction and replacing a nested fragment has some issues.

Z-ordering of child views with respect to their parent

Background
In my app I have a lot of fragments that share the same static overlay. Each fragment can be resized dynamically (i.e. its weight may change) so I want the size of my overlay to be in sync with it. Therefore it makes sense to either make them siblings or, as it occurred to me, put one inside another. The first approach works fine but it implies introducing one extra ViewGroup which seems redundant (or does it not?). The latter is the one I'm having problems with.
Problem
Consider these two layouts.
Container R.id.container is where I put my fragment in runtime with FragmentManager.
Fragment R.id.overlay is my overlay.
The difference is which one is the parent.
Layout A.
<FrameLayout
android:id="#+id/container"
android:layout_width="match_parent"
android:layout_height="match_parent">
<fragment class="com.example.OverlayFragment"
android:id="#+id/overlay"
android:layout_width="match_parent"
android:layout_height="match_parent" />
</FrameLayout>
Layout B.
<fragment class="com.example.OverlayFragment"
android:id="#+id/overlay"
android:layout_width="match_parent"
android:layout_height="match_parent">
<FrameLayout
android:id="#+id/container"
android:layout_width="match_parent"
android:layout_height="match_parent" />
</fragment>
In both cases my overlay ends up below container (by z-axis). That is, container keeps overlapping it regardless of its role in hierarchy.
What are the rules for defining views's z-order in situations like this? Is it just the order of their initialization? I couldn't google it out.
Thanks.

From documentation:
When the system creates this activity layout, it instantiates each
fragment specified in the layout and calls the onCreateView() method
for each one, to retrieve each fragment's layout. The system inserts
the View returned by the fragment directly in place of the
element.
So I think you should use something like this:
<FrameLayout
android:layout_width="match_parent"
android:layout_height="match_parent">
<FrameLayout
android:id="#+id/container"
android:layout_width="match_parent"
android:layout_height="match_parent"/>
<fragment class="com.example.OverlayFragment"
android:id="#+id/overlay"
android:layout_width="match_parent"
android:layout_height="match_parent" />
</FrameLayout>

Use ViewStub as generic layout in android

As I mentioned in the title, I would like to use ViewStub as a generic layout. What I mean is, currently I have my base activity class and base fragment class to be extended for other activities or fragments. So since I have generic classes, I wonder if I can have a generic layout. Is it possible?
Example layout:
<?xml version="1.0" encoding="utf-8"?>
<android.support.design.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:fitsSystemWindows="true"
tools:context=".activities.Activity_Main">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical">
<include layout="#layout/toolbar" />
<ViewStub
android:layout_width="match_parent"
android:layout_height="match_parent"
android:id="#+id/viewStub"
/>
</LinearLayout>
</android.support.design.widget.CoordinatorLayout>
Where #+id/viewStub content will change according to desired layout.

Yes, you can do that programmatically by using the setLayoutResource() method to which you pass the desired layout id.
ViewStub stub = (ViewStub) findViewById(R.id.viewStub);
stub.setLayoutResource(R.layout.some_layout);
View inflatedLayout = stub.inflate();
When inflate() is invoked, the ViewStub is replaced by the inflated View and the inflated View is returned. This lets applications get a reference to the inflated View without executing an extra findViewById().
Here is the reference.

Z-Layering Fragments in Android

It's is possible to "stack" fragments on top of each other?
Just tried to do this without really thinking about it and everything got kinda crazy.
I can (and probably should) create a ViewGroup instead if it's not possible, but I was just wondering.

Yes, it's possible. E.g. by wrapping them inside a FrameLayout like this:
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
<fragment android:name="com.package.FragmentOne"
android:layout_width="match_parent"
android:layout_height="match_parent"
/>
<fragment android:name="com.package.FragmentTwo"
android:layout_width="match_parent"
android:layout_height="match_parent"
/>
</FrameLayout>
The z-index depends on the order of the children within the layout. In this example FragmentTwo is above FragmentOne because it's the second child.