The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
Approximately 30 months after Google added the action bar to Android 3.0,
Google released a backport for previous devices. Referred to here as AppCompat or,
appcompat-v7 (after its library name), this adds action
bar support to Android apps, going all the way back to API Level 7.
appcompat-v7 Android Support Package artifact houses AppCompat. Version 21
and higher of this artifact change the way that AppCompat looks, to try to
not only backport the action bar, but to backport a bit of the Material Design
This chapter will outline why you might want to use AppCompat and how to employ it in your Android applications.
Understanding this chapter requires that you have read the core chapters, particularly the one on the action bar.
You might wonder why we would bother with any of it. AppCompat is not required, and apps can work fine without it. And, in truth, most apps will be just fine using the native action bar implementation.
That being said, you may find some pressures nudging you towards using an action bar backport, and AppCompat specifically.
minSdkVersion is 11 or higher, you have an action bar on all
Android versions that your app supports.
If, however, your
minSdkVersion is below 11, by default you will
get the old-style options menu on Android 1.x/2.x devices. That is not
a crime. However, the action bar design pattern had been used in various
Android apps prior to Android 3.0’s formalization of the pattern. Many
apps that users will see on older devices will have an action bar,
courtesy of one of the backports. By adopting a backport, you will
gain a measure of consistency in your UX across Android versions that you
would otherwise miss by falling back to the options menu.
You might also adopt a backport because something else is steering you to use AppCompat, and therefore you elect to use it for those reasons.
AppCompat is a somewhat controversial library nowadays. It did not start that way when it was released in the Summer of 2013. But Google has been rather aggressive about trying to get developers to use AppCompat, and that aggressiveness has had its downsides.
The #1 reason for using AppCompat is because you decided, for other reasons, that you wanted an action bar backport, and AppCompat right now is the primary supported option.
The original backport, ActionBarSherlock, was officially deprecated by its author (Jake Wharton), who is steering you towards the native action bar or AppCompat as alternatives. While this does not prevent you from using ActionBarSherlock, it is probably not a great choice today given that Google is supporting AppCompat.
The current version of AppCompat does not only give you an action bar.
It gives you an action bar that looks like the one that you get from
Theme.Material. It also will attempt to apply your accent color
to select widgets, the way Android 5.0 and
Theme.Material do, to make
your app abide a bit more by the Material Design aesthetic.
Whether or not this is a good thing is up to you.
One hidden advantage of using AppCompat, particularly in concert with the fragments backport, is consistency across Android versions. By using the native action bar and fragments, you are at some risk of inconsistent behavior based upon:
Having your action bar and fragments be in a library in your app isolates you from those changes. AppCompat always uses its own implementation, so any changes in the native implementation will not affect your app.
This comes at a cost of additional complexity and APK size.
Some things in the Android development ecosystem, like official support
MediaRouteActionProvider, only work with the AppCompat action bar,
as Google has either not shipped or has deprecated their native alternatives.
You may find some “cross-ports” of those things that work with the native action bar, but those are unlikely to be as well-supported as Google’s own editions.
Also, new projects created via Android Studio basically shove
down your throat. This is why this book’s tutorials have you start by
importing an existing project, so you do not have to rip
its references out by the roots to start a new project.
While it is theoretically possible that Google itself will eventually offer native action bar implementations of those things, it is unlikely. Hence, if you determine that you need one of those, you may be more inclined to use AppCompat, even if you do not need it for any other reason.
The preview of this section may contain nuts.
The preview of this section is unavailable right now, but if you leave your name and number at the sound of the tone, it might get back to you (BEEEEEEEEEEEEP!).
The preview of this section was eaten by a grue.
The preview of this section apparently resembled a Pokémon.