When to use PreferenceFragment and PreferenceFragmentCompat? - android

I am just a beginner but i have some questions regarding the support library.
Every time google team add's a new Support version it deprecated the use in new Version, so because of this we have to redo the code again just to support new API level.Can't it be like this , you can have this library but you will be not getting extra features .Instead of just deprecating the entire work ? Because of this there is a lot of extra work to do while making android app.
Why was PreferenceFragment deprecated in Android P and what are the support versions for both libraries PreferenceFragment and PreferenceFragmentCompat also what addition features to do you get?
Android platform is amazing but it's difficult to understand this things . If a developer has made an app what is the guaranty it will work when android releases new version ? With every release something is deprecated either the feature or the whole library.

Every time google team add's a new Support version it deprecated the use in new Version, so because of this we have to redo the code again just to support new API level.
That is not the case. "Deprecated" in Android usually means "we have something that we would prefer that you use". So, while eventually you should try to move off of deprecated APIs, "eventually" could be on the order of a couple of years.
Why was PreferenceFragment deprecated in Android P
The native android.preference.PreferenceFragment was deprecated in Android 9.0, mostly because it inherits from android.app.Fragment, which was deprecated in Android 9.0. The fragment code has had lots of bugs over the years. Google is trying to steer developers towards using a library-supplied fragment implementation, as the libraries can be kept up to date, while older Android devices (unfortunately) do not get updates.
There is nothing stopping you from using android.preference.PreferenceFragment in Android 9.0 if you wish. Ideally, over time, you stop using it, but you do not need to drop everything and change your code tomorrow.
what are the support versions for both libraries PreferenceFragment and PreferenceFragmentCompat
AFAIK android.support.v14.preference.PreferenceFragment should also be marked as deprecated, as it too inherits from android.app.Fragment.
android.support.v7.preference.PreferenceFragmentCompat extends from android.support.v4.app.Fragment, and so AFAIK this is the one that you should be using in the short term.
The whole preference fragment stuff is a bit of a mess at the moment — I am hoping that Google settles this out and provides clearer instructions as part of the migration to androidx over the next few months.

Related

Fragment vs Support Fragment when targeting api 21 (Android 5.0) and above

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.

Appropriate way to use Android Support Library

When I created a new app, I got this
class NewApplicationActivity extends ActionBarActivity{... }
So I have read that, if you want to use a new feature from a newer API level, you better make it such that there is an alternative option for the App to combat any situation for the minSDKVersion that you plan to support.
Assuming this is true, lets say I decide to build my App against targetSDKVersion = 21(which I did in the above example), I would get the base Activity class as ActionBarActivity. Now this is from support library and works for older version(down to Android 2.1 I guess..).
The thing is, I am stuck with these alternative set of support libraries rather than platform libraries. Am I gonna miss something significant if this happens? Will I get a chance to incorporate the platform specific code from API 21 into my App ever? The majority of Apps are made with compatibility in mind. How do you people handle this?
Support Libraries such as AppCompat (which is what ActionBarActivity and its replacement AppCompatActivity are part of) are designed to reflect the latest platform changes and backport as much as possible. Thereby by using AppCompat, you are already using a large number of API 21 features (such as material theme).
Of course, there is nothing stopping you including any API from any level in your application: just make sure that they are guarded by the appropriate API level checks: this is exactly what many of the Compat classes in Support v4 such as NotificationCompat and ViewCompat do for you.

android: getFragmentManger and getSupportFragmentManger

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

Usage of android.support.v4.app or android.app for DialogFragment?

Reading through official documentation of Android made me little bit confused about this 2 libraries. When should I use one and when the other one?
As far as I'm understanding, it's the best to use Android Support library depending to the number of devices that will be able to run it and the look will stay always the same. No matter what might get in the future of the android, Support library will always be supported on any future Android API. But why is then DialogFragment for android.app? It is logic to me that android.app.DialogFragment has some benefits which that from support's doesn't because anyways it would be useless to have it, since it's not supported on so many devices.
Can you help me which I should prefer to use it and if my sayings were right?
If your app needs to be compatible with Android 2.x you should use the DialogFragment from the Support Library. Notice that adding the Support Library to your project makes your app bigger because the JAR of the Support Library will be included in your APK.
If you only support Android 3.x or higher you can stick with the DialogFragment built-in into the OS.
Both versions of the API offer (roughly) the same functionality.

"The type TabActivity is deprecated" For app tab

"The type TabActivity is deprecated"?
I am making the Tabs of app following tutorial book.
I've checked from the android developer.com website, but i have no ideas on the significance of the following message : This class is deprecated.
New applications should use Fragments instead of this class; to continue to run on older devices, you can use the v4 support library which provides a version of the Fragment API that is compatible down to DONUT."* (http://developer.android.com/reference/android/app/TabActivity.html)
What is v4 support library?
How to finish the tab functions?
You can still use a deprecated package. It is however recommended to use Fragments, and thus the support package. You can read more about it here. However, if you are a beginner at java and android development, I would recommend ignoring the deprecation for now and come back to this when you have completed the tutorial you are currently using if you find it educating.
If you want to watch a nice example of tabbed navigation using Fragments, then create a new project in Eclipse using android 4.0 or later. Make sure your android-plugin is updated. You will get the option to create a project with basic navigation already implemented.
"Deprecated" means that the api developers don't recommend using it anymore, probably because its not a good model, or inefficient, etc. Fragments were introduced in Honeycomb and can be used to provide a similar functionality as tabs and is more in-line with android's current design philosophy.
Since Fragment was introduced in Android 3.0 Honeycomb, you might think you cannot use that for pre-Honeycomb devices. Enter Support Libraries. They are libraries which you can include in your application which needs to run on pre-Honeycomb and still use this class.
So if you want to, you can finish the TabActivity as described in whatever tutorial you are following, it'll probably work on a few more upcoming android versions. But it is recommended that you start using Fragments.

Categories

Resources