from some of the answer such as
Using getFragmentManager() vs getSupportFragmentManager()?
I find that getFragmentManager() is used for API>=14,
and getSupportFragmentManager() will be used in support lib such as v4 which also support older API.
So my question is should I just use getSupportFragmentManager (import the support.v4 for each classes) so that my application can be used in any API version?
And are there any different I should know between these 2 FragmentManager?
If you are interested in supporting API versions that do not have Fragments, then by all means use the FragmentActivity and getSupportFragmentManager() patterns.
Even if you are not targeting an API below 14, it may be a good idea to use the support library. Classes in the support library can be updated by you, the developer, whenever Google releases a bugfix/feature in the library that you are interested in. If you use a framework class, you only get the updates when your users get a firmware update, which we all know can take a while. Using the support library means all users are using the same "latest-and-greatest" classes.
Yes, for Fragment, just use getSupportFragmentManager, then your app for Fragment can be compatible backward to old API levels, normally minSDKversion = 7 is enough. However if you really want your app to get compitability with most API levels, then there still many other components your app concerning need use support library, such as ActionBar, etc..
For more info, please go through Android Docs: Support Library Features
Related
We have an app which has minimum SDK level set to API 21. We are currently using support fragments and are now discussing migrating to native fragments.
This discussion of the move towards native fragment is because support fragment is meant for lower API devices which don't support native fragments. Now that every device has fragment and they seem stable. So why not migrate to native fragments for leaner implementation.
New features will hopefully be supported for native fragments with support library v13's FragmentCompat, things like ViewPager are already present in support library v13. But platform specific bugs will require API specific handling.
On the other hand with support library v4's Fragment we get
Backward compatibility with features e.g. runtime permissions.
Consistency across all the platforms as it uses the same implementation across platforms. No platform specific handling.
All new methods in next android version are available to use across all the platform.
Support library is released more frequently than Android platforms. So bug fixes will be faster and we'll have more control when pushing that fix. Don't need to wait for OEMs to update each phone but rather update the support library in the app.
But are these benefit enough to hang on to the old code which is meant for devices with API level less than 11?
This should help you decide as it's now the official Android Team stance:
Fragment
This class was deprecated in API level P.
Use the Support Library Fragment for consistent behavior across all devices and access to Lifecycle.
Source: https://developer.android.com/reference/android/app/Fragment
But are these benefit enough [...]?
Absolutely, you want the consistent behavior without having to cater to each API level and vendor specific quirks.
Android dashboards show that only half of devices have Android 5.0 and above, but numbers look different for our customer data set - it's over 93% of our users. So we've decided to abandon support for devices with Android version lower than 5.0 and change minSdkVersion from 15 to 21.
This upgrade require from us to review all of obsolete functionalities and clean some hacky workarounds which we applied to support older versions. One of main functionality which we can apply now is to replace android.support.v4.app.Fragment with android.app.Fragment. It sounds like good idea, especially when we know that fragment API had been reviewed and improved.
Just to make sure that I’ll take right path and android.app.fragment won’t surprise me I would like to paraphrase question from this stackoverflow thread - Are you using fragments from the support library, even though they are already available, when developing for Android 5? Are there any bugs in fragment API which occur on Android 5.0 and above and were fixed in support library?
Update
After Android-KTX release, Jake Wharton made the following statement in one of PRs:
Thanks for taking the time to make the PR (with tests!), but we would like to encourage that developers only use the support library fragments. The next version of Android will deprecate the version of fragments that are part of the platform. Thus, we aren't going to add any extensions to support them in this project.
So using fragment from support library is the right thing to do.
I would suggest using the support library fragments anyway, for a few reasons:
Future features may be added and backported, and then you'd need to rewrite to use them
Consistency. The support library works to make sure support fragments always work the same. Whereas the native fragments may have subtle differences between versions.
The support library can contain bug fixes to the platform and can be updated much more frequently.
Edit: As of 2018, the OS level Fragment is deprecated. Google's path forward technically is to do less in the OS library and more in add ons. So for Fragment this is absolutely now support library, and likely to go this way for more items.
We started a fresh Android app few months back and we were wondering the same thing.
IMO, you should always try to use android.app.Fragment if it is possible. This way, you are certain that Android developers optimize, update and support this API and they will give you a quality product.
Right now, we are using android.support.v4.view.ViewPager and other similar components that provide different functionality in Support library than in the normal API.
I came across the ViewPager and the related FragmentPagerAdaptor which are not part of the regular Android packages, but only available in the V4 support package. It seems I cannot use the FragmentPagerAdaptor with a android.app.Fragment since the FragmentPagerAdaptor requires a v4 FragmentManager to instantiate. Reading Difference between Activity and FragmentActivity this seems to be aligned - use either v4 Fragments and related classes or the regular android.app.Fragments. Never mix.
Taking it further, I see no need to use the regular android.app.Fragments at all since they are less powerful than the v4 support packages. (Cite from another question: The Android Support package is not only for backports of newer APIs. It is also for other classes that, for whatever reason, are not being added to the SDK, such as ViewPager and its supporting classes.). The "only" downside I can think off is that the v4 support libraries is bundled with the APK which means my app will take up more space.
Am I correct to conclude that I should always use v4 support libraries for fragments since those include more functionality? (And they are backwards compatible, not to forget.)
I just realized that it is possible to use the android.app.Fragment and the android.support.v4.view.ViewPager together... If you use the android.support.v13.app.FragmentPagerAdapter... So it seems that the v13 support package solves/improves the compatibility issues between android.app.Fragment and android.support.v4.view.ViewPager. What a mess.
While this resolves the particular example I came up with, I am still wondering if the best option is to always use v4 classes when they are available instead of the build-in classes (e.g. android.app.Fragment) even if I am only worried about ICS and newer devices?
In terms of backwards compatibility, indeed using the v4 support package version is the best approach.
As the shift of devices moves towards the operating systems that have the functionality built in it will probably become easier to use the SDK version, as all of the functionality found in the support package will be included in the SDK.
For now, stick with v4 to offer support for 2.2/2.3 devices which still hold a large share of the Android device pie
SO here is my understanding of the purpose of importing fragment library(the v4.jar).
Because the developer wants to use and follow the new Fragment's way of coding, but using this will result compatibility issue on older devices that runs on android 2.xx, therefore, in the project that uses fragment, the developer has to import the v4.jar library so that the older devices know what fragment APIs and are able to call them in the app.
If this is correct, I suppose after importing the library, the android:minSdkVersion should be able to set to older version such as 8 (93% of the market), not l0, because the project had already import the library.
But When I am using the method from the fragment, for example, the instantiate method, I got this error:
Call requires API level 11 (current min is 8): android.app.Fragment#instantiate
So apparent the sdk wants me to switch my android:minSdkVersion to 11, but then what is the purpose of importing the library? And by doing so older device that running on android 2.xx will not be able to use this app.
Can someone explain this issue ?
It sounds like you're importing the wrong Fragment library.
This one requires API level 11 (Android 3.0):
http://developer.android.com/reference/android/app/Fragment.html
This one, as available in the support library, requires API level 4 (Android 1.6):
http://developer.android.com/reference/android/support/v4/app/Fragment.html
Also, you should be aware that you need to use the FragmentManager available in the support library.
There are no drawbacks to using the support Fragment APIs on Android 3.0+.
I have searched a bit around for a pager for fragment , I develop on ICS API.
I know about ViewPager and all the support libs for earlier version but i don't get why I should use a support library consider the fact that I use the lastest version of the api and don't plan to support earlier version.
Do I have to write the "ViewPager" myself or is there something i didn't see in the api.
Does the Android ICS API have a native equivalent to ViewPager support lib?
No.
I know about ViewPager and all the support libs for earlier version but i don't get why I should use a support library consider the fact that I use the lastest version of the api and don't plan to support earlier version.
The Android Support package is not only for backports of newer APIs. It is also for other classes that, for whatever reason, are not being added to the SDK, such as ViewPager and its supporting classes.
Do I have to write the "ViewPager" myself or is there something i didn't see in the api.
You are welcome to write your own implementation of a view paging component. Savvy programmers would use the one in the Android Support package, since it is already written and (mostly) debugged.
UPDATE: Note that ViewPager works just fine with pages that are:
API Level 11+ native fragments
Android Support backported fragments
arbitrary Views
For the first case, you need the v13 version of the support JAR, which contains v13 versions of the FragmentPagerAdapter and FragmentStatePagerAdapter classes.