I want to use ActionBar.setHomeAsUpIndicator(drawable), but it's only available from api 18 onwards:
http://developer.android.com/reference/android/app/ActionBar.html#setHomeAsUpIndicator(android.graphics.drawable.Drawable)
It seems available in the compatibility library from v7 onwards?:
http://developer.android.com/reference/android/support/v7/app/ActionBar.html#setHomeAsUpIndicator(android.graphics.drawable.Drawable)
I'm not using any of the compatibility libraries, though, since I was targeting only api 14 and higher. Reading this article I thought that was ok to do:
http://developer.android.com/training/basics/actionbar/setting-up.html
So now do I have to restructure everything to use the compatibility library and have all my activities extend from ActionBarActivity? Please let it be no.
Thanks
While the main reason to use the compatibility library is to run on pre-11 versions, there are always new features added and the compatibility library also addresses those differences. For example, there's a bunch of features that were added in 14 but not in 11, the compatibility library backports those to 11 as well as 7.
Since this feature is v18+ only, if you want to use it, you have to use the compatibility library. Or just drop the feature.
Related
I am seeing:
onSupportNavigateUp
supportShouldUpRecreateTask
onCreateSupportNavigateUpTaskStack
onPrepareSupportNavigateUpTaskStack
So what does it refer to?
Hey this support refer to backward compatibility
Definition from tutorialspoint
Support Library Features
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.
In order to effectively use the libraries, it is important to consider that which API level you want to target as each library supports different API level.
Following is a brief description of android support libraries and API level they support.
tutorialspoint android_support_library
I see some examples use
compile 'com.android.support:appcompat-v7:21.0.3'
and some show:
compile 'com.android.support:support-v7:21.0.3'
What is the difference between these two libraries?
v4 support 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.
v7 appcompat library
This library adds support for the Action Bar user interface design pattern. This library includes support for material design user interface implementations.
Note: This library depends on the v4 Support Library. If you are using Ant or Eclipse, make sure you include the v4 Support Library as part of this library's classpath.
Source: https://developer.android.com/tools/support-library/features.html
AppCompat (At first ActionBarCompat) started out as a backport of the Android 4.0 ActionBar API for devices running on Gingerbread, providing a common API layer on top of the backported implementation and the framework implementation. AppCompat v21+ delivers an API and feature-set that is up-to-date with Android 5.0 like some material styles and themes as well as some Android 5 components like cardview and palette library.
As you can see AppCompat is mostly about making new android app design concept available in older versions.
Support Library on the other hand tries to provide functionalities of new version of android in older versions like fragments. It also has some useful classes which are not present in any version of android like ViewPager, LruCache and LocalBroadcastManager.
I've been developing for Android for a few months now, and this question arises again and again: what is the motivation behind addition of completely new features (APIs) to support libraries without them being available in the standard SDK?
Example:
FragmentTabHost API is available only through android.support.v4.app.FragmentTabHost. It is fine most of the time, but if you want to use fragments nesting and PreferenceFragment together, you're dead in the waters - nesting requires you to switch to android.support.v4.app.Fragment (for supporting below 4.2), but there is no implementation of PreferenceFragment in this support lib. As a consequence you either implement custom workarounds, or use third party libraries that have already implemented them (see this question)
Edit: as pointed out by #eugen in his answer, I myself referenced FragmentTabHost from support-v13, which supports native Fragments. However, this information does not change the overall question. In fact, if I would've used this API with fragments nesting, my app wouldn't run on ~30% of devices today (native fragments support nesting from 4.2 onwards).
Example:
Another issue that I encountered today (and wasted too much time on) is with ActionBarDrawerToggle available through android.support.v7.app.ActionBarDrawerToggle. I wanted to use this functionality, therefore I added the entire com.android.support:appcompat-v7:21.0.+ to project's dependencies. I guessed that this will do, but I was wrong - my app did not compile (missing resources referenced by the support library). After trying few tricks from the web, I found this question which finally provided the solution. In short: v7 support library has dependency on SDK, therefore I had to define compileSdkVersion 21.
Consequences:
Now, I tell myself: FragmentTabHost haven't been added to any SDK version yet, which implies that even 4-5 years from now developers will continue to use support-v4 lib for providing this functionality (because even if this API is added today, it will take years before you could safely assume that all target devices support it natively), right? The same argument applies to android.support.v4.widget.DrawerLayout and other APIs present only in support libraries.
If developers bound to use support libraries for years, this also imply that they are bound to experience the above inconsistency/dependency issues long after these issues could have already been resolved, right?
Question:
Why would Google want to keep these libraries forever? Won't it be better for everybody if all the new APIs were added to SDK in parallel to compatibility libs, such that compatibility libraries could age and "retire" at some point?
Edit: following #eugen's answer I'm now puzzled even more - some APIs "evolve" with newer support libs, but do not make it into main SDK (like FragmentTabHost, which evolved from support-v4 to support-v7). What is the reason for not adding them to SDK?
FragmentTabHost API is available only through android.support.v4.app.FragmentTabHost.
Incorrect. The link you provided leads to android.support.v13.app.FragmentTabHost which (as opposed to android.support.v4.app.FragmentTabHost) works with native Fragments but makes APIs introduced above API 13 available since API 13.
In short: v7 support library has dependency on SDK, therefore I had to define compileSdkVersion 21.
Of course the version 21 of the library needs version 21 of tools and version 21 of SDK. Always use corresponding versions of build tools, compile SDK and support libraries!
As of today these values are recommended:
compileSdkVersion 22
buildToolsVersion '22.0.1'
targetSdkVersion 22
compile 'com.android.support:support-v4:22.0.0'
compile 'com.android.support:appcompat-v7:22.0.0' // includes support-v4
compile 'com.android.support:support-v13:22.0.0' // includes support-v4
Now, I tell myself: FragmentTabHost haven't been added to any SDK version yet, which implies that even 4-5 years from now developers will continue to use support-v4 lib for providing this functionality (because even if this API is added today, it will take years before you could safely assume that all target devices support it natively), right?
Which means that if you implement it using the support-v13 library, you have nothing to worry about. It's going to work as far as API 13.
Read about the difference between support-v4 and support-v13 above.
Why would Google want to keep these libraries forever?
Because you'll most likely want to support older platforms. Which means you need a support library.
Even now you use ActionBarActivity from appcompat-v7 (which was originally intended to backport action bar to API 7) with minSdkVersion 14 because you want that material design backport. This also means you're stuck with support fragments because ActionBarActivity is using them.
Won't it be better for everybody if all the new APIs were added to SDK in parallel to compatibility libs, such that compatibility libraries could age and "resign" at some point?
Support libraries age. You may have noticed that recyclerview-v7 (and other recent android libraries) is available since API 7 and not API 4. And you may also have noticed that RecyclerView is not in the native SDK. Why would you add it to a native SDK making it available only to the newest platform when you can put out a support library making it available for everyone?
I have created a new android project in Eclipse, and I have setted this configuration:
Minimum required SDK: API 7
Target SDK: API 18
Compile with: API 18
Theme: Holo Light
So, my application has the actionbar. Eclipse has automatically included only android-support-v4.jar.
But, since ActionBar class is included in the support library for compatibility with API level 7 and higher. I am wondering why in my project are included only android-support-v4 library.
I guess that if I don't include v7 appcompat library I can continue to show the actionbar in my application, but I can't manage or customize it using ActionBar API? Is this right?
Quoting from the docs
The ActionBar APIs were first added in Android 3.0 (API level 11) but they are also available in the Support Library for compatibility with Android 2.1 (API level 7) and above.
http://developer.android.com/guide/topics/ui/actionbar.html
If you want your app to support action bar below 3.0 you need to use app compact v7 from the support library.
Also check the below link
http://android-developers.blogspot.in/2013/08/actionbarcompat-and-io-2013-app-source.html
you need to understand some of the very basic things.
1) Support libraries are meant to support functionalities in previous versions. you need to manually setup your project(addition in build path etc) to use support libraries.
2) If you dont use support library v7 in this case, You can show action bar, can customize it and do whatever it is supported in the version(3.0) ActionBar supported in.
3) If you want to show Action Bar in suppose Api levels 8/7(2.2/2.1), you must use support libraries v7.
Here is how to create action bars and support it lower versions
Please dont forget to use/imports classes/apis from support library instead of SDKs classes.
Tutorial is easy enough to understand.
1) Support libraries are meant to support functionalities in previous versions and add functionalities that only exists in these libraries. You need to manually setup your project(addition in build path etc) to use support libraries.
I wanted to know the difference between android-support-v4.jar
and android-support-v7-appcompat.jar. If I want to add appcompat Action Bar in my application do I need to add both android-support-v7-appcompat.jar and android-support-v4.jar or only android-support-v7-appcompat.jar.
Also, does android-support-v13.jar has appcompat?
UPDATE
There are many changes done into support library since this question was answered. Good thing is, it is very well documented also. So you must read Support Library Documentation for more details and more available support library.
Starting with Support Library release 26.0.0 (July 2017), the minimum
supported API level across most support libraries has increased to
Android 4.0 (API level 14) for most library packages.
Below is difference from Support Library Packages:
v4 Support Library
This library is designed to be used with Android 1.6 (API level 4) Android 2.3 (API level 9) Android 4.0 (API level 14) 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.
v7 Libraries
There are several libraries designed to be used with Android 2.1 (API level 7) Android 2.3 (API level 9) Android 4.0 (API level 14) and higher. These libraries provide specific feature sets and
can be included in your application independently from each other.
v7 appcompat library
This library adds support for the Action Bar user interface design pattern.
Note:
This library depends on the v4 Support Library. If you are using Ant or Eclipse, make sure you include the v4 Support Library as part
of this library's classpath.
So yes you need both jars if you want to use v7.
Update for android-support-v13.jar
v13 Support Library
This interface was deprecated in API level 27.1.0. Use Fragment instead of the framework Fragment.
v13 Support Library
This library is designed to be used for Android 3.2 (API level 13) and higher. It adds support for the Fragment user interface pattern
with the (FragmentCompat) class and additional fragment support
classes
When you see the package details it has a class FragmentCompat as given in definition. So it has not the all classes of appcompat library.
What is a support library?
Support libraries are code libraries(Collection of classes) which makes a newly added feature to work with the older devices.
For example, Material Design was introduced in API 21 (Android 5.0 - Lolipop) but
the v7-support library makes it available for API 7 (Android 2.1.x -Eclair) and higher.
What are different support libraries?
Some of the main support libraries are
V4 Support library
V7 Support library
V8 Support library
v13 Support library
What does 7 stand for in v7 Support Library?
It means this library has features designed to be used with API level 7 and higher. Same goes with V4 (contains features meant for API 4 and higher) and so on.
Difference between v7 Support library and v7 appcompat library?
Few people including me get confused with these two terms. Actually, v7 appcompat library is a part of v7 Support library. v7 support library was mainly developed to support Material design and ActionBar design pattern for API 7 and higher.
V7 can be categorized into more sub categories
v7 appcompat library
v7 cardView library
v7 recyclerView library
v7 pallete library etc
v7 appcompat library has following key classes ActionBar, ActionBarActivity, ShareActionProvider.
So adding,
com.android.support:appcompat-v7:21.0.+
dependency in your gradle file, imports the above-mentioned classes.
Bonus
Other support libraries
Multidex Support Library (For creating apps with more than 65k methods)
v17 Leanback support Library (A Support library which provides important widgets for Android TV)
Relevant links
Support Library Features
Support Library Packages
Support Library Features Guide
What is Multidex and what is the use of Multidex Support Library?
Support library only required if your minimum sdk version is less than API Level 11. otherwise you do not need to add support library to your project for Api Level 11 or Greater.
android-support-v4.jar: Support android.app classes to assist with development of applications for android API level 4 or later. So that you will able to make your application backword compatible,
android-support-v7.jar It is recently added in latest support library updation. ActionBar to allow implementation of the action bar user interface design pattern back to Android 2.1 (API level 7) and higher. Use of this class requires that you implement your activity by extending the new ActionBarActivity class.
If I want to add appcompat action bar in my application do I need to
add both android-support-v7-appcompat.jar and android-support-v4.jar
or only android-support-v7-appcompat.jar.
Yes you need to add reference of both libraries if you want to use it.
does android-support-v13.jar has appcompat?
No, It includes FragmentCompat so that if some of the Fragment feature add added after version 13 than you can make it backword compatible to Api level 11. so that Application targeting API 11 or greater can use feature which added on newer versions.
This answer is relevant for clients of support libraries which their version is >= 26.0.0:
Caution: Starting with Support Library release 26.0.0 (July 2017), the minimum supported API level across most support libraries has increased to Android 4.0 (API level 14) for most library packages.
For example, the support-v4 and the support-v7 package both support a minimum API level of 14, for releases of the Support Library from 26.0.0 and higher.
For more information, see Support Library - Version Support and Package Names.