As the Android operating system evolves, many new features are added and older devices are often left behind.
In order to add the new features of the later versions of Android to the older versions of Android, all we need to do is add a small package:
An Android app has three platform versions to be set. The first is the API features that are available to code against. We set this to always be the latest in the Target Framework dropdown of the project options.
The next version to set (via Minimum Android version) is the lowest version of the OS that the app can be installed on. When using the support libraries, we can usually target versions down to version 2.3.
Lastly, the Target Android version dropdown specifies how the app should behave when installed on a later version of the OS. Typically, this should always be the latest version so the app will always function as the user expects.
If we want to add support for the new UI paradigm that uses fragments and action bars, we need to install two of the Android support packages:
Create or open a project in Xamarin Studio.
Right-click on the project folder in the Solution Explorer list.
Select Add and then Add Packages….
In the Add Packages dialog that is displayed, search for Xamarin.Android.Support.
Select both Xamarin Support Library v4 and Xamarin Support Library v7 AppCompat.
Click on Add Package.
There are several support library packages, each adding other types of forward compatibility, but these two are the most commonly used.
Once the packages are installed, our activities can now inherit from the
AppCompatActivitytype instead of the usualActivitytype:public class MyActivity : AppCompatActivity { }Finally, we specify that the activity theme be one of the
AppCompatderivatives using theThemeproperty in the[Activity]attribute:[Activity(..., Theme = "@style/Theme.AppCompat", ...)]
As Android is developed, new features are being added and designs change. We want to always provide the latest features to our users, but some users either haven't or can't upgrade to the latest version of Android. By including the Android Support Libraries in our app, we can make use of the new features, but still support the old versions.
Note
Types from the Android Support Library are available to almost all versions of Android currently in use.
Xamarin.Android provides three version numbers to specify what and how types can be used. The target framework version specifies what types are available for consumption as well as what toolset to use during compilation. This should be the latest as we always want to use the latest tools.
However, this will make some types and members available to apps even if they aren't actually available on the Android version that the user is using. For example, it will make the ActionBar type available to apps running on Android version 2.3. If the user were to run the app, it would probably crash.
In these instances, we can set the minimum Android version to be a version that supports these types and members. But, this will then reduce the number of devices that we can install our app on. This is why we use the support libraries; they allow the types to be used on most versions of Android.
Tip
Setting the minimum Android version for an app will prevent the app from being installed on devices with earlier versions of the OS.
The Android support libraries provide us with a type that we know we can use everywhere, and then that base type manages the features to make sure they function as expected. For example, we can use the ActionBar type on most versions of Android because the support library made it available through the AppCompatActivity type.
Because the AppCompatActivity type is an adaptive extension for the traditional Activity type, we have to use a different theme. This theme adjusts so that the new look and feel of the UI gets carried all the way back to the old Android versions.
Note
When using the AppCompatActivity type, the activity theme must be one of the AppCompat theme variations.
There are a few differences when using the support library. With native support for the action bar, the AppCompatActivity type has a property named ActionBar; however, in the support library, the property is named SupportActionBar. This is just a property name change, but the functionality is the same.
Sometimes, features have to be added to the existing types that are not in the support libraries. In these cases, static methods are provided. The native support for custom views in menu items includes a method named SetActionView:
menuItem.SetActionView(someView);
This method does not exist on the IMenuItem type for the older versions of Android, so we make use of the static method on the MenuItemCompat type:
MenuItemCompat.SetActionView(menuItem, someView);
Besides using the Android Support Libraries to handle different versions, there is another way to handle different versions at runtime. Android provides us with the version number of the current operating system through the Build.VERSION type.
This type has a property, SdkInt, which we can use to detect the current version. It represents the current API level of the version. Each version of Android has received a series of updates and new features. For example, Android 4 has received numerous updates since its initial release, new features being added each time.
Sometimes the support library cannot cover all the cases, and we will have to write specific code for particular versions:
int apiLevel = (int)Build.VERSION.SdkInt;
if (Build.VERSION.SdkInt >= BuildVersionCodes.IceCreamSandwich) {
// Android version 4.0 and above
} else {
// Android versions below version 4.0
}Although this can be done, it introduces spaghetti code and should be avoided. In addition to different code, the app may behave differently on different versions, even if the support library could have handled it. We will now have to manage these differences ourselves each time a new version of Android is released.