I have a question regarding the Android Support Libraries, Fragments, and as a specific example, the ViewPager class. My intention is to create an app with similar functionality to the sample provided on the Android Developer website (http://developer.android.com/training/animation/screen-slide.html or http://developer.android.com/training/implementing-navigation/lateral.html). Looking into their code, I've noticed they utilize the android.support.v4.app library, which from my research is the only way to access the ViewPager class.
In my situation, I have no interest in backward compatibility. The minimum API level is 14 (Ice Cream Sandwich) and the build target is 4.2 Jelly Bean. In it's simplest form, my app performs exactly as does the second demo I linked on the Android dev website - just swiping between three tabs with content in each.
All of the articles/posts/answers I've read seem to heavily favor the v4 support library. Now for my, albeit long-winded, question(s):
What's the best way to structure my application - using android.support.v4.app, and thereby using SupportFragments, or to use the Fragments provided in android.app - and why?
If Fragments from android.app are the way to go, what is the optimal way to approach ViewPagers?
If SupportFragments are best-suited to the task, I would estimate that they possess the same functionality as the other - so what's the purpose of having them at all inside android.app?
Hopefully someone with a clearer understanding can give me a bit of clarification because I'm boggled...
You can use ViewPager with native fragments from the android.app package with the adapters from the android.support.v13.app package. You have to use the v13 support jar for that.
There are two versions of the adapters that work with ViewPager, the ones in the v4 package are meant to be used with support fragments, the ones in v13 with native fragments.
The reason why there are now two fragment implementations is historical: Fragments in the android.app package were introduced with Android 3 for tablets only and the support library was created to bring fragments to phones running older versions. On Android 4 you have both.
From my own experience I would recommend using support fragments, even when developing for Android 4. Here are some reasons: Fragment or Support Fragment?
android.app.Fragment class is deprecated since Android P (link), so only android.support.v4.app.Fragment should be used everywhere.
If you're going to target API 11+, you won't need the support library [and your actual apk will be smaller, at least).
If you want to support anything before Android 3.x, you'll need the support library.
Is this what you're asking?
Related
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 think I'm missing something, but don't really understand the reasoning behind the support packages for objects like ViewPager and Fragment etc and how do I know which one to use?
I'm writing an app with min sdk 16, why are the objects not included somewhere in the API without the "support.v4" (some appear to be support v.13) qualification?
Can somebody shed a bit of light?
The support library is for the following reason:
for backwards compatibility
for functionality that is not included in the standard SDK's such as ViewPager
Here, ViewPager isn't included in the standard SDK. So, if you want to use Viewpager API then you have to use support library.
Fragment in the support library is mainly for backwards compatibility. If you are implementing something using support library which required to use Fragment then you will need to use Fragment from support library.
The current minSdkVersion for my app is 16, targetSdkVersion,compileSdkVersion are 21.
When I first started the app, minSdkVersion was 10, and the book I was learning from used the v4 Support library.
I've gone through my app and I found that these are the imports I have been using from the v4 support library:
ActionBarDrawerToggle
DialogFragment
DrawerLayout
Fragment
FragmentActivity
FragmentManager
FragmentStatePagerAdapter
ListFragment
NavUtils
ViewPager
Since I have raised the minSdkVersion, I don't think I need to use the support versions of most of these anymore. I believe I still have to use ViewPager and DrawerLayout, though.
The developer pages say:
Caution: When using classes from the Support Library, be certain you import the class from the appropriate package.
For example, when applying the ActionBar class:
android.support.v7.app.ActionBar when using the Support Library.
android.app.ActionBar when developing only for API level 11 or higher.
So, my question is:
1) May I simply use an import similar to android.app.Fragment for all of the above, since my API level is minimum 16? (Except ViewPager and DrawerLayout)
2) For ViewPager and DrawerLayout, is there a difference between using v4 or v7 or another support library version?
Any advice is appreciated. Thanks!
First, with Fragment and all its related paraphernalia (FragmentManager, FragmentTransaction, &c) the most important thing is to use the imports consistently (that is, don't mix and match). That, I think, is the point the documentation wants to make.
That said...
You could swap out usages of android.support.v4.app.Fragment with android.app.Fragment if you wanted to use the native versions of these classes instead of the support ones, but be careful: the support library also adds some methods and callbacks that were not present in API level 16 (one important example being getChildFragmentManager(). So, basically, it comes down to whether all the features of Fragments that you're using are available for the native Fragments in all the API levels you will support.
Also, using the support library Fragments means that they should behave exactly the same in all Android versions, while they might be differences in the native implementations.
In our particular case we decided to keep using the support library, but YMMV.
As for the second question, I don't think there is a v7-specific ViewPager (at least, I think so). The v7 libraries are add-ons (appcompat, gridlayout, &c).
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.
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