Is There Any Reason to Use the Support.V4 Library in Android

Is there any reason to use the support.v4 library in Android?

There are a number of features unique to the support library that apply to all API levels:

• LocalBroadcastManager - Allows applications to easily register for and receive intents within a single application without broadcasting them globally.
• ViewPager - Adds a ViewGroup that manages the layout for the child views, which the user can swipe between.
• DrawerLayout - Adds support for creating a Navigation Drawer that can be pulled in from the edge of a window.
• SlidingPaneLayout - Adds widget for creating linked summary and detail views that appropriately adapt to various screen sizes.
• FileProvider - Adds support for sharing of private files between applications.

And others such as

• WakefulBroadcastReceiver - Helper for the common pattern of implementing a BroadcastReceiver that receives a device wakeup event and then passes the work off to a Service, while ensuring that the device does not go back to sleep during the transition.
• AtomicFile - for atomic operations on a file
• SwipeRefreshLayout - adds pull to refresh to a view

Also note that some newer features, such as nested Fragments (which were added only in Android 4.2) are available in the support library versions of Fragments. Renderscript intrinics were also only introduced in Android 4.2 and important if you are doing things such as real time image processing. Big style notifications and notification actions (introduced in Android 4.1) are much easier to work with when using NotificationCompat (and the Android Wear Notification API is built on it).

Can you explain why support v4 and v7 on android

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.

What is the use of androidx.legacy:legacy-support-v4: dependency

androidx.legacy:legacy-support-v4 is Androidx artifacts of com.android.support:support-v4

com.android.support:support-v13 -> androidx.legacy:legacy-support-v13
com.android.support:support-v4 -> androidx.legacy:legacy-support-v4

You can find info about the library mapping here

The Support Library is a static library that you can add to your Android application in order to use APIs that are either not available for older platform versions or utility APIs that aren't a part of the framework APIs. Compatible on devices running API 14 or later.

Uses for the Support Libraries

There are a few distinct uses for the support libraries. Backward compatibility classes for earlier versions of the platform is just one of them.

• Backward Compatibility for newer APIs - A large amount of the support libraries provide backward compatibility for newer framework classes and methods. For example, the Fragment support class provides support for fragments on devices running versions earlier than Android 3.0 (API level 11).
• Convenience and Helper Classes - The support libraries provides a number of helper classes, particularly for user interface development. For example, the RecyclerView class provides a user interface widget for displaying and managing very long lists, useable on versions of Android from API level 7 and up.
• Debugging and Utilities - There are a number of features that provide utility beyond code you incorporate into your app, including the support-annotations library for improved code lint checks on method inputs and Multidex support for configuring and distributing apps with over 65,536 methods.

See official documents here support-library

Why is needed android support v4 and v7 library?

This library is designed to be used with Android 1.6 (API level 4) and higher. It includes the largest set of APIs compared to the other libraries, including support for application components, user interface features, accessibility, data handling, network connectivity, and programming utilities.

see this links

link1

link2

When to use support library

Here is your answer—Always!

The following reasoning is copied straight from Big Nerd Ranch's Android Dev book. Emphasis mine:

This book uses the support library implementation of fragments over the implementation built into the Android OS, which may seem like an unusual choice. After all, the support library implementation of fragments was initially created so that developers could use fragments on old versions of Android that do not support the API. Today, most developers can exclusively work with versions of Android that do include support for fragments.

We still prefer support fragments. Why? Support fragments are superior because you can update the version of the support library in your application and ship a new version of your app at any time. New releases of the support library come out multiple times a year. When a new feature is added to the fragment API, that feature is also added to the support library fragment API along with any available bug fixes. To use this new goodness, just update the version of the support library in your application.

As an example, official support for fragment nesting (hosting a fragment in a fragment) was added in Android 4.2. If you are using the Android OS implementation of fragments and supporting Android 4.0 and newer, you cannot use this API on all devices that your app supports. If you are using the support library, you can update the version of the library in your app and nest fragments until you run out of memory on the device.

There are no significant downsides to using the support library’s fragments. The implementation of fragments is nearly identical in the support library as it is in the OS. The only real downside is that you have to include the support library in your project and it has a nonzero size. However, it is currently under a megabyte – and you will likely use the support library for some of its other features as well.

We take a practical approach in this book and in our own application development. The support library is king.

So... There will always be a support library because you will almost always have to support older devices for a variety of reasons:

Device owners may not be able to update to the latest version because:

• Service providers and manufacturers are not bothered about updating a non-flagship type phone - costs money to regression test their bloatware on top of a new version of Android.
• Some device owners (thankfully not all!) care very little about the Android version on their phone. Totally different situation with the Tinder app though.
• Device owners may not have the resources to upgrade to a latest/newer device. App developers in developing countries probably face this issue. Google's Platform Versions statistics are not region specific, even though they probably should be!

Anyway, here is the gist: support libraries have the exact same functionality as OS/framework APIs and they have a compact size—since they have to be included in your APK, they don't increase the size very much. So we have established that there is no downside to using/including them. Now, the upsides are tremendous - look at the Fragment example above.

Need Some clarification about android-support-v4.jar

1. It is the Support Library for Android that provides backward compatibility for developers to use new API Level features in mobiles that doesn't provide that feature. Hence using Support Library you can broaden the range of targeted mobile devices.

The Android Support Library package is a set of code libraries that
provide backward-compatible versions of Android framework APIs as well
as features that are only available through the library APIs. Each
Support Library is backward-compatible to a specific Android API
level. This design means that your applications can use the libraries'
features and still be compatible with devices running Android 1.6 (API
level 4) and up.

1. You app or atleast some of the features will not work on Android Devices with Older API levels like Honeycomb or Freyo.

2. You can see all the classes in android-support-v4.jar here.

Eg: Including Support Library you can use ViewPager in API Level 8 which is Freyo.

You can know everything about android-support-v4.jar here.

Are Android support libraries necessary for high minimum SDK versions?

ViewPager which is a commonly used class is only available in the support libraries. There are other classes that are also only available in the support libraries. Some classes like Fragments are included in the support library for backwards compatibility. So it depends on what you need.

---

Related Topics