It takes a while for the number of users on the oldest Android versions to become insignificant. While it may be tempting to leave the new features alone until the majority of users have access to them, this can leave your apps looking stale and obsolete to users with the latest devices. In addition, effort spent deciphering older (and sometimes less developer-friendly) APIs could be better spent bringing in the latest and greatest technology.

Enter the Android Support Library, which makes some of the recent additions to Android available all the way back to Android 1.6. There are a number of classes included with this library, but the most important ones relate to fragments and loaders. Once you add the Android Support Library to your project, you’ll be off and running.

Fragments and supporting classes

Fragments, introduced in Android API 11 (Android 3.0), are the current recommended practice for creating reusable components. These components allow reorganizing content to make the best use of available screen space. Using fragments, an app can dynamically organize the UI based on available screen space without duplicating code or layouts.

The most common example is building an app that gracefully supports phones and tablets. Rather than stretching the existing layout to take up the entire tablet, the additional space could be used to show detail windows that previously had to either take the entire screen or be hidden.

This is called the Master/Detail Flow pattern (Figure A), and is directly supported in the new project wizard in Eclipse.
Figure A

To make use of fragments in your legacy app (once the library has been added to your project), you need to replace imports to use the Support Library, such as replacing android.app.Fragment with android.support.v4.app.Fragment.

There are just a few other changes, such as extending FragmentActivity instead of Activity, but in general the use of the support classes is exactly the same as for the original fragment-related classes. The minimum SDK in this app’s manifest can now be changed to lower than 11, and the fragment-related functionality will still work.

With the compatibility library, fragments can be used in all apps. This not only makes it possible to take advantage of the technology in current apps, it also prepares your app for eventually targeting just API 11+ and using the built-in fragment capabilities.

Loaders

Loaders are a convenient mechanism to asynchronously load data into a fragment or activity. As with fragments, loaders were introduced in API 11 (Android 3.0).

While loading smaller data sets may not slow down an application, loading a large data set on the UI thread can cause an app to behave slowly or get the dreaded Application Not Responding (ANR) closure. Neither of these is desirable for making a good impression on the user. Loaders prevent this problem by not loading the data on the UI thread.

Another benefit of loaders is that they can easily reconnect with the data source after a configuration change (e.g., changing orientation).

Given how many apps are data-driven, loaders are an important asset.

Maintaining compatibility

Neither the fragment nor the loader capabilities will switch to the native implementation when operating on a device running Android 3.0 or above — they will use the code in the Support Library. This shouldn’t be a problem, because the support library behaves the same as the native code. The behavior will be the same for all versions of Android the app supports.

If at some point there is no longer a desire to support older Android versions, the Android Support Library calls can be swapped out for native calls, and everything will run smoothly. This makes for minimal maintenance costs and prepares the app for the future.