AppCompat: The Official Action Bar Backport

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.

The 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
aesthetic.

This chapter will outline why you might want to use AppCompat and how to
employ it in your Android applications.

Prerequisites

Understanding this chapter requires that you have read the core chapters,
particularly the one on the action bar.

Ummmm… Why?

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.

Why an Action Bar Backport?

If your 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.

Why AppCompat?

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.

Supported

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.

Materialistic

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.

Consistent

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:

Android OS version, due to bug fixes, deprecations, and the like

Manufacturer or ROM modder tweaks to the native implementations, which
you do not control

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.

Forced

Some things in the Android development ecosystem, like official support
for the 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 appcompat-v7
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 appcompat-v7 and
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 Basics of Using AppCompat

The preview of this section may contain nuts.

Other AppCompat Effects

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!).