Explain like I am junior I-Support Library and Google Play Services
Today development environment is totally different then the first years of Android. For starters it is really difficult to grasp why these tools are used because it is usually neglected to tell what were the problems in the first place. I got a lot of questions from developers who just started with Android development or trying to get advanced. It is a long topic so I am planning to talk about it in three parts and the first part will be Android Support Library and Google Play Services.
Android Support Library
Android Support Library and other Android libraries Google released, merged under Jetpack. Android Support is the oldest one and the core of the Jetpack IMO and I will start with it. So why we ended up having to include Android Support to every Android project?
We have Android Support Library because of the OS update problems in Android. Android runs on devices with multiple brands and models unlike iOS. It is pretty hard process to develop an OS version update for manufacturers so they avoid it as much as possible. Even Google releases OS version updates for Pixel and Nexus phones just for two years. Because of this update problem Google had to separate some of the features as external libraries so this features could be used in older versions. In iOS the supported devices can easily get OS updates so an external library like Support Library is not needed. Let’s take a look briefly what libraries Google seperated from the OS.
Fragment
As far as I can remember Fragments introduced for tablet only Android version 3.0 HoneyComb and this page verifies me. Google put Fragment’s to both OS and support library but they corrected this mistake by deprecating the version bundled with the OS a while ago . It was really confusing which version of the Fragment needs to be used. The reason of the introduction of the fragments was Multi Pane Layouts. It is basically dividing the screen into list and detail views when the screen is landscape and using the whole screen either list or detail view in portrait mode. The answer to the “Why we are not using custom View’s?” complicates things more. I believe the purpose of Fragments was not bundling views as screens but have constructs that would survive between Activities when they recreated because of the config changes like screen orientation change. The recreation of Activities caused two problems:
- It was hard to transfer state of the destroyed Activity to newly created one
- If a async task (it was probably AsyncTask) is running while the config change is made it was causing crashes because it cannot find the Activity and its elements callback referring to. It was causing crashes and failure to notify user about the result of the task.
Of course this problems had solutions but they introduce a lot of boilerplate and they were not mentioned in code examples. So a lot of developers and apps suffered with this problems. So the Fragments introduced as best practice to this problems since they can stay alive if an Activity gets destroyed. Many believed Fragments complicated things more and I mostly agree with them.
Layout
With the layouts introduced with the Support library was adding new layouts to the stack and improve the existing ones. I will mention about three layouts and tell some Android history.
Toolbar
When Android 3.0 introduced a new design language called Halo was also introduced along with Multi Pane Layout. One of the core elements to Halo was using the ActionBar. But pre 3.0 versions didn’t have ActionBar bundled in. As far as I know Jake Wharton ported ActionBar source code as ActionBar Sherlock and allow developers to use it in older Android versions. ActionBar Sherlock was so good that Google didn’t have to release a Support Library for ActionBar for years. Now with Material Design we have Toolbar to serve this purpose.
RecyclerView
Before RecyclerView, ListView and GridView is used to dynamically display a list of similar kind of items in an efficient way.
There are two things needs to be done in the getView() method of the adapter for scroll performance with ListView and GridView. First one is reusing the convertView instead of creating a new View and the second one is to use ViewHolder pattern to avoid calling findViewById() to access children of the parent view every time the method called. With this two techniques we might have similar performance with the RecyclerView but ListView api doesn’t enforce them to be implemented. But with RecyclerView and its adapter takes care of some of this stuff and enforces developers to do the rest.
ListView and Gridview has other problems like hard customization and using different types of views. With LayoutManager we can set how the list will be displayed(in a list, grid etc) and with ItemDecorator we can specify things like dividers and headers to the RecyclerView. getItemViewType(position: Int)metod in the RecyclerView.Adapter and the viewType parameter in the onCreateViewHolder(parent: ViewGroup, viewType: Int) method allows us to use different kinds of views.
ConstraintLayout
FrameLayout, RelativeLayout and LinearLayout were main layouts on Android. With these we could pretty much get any screen done but in some cases we had to use nested layouts. Every View and ViewGroup added to the layout affects the performance. ConstraintLayout came to help to create screens in a flat hierarchy. RelativeLayout can also achieve a flat view hierarchy but ConstraintLayout offers better performance. I want to note that for better performance I still prefer LinearLayout or FrameLayout over ConstraintLayout if I won’t have nested layouts.
MultiDex
When the .apk is getting build the codes we wrote and libraries we use are compiled into bytecode and put into .dex files. Dalvik can reference 64k (65,536) methods in memory in a .dex file. Before Android 5 .apk’s containing only one dex file. This was potentially causing exceeding 64k limit in a .dex file and it was causing crashes. After the Support Library introduced, classes should have been bundled with the os was included in to .apk as a library. Also the Android ecosystem also grown and developers started to include more libraries to their projects. Eventually projects started to hit 64k limit. Companies like Facebook implemented their own solutions but it was not case for everyone. I remember I had to remove stuff to not get passed with the 64k limit. At some point Android Support Library and Google Play Services split up into multiple smaller libraries and reduced the contribution to the dex method count. Proguard saved a lot of people from this headaches but it wasn’t used in every project. MultiDex support library came to rescue for projects supporting pre Android 5 and enabled using multiple .dex files in an .apk. I hope all projects would be minSdkVersion 21+ so we won’t have to use Multidex Support library.
AppCompat
AppCompat adds some new functionality but I think the main purpose of this is to allow us to use whatever is available in the OS without having to worry about the api version. That means you might get different results with different api versions. For example NotificationCompat api document gives this example “Action buttons won’t appear on platforms prior to Android 4.1. Action buttons depend on expanded notifications, which are only available in Android 4.1 and later.”
Google Play Services
As you know Android is an open source OS. This means anyone can get the code, do customizations and run it on their devices. But it doesn’t contain Google services (Google apps) so if you fork the OS you won’t get Google Play, the Google search engine even Firebase Cloud Messaging(aka Google Cloud Messaging). If a company wants to run Android on their devices and needs this of services there are two ways: first one is to agree Google’s terms and get a license to include Google apps to your device and the second one is to fill in the gaps yourself (Amazon and at some point Blackberry went this way).
In the center of the Google Services on Android there is a library called Google Play Services. This is updatable through Google Play and has root privileges. With the Google Play Services and Firebase libraries, we are calling to api’s of Google Play Services. After Google acquired Firebase, combined some of the existing Google functionality under Firebase and made it available through Google Play Services on Android. I think Google Play Services created to serve Google Play app but Google extended the functionality to other services.
In the second part of this series I want to talk about Android architecture and Architecture Components in the last one. If you can let me know about things you think is missing and you want to be explained I can try to include it as part of this series. I thank Furkan Aşkın for reviewing this post. See you in the next one.
Here is the second and third part of the series:
📝 Read this story later in Journal.
👩💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.
