I was checking support library for android, but i cant understand why they divided into v4 and v7 ?
Why just don't use one support library for all versions? Or even all classes on support, be on SDK properly?
but i cant understand why they divided into v4 and v7 ?
They are not "divided into v4 and v7". They are divided along functional lines. There are many pieces of the Android Support package, such as:
compile 'com.android.support:appcompat-v7:21.0.0'
compile 'com.android.support:cardview-v7:21.0.0'
compile 'com.android.support:gridlayout-v7:21.0.0'
compile 'com.android.support:leanback-v17:21.0.0'
compile 'com.android.support:mediarouter-v7:21.0.0'
compile 'com.android.support:palette-v7:21.0.0'
compile 'com.android.support:recyclerview-v7:21.0.0'
compile 'com.android.support:support-annotations:21.0.0'
compile 'com.android.support:support-v13:21.0.0'
compile 'com.android.support:support-v4:21.0.0'
The only ones of these that are replacements for the other are support-v4
and support-v13
. support-v13
contains everything that is in support-v4
, plus a few additional classes that are only relevant for devices running API Level 13 or higher.
The -vNN
notation in the artifact name is just to help remind you what Android API level the code in that library works back to.
Why just dont use one support library for all versions?
For the same reason that we do not compile in every line of code ever written in human history: we don't need it. appcompat-v7
is an independent library from leanback-v17
, for example -- they are about as related as they are to one of my libraries.
Or even all classes on support, be on SDK properly?
In some cases, it it because we have not invented a time machine yet, and so we cannot "retcon" older versions of Android to have different classes and methods. For example, part of the reason why appcompat-v7
exists is to allow the action bar pattern to be used on devices going back to API Level 7; the native action bar only showed up at API Level 11.
There is also pressure from manufacturers to keep the size of the OS down, particularly framework classes, to reduce the amount of RAM and flash storage needed to build an Android device. Hence, some things (e.g., leanback-v17
, for Android TV-style experiences) are not part of the OS as they are not needed everywhere.
Also, by having things in libraries, your app is more independent of the underlying device. For example, some developers will use the backport of fragments in support-v4
or support-v13
, not because they want to run on devices older than API Level 11 (when native fragments were introduced), but because they want an implementation of fragments that works the same across all Android versions. The native fragments implementation will vary by Android OS version.