I am getting started with Android. I am quite confused with what support library actually does . I am following a book and in the book it is mentioned that :
If an app is installed on a minimum SDK system, and our Java code
contains any calls to classes that are not present in minimum SDK ,
our app will crash
I read an article about support libraries here:
Tutorials Point
If Support libraries provide backward compatibility, doesn't it mean when they should prevent app crash?(may be by wrapping up those newer classes and making them backward compatible). What does support library actually do? Please explain.
When should I use the Android Support Library?
As new versions of Android are released, some style and behaviors may change. You should use one of the support libraries when you need specific framework features that are newer than the minSdkVersion of your app or that are not available in the standard framework.
What does support library actually do?
There are many devices still running in Jelly bean and below versions. So you need to give the same importance for old and new devices While making an app. Otherwise, the App in old devices looks dull when compared to new ones. That may affect the app’s market. To avoid this trouble, Android introduced the Support library. These are set of code libraries provides backward compatibility
Example:
Fragment API was introduced in API 11 HONEYCOMB .android.app.Fragment is the Fragment class introduced in API 11 and android.support.v4.app.Fragment is the Fragment class in the android support library,
If you want to make your app use fragments, and want to target devices before API 11, you must use android.support.v4.app.Fragment. However, if you want only targeting devices >=API 11 ,you can use android.app.Fragment.Therefore, android.support.v4.app.FragmentManager is used to deliver newer features to older platforms.
For more info about android support library:doc
1.Suppose you want to create an app which runs on platform comes after marshmallow.
then minimum sdk of your app will be marshmallow.
2.While creating your app you call a method which is present in oreo or later version then you app will have chances to crash on marshmallow and nougat.
I'm working with Xamarin.Android.
Appcompat is actually necessary for use material design because the nougat package (Android.support.design) requires it.
But why, for example, if I work only with API 27, I must add the AppCompat package? In my toolBox i've not the floatingActionButton, NavigationDrawer etc.. so I must add this packet to unlock them.
What is exactly this package? I've read on the web that this package works with backward compatibility but I only work with new APIs, so why I must install it?
Thanks.
AppCompat should add the functionality of the latest API to older APIs when needed. For instance, lollipop added the CardView class, which can be used in older Android APIs when AppCompat is used, with some minor differences (some of the Android L animations may not apply on older versions of Android for example). It is recommended to use AppCompat in most cases since more users will be able to run your app when you do (depending on your MinSdkVersion). If you want to know what classes you can access in AppCompat, you can take a look at the features here:
https://developer.android.com/topic/libraries/support-library/features.html
The Xamarin.Android.AppCompat is just what it says. Its a library for App Compatibility for backward compatibility for previous versions of Android and more specifically this version (v7) brings support for Action Bar support. Read more here :
AppCompat
They are libraries used for accessing the latest features of an Android OS version. It is backward compatible by the way.
I understand that it is considered good practice to program for Android using the AppCompat support libraries for backwards compatibility. However, for this specific project, the minimum API level I am to support is Android 5.0 (level 22).
However all information I can find for new Lollipop features always points towards the AppCompat support libraries. Must I do this, or are there vanilla equivalents that do not require AppCompat themes, classes or attention to backwards compatibility (ie. a plain CoordinatorLayout in layout XML instead of android.support.design.widget.CoordinatorLayout)?
First, Andorid 5.0 is API 21. If you set the min SDK to 21, most features like material design theme comes by default, you don't need any libraries. But I think the CoordinatorLayout is only in the com.android.support:design library, you have to include the library to use it.
You will need to use various support libs for certain functionality.
The CoordinatorLayout exists in the design library, and not in the OS framework.
This can actually be quite useful. Use of the design library means you can use these components independently from the OS version of the user's device. Meaning you can get updated functionality without the user updating their OS.
And won't experience breaking API differences depending on what OS the user runs.
As far as I know, support library is using because old devices don't have new APIs. For example they don't know what Fragment is and how to implement it. Therefore, these behaviors are defined in support library.
So, my main question is, what is/are difference(s) between library of Fragment in support library with its twin which is introduced in API 11 (Android v3.0, Honeycomb).
My second question is, If its possible to put every new API in support library, why we have two types of libraries? I mean Android can release all APIs just under support library rather than support library and Android version X.xx library.
As far as I understood, support libraries may work as alternative of built-in APIs, but they are not supposed to be, because they directly effect the size of the application.
For example, a support library is of 2MB, and to use its functionality, it takes all classes, resources, etc (of 2MB), so now classes.dex (Dalvik executable file of all classes being used in application) of my application also include that support library classes, and same for resources. So, if without support library my app size was 1MB, then now with support library the size is 2MB extra, which means 3MB total.
Now, suppose this support library feature is so common that on single device, if I have 10 apps, then at least 9 are using this same support library, so 9*2 = 18MB on my device is being used by the same support library, which is repeated in every application, which is bad, because for now 18MB might not be so much, but the space required can increase, if you have more applications using that support library.
Thus, the best option is to have that 2MB support library already in your OS for any number of apps, instead of having it for each application. So, support libraries are meant to be used when you really want some efficient features in your app to support older versions.
Another question arise here:
why not this support library is added to the OS as its own update, so that every app without size problems can access that functionality?
The answer is that there could be a lot of errors. Suppose some user doesn't have that update (support library) installed...
There is also the chance that as an update, it may not work as efficient as supposed to be, or may cause problems while integrating with the OS, as we already seen that each OS (windows, Linux, mac) comes with new versions, instead of just giving updates for life time for all new features.
Android 4.0.x (ICS) has a lot of added features compared to lets say Android 2.3.x (Gingerbread). The compatibility libraries are there to bridge some of those changes that were added to ICS that -could be- supported by Gingerbread. "could be" being the key phrase here because there are a ton of changes made to ICS that would never work with Gingerbread and those, of course, will not get a compatibility library.
Fragments for example, which you brought up, are actually done slightly different in ICS than in the compatibility library because ICS has more features it can use. If you look at the code for ICS for the Fragments class, they are not the same as those in the compatibility library. Its a whole second set of code to make something "like" the Fragments in ICS be used in an older version like Gingerbread without the programmer noticing much difference.
That is the point of compatibility libraries and the reason why they aren't used to extensively patch Gingerbread to use all of the features in ICS (they just can't). The point of the compatibility libraries is to interface things available in newer versions of android such as ICS, done the ICS way into older versions such as GB, done the GB way.
As far as why they don't just keep the support library growing and leave the same base OS -- the answer to that is compatibility issues. If a user only has v4 and v12 is out, what happens? Android right now uses the Android API version of the OS as a basis for application compatibility and developers have an option to include support libraries (increasing file size of their app, but giving them newer features). Every application that uses support libraries, independently includes them (meaning 4 apps = 4x included).
The idea is, you may only download apps supported by the current API version of your OS (as far as Google Play is concerned) and you may choose to include support libraries to keep the look and feel of your app supported for older APIs, that do not yet have features that you elect to have available for those users on newer APIs. It's really a look and feel consideration more than anything else.
Hope that clears things up :)
What has been said already it is true. Although there are some details missing.
In fact, I had the chance to attend to a session in the last Google IO where they specially talked about that.
It was actually surprising for me to get to know that support library doesn't host the code for all the posible API versions, rather it's an adaptation of the new features which they think are relevant enough to make them available to older platforms. So the way it works it is generally the following:
Let's say we need to use the brand new (available from API 16) ConnectivityManager to keep track of network changes
We include support libraries v4 and we use the class
The way it works after is that the system will check our API version and will run built-in native code in case we are in API 16 or will run the code of the support library in any other case.
So it's acting like some kind of route gateway. Reason being is that it's generally more efficient (and performing) to use the last code optimized for the last OS and the last system improvements (ie.: hardware acceleration).
Nonetheless there are some elements that weren't translated to the compat library as they are in the native built-in code. For instance fragments weren't meant to be re-written as they are from API13 since they are a huge component that need to run in a wide range of different scenarios within system and devices with less capabilities.
Ultimately and because all this, it is recommended to use compats libraries which is known as a good practice, specially if you intend to make your apps / code available for older versions (which should be the ideal way)
The support library does not in fact have everything that is in the newer APIs. It does support parts of the Fragment API, but it does not yet support ActionBar. For that you need another library like ActionBar Sherlock.
Why are there two libraries?
Because part of the problem was Google only back ported some of the stuff, but my understanding is that, additionally, some of the new functionality can't be back ported due to core OS framework limitations and missing APIs deep in the core of the Android UI framework.
Android came up with cool features of fragments and action bar in recent releases.
Now if we want to use these features and also support older version of android then we will have to write highly messy version dependent code, which is not good.
To save us from all these mess, android came up with support library which does not provide full support of new features but is good enough to allow developers to write neat code which is supported on all devices.
Answer to your second question is very simple, fragments are integrated part of v3.0 and if you want you application to run only on v3.0+ then you really don't have to include external library.
Fragments from Support library equivalent to fragments of Honeycomb+.
To second quest, from documentation:
v13 is a superset of v4 and includes additional support classes to work with v13 APIs
ie the same functional, just adapted to v13 API.
I am use modified v4 support library - with maps.
I have a project that is just using Android 1.5 for programming, but with the proliferation of other handsets and some cool features in Android 2.2, we'd like to support the features without losing support for 1.5 or forking a new code base. Is it possible to do with Android SDK?
I do have some sense of the "ugly" way to do it, as in keeping the same code base but have a build system that builds different versions for the platforms and keep different Java files around that get added in our out of the build based on which version is selected. I'm hoping someone else has solved the problem based on the many versions of apps in the market that run on multiple Android versions.
we'd like to support the features
without losing support for 1.5 or
forking a new code base. Is it
possible to do with Android SDK?
Sure. The techniques have been around for about a decade or so.
Option #1: Use reflection to access new classes (or new methods of existing classes) at runtime. See here for an example.
Option #2: Use conditional class loading, by creating an interface plus two implementations (one for an older API, one for a newer API), and loading the right implementation at runtime. Since the newer implementation will not be loaded on a older device, the fact that the newer implementation uses classes or methods that the older device lacks will not pose a problem. See here for an example.