Foundation Components of Android Jetpack

Android Jetpack is a set of software components, libraries, tools, and guidance to help in developing robust Android applications. Launched by Google in 2018, Jetpack comprises existing android support libraries, android architecture components with an addition of the Android KTX library as a single modular entity. Nowadays, nearly 99% of the apps present on the Google Play Store uses Android Jetpack libraries. The core system components of android apps reside in the Foundation area of Jetpack. Kotlin extension for the language support and Testing libraries are also present in it. Moreover, backward compatibility is provided from the libraries present in this component. This article explains each and every library of the Foundation component in detail. Jetpack consist of a wide collection of libraries that are built in a way to work together and make robust mobile applications. Its software components have been divided into 4 categories:

1. Foundation Components
2. Architecture Components
3. Behavior Components
4. UI Components

Further, the following are the list of all Foundation components:

1. AppCompat
2. Android KTX
3. Test
4. Multidex

Ways to include Android Jetpack libraries in the application

Add google repository in the build.gradle file of the application project.

allprojects {

  repositories {

      google()

      mavenCentral()

      }

}

All Jetpack components are available in the Google Maven repository, include them in the build.gradle file

allprojects {

   repositories {

       google()

       mavenCentral()

   }

}

Foundation Components

1. AppCompat

The AppCompat library in Jetpack foundation includes all of the components from the v7 library. This includes AppCompat, Cardview, GridLayout, MediaRouter, Palette, RecyclerView, Renderscript, Preferences, Leanback, Vector Drawable, Design, Custom tabs, etc. Moreover, this library provides implementation support to the material design user interface which makes AppCompat very useful for the developers. Following are some key areas of an android application that are difficult to build but can be designed effortlessly using the AppCompat library:

• App bar: The topmost element in an application is its app bar/action bar which generally contains the name of the application or current activity name. AppCompat library facilitates the developers to design a more customized App bar. It provides a toolbar for designing and painting the background of the app bar with primary colors or gradient background(multiple colors).
• Navigation drawer: It is the left pane menu that provides an easy navigation guide of the application. This is a very common design pattern nowadays, and so it is needed to add very often. By using the AppCompat library, it is very straightforward to manage the colors and icons of the navigation drawer. In order to create a navigation drawer, developers just required to add a DrawerLayout with the main view and a NavigationView. Further, this library also assists in managing the active state of each menu element with XML resources.
• Permissions: In the newer version of android OS, applications ask permission from users in order to access device hardware such as camera, microphone, etc or to perform certain actions. The further operations performed by the application depend upon the choice selected by the user i.e., whether permission is granted or not. However, this was not the case before the Marshmallow(6.0) version of the Android OS. In older versions, developers do not need to write any code in the SDK which asks permission from the users and check whether it is granted or not. This problem has been solved by the ContextCompat(a component of AppCompat) which checks the permission status of an operation and request from the user if needed irrespective of the android OS version.
• Resources: Previously, more lines of code are needed to design the XML resources like drawable resources which are supported by a specific Android OS version. Using ContextCompat(part of AppCompat), the number of lines of code reduce drastically as well as the dependency of drawables on the OS version also removed.
• Dialog box: The AppCompat library has an AppCompatDialog component which is similar to the toolbar. It helps in making the material design dialog box in an application.
• Share actions: Sharing of any document/file from one application to another platform is possible because of the AppCompat library. The list of share actions like Gmail, Facebook, message, etc which appears on the screen when a document/file is selected to share is provided by the Activity toolbar of the AppCompat library.

2. Android KTX

This library is the only one among the foundation components which was introduced for the first time with the release of the Jetpack. Android KTX is a collection of Kotlin extensions that are designed to facilitate developers to remove boilerplate code as well as to write concise code while developing android applications with Kotlin language. Here KTX in the name stands for Kotlin Extensions. Below is an example of a piece of code without using and after using the Android KTX library:

Code snippet of SQLite without using KTX library:

db.beginTransaction()

try {

 // insert data

 db.setTransactionSuccessful()

} 

finally {

 db.endTransaction()

}

Above code after using KTX library:

db.transaction {

   // insert data

}

This example clearly depicts how the Android KTX library reduced the lines of code and gracefully organized the SQLite transactions using a simple function along with a trailing lambda. Many of the jetpack libraries are linked with various Android KTX modules. For example, one can use the below extensions while working with the Navigation component of Android Jetpack.  

• android.arch.navigation:navigation-common-ktx
• android.arch.navigation:navigation-fragment-ktx
• android.arch.navigation:navigation-runtime-ktx
• and android.arch.navigation:navigation-ui-ktx

3. Test

This part of the foundation component includes the Espresso UI testing framework for the runtime UI test and AndroidJUnitRunner for the purpose of unit testing of Android applications. Espresso is primarily used for the testing of UI elements. Further, AndroidJUnitRunner performs small tests on the logic of each and every method. It assures the fast and accurate testing of a specific piece of logic within the project code.

4. Multidex

The multidex property of Android is one of the most important features while developing mobile applications. Dex is the format of the executable file which runs on the Android virtual machine(known as Dalvik). To make a .dex file according to the Dalvik Executable specification, it must not contain more than 65,536 methods considering all libraries of the project. 

While making any real-life mobile application, the count of methods in project libraries can easily cross that number. In this situation, developers take the help of Multidex library which performs the system split of the .dex file of the application into multiple .dex files. Further, the Multidex component also provides support to the collective dex files of an application.

Detecting the need for Multidex in the application:

It is impractical for anyone to keep a record of method count while developing an application. Thus to know if there is a need for Multidex in the project files or not, one should look out for the following errors. If the IDE shows one of these errors while building the application files, then it means there is a need to enable Multidex.

Error Message 1: 

trouble writing output:

Too many field references: 131000; max is 65536.

You may try using –multi-dex option.

Error Message 2: 

Conversion to Dalvik format failed:

Unable to execute dex: method ID not in [0, 0xffff]: 65536

Enable Multidex:

The code to enable Multidex depends upon the minimum SDK version of the android app. For different SDK versions, below is the code snippet of the build.gradle file.

a. For minimum SDK version equal to or above 21:

android{

   // …

   defaultConfig {

       // …

       minSdkVersion 21

       targetSdkVersion 30

       multiDexEnabled true

   }

   // …

}

b. For minimum SDK version less than 21:

i. For AndroidX

android {

   defaultConfig {

       // …

       minSdkVersion 18

       targetSdkVersion 30

       multiDexEnabled true

   }

   // …

}

dependencies {

   // …

   implementation ‘androidx.multidex:multidex:2.0.0’

}

ii. For old Support Library:

android {

   defaultConfig {

       // …

       minSdkVersion 18

       targetSdkVersion 30

       multiDexEnabled true

   }

   // …

}

dependencies {

   // …

   implementation ‘com.android.support:multidex:1.0.3’

}