The version 27.0.0 of the Android Support Library introduces the class FragmentCompat.PermissionCompatDelegate. I wondered what it was exactly and how it should be used (reading the docs without any example didn't help much).
I dived a bit deeper, and discovered FragmentCompat.OnRequestPermissionsResultCallback, introduced back in 24.1.0, and also noticed that these two nested interfaces have ActivityCompat variants, introduced in the same Support Library versions.
Do these interfaces finally allow any class to manage permissions requests and grant results without having to do ugly hacks like are done in most of these libraries that often required to extend a "BaseActivity" or "BaseFragment"?
How to use them? If you answer with code, Kotlin snippets are appreciated, but Java ones are accepted too!
Related
I want to know when deprecated classes become unusable.
How can I find out about it?
Example, I used below.
android.widget.TabHost
androidx.fragment.app.FragmentPagerAdapter
androidx.fragment.app.FragmentTabHost
android.os.AsyncTask
Framework classes, such as the ones that you cite, cannot be removed without breaking backwards compatibility.
It is entirely possible that at some point Google will break backwards compatibility and remove these classes from a future version of Android. IMHO that is unlikely, and if it happens, the community will be very noisy about it, so hopefully you will not miss it.
Library classes, such as the androidx ones from the Jetpack, can and do get removed from the library in future versions. However, usually, you have some control over when you take on new library versions.
Iam an android beginner. I couldn't understand when we have to use imports statements starting with android.support.content and android.content?
I used content as an example.
The Support Library is generally used when you want to easily support a wider range of OS versions with less version specific source - with it you can use features introduced in higher version of the OS on older platforms without having to worry and check whether this platform has that feature and do something in case it doesn't.
For more information: it has already been discussed and this was a part of the answer, there are many more and they are useful so read them if you want to know in depth how,why and when. Hope this helps. Support library android
I was wondering, lets assume I want to develope some android app and I need new API specifics but supporting some older versions aswell. The question is: do I build everything with support lib or do I check for sdk version everytime and according to this I run selected piece of code?
Best regards,
Robert
If all the functionality that you need is available in support library, I would go for support library.
It will simplify your code, layouts, etc. a lot if you won't have to check for API version all the time. This means maintenance of your code will be much easier and number of bugs should also be lower.
Support library classes and usage are very similar to the actual classes so when you decide to drop support for older Android versions later on, the job of removing the support library will be fairly easy.
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.
I am developing an app that supports Android >= 4.0. It uses fragments from the android.app package. As I am facing problems with the older fragment implementation in 4.0, like this one, that are already fixed in the support library, I am considering switching back to the fragment implementation from the support library to get a more reliable and consistent implementation.
What is your opinion on this? Are you using fragments from the support library, even though they are already available, when developing for Android 4?
From my experience, using the same fragment implementation on all Android devices is a great advantage. I could not get rid of all NullPointerExceptions when state is saved on Android 4.0 using native fragments, with the support library they are all gone. Also I could not see any disadvantage so far with this approach.
So my answer to my own question is now: When developing for Android 4.x, using the fragments from the support library is a good idea. The support library has bugs fixed that are still present in older fragment implementations and is frequently updated with more bug fixes.
One big reason to stick with the SupportFragment for a while is that you do not have access to the ChildFragmentManager until API 17. The support library will give you a support version of the child fragment manager.
This becomes a big deal if you have fragments that contain other fragments. This is common in tablet applications with a good deal of complexity and/or your overall architecture is based on either a tabbed layout or uses the navigation drawer.
I was also getting frustrated at having to include the support libraries, despite targeting Android 4.0+ - but it seems it is officially recommended:
The Android Support Library package contains several libraries that
can be included in your application. Each of these libraries supports
a specific range of Android platform versions and set of features.
This guide explains the important features and version support
provided by the Support Libraries to help you decide which of them you
should include in your application. In general, we recommend including
the v4 support and v7 appcompat libraries, because they support a wide
range of Android versions and provide APIs for recommended user
interface patterns.
http://developer.android.com/tools/support-library/features.html
IMHO if you are planning to develop for 4.0 only, I would recommend going with the native libraries since the executable will get smaller. It is true that you might run into problems of bugs in early versions, but I think most of these should be fairly trivial to work around. Also the compatibility library is supposed to map to the native fragments in case you are running on 4.0 and higher anyway. So you might end up having to struggle with these kinds of problems anyway.
The problem with the support libraries is that you have a lot of the classes appear 2x (once in the support package structure and once in the "native" package structure) which makes development a bit more cumbersome.
However, if you want to also release your app pre 4.0 then there is no way around the support library. Also since there are about 38% of all users on 2.3 it might make business sense to include this OS version. In such a case you can use the support library in combination with Jake Wartons ActionBarSherlock (or with googles support ActionBar Library once it is finally released).
It seems that it is better to use Support Library now because I saw the statement here https://developer.android.com/reference/android/app/Fragment.html
This class was deprecated in API level P. Use the Support Library
Fragment for consistent behavior across all devices and access to
Lifecycle.