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.
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.
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.
I'm trying to implement a ViewPager with a FragmentPagerAdapter, where the ViewPager itself is located inside a fragment. I've read in the docs that it should be possible with the newest Support Library and by using nested fragments. Principally I would like the PagerAdapter to use the root fragment's child fragment manager.
So, my project uses ActionBarSherlock and SherlockFragments. As the support lib bundled with ActionBarSherlock didn't include the method getChildFragmentManager() at all, I downloaded the newest support library v4 and placed it in the libs folder of ActionBarSherlock and my project, too. With this change the project compiles okay, but at first run it exits with a NoSuchMethodError regarding getChildFragmentManager(). What am I doing wrong here?
(P.s. I'm testing it with Android 2.2 which is my targeted minimum platform.)
Thanks!
SOLVED: I replaced the support library in my project and in all referenced libraries with the latest version. Then I cleaned my project, however I forgot to clean and rebuild the referenced libraries, too... This led to this peculiar behaviour.
Make sure that none of your referenced libraries use Support Library v13. If you do only the v13 library will be used in all your projects referencing the one using v13 and this seems to interfere with the getChildFragmentManager() method. See THIS QUESTION for more info and pay attention to the console print out when doing a Project->Clean on your whole workspace (assuming you are using Eclipse).
I had the same issue as you but it got resolved once I had the v13 library removed from one of the five Libraries referenced.
The only way to fix this, is just updating ActionBarSherlock with the last android-support-v4 library, wich is 19.1. You can get it uploading it from Android Manager. After that recompile the apk with this change and you will get the method.
SOLVED: I replaced the support library in my project and in all referenced libraries with the latest version. Then I cleaned my project, however I forgot to clean and rebuild the referenced libraries, too... This led to this peculiar behaviour.
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.