I've just read this description of the Android Support Package / Compatibility Library...
http://developer.android.com/sdk/compatibility-library.html
... and it's left me a little confused! It says that the v13 library is a superset of v4 but I thought it was the other way around?
Getting practical: If I want to use the compatibility library such that my app builds and works fine for phones running Android 2.2 (API 8) through to 4.0 (API 14) and beyond, will v4 suffice for me?
To target API 8 (v2.2) you should use the v4 version.
Large sections of the v13 will work, but if you use any of the features in it that rely on the platform 13 APIs, your app will blow up on older devices.
Unless there's a particularly compelling reason to need v13, I'd suggest going straight for v4.
The Answer is correct but is also slightly confusing!
Currently there are 3 support jars: V4, V7 and V13.
Unfortunately V7 is specifically for gridlayout only and is therefore NOT a superset.
We are interested in only one jar from the support library [unless we also want gridlayout (I don't know what it is!)]. Therefore we are looking at our android:minSdkVersion="8" and checking it against the jars. So we want V4.
V13 is only a superset in the sense that it duplicates the V4 methods, NOT the code. I.e. the use of V13 would be incorrect in this example.
I don't think we should use superset(or subset) to describe these three libraries(v4, v7, v13) though the simplest meaning seems backward-compatible version 4, 7 and 13.
Google added Fragment in v4 first,then update it when every new version was published.That means unless your app only support the newest version (which strongly not recommended), we need support-v4 almost anytime.Suppose your minsdk is 14 which has fragment already, but 'embedded fragment' only support after 17,so we still need v4 and use v4 fragment in that situation.
This year(2013) google published v7,and added appcompat-library in it.That means besides third support Actionbar(ActionbarSherlock) before 11, offical support maybe a better One?? Then I believe we'll have every actionbar feature update when every new version publish in future in v7.
We still need minsdk=XX (between 7 and 10) today(Nov.24,2013).We should add support-v4 for fragment and support-v7 for actionBar both for best practice.
I checked the source code of v13, it adds only 4 more classes.
FragmentCompat
FragmentPagerAdapter
FragmentStatePagerAdapter
FragmentTabHost
FragmentCompat adds 2 static util methods which are included in v4 Fragment already.
FragmentPagerAdapter, FragmentStatePagerAdapter and FragmentTabHost, all these 3 classes have corresponding same name classes in v4, and have the same behavior.
The extra APIs provided in v13 are not necessary.
So by adding v4, you can support more platforms than v13, with same behavior with v13, so why not just use v4?
So I could not see any neccessarity for v13.
Am I right?
v13 just have functions about Fragment.
mostly if your minVersion is above 13 and not used functions like : FragmentPagerAdapter,FragmentStatePagerAdapter,FragmentTabHost,and nested fragments;
you do not need support v13.
so "v4 is a subset of v13" is incorrect!
A little late but please have a good look at the picture below.
In the JAR file android-support-v13.jar, there are 3 packages:
annotation
v4
v13
Meaning we just need to add this one jar, and we would have support for both v4 and v13. Since v7 is NOT in the compilation, we would need to add that JAR on our own.
Related
I am currently reading up on the Android Support Libraries (I am aware of Jetpack/AndroisX, but can't use them yet).
I understand that v7 depends on v4, so with adding v7 I get v4 and what comes with v7. What I don't understand are the other v<number> like v8, v13. Do they extend v7? In general, if I start a new application with Android Support Libraries, would I use the highest v<number> or still v7?
You should think in v4, v7, v13 as the name of the library and not like an actual "version". In a certain way, they are just the name of the library.
Each Android Support Library comes with its own set of sub-libraries. Those sub-libraries can be found in one library (v7, for example) and therefore, you can't just use the highest number (if you try to use v13 you get an error).
CardView for example. You add it to your project with com.android.support:cardview-v7:28.0.0. It is only found in the v7 library. If you try to import via com.android.support:cardview-v13:28.0.0, you will get an error.
Some classes can be found in more than one library (e.g. Fragments). They can be found in v4 and also on v13. However, each of those classes have a different implementation. So, you should use v4 or v13 according to your project/necessity. You don't need to simply use the highest number because they are just names... not an actual version.
If you simple use v13, for example, you won't get v7 sub-libraries because the v13 library does not depends of the v7 library.
Hi I tried using the android supported lib v4 as well as v13 instead of android app lib but eclipse still cannot recognize the getSupportedFragmentManager and getChildFragmentManager functions. Are there any steps I need to take in order fro eclipse to recognize both functions?
Currently using Eclipse luna with latest android sdk, targeting api 17 platform.
I need either function to see why the app crashes with no view found for id ?? when using viewpager inside dialogfragment.
Thanks in Advance.
I found the reason why eclipse cant recognize both functions and that is because while getSupportFragmentManager is available in supported lib v13 but both function are only available in support lib v4 which is weird considering v13 is higher and v4 is included. perhaps they removed getChildFragmentManager function in v13 for some reason. Discovered when using the software provided here jd.benow.ca to search for the function on which class they reside and viola, v13 actually don't have getChildFragmentManager in any of the classes available and it's only existed in v4, so for now, if getChildFragmentManager is needed just use support lib v4 for now or find a way to use both support lib v4 and 13. happy programming using support lib v4 and v13 guys.
We have an existing Android app that supports API Level 8 up to 18. We used compatibility libraries 19.1.0. Now we are changing/upgrading to:
Minimum SDK = 14
Target = android-22
Now given that there are v4, v7, v13 support, compatibility, and appcompat libraries in different versions, I'm not sure which ones to include and which ones not.
We are using maven for dependency management and using Maven SDK deployer
Android Support Library v4, v7, v8, v13 and v17 are totally different libraries. v7 is not the newer version of v4 and v8 is not the newer version of v7. You can't find a component provided by v7 in v4 and with the same reason, you can't find a component provided by v8 in v7.
The number of each v indicate the minimum Android version that library provided inside can be backward compatible. For example, if you use a v8 component. You application will be able to run on a phone with API Level 8 and above. If you need to use a component from both v7 and v8, you have to include BOTH of them to your project.
Since your minSdkVersion is now 14, you are safe to use any of v4, v7, v8 and v13.
Please note that the latest version of Android Support Library is now 22.0.0. I suggest you to move from 19.1.0 to 22.0.0. It is far better.
If you are using a minSDK of 14 then technically you do not need any of them. However, here are things to think about:
Support v4 (com.android.support:support-v4:23.0.0)
App Components Fragment - Adds support for encapsulation of user
interface and functionality with Fragments, enabling applications to
provide layouts that adjust between small and large-screen devices.
NotificationCompat - Adds support for rich notification features.
LocalBroadcastManager - Allows applications to easily register for and
receive intents within a single application without broadcasting them
globally.
User Interface ViewPager - Adds a ViewGroup that manages the
layout for the child views, which the user can swipe between.
PagerTitleStrip - Adds a non-interactive title strip, that can be
added as a child of ViewPager.
PagerTabStrip - Adds a navigation widget for switching between paged views, that can also be used with ViewPager.
App Compat v7 (com.android.support:appcompat-v7:23.0.0)
Here are a few of the key classes included in the v7 appcompat
library
ActionBar - Provides an implementation of the action bar user
interface pattern. For more information on using the Action Bar, see
the Action Bar developer guide.
ActionBarActivity - Adds an application activity class that must be used as a base class for activities that uses the Support Library action bar implementation.
ShareActionProvider - Adds support for a standardized sharing action
(such as email or posting to social applications) that can be in an action bar.
Support v13 (com.android.support:support-v13:23.0.0)
This library is designed to be used for Android 3.2 (API level 13) and
higher. It adds support for the Fragment user interface pattern with
the (FragmentCompat) class and additional fragment support classes.
For more information about fragments, see the Fragments developer
guide. For detailed information about the v13 Support Library APIs,
see the android.support.v13 package in the API reference.
See their revisions here: http://developer.android.com/tools/support-library/index.html
See all of the libraries listed here: http://developer.android.com/tools/support-library/features.html
When switching from support library v4 to v13 I expected the method count number to go down because now all the methods which are in the SDK version 13+ don't have to be in the support jar anymore. Well I checked what happens when I exchange the v7 against the v13 and here are the method count numbers per package.
When using android-support-v4:
android.support: 10117
v4: 6402
v7: 3712
and when using android-support-v13:
android.support: 10203
v13: 82
v4: 6406
v7: 3712
Why are there still all methods from v4 (+4 additional ones?!) included in the v13 version? Reading http://developer.android.com/tools/support-library/features.html I thought the version number relates to the API level number.
When switching from support library v4 to v13 I expected the method count number to go down because now all the methods which are in the SDK version 13+ don't have to be in the support jar anymore.
No. support-v13 has everything that is in support-v4, plus additional classes that are only relevant for apps with a build target of API Level 13+.
Why are there still all methods from v4 (+4 additional ones?!) included in the v13 version?
Since the Android Support package pre-dated widespread Android use of things like Maven and Gradle, with transitive dependency support, Google elected to have support-v13 be a superset of support-v4. If they had to do it over again, they might have made support-v13 be a small JAR that depended upon support-v4.
Hello I was checking support library page on android doc where I found v13 library also. I use v4 in my projects.
I understood that v4 is required If I set the minSDKVersion between 4-12 and If I set it to >=13 then I should use v13 support library.
Question
What is the use of support library v13 if we have already native Fragment classes if I set minSDKVersion to 13 because native Fragment is already from API 11 http://developer.android.com/reference/android/app/Fragment.html.
and Why they divided it into v4 and v13 if we have all features of v13 in v4 ?
What is use of support library v13 if we have already native Fragment classes
You may not want to use the native Fragment classes. For example, nested fragments was only added to the native Fragment classes in API Level 17 -- if you wanted nested fragments on older devices, you have to use the backport.
Why they divided it into v4 and v13 if we have all features of v13 in v4 ?
Not every class in support-v13 works back to API Level 4. Notably, support-v13 has implementations of FragmentPagerAdapter and FragmentStatePagerAdapter that work with native fragments. support-v13 is a superset, not identical to, support-v4.