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.
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 am working on a project and so far in order to provide minimal integration effort for my consumers, I was forced to use all core Android framework APIs. That being said, I did not use any additional dependencies although there are alot of android library available out there to make my life easier. But recently I've been thinking about using Android annotation library. and in order to use it the docs ask me to include them into the project.
dependencies { compile 'com.android.support:support-annotations:24.2.0' }
From my knowledge, this will make my consumers forced to downland the libraries(they might not need) when they use my library. Can anyone please let me know if there is any better practice to achieve that not to include the library for my consumer but only my own project scope?
UPDATED:
I think I just found those two lines from the official docs.
If you use annotations in your own library module, the annotations are included as part of the Android Archive (AAR) artifact in XML format in the annotations.zip file. Adding the support-annotations dependency does not introduce a dependency for any downstream users of your library.
But I am still curious about general dependency issue and how to handle the dependencies if we are just a library.
In general, it is OK to make the library you depend on available to the user of your library.
If several libraries require a popular dependency, it's better to have the code included just once, if you want to reduce your apk size.
Also, if the user of your library doesn't want to include the transitive dependency, an exclude option can be added to the dependency declaration.
Other case is when you hapen to provide several libraries, where you can also ensure that the transitive dependency has the same version among your libraries
In other words, I would let the users the power to decide if they want the transitive dependency or not.
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 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).
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.