|Android Support Library 22.1 - The Way To Write Android Apps|
|Written by Harry Fairhead|
|Thursday, 23 April 2015|
We tend to get all excited about new versions of Android - IceCream Sandwich, Lollipop and so on, but we probably should also take note of what is happening to the Support Library. A decimal point upgrade has just been announced and it contains some important changes.
The Android Support Library was introduced to bring the new features introduced with Honeycomb to earlier versions of Android. At first this was its only function and if you wanted to target just Honeycomb or later you didn't have to use it. As time has passed, more and more code has been introduced into the Support Library which hasn't made its way into the full OS. For example, if you want to make use of ViewPager and similar UI components then you have to use the Support Library as they are not part of the OS. Once you start to use components such as ViewPager you find that the Support Fragment class works with it better than the real thing. In fact, Support Fragment is often quoted as working better than the real thing.
Slowly but surely you have to come to the conclusion that Android depends so heavily on the Support Library that it should be considered the standard way of doing things. In other words, all Android apps, even if they are only targeting the latest OS, should use the Support Library.
The downside of using the Support Library is that the code is included with your app - so making your app bigger. In principle, the Support Library hands off to the OS if it finds support for the feature you are using, but in practice there is often enough difference in behavior to suggest that the hand-off isn't particularly clean. Putting it simply, even when the feature is available, the Support Library seems to do some work to make it "better".
In the case of the latest 22.1 version of the Support Library we are supposed to stop using ActionBarActivity, the almost ubiquitous class for implementing an Activity, and switch to AppCompatActivity class which supports the new Lollipop features - the material palette, widget tinting and so on.
This is not just a suggestion as ActionBarActivity has been deprecated.
The strange part about this move is that AppCompatActivity is based on the use of AppCompatDelegate. This can be used to extend AppCompat support to any Activity-derived class by simply creating an instance of AppCompatDelegate and then using its methods in place of the Activities methods. For example, instead of calling the Activity's setContentView method you would call the AppCompatDelegate.setContentView.
There is also a new AppCompatDialog class that supports the new Lollipop themes and a whole set of tint-aware widgets. If you use the AppCompat approach then these are automatically substituted for your existing controls when the layout is inflated. For example, Button is automatically replaced by AppCompatButton.
You can see the basic idea in the following video:
As well as the big AppCompat change there are improvements to the RecyclerView by way of a new SortedList data structure with batched changes. The Palette class has been made faster, Renderscript is more reliable and faster, and the Leanback library and samples have been updated.
What is amazing is that the way that most of us code Android apps has just changed and it is is all because of the Support Library, which has grown well beyond its original intent.
To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin, or sign up for our weekly newsletter.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Thursday, 23 April 2015 )|