Fragments Within Fragments

Fragment Inside Fragment

AFAIK, fragments cannot hold other fragments.

UPDATE

With current versions of the Android Support package -- or native fragments on API Level 17 and higher -- you can nest fragments, by means of getChildFragmentManager(). Note that this means that you need to use the Android Support package version of fragments on API Levels 11-16, because even though there is a native version of fragments on those devices, that version does not have getChildFragmentManager().

Android adding Fragment inside Fragment

Try to use FrameLayout instead of LinearLayout as Placeholder.

fragment inside fragment {Kotlin}

If you are adding fragment for an activity you use either fragmentManager or supportFragmentManager.

If you are adding fragment for a fragment - you should use childFragmentManager, accessing fragmentManager from fragment will lead to using the same one that activity does.

Fragments within Fragments

Nested fragments are not currently supported. Trying to put a fragment within the UI of another fragment will result in undefined and likely broken behavior.

Update: Nested fragments are supported as of Android 4.2 (and Android Support Library rev 11) : http://developer.android.com/about/versions/android-4.2.html#NestedFragments

NOTE (as per this docs): "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."

To Fragment or not to Fragment - Nested Fragments against Activities. Why should I use more than one Activity?

First off, I will agree with you that it is possible to write a huge application using only one activity and nested fragments. That's the fun of software - you can achieve the same functionality using a variety of approaches. For me, the choice to use multiple activities comes down to my personal preferences for encapsulation, reusability, and testability.

If I have a widget that can be reused in other applications, I make it a Fragment. For example, my app features a "sync with server" button and I have created a custom Fragment that uses Progress Bars to visually show the synchronization process. It's easy to imagine another application being able to use this widget, so that's why I developed it as a Fragment.

If I am switching tasks within my app, such that the new task is conceptually independent of the previous task, then I use a new activity. For example, the first page of my app asks you to select a user. Once you've clicked on a user, I send you to the main menu for that user. This main menu for the user is displayed in a new activity.

Now let's imagine a large, complex app, and a team of developers assigned to develop that app. If the app can be divided into separate activities, it is conceptually very easy to divide up the tasks. Each activity is its own sandbox, so parallel development is simple and unit-testable. If there are any common needs, the team should still develop Fragments and reuse them, of course. I should add that code reuse does not happen often enough in software development, but if done right, there should be a lot of reusable Fragments.

Now suppose it is time to test the app. Your testing team can treat each activity as its own black box. This is easier to test than a single huge app that relies on a single activity and tons of nested fragments. This is especially important if a bug exists. If a bug exists that is not obvious, at least I know the scope of the bug is limited to a single activity out of many.

In summary, my guess is that you are developing your app as an individual, and therefore your development decisions do not affect anybody else. Your perspectives would likely change if you were developing an app with a larger team, and I hope my response makes a lot of sense in that light.