Develop Reference

Which Activity / Fragment / FragmentManager?

I am new to Android programming and I am totally lost about from which Activity and Fragment version i shall derive and which FragmentManager I shall use.
I want to support API level 15 and above and I want to use androidx/Jetpack.
So, from which Activity implementation should my MainActivity derive? And from which Fragment implementation shall my fragments derive? Which FragmentManager implementation shall I use?
Thanks!

The activity should derive from AppCompatActivity.
From https://codelabs.developers.google.com/codelabs/kotlin-android-training-app-anatomy/index.html?index=..%2F..android-kotlin-fundamentals#2
AppCompatActivity is a subclass of Activity that supports all modern Android features while providing backward compatibility with older versions of Android. To make your app available to the largest number of devices and users possible, always use AppCompatActivity.
In general, as a rule, you should have a look at the package, if there is a androidx package (previously it was android support) which has the class type you are looking for use this one, as they have backwards compatibility.
Another way of knowing which activity to use is using the android studio menus, if you create a new activity (File / New / Activity / Basic activity) you can see that the generated file uses androidx.appcompat.app.AppCompatActivity.
The same goes for the fragments Fragment (File / New / Fragment) and then you go to the source file you can see androidx.fragment.app.Fragment in the imports. Use this one.
And about the FragmentManager if you search for an androidx package with FragmentManager you'll get androidx.fragment.app.FragmentManager.
Quoting https://codelabs.developers.google.com/codelabs/kotlin-android-training-images-compat/#5
Tip: In general, if your app can use a compatibility class from the Jetpack libraries, it should use one of those classes, because those classes provide support for the largest possible number of features and devices.
refering to classes with the androidx namespace.

AppCompatActivity design

Why doesn't AppCompatActivity's getFragmentManager() return a support version of the fragment manager? Instead you have to both make your Activity an AppCompatActivity AND specifically call getSupportFragmentManager(). The same is true for a dozen other methods. It bugs me that you have to magically know which methods you can call as themselves, and which you have to rebrand as the "support" version. Is there even any use case for wanting to call the "normal" version instead of the "support" version, when you're still supporting lower versions of Android? It'd make a lot more sense to me if AppCompatActivity functioned indistinguishably from the later API versions of Activity - after all, that's what it's SUPPOSED to do, isn't it? Provide the same functionality as the later API versions of Activity?
Is there some kind of design principle or hidden Java limitation that prevents them from doing so?

Why doesn't AppCompatActivity's getFragmentManager() return a support version of the fragment manager?
Because it can't.
Activity, on API Level 11+, defines getFragmentManager() as returning an android.app.FragmentManager. The only way that AppCompatActivity could override it is if the overridden method also returns an android.app.FragmentManager. That's not possible. AppCompatActivity is designed to work back to API Level 7, where there is no android.app.FragmentManager to return. Hence, we have getSupportFragmentManager(), returning an android.support.v4.app.FragmentManager.
Note that AppCompactActivity really gets its fragments from FragmentActivity, which is designed to work back to API Level 4, two years before API Level 11 and native fragments were implemented.

What is difference between FragmentActivity and Activity?

I have used it in my basic code replace activity by fragment activity,but i have not got any kind of error.Application has working.

As seen in the documentation:
FragmentActivity
Base class for activities that want to use the support-based Fragment
and Loader APIs.
Activity
An activity is a single, focused thing that the user can do. Almost all activities interact with the user, so the Activity class takes care of creating a window for you in which you can place your UI with setContentView(View). While activities are often presented to the user as full-screen windows, they can also be used in other ways: as floating windows (via a theme with windowIsFloating set) or embedded inside of another activity (using ActivityGroup)
Can see more at : http://developer.android.com/reference/android/support/v4/app/FragmentActivity.html

A fragment activity can contain fragments (as it's name implies). It's the support version of activities for older APIs, which want to use fragments.

A Fragment , introduced in Android 3.0 HoneyComb is a portion of a user interface inside an activity. You can have many fragments in you UI.
FragmentActivity is the base class you must extend in order to use fragments with the support library.

The nuance here is that an Activity can use Fragments from the native SDK (as long as you are targeting API 11+), while a FragmentActivity can use Fragments from the support library.
So, assuming API 11+, if you are using android.app.Fragments in your app, you can use Activity, but if you are using android.support.v4.app.Fragments in your app, then you must use FragmentActivity.

What is the difference between Fragment and FragmentActivity?

My question is apart from the obvious inheritance differences, what are the main differences between Fragment and FragmentActivity? To what scenarios are each class best suited? I'm trying to get an understanding of why both of these classes exist...

A Fragment is a section of an Activity, which has:
its own lifecycle
receives its own input events
can be added or removed while the Activity is running.
A Fragment must always be embedded in an Activity.
Fragments are not part of the API prior to HoneyComb (3.0). If you want to use Fragments in an app targeting a platform version prior to HoneyComb, you need to add the Support Package to your project and use the FragmentActivity to hold your Fragments. The FragmentActivity class has an API for dealing with Fragments, whereas the Activity class, prior to HoneyComb, doesn't.
If your project is targeting HoneyComb or newer only, you should use Activity and not FragmentActivity to hold your Fragments.
Some details:
Use android.app.Fragment with Activity. Use android.support.v4.app.Fragment with FragmentActivity. Don't add the support package Fragment to an Activity as it will cause an Exception to be thrown.
A thing to be careful with: FragmentManager and LoaderManager have separate support versions for FragmentActivity:
If you are using a Fragment in an Activity (HoneyComb and up), call
getFragmentManager() to get android.app.FragmentManager
getLoaderManager() to get android.app.LoaderManager
if you are using a Fragment in a FragmentActivity (pre-HoneyComb), call:
getSupportFragmentManager() to get android.support.v4.app.FragmentManager.
getSupportLoaderManager() to get android.support.v4.app.LoaderManager
so, don't do
//don't do this
myFragmentActivity.getLoaderManager();
//instead do this:
myFragmentActivity.getSupportLoaderManager();
or
//don't do this:
android.app.FragmentManager fm = myFragmentActivity.getSupportFragmentManager();
//instead do this:
android.support.v4.app.FragmentManager fm = myFragmentActivity.getSupportFragmentManager()
Also useful to know is that while a fragment has to be embedded in an Activity it doesn't have to be part of the Activity layout. It can be used as an invisible worker for the activity, with no UI of its own.

FragmentActivity is our classic Activity with fragment support, nothing more. Therefore FragmentActivity is needed, when a Fragment will be attached to Activity.
Well Fragment is good component that copy the basic behaviors of Activity, still not a stand-alone application component like Activity and needs to be attached to Activity in order to work.
Look here for more details

Think of FragmentActivity as a regular Activity class that can support Fragments. Prior to honeycomb, an activity class could not supoprt Fragments directly, so this is needed in activities that use Fragments.
If your target distribution is Honeycomb and beyond you can extend off of Activity instead.
Also a fragment is to be considered as a 'sub-activity'. It cannot exist without an activity. Always think of a fragment as a sub-activity and you should be good. So the activity would be the parent and the fragment(s) the child kind of symbolic relationship.

a FragmentActivity is an ad-hoc activity that contains Fragment.
In these few words I have explain you one of the main important changes that, with android 3.0(HoneyComb), android team has inserted in the android sdk.
With these new kind of concept your pieces of code and layout becomes more flexible and maintainable. If you search on google there are a lot of examples.

Difference between Activity and FragmentActivity

I was working on fragments and came across two things Activity and FragmentActivity which are used several times. I want to know that is there any difference between these two, because when I changed Activity with FragmentActivity, it had no effect on the app.

A FragmentActivity is a subclass of Activity that was built for the Android Support Package.
The FragmentActivity class adds a couple new methods to ensure compatibility with older versions of Android, but other than that, there really isn't much of a difference between the two. Just make sure you change all calls to getLoaderManager() and getFragmentManager() to getSupportLoaderManager() and getSupportFragmentManager() respectively.

FragmentActivity is part of the support library, while Activity is the framework's default class. They are functionally equivalent.
You should always use FragmentActivity and android.support.v4.app.Fragment instead of the platform default Activity and android.app.Fragment classes. Using the platform defaults mean that you are relying on whatever implementation of fragments is used in the device you are running on. These are often multiple years old, and contain bugs that have since been fixed in the support library.