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.
Related
Could you please help me with this question?
When I create a new project I see MainActivity extending the Activity class or AppCompatActivity. Why does this happens? What is the reason behind changing the default settings of android project everytime? What are the other classes that MainActivity can extend? I would appreciate any help.
Actvity has support for system ActionBar which was introduced in Android 3.0 (API level 11).
AppCompatActivity has interface to work with ActionBar from support library and can be used with API Level 7).
If you want to support some features like actionbar, to lower API level of android so use AppcompateActivity.For example, if you extend youractivity with Activity class then you can not use actionbar in api level 7 because actionbar feature added in api level 11.
AppCompatActivity provide backward compatibility for new features
I see MainActivity extending the Activity class or AppCompatActivity.
Well it depends on you what type Activity you uses in your project.when you creates a new project it asks for Activitytype. like FragmentActivity etc.
I am making an app which should have minSdk = 15 and targetSdk = 21, therefore I want to use the features provided by the appcompat-v7 library.
I always wondered if I should use getFragmentManager or getSupportFragmentManager when using the supportlibrary-v7.
I am encountering a small problem now: when using getFragmentManager (and therefore using the framework fragments and fragmenttransaction) I wasnt able to pop the backstack by simply pressing the backbutton - I had to do a backStackCount > 0 check and manually popBackStack, otherwise my activity was simply finished. This problem was solved when I switched my small app to use the v4 classes (getSupportFragmentManager etc.). Which is fine I guess, but I would like to have a guideline/bestpractice to know which way to go and why
So, my Activity is inheriting from ActionBarActivity (according to AppCompat-Blog-Entry) and I am using the new toolbar, should I use only v4-Fragments(-Manager, -Transactions)?
I havent found any best practices or guidlines for that. And I am unsure about what to consider when deciding between these two :-/
If you are inheriting your activities from ActionBarActivity you should always use getSupportFragmentManager(). It automatically forwards your calls to getFragmentManager() if the phone supports it (runs Honeycomb or later), otherwise it uses its compatibility implementation.
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.
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.
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.