Iam an android beginner. I couldn't understand when we have to use imports statements starting with android.support.content and android.content?
I used content as an example.
The Support Library is generally used when you want to easily support a wider range of OS versions with less version specific source - with it you can use features introduced in higher version of the OS on older platforms without having to worry and check whether this platform has that feature and do something in case it doesn't.
For more information: it has already been discussed and this was a part of the answer, there are many more and they are useful so read them if you want to know in depth how,why and when. Hope this helps. Support library android
The support libraries allow us to use newer features even when using older versions of android, but I've noticed that they also work on newer versions.
Are we expected to detect the version and choose to use the support
library version of a class only if the application is made to run in
an older version?
Or is it appropiate to simply use the support library version of a
class even in cases where the regular version would be available?
Right now I'm thinking the second option would be better as it would make the application simpler to read and understand, with less special cases. However are there any other pros and cons to consider?
Is there a third option?
We have both advantages and disadvantages on using Support library classes than Android Framework classes.
Advantages :
It is updated much often. If any issue is found, it can be fixed on next release of support library. For framework , google will have to release another version of Android.
New APIs can be used on previous versions easily.
Disadvantages :
Of course, APK size will increase.
"Which" support library to use is always a tedious task.
So, I will prefer option 2
Or is it appropiate to simply use the support library version of a class even in cases where the regular version would be available
Also, If any new version is available , it is notified on Android Studio. We don't have to check manually if any update is available.
Reading through official documentation of Android made me little bit confused about this 2 libraries. When should I use one and when the other one?
As far as I'm understanding, it's the best to use Android Support library depending to the number of devices that will be able to run it and the look will stay always the same. No matter what might get in the future of the android, Support library will always be supported on any future Android API. But why is then DialogFragment for android.app? It is logic to me that android.app.DialogFragment has some benefits which that from support's doesn't because anyways it would be useless to have it, since it's not supported on so many devices.
Can you help me which I should prefer to use it and if my sayings were right?
If your app needs to be compatible with Android 2.x you should use the DialogFragment from the Support Library. Notice that adding the Support Library to your project makes your app bigger because the JAR of the Support Library will be included in your APK.
If you only support Android 3.x or higher you can stick with the DialogFragment built-in into the OS.
Both versions of the API offer (roughly) the same functionality.
I am developing an app that supports Android >= 4.0. It uses fragments from the android.app package. As I am facing problems with the older fragment implementation in 4.0, like this one, that are already fixed in the support library, I am considering switching back to the fragment implementation from the support library to get a more reliable and consistent implementation.
What is your opinion on this? Are you using fragments from the support library, even though they are already available, when developing for Android 4?
From my experience, using the same fragment implementation on all Android devices is a great advantage. I could not get rid of all NullPointerExceptions when state is saved on Android 4.0 using native fragments, with the support library they are all gone. Also I could not see any disadvantage so far with this approach.
So my answer to my own question is now: When developing for Android 4.x, using the fragments from the support library is a good idea. The support library has bugs fixed that are still present in older fragment implementations and is frequently updated with more bug fixes.
One big reason to stick with the SupportFragment for a while is that you do not have access to the ChildFragmentManager until API 17. The support library will give you a support version of the child fragment manager.
This becomes a big deal if you have fragments that contain other fragments. This is common in tablet applications with a good deal of complexity and/or your overall architecture is based on either a tabbed layout or uses the navigation drawer.
I was also getting frustrated at having to include the support libraries, despite targeting Android 4.0+ - but it seems it is officially recommended:
The Android Support Library package contains several libraries that
can be included in your application. Each of these libraries supports
a specific range of Android platform versions and set of features.
This guide explains the important features and version support
provided by the Support Libraries to help you decide which of them you
should include in your application. In general, we recommend including
the v4 support and v7 appcompat libraries, because they support a wide
range of Android versions and provide APIs for recommended user
interface patterns.
http://developer.android.com/tools/support-library/features.html
IMHO if you are planning to develop for 4.0 only, I would recommend going with the native libraries since the executable will get smaller. It is true that you might run into problems of bugs in early versions, but I think most of these should be fairly trivial to work around. Also the compatibility library is supposed to map to the native fragments in case you are running on 4.0 and higher anyway. So you might end up having to struggle with these kinds of problems anyway.
The problem with the support libraries is that you have a lot of the classes appear 2x (once in the support package structure and once in the "native" package structure) which makes development a bit more cumbersome.
However, if you want to also release your app pre 4.0 then there is no way around the support library. Also since there are about 38% of all users on 2.3 it might make business sense to include this OS version. In such a case you can use the support library in combination with Jake Wartons ActionBarSherlock (or with googles support ActionBar Library once it is finally released).
It seems that it is better to use Support Library now because I saw the statement here https://developer.android.com/reference/android/app/Fragment.html
This class was deprecated in API level P. Use the Support Library
Fragment for consistent behavior across all devices and access to
Lifecycle.
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.