I am developing an application to SDK version 16 and above, As I understood the fragment framework is included in the OS framework in those versions.
I want to remove the support library fragment framework (now that the v4 support library is split) but all the other support libraries are using it (com.android.support:design:25.1.0 and more).
So what is the advantage of splitting the v4 support library?
With respect to that particular library (com.android.support:design), they have not updated it to use the more-granular dependencies. With luck, they will do that someday.
In general, the advantage is to allow for flexibility. Not all apps use com.android.support:design, com.android.support:appcompat-v7, or other libraries that Google has not yet updated to use the more-granular dependencies. Apps that avoid those libraries can use individual dependencies (e.g., com.android.support:compat).
Also, you can use Gradle exclusion rules to attempt to block portions of the aggregate support-v4 that you feel that you are not going to use. For example, you could exclude support-fragment, then see if your app holds up under testing (though that will not work in your specific case, since the Design Support library requires appcompat-v7, which in turn requires FragmentActivity).
Related
In my mind, androidx.* is optional for an Android project, I find that androidx.* is necessary when I update to Android Studio to 3.4.2.
See the Image. So androidx.* will be standard, right?
Image
AndroidX is a major improvement to the original Android Support Library.
Like the Support Library, AndroidX ships separately from the Android OS and provides backwards-compatibility across Android releases. androidX fully replaces the Support Library by providing feature parity and new libraries.
Here
If your app currently depends on the original Design Support Library, you can make use of the Refactor to androidX option provided by Android Studio. Doing so will update your app’s dependencies and code to use the newly packaged androidx.
New Design support library requires andriodX migration too! You should consider using androidX for your future projects! Here
Add the library to the in your build.gradle(app-level) dependencies section:
implementation 'com.google.android.material:material:version' Latest Version
you can still make app absolutely..androidx is just a extension of the android library itself...so if you completely know android libraries,you can make any app,same as what androidx can,as the name implies,its a "support library" so without using it you can still make full blown app...again its a support library to make your life not worrying of compatibility for your app,but if your really know android programming,your dont need androidx.infact making app in android(not androidx)is better because you dont need transitions in the future same to what happen to those who rely on android support libraries..
I know there are many versions such as v4, v7, v8, v13, v14, v17, etc and they aren't in order of upgrades. What I don't understand is the meaning of this checkbox in Android Studio when you create a new project and choose an empty activity
Backwards compatibility (AppCompat)
The description says
if false, this activity will be Activity instead of AppCompatActivity
It's a bit foggy to me, then I checked the library and I found out that it was android.support.v7.app.AppCompatActivity
The descriptions says that
v7 Support Libraries
There are several libraries designed to be used with Android 2.3 (API level 9) and higher.
Again I don't understand whether I have to use it or not, depending on different cases. If I set the maximum target API, what is the necessary minSdk to not use it?
It is not simple to answer your question.
The Support Libraries provide a wide range of classes for building apps, from fundamental app components, to user interface widgets, to media handling, to TV app components.
Many of the classes are backward compatible implementations, but some of them are new features in their own right.
It is very important this step. Not all support libraries are used to support backward implementation.
For example in your application you will need to use some components like:
RecyclerView
CardView
ViewPager
Design Library
.....
In particular the design support library has a dependency with the appcompat library.
It means that you can't avoid the use of the support libraries only using a minSdk. Or in other words you have to use them always.
Here more info about the support libraries.
Please note that, when you opt out support libraries, you can not get benefit of the powerful RecyeclerView, CardView, DesignSupportLib etc. Because these libs are dependent on appCompat
what version should we use in order to avoid the support library?
You can use any version as min sdk version. It does not matter. Support lib is included in every project by default by android studio, you have to remove it manually.
How to create new project without support library?
While creating a new project,set min sdk version as 14 (just for example), don't add
any activities during the wizard dialog. Just create a project with
no activities. Then after you can add code as you wish
You can remove the support library , removing the dependency from your build.gradle
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
//compile 'com.android.support:appcompat-v7:25.2.0'
}
Replace your theme parent in styles.xml into a non AppCompat version like Holo.Light
I just created a new library, Powerful Image View.
My library is a custom AppCompatImageView, so I need the appcompat-v7 library. And here comes the question:
How should I add it to my library?
Should I use 'compile', or 'provided' and let the user add the library to its own dependencies?
And how should i handle different versions of the libraries used, since i'm not depending on a specific version?
I added to the library's gradle file this line:
provided 'com.android.support:appcompat-v7:+'
I'd like to know your thoughts about this :)
Should I use 'compile', or 'provided' and let the user add the library to its own dependencies?
I would use compile and make sure that the developer using your library understands that your library relies upon appcompat-v7, as that in turn places lots of other requirements (e.g., using AppCompatActivity, using Theme.AppCompat).
And how should i handle different versions of the libraries used, since i'm not depending on a specific version?
Well, you are requiring some version. AppCompatImageView does not exist in all versions of appcompat-v7. I recommend depending upon a concrete version (i.e., not +), ideally the latest-and-greatest version.
This question already has an answer here:
How do make sure there is no conflict of "v7 appcompat or support" of my library when any application uses my library?
(1 answer)
Closed 6 years ago.
I have a android library with com.android.support:appcompat-v7:23.0.1 dependency in the gradle with compliedSDK of 23
I have following doubts
case 1) Say any applicaion with different version com.android.support:appcompat-v7:23.3.0 uses my library.
which version does the android take? Lower one or Higher one? How do i see it?
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
case 2) Say any applicaion with different version com.android.support:appcompat-v7:25.0.1 or com.android.support:appcompat-v7:24+ and different compiledSDk(24 or 25) uses my library.
I know that The support library should not use a different version than the compileSdkVersion.
How does the android merge the support libraries now? (Since the support library version(appcompat-v7:23.0.1) of my library is different from that of the application's compiledSDK (25) )
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
Anyone Please clear my doubts
which version does the android take? Lower one or Higher one? How do i see it?
When building library you put the dependency explicitly in build.gradle. The same is done by the creator of app, that uses your library as a dependency declared in his build.gradle. If the creator explicitly declares support library as a dependency, that version is taken (regardless the versions declared by dependencies). If he does not do that, the highest version declared by any dependency is taken (such support library is regarded as a transitive dependency).
Example: Your library uses appcompat-v7:23.3.0. The creator of app declared appcompat-v7:25.0.1. Simple case: appcompat-v7:25.0.1 is taken.
Example 2: Your library uses appcompat-v7:23.3.0. The creator of app does not use appcompat-v7. appcompat-v7:23.3.0 will be in output app.
Example 3: Your library uses appcompat-v7:23.3.0. Another library uses appcompat-v7:24.1.0. If the creator does not explicitly declare appcompat-v7:xx.x.x the version appcompat-v7:24.1.0 will be in output app.
Hope you understand.
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
You can't assure that. That is why you should always put the highest version of support libraries in the library. I can't even assure you the support libraries maintain backward compatibility. Here is the example that they don't.
I know that The support library should not use a different version than the compileSdkVersion.
That is only a suggestion. However, you should conform to it, but you don't have to.
I've been developing for Android for a few months now, and this question arises again and again: what is the motivation behind addition of completely new features (APIs) to support libraries without them being available in the standard SDK?
Example:
FragmentTabHost API is available only through android.support.v4.app.FragmentTabHost. It is fine most of the time, but if you want to use fragments nesting and PreferenceFragment together, you're dead in the waters - nesting requires you to switch to android.support.v4.app.Fragment (for supporting below 4.2), but there is no implementation of PreferenceFragment in this support lib. As a consequence you either implement custom workarounds, or use third party libraries that have already implemented them (see this question)
Edit: as pointed out by #eugen in his answer, I myself referenced FragmentTabHost from support-v13, which supports native Fragments. However, this information does not change the overall question. In fact, if I would've used this API with fragments nesting, my app wouldn't run on ~30% of devices today (native fragments support nesting from 4.2 onwards).
Example:
Another issue that I encountered today (and wasted too much time on) is with ActionBarDrawerToggle available through android.support.v7.app.ActionBarDrawerToggle. I wanted to use this functionality, therefore I added the entire com.android.support:appcompat-v7:21.0.+ to project's dependencies. I guessed that this will do, but I was wrong - my app did not compile (missing resources referenced by the support library). After trying few tricks from the web, I found this question which finally provided the solution. In short: v7 support library has dependency on SDK, therefore I had to define compileSdkVersion 21.
Consequences:
Now, I tell myself: FragmentTabHost haven't been added to any SDK version yet, which implies that even 4-5 years from now developers will continue to use support-v4 lib for providing this functionality (because even if this API is added today, it will take years before you could safely assume that all target devices support it natively), right? The same argument applies to android.support.v4.widget.DrawerLayout and other APIs present only in support libraries.
If developers bound to use support libraries for years, this also imply that they are bound to experience the above inconsistency/dependency issues long after these issues could have already been resolved, right?
Question:
Why would Google want to keep these libraries forever? Won't it be better for everybody if all the new APIs were added to SDK in parallel to compatibility libs, such that compatibility libraries could age and "retire" at some point?
Edit: following #eugen's answer I'm now puzzled even more - some APIs "evolve" with newer support libs, but do not make it into main SDK (like FragmentTabHost, which evolved from support-v4 to support-v7). What is the reason for not adding them to SDK?
FragmentTabHost API is available only through android.support.v4.app.FragmentTabHost.
Incorrect. The link you provided leads to android.support.v13.app.FragmentTabHost which (as opposed to android.support.v4.app.FragmentTabHost) works with native Fragments but makes APIs introduced above API 13 available since API 13.
In short: v7 support library has dependency on SDK, therefore I had to define compileSdkVersion 21.
Of course the version 21 of the library needs version 21 of tools and version 21 of SDK. Always use corresponding versions of build tools, compile SDK and support libraries!
As of today these values are recommended:
compileSdkVersion 22
buildToolsVersion '22.0.1'
targetSdkVersion 22
compile 'com.android.support:support-v4:22.0.0'
compile 'com.android.support:appcompat-v7:22.0.0' // includes support-v4
compile 'com.android.support:support-v13:22.0.0' // includes support-v4
Now, I tell myself: FragmentTabHost haven't been added to any SDK version yet, which implies that even 4-5 years from now developers will continue to use support-v4 lib for providing this functionality (because even if this API is added today, it will take years before you could safely assume that all target devices support it natively), right?
Which means that if you implement it using the support-v13 library, you have nothing to worry about. It's going to work as far as API 13.
Read about the difference between support-v4 and support-v13 above.
Why would Google want to keep these libraries forever?
Because you'll most likely want to support older platforms. Which means you need a support library.
Even now you use ActionBarActivity from appcompat-v7 (which was originally intended to backport action bar to API 7) with minSdkVersion 14 because you want that material design backport. This also means you're stuck with support fragments because ActionBarActivity is using them.
Won't it be better for everybody if all the new APIs were added to SDK in parallel to compatibility libs, such that compatibility libraries could age and "resign" at some point?
Support libraries age. You may have noticed that recyclerview-v7 (and other recent android libraries) is available since API 7 and not API 4. And you may also have noticed that RecyclerView is not in the native SDK. Why would you add it to a native SDK making it available only to the newest platform when you can put out a support library making it available for everyone?