Android – How To Schedule Tasks With WorkManager ?

Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Schedule Tasks With WorkManager ?).

In this article, we will learn about how to schedule tasks with WorkManager. WorkManager is an API that makes it easy to schedule deferrable, asynchronous tasks that are expected to run even if the app exits or the device restarts. The WorkManager API is a suitable and recommended replacement for all previous Android background scheduling APIs, including FirebaseJobDispatcher, GcmNetworkManager, and Job Scheduler. WorkManager incorporates the features of its predecessors in a modern, consistent API that works back to API level 14 while also being conscious of battery life. This article explains about WorkManager workflow and advantages in Android application.

To understand the WorkManager in Android, we cover the below topics as below :

  • What is WorkManager?
  • Why use WorkManager ?
  • Features of WorkManager
  • When to use WorkManager?
  • How WorkManager works?
  • WorkManager implementation demo application to Schedule Tasks
  • Demo application output

A famous quote about learning is :

There is no end to education. It is not that you read a book, pass an examination, and finish with education. The whole of life, from the moment you are born to the moment you die, is a process of learning.

So Let’s begin.

What is WorkManager ?

WorkManager is a background processing library which is used to execute background tasks which should run in a guaranteed way but not necessarily immediately.

WorkManager is a task scheduler that makes it easy to specify the asynchronous task easily and when they should run. The WorkManager API helps create the task and hand it to the Work Manager to run immediately or at an appropriate time as mentioned.

With WorkManager, we can enqueue our background processing even when the app is not running and the device is rebooted for some reason. WorkManager also lets us define constraints necessary to run the task e.g. network availability before starting the background task.

For example, we might point our app to download new resources from the network from time to time and now the downloading is a task and we can set up this task to run at an appropriate time depending on the availability of the WIFI network or when the device is charging. So this way we can schedule a task using WorkManager.

WorkManager is a part of Android Jetpack (a suite of libraries to guide developers to write quality apps) and is one of the Android Architecture Components (collection of components that help developers design robust, testable, and easily maintainable apps).

Source : Android Developers – WorkManager Criteria

If our app targets Android 10 (API level 29) or above, our FirebaseJobDispatcher and GcmNetworkManager API calls will no longer work on devices running Android Marshmallow (6.0) and above.

Why use WorkManager ?

Since Marshmallow, The Android development team is continuously working on battery optimizations. After that team introduced Doze mode. Then in Oreo imposed various kind of limitation on performing background jobs. Before WorkManager, we use various job scheduler for performing background task, such as Firebase JobDispatcher, Job Scheduler and Alarm Manager + Broadcast receivers. So for the developer perspective, it is difficult to choose which scheduler should use and which one is good. So the Work Manager handles these kinds of stuff. We have to pass the task to the WorkManager and It uses all this Firebase Job Dispatcher, Alarm Manager + Broadcast Receivers, Job Scheduler to perform the background task depending on the requirement.

Features of WorkManager

In addition to providing a simpler and consistent API, WorkManager has a number of other key benefits, including:

Work Constraints

Declaratively define the optimal conditions for our work to run using Work Constraints. (For example, run only when the device is Wi-Fi, when the device idle, or when it has sufficient storage space, etc.)

Robust Scheduling

WorkManager allows us to schedule work to run one- time or repeatedly using flexible scheduling windows. Work can be tagged and named as well, allowing us to schedule unique, replaceable work and monitor or cancel groups of work together. Scheduled work is stored in an internally managed SQLite database and WorkManager takes care of ensuring that this work persists and is rescheduled across device reboots. In addition, WorkManager adheres to power-saving features and best practices like Doze mode, so we don’t have to worry about it.

Flexible Retry Policy

WorkManager offers flexible retry policies, including a configurable exponential backoff policy, if work fails.

Work Chaining

For complex related work, chain individual work tasks together using a fluent, natural, interface that allows us to control which pieces run sequentially and which run in parallel. For each work task, we can define input and output data for that work. When chaining work together, WorkManager automatically passes output data from one work task to the next.

Built-In Threading Interoperability

WorkManager integrates seamlessly with RxJava and Coroutines and provides the flexibility to plug in our own asynchronous APIs.

When to use WorkManager?

WorkManager handles background work that needs to run when various constraints are met, regardless of whether the application process is alive or not. Background work can be started when the app is in the background, when the app is in the foreground, or when the app starts in the foreground but goes to the background. Regardless of what the application is doing, background work should continue to execute, or be restarted if Android kills its process.

A common confusion about WorkManager is that it’s for tasks that needs to be run in a “background” thread but don’t need to survive process death. This is not the case. There are other solutions for this use case like Kotlin’s coroutines, ThreadPools, or libraries like RxJava. There are many different situations in which we need to run background work, and therefore different solutions for running background work.

WorkManager can be a perfect background processing library to use in android when our task:

  • Does not need to run at a specific time
  • Can be deferred to be executed
  • Is guaranteed to run even after the app is killed or device is restarted
  • Has to meet constraints like battery supply or network availability before execution

The simplest example can be when our app needs to upload a large chunk of user data to the server. This particular use case meets the criteria we mentioned above to choose WorkManager because:

  • Results need not be reflected immediately in our Android app
  • Data needs to be uploaded even when the upload begins and the user kills the app to work on some other app, and
  • The network needs to be available in order to upload data on the server.

How WorkManager Works ?

In this section, we will understand the class and concept of WorkManager. Let’s understand what are various base classes that are used for Job Scheduling.

Worker

Work is defined using the Worker class. It specifies what task to perform. The WorkManager API include an abstract Worker class and we need to extends this class and perform the work.

WorkRequest

WorkRequest represents an individual task that is to be performed. Now this WorkRequest, we can add values details for the work. Such as constraint or we can also add data while creating the request.

WorkRequest can be of to type :

  • OneTimeWorkRequest– That means we requesting for non-repetitive work.
  • PeriodicWorkRequest– This class is used for creating a request for repetitive work.

WorkManager

The WorkManager class in enqueues and manages all the work request. We pass work request object to this WorkManager to enqueue the task.

WorkInfo

WorkInfo contains the information about a particular task, The WorkManager provides LiveData for each of the work request objects, We can observe this and get the current status of the task.

WorkManager Implementation Demo Application to Schedule Tasks

In this section, we will discuss the below steps for implement WorkManager to schedule task with authentic android demo application :

  • Add WorkManager dependency in app/buid.gradle file
  • Create Layout
  • Add a base class of Worker
  • Create WorkRequest
  • Enqueue the request with WorkManager
  • Fetch the particular task status

1. Add WorkManager dependency in app/buid.gradle file

For using WorkManager we have to add dependency in app/build.gradle file. So let’s open the app build.gradle file and add below lines.

implementation 'androidx.work:work-runtime-ktx:2.5.0'

The source code of app/buid.gradle file is

plugins {
    id 'com.android.application'
    id 'kotlin-android'
}

android {
    compileSdkVersion 30
    buildToolsVersion "30.0.2"

    defaultConfig {
        applicationId "com.coolmonktechie.android.workmanagerdemo"
        minSdkVersion 23
        targetSdkVersion 30
        versionCode 1
        versionName "1.0"

        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
    kotlinOptions {
        jvmTarget = '1.8'
    }
}

dependencies {

    implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
    implementation 'androidx.core:core-ktx:1.3.2'
    implementation 'androidx.appcompat:appcompat:1.2.0'
    implementation 'com.google.android.material:material:1.3.0'
    implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
    implementation 'androidx.work:work-runtime-ktx:2.5.0'
    testImplementation 'junit:junit:4.+'
    androidTestImplementation 'androidx.test.ext:junit:1.1.2'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0'
}

2. Create Layout

In this step, we will create a layout. This layout will contain TextView and Button. After that, we will set onClickListener() and this event will enqueue the WorkRequest to WorkManager and shows the status on TextView.

activity_main.xml

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <TextView
        android:id="@+id/tvStatus"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginBottom="8dp"
        android:gravity="center"
        android:text="Result display here"
        android:textSize="18sp"
        app:layout_constraintBottom_toTopOf="@+id/btnSend"
        app:layout_constraintHorizontal_bias="0.5"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintVertical_chainStyle="packed" />

    <Button
        android:id="@+id/btnSend"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_marginStart="16dp"
        android:layout_marginTop="16dp"
        android:layout_marginEnd="16dp"
        android:background="@color/accent"
        android:paddingLeft="8dp"
        android:paddingRight="8dp"
        android:text="Send Notification without Constraints"
        android:textAllCaps="false"
        android:textColor="#fff"

        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintHorizontal_bias="0.5"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/tvStatus" />

    <Button
        android:id="@+id/buttonStorageNotLow"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_marginStart="16dp"
        android:layout_marginTop="8dp"
        android:layout_marginEnd="16dp"
        android:background="@color/accent"
        android:text="Send Notification with requiresStorageNotLow()"
        android:textAllCaps="false"
        android:textColor="#fff"
        app:layout_constraintBottom_toTopOf="@+id/buttonBatteryNotLow"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintHorizontal_bias="0.5"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/btnSend" />

    <Button
        android:id="@+id/buttonBatteryNotLow"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_marginStart="16dp"
        android:layout_marginTop="8dp"
        android:layout_marginEnd="16dp"
        android:background="@color/accent"
        android:text="Send Notification with requiresBatteryNotLow()"
        android:textAllCaps="false"
        android:textColor="#fff"
        app:layout_constraintBottom_toTopOf="@+id/buttonRequiresCharging"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintHorizontal_bias="0.5"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/buttonStorageNotLow" />

    <Button
        android:id="@+id/buttonRequiresCharging"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_marginStart="16dp"
        android:layout_marginTop="8dp"
        android:layout_marginEnd="16dp"
        android:background="@color/accent"
        android:text="Send Notification with requiresCharging()"
        android:textAllCaps="false"
        android:textColor="#fff"
        app:layout_constraintBottom_toTopOf="@+id/buttonDeviceIdle"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintHorizontal_bias="0.5"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/buttonBatteryNotLow" />

    <Button
        android:id="@+id/buttonDeviceIdle"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_marginStart="16dp"
        android:layout_marginTop="8dp"
        android:layout_marginEnd="16dp"
        android:background="@color/accent"
        android:text="Send Notification with requiresDeviceIdle()"
        android:textAllCaps="false"
        android:textColor="#fff"
        app:layout_constraintBottom_toTopOf="@+id/buttonNetworkType"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintHorizontal_bias="0.5"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/buttonRequiresCharging" />

    <Button
        android:id="@+id/buttonNetworkType"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_marginStart="16dp"
        android:layout_marginTop="8dp"
        android:layout_marginEnd="16dp"
        android:layout_marginBottom="32dp"
        android:background="@color/accent"
        android:text="Send Notification with getRequiredNetworkType()"
        android:textAllCaps="false"
        android:textColor="#fff"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintHorizontal_bias="0.5"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/buttonDeviceIdle" />

</androidx.constraintlayout.widget.ConstraintLayout>

3. Add a base class of Worker

In this step, we create a base class of Worker class and override un-implemented methods and super constructor.

NotificationWorker.kt

package com.coolmonktechie.android.workmanagerdemo

import android.app.NotificationChannel
import android.app.NotificationManager
import android.content.Context
import android.os.Build
import androidx.core.app.NotificationCompat
import androidx.work.Data
import androidx.work.Worker
import androidx.work.WorkerParameters

class NotificationWorker(context: Context, workerParams: WorkerParameters) :
    Worker(context, workerParams) {
    override fun doWork(): Result {
        val taskData = inputData
        val taskDataString = taskData.getString(MainActivity.MESSAGE_STATUS)
        showNotification("WorkManager", "Message has been Sent")
        val outputData = Data.Builder().putString(WORK_RESULT, "Jobs Finished").build()
        return Result.success(outputData)
    }

    private fun showNotification(task: String, desc: String) {
        val manager =
            applicationContext.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager
        val channelId = "task_channel"
        val channelName = "task_name"
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val channel =
                NotificationChannel(channelId, channelName, NotificationManager.IMPORTANCE_DEFAULT)
            manager.createNotificationChannel(channel)
        }
        val builder = NotificationCompat.Builder(applicationContext, channelId)
            .setContentTitle(task)
            .setContentText(desc)
            .setSmallIcon(R.mipmap.ic_launcher)
        manager.notify(1, builder.build())
    }

    companion object {
        private const val WORK_RESULT = "work_result"
    }
}

4. Create WorkRequest

Let’s move to MainActivity and create a WorkRequest to execute the work that we just created. Now first we will create WorkManager. This work manager will enqueue and manage our work request.

var mWorkManager:WorkManager = WorkManager.getInstance()

Now we will create OneTimeWorkRequest, because we want to create a task that will be executed just once.

var mRequest: OneTimeWorkRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java).build()

Using this code, we built work request that will be executed one time only.

5. Enqueue the request with WorkManager

In this step, we discuss onClick() of the button. we will enqueue this request using the WorkManager. So that’s all we need to do.

mWorkManager!!.enqueue(mRequest!!)

6. Fetch the particular task status

In this steps, we will fetch some information about this particular task and display it on tvStatus TextView. We will do that using WorkInfo class. The work manager provides LiveData for each of the work request objects, We can observe this and get the current status of the task.

mWorkManager!!.getWorkInfoByIdLiveData(mRequest!!.id).observe(this, { workInfo ->
        if (workInfo != null) {
            val state = workInfo.state
            tvStatus!!.append(
                """
$state

""".trimIndent()
            )
        }
    })

Finally, the full source code of MainActivity.kt looks like this:

package com.coolmonktechie.android.workmanagerdemo

import android.os.Build
import android.os.Bundle
import android.view.View
import android.widget.Button
import android.widget.TextView
import androidx.appcompat.app.AppCompatActivity
import androidx.work.Constraints
import androidx.work.NetworkType
import androidx.work.OneTimeWorkRequest
import androidx.work.WorkManager
import com.sunilmishra.android.workmanagerdemo.NotificationWorker

class MainActivity : AppCompatActivity(), View.OnClickListener {
    var tvStatus: TextView? = null
    var btnSend: Button? = null
    var btnStorageNotLow: Button? = null
    var btnBatteryNotLow: Button? = null
    var btnRequiresCharging: Button? = null
    var btnDeviceIdle: Button? = null
    var btnNetworkType: Button? = null
    var mRequest: OneTimeWorkRequest? = null
    var mWorkManager: WorkManager? = null
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        initViews()
        tvStatus = findViewById(R.id.tvStatus)
        btnSend = findViewById(R.id.btnSend)
        mWorkManager = WorkManager.getInstance()
    }

    private fun initViews() {
        tvStatus = findViewById(R.id.tvStatus)
        btnSend = findViewById(R.id.btnSend)
        btnStorageNotLow = findViewById(R.id.buttonStorageNotLow)
        btnBatteryNotLow = findViewById(R.id.buttonBatteryNotLow)
        btnRequiresCharging = findViewById(R.id.buttonRequiresCharging)
        btnDeviceIdle = findViewById(R.id.buttonDeviceIdle)
        btnNetworkType = findViewById(R.id.buttonNetworkType)
        btnSend!!.setOnClickListener(this)
        btnStorageNotLow!!.setOnClickListener(this)
        btnBatteryNotLow!!.setOnClickListener(this)
        btnRequiresCharging!!.setOnClickListener(this)
        btnDeviceIdle!!.setOnClickListener(this)
        btnNetworkType!!.setOnClickListener(this)
    }

    override fun onClick(v: View) {
        tvStatus!!.text = ""
        val mConstraints: Constraints
        when (v.id) {
            R.id.btnSend -> mRequest =
                OneTimeWorkRequest.Builder(NotificationWorker::class.java).build()
            R.id.buttonStorageNotLow -> {
                /**
                 * Constraints
                 * If TRUE task execute only when storage's is not low
                 */
                mConstraints = Constraints.Builder().setRequiresStorageNotLow(true).build()
                /**
                 * OneTimeWorkRequest with requiresStorageNotLow Constraints
                 */
                mRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java)
                    .setConstraints(mConstraints).build()
            }
            R.id.buttonBatteryNotLow -> {
                /**
                 * Constraints
                 * If TRUE task execute only when battery isn't low
                 */
                mConstraints = Constraints.Builder().setRequiresBatteryNotLow(true).build()
                /**
                 * OneTimeWorkRequest with requiresBatteryNotLow Constraints
                 */
                mRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java)
                    .setConstraints(mConstraints).build()
            }
            R.id.buttonRequiresCharging -> {
                /**
                 * Constraints
                 * If TRUE while the device is charging
                 */
                mConstraints = Constraints.Builder().setRequiresCharging(true).build()
                /**
                 * OneTimeWorkRequest with requiresCharging Constraints
                 */
                mRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java)
                    .setConstraints(mConstraints).build()
            }
            R.id.buttonDeviceIdle -> if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
                /**
                 * Constraints
                 * If TRUE while the  device is idle
                 */
                mConstraints = Constraints.Builder().setRequiresDeviceIdle(true).build()
                /**
                 * OneTimeWorkRequest with requiresDeviceIdle Constraints
                 */
                mRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java)
                    .setConstraints(mConstraints).build()
            }
            R.id.buttonNetworkType -> {
                /**
                 * Constraints
                 * Network type is conneted
                 */
                mConstraints =
                    Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build()
                /**
                 * OneTimeWorkRequest with requiredNetworkType Connected Constraints
                 */
                mRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java)
                    .setConstraints(mConstraints).build()
            }
            else -> {
            }
        }
        /**
         * Fetch the particular task status using request ID
         */
        mWorkManager!!.getWorkInfoByIdLiveData(mRequest!!.id).observe(this, { workInfo ->
            if (workInfo != null) {
                val state = workInfo.state
                tvStatus!!.append(
                    """
    $state
    
    """.trimIndent()
                )
            }
        })
        /**
         * Enqueue the WorkRequest
         */
        mWorkManager!!.enqueue(mRequest!!)
    }

    companion object {
        const val MESSAGE_STATUS = "message_status"
    }
}

Demo Application Output

In this section, we will see the demo application output screen as below. We click on Send Notification button. The Job status will show on TextView.

WorkManager Demo Application Output 1
WorkManager Demo Application Output 2

That’s all about in this article.

Related Other Articles / Posts

Conclusion

In this article, we understood about how to schedule tasks with WorkManager. This article explained about WorkManager workflow and advantages in Android application.

Thanks for reading! I hope you enjoyed and learned about WorkManager concepts in Android. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find other articles of CoolMonkTechie as below link :

You can also follow official website and tutorials of Android as below links :

If you have any comments, questions, or think I missed something, leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???

Android – How To Run Android Tasks In Background Threads ?

Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Run Android Tasks In Background Threads ?).

In this article, we will learn about how to run android tasks in background threads. All Android apps use a main thread to handle UI operations. Calling long-running operations from this main thread can lead to freezes and unresponsiveness. For example, if our app makes a network request from the main thread, our app’s UI is frozen until it receives the network response. We can create additional background threads to handle long-running operations while the main thread continues to handle UI updates.

This article shows both Kotlin and Java Programming Language developers to use of a thread pool to set up and use multiple threads in an Android app. It also explains code definitions to run on a thread and communications between one of these threads and the main thread.

A famous quote about learning is :

That is what learning is. You suddenly understand something you’ve understood all your life, but in a new way.

So Let’s begin.

Overview

In this example section, we will make a network request and return the result to the main thread, where the app then might display that result on the screen. Specifically, the ViewModel calls the repository layer on the main thread to trigger the network request. The repository layer is in charge of moving the execution of the network request off the main thread and posting the result back to the main thread using a callback.

To move the execution of the network request off the main thread, we need to create other threads in our app.

Creating Multiple Threads

thread pool is a managed collection of threads that runs tasks in parallel from a queue. New tasks are executed on existing threads as those threads become idle. To send a task to a thread pool, use the ExecutorService interface. Note that ExecutorService has nothing to do with Services, the Android application component.

Creating threads is expensive, so we should create a thread pool only once as our app initializes. Be sure to save the instance of the ExecutorService either in our Application class or in a dependency injection container. The following example creates a thread pool of four threads that we can use to run background tasks.

class MyApplication : Application() {
    val executorService: ExecutorService = Executors.newFixedThreadPool(4)
}

Executing In A Background Thread

Making a network request on the main thread causes the thread to wait, or block, until it receives a response. Since the thread is blocked, the OS can’t call onDraw(), and our app freezes, potentially leading to an Application Not Responding (ANR) dialog. Instead, let’s run this operation on a background thread.

First, let’s take a look at our Repository class and see how it’s making the network request:

sealed class Result<out R> {
    data class Success<out T>(val data: T) : Result<T>()
    data class Error(val exception: Exception) : Result<Nothing>()
}

class LoginRepository(private val responseParser: LoginResponseParser) {
    private const val loginUrl = "https://example.com/login"

    // Function that makes the network request, blocking the current thread
    fun makeLoginRequest(
        jsonBody: String
    ): Result<LoginResponse> {
        val url = URL(loginUrl)
        (url.openConnection() as? HttpURLConnection)?.run {
            requestMethod = "POST"
            setRequestProperty("Content-Type", "application/json; charset=utf-8")
            setRequestProperty("Accept", "application/json")
            doOutput = true
            outputStream.write(jsonBody.toByteArray())

            return Result.Success(responseParser.parse(inputStream))
        }
        return Result.Error(Exception("Cannot open HttpURLConnection"))
    }
}

makeLoginRequest() is synchronous and blocks the calling thread. To model the response of the network request, we have our own Result class.

The ViewModel triggers the network request when the user taps, for example, on a button:

class LoginViewModel(
    private val loginRepository: LoginRepository
) {
    fun makeLoginRequest(username: String, token: String) {
        val jsonBody = "{ username: \"$username\", token: \"$token\"}"
        loginRepository.makeLoginRequest(jsonBody)
    }
}

With the previous code, LoginViewModel is blocking the main thread when making the network request. We can use the thread pool that we’ve instantiated to move the execution to a background thread. First, following the principles of dependency injectionLoginRepository takes an instance of Executor as opposed to ExecutorService because it’s executing code and not managing threads:

class LoginRepository(
    private val responseParser: LoginResponseParser
    private val executor: Executor
) { ... }

The Executor’s execute() method takes a Runnable. A Runnable is a Single Abstract Method (SAM) interface with a run() method that is executed in a thread when invoked.

Let’s create another function called makeLoginRequest() that moves the execution to the background thread and ignores the response for now:

class LoginRepository(
    private val responseParser: LoginResponseParser
    private val executor: Executor
) {

    fun makeLoginRequest(jsonBody: String) {
        executor.execute {
            val ignoredResponse = makeSynchronousLoginRequest(url, jsonBody)
        }
    }

    private fun makeSynchronousLoginRequest(
        jsonBody: String
    ): Result<LoginResponse> {
        ... // HttpURLConnection logic
    }
}

Inside the execute() method, we create a new Runnable with the block of code, we want to execute in the background thread—in our case, the synchronous network request method. Internally, the ExecutorService manages the Runnable and executes it in an available thread.

In Kotlin, we can use a lambda expression to create an anonymous class that implements the SAM interface.

Considerations

Any thread in our app can run in parallel to other threads, including the main thread, so we should ensure that our code is thread-safe. Notice that in our example that we avoid writing to variables shared between threads, passing immutable data instead. This is a good practice, because each thread works with its own instance of data, and we avoid the complexity of synchronization.

If we need to share state between threads, we must be careful to manage access from threads using synchronization mechanisms such as locks. In general we should avoid sharing mutable state between threads whenever possible.

Communicating With The Main Thread

In the previous step, we ignored the network request response. To display the result on the screen, LoginViewModel needs to know about it. We can do that by using callbacks.

The function makeLoginRequest() should take a callback as a parameter so that it can return a value asynchronously. The callback with the result is called whenever the network request completes or a failure occurs. In Kotlin, we can use a higher-order function.

class LoginRepository(
    private val responseParser: LoginResponseParser
    private val executor: Executor
) {

    fun makeLoginRequest(
        jsonBody: String,
        callback: (Result<LoginResponse>) -> Unit
    ) {
        executor.execute {
            try {
                val response = makeSynchronousLoginRequest(jsonBody)
                callback(response)
            } catch (e: Exception) {
                val errorResult = Result.Error(e)
                callback(errorResult)
            }
        }
    }
    ...
}

The ViewModel needs to implement the callback now. It can perform different logic depending on the result:

class LoginViewModel(
    private val loginRepository: LoginRepository
) {
    fun makeLoginRequest(username: String, token: String) {
        val jsonBody = "{ username: \"$username\", token: \"$token\"}"
        loginRepository.makeLoginRequest(jsonBody) { result ->
            when(result) {
                is Result.Success<LoginResponse> -> // Happy path
                else -> // Show error in UI
            }
        }
    }
}

In this example, the callback is executed in the calling thread, which is a background thread. This means that we cannot modify or communicate directly with the UI layer until we switch back to the main thread.

To communicate with the View from the ViewModel layer, use LiveData as recommended in the updated app architecture. If the code is being executed on a background thread, we can call MutableLiveData.postValue() to communicate with the UI layer.

Using Handlers

We can use a Handler to enqueue an action to be performed on a different thread. To specify the thread on which to run the action, construct the Handler using a Looper for the thread. A Looper is an object that runs the message loop for an associated thread. Once we’ve created a Handler, we can then use the post(Runnable) method to run a block of code in the corresponding thread.

Looper includes a helper function, getMainLooper(), which retrieves the Looper of the main thread. We can run code in the main thread by using this Looper to create a Handler. As this is something we might do quite often, we can also save an instance of the Handler in the same place we saved the ExecutorService:

class MyApplication : Application() {
    val executorService: ExecutorService = Executors.newFixedThreadPool(4)
    val mainThreadHandler: Handler = HandlerCompat.createAsync(Looper.getMainLooper())
}

It’s a good practice to inject the handler to the Repository, as it gives us more flexibility. For example, in the future we might want to pass in a different Handler to schedule tasks on a separate thread. If we’re always communicating back to the same thread, we can pass the Handler into the Repository constructor, as shown in the following example.

class LoginRepository(
    ...
    private val resultHandler: Handler
) {

    fun makeLoginRequest(
        jsonBody: String,
        callback: (Result<LoginResponse>) -> Unit
    ) {
          executor.execute {
              try {
                  val response = makeSynchronousLoginRequest(jsonBody)
                  resultHandler.post { callback(response) }
              } catch (e: Exception) {
                  val errorResult = Result.Error(e)
                  resultHandler.post { callback(errorResult) }
              }
          }
    }
    ...
}

Alternatively, if we want more flexibility, we can pass in a Handler to each function:

class LoginRepository(...) {
    ...
    fun makeLoginRequest(
        jsonBody: String,
        resultHandler: Handler,
        callback: (Result<LoginResponse>) -> Unit
    ) {
        executor.execute {
            try {
                val response = makeSynchronousLoginRequest(jsonBody)
                resultHandler.post { callback(response) }
            } catch (e: Exception) {
                val errorResult = Result.Error(e)
                resultHandler.post { callback(errorResult) }
            }
        }
    }
}

In this example, the callback passed into the Repository’s makeLoginRequest call is executed on the main thread. That means we can directly modify the UI from the callback or use LiveData.setValue() to communicate with the UI.

Configuring A Thread Pool

We can create a thread pool using one of the Executor helper functions with predefined settings, as shown in the previous example code. Alternatively, if we want to customize the details of the thread pool, we can create an instance using ThreadPoolExecutor directly. We can configure the following details:

  • Initial and maximum pool size
  • Keep alive time and time unit. Keep alive time is the maximum duration that a thread can remain idle before it shuts down.
  • An input queue that holds Runnable tasks. This queue must implement the BlockingQueue interface. To match the requirements of our app, we can choose from the available queue implementations.

Here’s an example that specifies thread pool size based on the total number of processor cores, a keep alive time of one second, and an input queue.

class MyApplication : Application() {
    /*
     * Gets the number of available cores
     * (not always the same as the maximum number of cores)
     */
    private val NUMBER_OF_CORES = Runtime.getRuntime().availableProcessors()

    // Instantiates the queue of Runnables as a LinkedBlockingQueue
    private val workQueue: BlockingQueue<Runnable> =
            LinkedBlockingQueue<Runnable>()

    // Sets the amount of time an idle thread waits before terminating
    private const val KEEP_ALIVE_TIME = 1L
    // Sets the Time Unit to seconds
    private val KEEP_ALIVE_TIME_UNIT = TimeUnit.SECONDS
    // Creates a thread pool manager
    private val threadPoolExecutor: ThreadPoolExecutor = ThreadPoolExecutor(
            NUMBER_OF_CORES,       // Initial pool size
            NUMBER_OF_CORES,       // Max pool size
            KEEP_ALIVE_TIME,
            KEEP_ALIVE_TIME_UNIT,
            workQueue
    )
}

Concurrency Libraries

It’s important to understand the basics of threading and its underlying mechanisms. There are, however, many popular libraries that offer higher-level abstractions over these concepts and ready-to-use utilities for passing data between threads. These libraries include Guava and RxJava for the Java Programming Language users and coroutines, which we recommend for Kotlin users.

In practice, we should pick the one that works best for our app and our development team, though the rules of threading remain the same.

That’s all about in this article.

Related Other Articles / Posts

Conclusion

In this article, we understood about how to run android tasks in background threads. This article showed both Kotlin and Java Programming Language developers to use of a thread pool to set up and use multiple threads in an Android app. It also explained code definitions to run on a thread and communications between one of these threads and the main thread.

Thanks for reading! I hope you enjoyed and learned about Running Android Tasks In Background Threads concepts. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find other articles of CoolMonkTechie as below link :

You can also follow official website and tutorials of Android as below links :

If you have any comments, questions, or think I missed something, leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???

Android – How To Apply Background Processing In Android Application?

Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Apply Background Processing In Android Application?).

In this article, we will learn about how to apply background processing in android application. Processing data in the background is an important part of creating an Android application. Therefore, it is both responsive for our users as well as a good citizen on the Android platform. This article explains the below points :

  • what qualifies as background work,
  • defines background task categories,
  • provides us with criteria to categorize our tasks, and
  • recommends APIs that we should use to execute them.

A famous quote about learning is :

Learn as though you would never be able to master it; hold it as though you would be in fear of losing it.

So Let’s begin.

Background Processing Principle

In general, any task that takes more than a few milliseconds should be delegated to a background thread. Common long-running tasks include things like decoding a bitmap, accessing storage, working on a machine learning (ML) model, or performing network requests.

Background Work Definition

An app is considered to be running in the background as long as each of the following conditions are satisfied:

  • None of the app’s activities are currently visible to the user.
  • The app isn’t running any foreground services that started while an activity from the app was visible to the user.

Otherwise, the app is considered to be running in the foreground.

Sometimes, after a foreground service starts while an activity from the app is visible to the user, the user navigates away from the app, such as returning to the home screen. In this situation, the app is considered to be running in the foreground even after the user navigates away from the app.

Common Background Tasks

The following list shows common tasks that an app manages while it runs in the background:

  • Our app registers a broadcast receiver in the manifest file.
  • Existing app schedules a repeating alarm using Alarm Manager.
  • Currently used app schedules a background task, either as a worker using Work Manager or a job using Job Scheduler.

Categories of Background Tasks

Background tasks fall into one of the following main categories:

  • Immediate
  • Deferred
  • Exact

To categorize a task, we need answer the following questions:

Does the task need to complete while the user is interacting with the application?

If so, this task should be categorized for immediate execution. If not, proceed to the second question.

Does the task need to run at an exact time?

If we do need to run a task at an exact time, categorize the task as exact.

Most tasks don’t need to be run at an exact time. Tasks generally allow for slight variations in when they run that are based on conditions such as network availability and remaining battery. Tasks that don’t need to be run at an exact time should be categorized as deferred.

After getting the answer, we traverse the corresponding decision tree which helps us decide best category for our background task.

Source : Android Developers – Task Category Decision Tree

Recommended Solutions

The following sections describe recommended solutions for each background task type.

Immediate Tasks

We recommend Kotlin coroutines for tasks that should end when the user leaves a certain scope or finishes an interaction. Many Android KTX libraries contain ready-to-use coroutine scopes for common app components like ViewModel and common application lifecycles.

Threading on Android is the recommended options for Java programming language users.

For tasks that should be executed immediately and need continued processing, even if the user puts the application in background or the device restarts, we recommend using WorkManager and its support for long-running tasks.

In specific cases, such as with media playback or active navigation, we might want to use foreground Services directly.

Deferred Tasks

A task can deferred if:

  • it is not directly connected to a user interaction and,
  • it can run at any time in the future.

The recommended solution for deferred tasks is WorkManager.

WorkManager makes it easy to schedule deferrable, asynchronous tasks that are expected to run even if the app exits or the device restarts.

Exact Tasks

We can use AlarmManager if task that needs to be executed at an exact point in time.

That’s all about in this article.

Related Other Articles / Posts

Conclusion

In this article, we understood about how to apply background processing in android application. Processing data in the background is an important part of creating an Android application. We can use WorkManager for Immediate and deferred task and continued processing while AlarmManager for Exact Tasks. This article reviewed background work definitions and qualifies, common categories and recommended solutions for background processing tasks in android.

Thanks for reading! I hope you enjoyed and learned about Background Processing concepts in Android. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find other articles of CoolMonkTechie as below link :

You can also follow official website and tutorials of Android as below links :

If you have any comments, questions, or think I missed something, leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???

React Native – How To Apply Run Time Android Permission In React Native ?

Hello Readers, CoolMonkTechie heartily welcomes you in this article ( How To Apply Run Time Android Permission In React Native ).

In this article, we will learn how to apply Run Time Android Permission In React Native. Android Permission feature helps a user to know which application is trying to access sensitive data such as files, contacts and SMS, and system-specific features such as camera and internet. This article shows to apply the run time permission with the authentic example.

To understand the Run Time Android Permission In React Native, we cover the below topics as below :

  • What is Android Permission?
  • Why we need permission?
  • How to apply Permission in Android?
  • How to apply run time Permission in React Native?
  • Example to apply the run time permission.

A famous quote about learning is :

” The great aim of education is not knowledge, but action. “

So Let’s begin.


What is Android Permission ?

According to Google’s privacy policy, a user should know which application is trying to access sensitive data such as files, contacts and SMS, and system-specific features such as camera and internet. So they introduced the Android Permission feature.

In Android permission modal, every application which is using sensitive data or some certain system features has to ask the permissions from the user.

The purpose of permission is to protect the privacy of an Android user.


Why We need Permission ?

Android applies the permission modal because some applications were tracking the user’s location in the background and accessing the private data like contacts, call history and messages without informing the user which is the violation of googles privacy policy.

So solving this sensitive issue application has to ask for permission to access those sensitive data.


How to Apply Permission in Android ?

Now we get an idea about the Android permission, let’s see how to apply the permission in Android.

To apply permission in Android, we have to follow two steps:

  1. We have to add those permissions requests in project -> app -> src -> AndroidManifest.xml file.

For Example, if we want to ask for the device location Permission, we have to add the following permission request in AndroidManifest.xml :

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

After adding the permission in AndroidManifest file, this permission will be automatically asked by the play store when they install the app and this permission will be granted to the applications.

On devices before SDK version 23, the permissions are automatically granted if we add those permissions in our AndroidManifest.xml file, but after SDK version 23 we have to ask runtime permission as well.

2. After Google’s new permission modal, they have introduced the run time permission mechanism in Android version 23. According to that, we have to include all the permissions in AndroidManifest.xml and also have to apply some dangerous permissions in run time.

According to the official docs, dangerous permissions require a dialog prompt.

So whenever we are working with this dangerous permissions, we need to check whether the permission is granted by the user, and that can be done with the help of PermissionsAndroid in React Native.

For example, If we need INTERNET permission and CAMERA permission then we have to add both the permission in AndroidManifest.xml file but have to ask only for the CAMERA permission in run time because CAMERA permission comes under the dangerous permission not INTERNET permission.

Run Time Permissions that requires Confirmation from the User. Here is the list of dangerous permissions.

READ_CALENDARandroid.permission.READ_CALENDAR
WRITE_CALENDARandroid.permission.WRITE_CALENDAR
CAMERAandroid.permission.CAMERA
READ_CONTACTSandroid.permission.READ_CONTACTS
WRITE_CONTACTSandroid.permission.WRITE_CONTACTS
GET_ACCOUNTSandroid.permission.GET_ACCOUNTS
ACCESS_FINE_LOCATIONandroid.permission.ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATIONandroid.permission.ACCESS_COARSE_LOCATION
RECORD_AUDIOandroid.permission.RECORD_AUDIO
READ_PHONE_STATEandroid.permission.READ_PHONE_STATE
CALL_PHONEandroid.permission.CALL_PHONE
READ_CALL_LOGandroid.permission.READ_CALL_LOG
WRITE_CALL_LOGandroid.permission.WRITE_CALL_LOG
ADD_VOICEMAILcom.android.voicemail
USE_SIPandroid.permission.USE_SIP
PROCESS_OUTGOING_CALLSandroid.permission.PROCESS_OUTGOING_CALLS
BODY_SENSORSandroid.permission.BODY_SENSORS
SEND_SMSandroid.permission.SEND_SMS
RECEIVE_SMSandroid.permission.RECEIVE_SMS
READ_SMSandroid.permission.READ_SMS
RECEIVE_WAP_PUSHandroid.permission.RECEIVE_WAP_PUSH
RECEIVE_MMSandroid.permission.RECEIVE_MMS
READ_EXTERNAL_STORAGEandroid.permission.READ_EXTERNAL_STORAGE
WRITE_EXTERNAL_STORAGEandroid.permission.WRITE_EXTERNAL_STORAGE
Run Time Permissions


How to apply Run Time Android Permission using React Native PermissionsAndroid ?

In React Native, PermissionsAndroid component provides access to Android M’s (Over API level 23) new permissions model. We always need to check the permission before using native APIs which comes under dangerous permissions.

Above mentioned all the dangerous permissions comes under PermissionsAndroid.PERMISSIONS as constants.

We can check the permission granted or not using PermissionsAndroid.RESULTS.GRANTED.

To apply the permission to use

PermissionsAndroid.request(permission name,{Permission dialog heading, body})

Result Strings for Requesting Permissions

As constants under PermissionsAndroid.RESULTS:

ResponseResult
GRANTEDPermission granted successfully by the user
DENIEDPermission denied by the user
NEVER_ASK_AGAINPermission denied by the user with never ask again.
Result Strings for Requesting Permissions

Now we get an idea about Android permissions and components. Let’s move towards the Example which can help us apply permission in our application.


Example to Apply the Run Time Permission

In this example, we will apply the device location permission, which needs run time permission. We are making a button on the centre of the screen and on a click of button we will apply the run time permission for device location known as ACCESS_FINE_LOCATION. So let’s get started.


Example Project Setup

To demonstration of apply the Run Time Permission, we have to follow the below steps:

  • Create a new React Native project
  • Adding device location permission in AndroidManifest.xml


1. Create a new React Native project

Assuming that we have node installed, we can use npm to install the react-native-cli command line utility. Open the terminal and go to the workspace and run the following commands to create a new React Native project.

npx react-native init ProjectName

This will make a project structure with an index file named App.js in our project directory.


2. Adding device location permission in AndroidManifest.xml

If we are using any features in our app that needs permission, we need to add it in AndroidManifest.xml. For this example, we are adding device location permission in AndroidManifest.xml.

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
Android Permission

Now jump into the project using

cd ProjectName


Example Code to Apply for the Run Time Permission

Open App.js in any code editor and replace the code with the following code.

App.js

import React, {Component} from 'react';

import {
  Platform,
  StyleSheet,
  View,
  PermissionsAndroid,
  Text,
  Alert,
} from 'react-native';

export async function request_location_runtime_permission() {
  try {
    const granted = await PermissionsAndroid.request(
      PermissionsAndroid.PERMISSIONS.ACCESS_FINE_LOCATION,
      {
        title: 'ReactNativeCode Location Permission',
        message: 'ReactNativeCode App needs access to your location ',
      },
    );
    if (granted === PermissionsAndroid.RESULTS.GRANTED) {
      Alert.alert('Location Permission Granted.');
    } else {
      Alert.alert('Location Permission Not Granted');
    }
  } catch (err) {
    console.warn(err);
  }
}

export default class App extends Component {
  async componentDidMount() {
    await request_location_runtime_permission();
  }

  render() {
    return (
      <View style={styles.MainContainer}>
        <Text>React Native Runtime Permission Request</Text>
      </View>
    );
  }
}

const styles = StyleSheet.create({
  MainContainer: {
    flex: 1,
    paddingTop: Platform.OS === 'ios' ? 20 : 0,
    justifyContent: 'center',
    margin: 20,
  },
});

Here PermissionsAndroid.request has two arguments:

  1. PermissionsAndroid.PERMISSIONS.ACCESS_FINE_LOCATION to generate a dialog to ask for Device Location Permission.
  2. A JSON {‘title’:”,’message’:”}, which will help us to communicate or to show the dialog about the permission if the user denied the permission. They will generate it like this.
Android Permission Dialog Box


To Run the React Native Example Code

Open the terminal again, and jump into our project using

cd ProjectName

To run the project on an Android Virtual Device or on real debugging device

npx react-native run-android

or on the iOS Simulator by running (macOS only)

npx react-native run-ios (macOS only).

The output of example code is as below:

Android Permission Grant Example Output Screenshot

That’s all about in this article.


Conclusion

In this article, we understood how to apply Run Time Android Permission in React Native. This article showed the example code to apply the RunTime Android Permission in React Native.

Thanks for reading! I hope you enjoyed and learned about RunTime Android Permission Concepts in React Native. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe us on this blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find Other articles of CoolmonkTechie as below link :

You can also follow official website and tutorials of React Native as below links :

React Native Official Website

If you have any comments, questions, or think I missed something, feel free to leave them below in the comment box.

Thanks again Reading. HAPPY READING!!???

Android – How To Select Scope Functions In Kotlin?

Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Select Scope Functions In Kotlin?).

In this article, we will learn about how to select Scope Functions in Kotlin. The Kotlin standard library contains several functions whose sole purpose is to execute a block of code within the context of an object. When we call such a function on an object with a lambda expression provided, it forms a temporary scope. In this scope, we can access the object without its name. Such functions are called Scope Functions. This article provides the detailed descriptions of the differences between scope functions and the conventions on their usage in Kotlin with some authentic examples.

A famous quote about learning is :

” Tell me and I forget, teach me and I may remember, involve me and I learn.”

So Let’s begin.

Scope Functions in Kotlin

The definition of Scope function is

Scoped functions are functions that execute a block of code within the context of an object.

These functions provide a way to give temporary scope to the object under consideration where specific operations can be applied to the object within the block of code, thereby, resulting in a clean and concise code. There are five scoped functions in Kotlin: letrunwithalso and apply.

Basically, these functions do the same: execute a block of code on an object. What’s different is how this object becomes available inside the block and what is the result of the whole expression.

Example

Here’s a typical usage of a scope function:

Person("Alice", 20, "Amsterdam").let {
     println(it)
     it.moveTo("London")
     it.incrementAge()
     println(it)
 }

If we write the same without let, we’ll have to introduce a new variable and repeat its name whenever we use it.

val alice = Person("Alice", 20, "Amsterdam")
 println(alice)
 alice.moveTo("London")
 alice.incrementAge()
 println(alice)

The scope functions do not introduce any new technical capabilities, but they can make our code more concise and readable.

Due to the similar nature of scope functions, choosing the right one for our case can be a bit tricky. The choice mainly depends on our intent and the consistency of use in our project. 

Common Difference between Scope Functions

Because the scope functions are all quite similar in nature, it’s important to understand the differences between them. There are two main differences between each scope function:

  • The way to refer to the context object
  • The return value.

Context object – this or it

Inside the lambda of a scope function, the context object is available by a short reference instead of its actual name. Each scope function uses one of two ways to access the context object: as a lambda receiver (this) or as a lambda argument (it). Both provide the same capabilities, so we’ll describe the pros and cons of each for different cases and provide recommendations on their use.

fun main() {
     val str = "Hello"
     // this
     str.run {
         println("The receiver string length: $length")
         //println("The receiver string length: ${this.length}") // does the same
     }
     // it 
     str.let {     
        println("The receiver string's length is ${it.length}")           }
}

this

runwith, and apply refer to the context object as a lambda receiver – by keyword this. Hence, in their lambdas, the object is available as it would be in ordinary class functions. In most cases, we can omit this when accessing the members of the receiver object, making the code shorter. On the other hand, if this is omitted, it can be hard to distinguish between the receiver members and external objects or functions. So, having the context object as a receiver (this) is recommended for lambdas that mainly operate on the object members: call its functions or assign properties.

val adam = Person("Adam").apply { 
     age = 20                       // same as this.age = 20 or adam.age = 20
     city = "London"
 }
 println(adam)

it

In turn, let and also have the context object as a lambda argument. If the argument name is not specified, the object is accessed by the implicit default name itit is shorter than this and expressions with it are usually easier for reading. However, when calling the object functions or properties we don’t have the object available implicitly like this. Hence, having the context object as it is better when the object is mostly used as an argument in function calls. it is also better if we use multiple variables in the code block.

fun getRandomInt(): Int {
     return Random.nextInt(100).also {
         writeToLog("getRandomInt() generated value $it")
     }
 }
 val i = getRandomInt()

Additionally, when we pass the context object as an argument, we can provide a custom name for the context object inside the scope.

fun getRandomInt(): Int {
     return Random.nextInt(100).also { value ->
         writeToLog("getRandomInt() generated value $value")
     }
 }
 val i = getRandomInt()

Return value

The scope functions differ by the result they return:

  • apply and also return the context object.
  • letrun, and with return the lambda result.

These two options let we choose the proper function depending on what we do next in our code.

Context object

The return value of apply and also is the context object itself. Hence, they can be included into call chains as side steps: we can continue chaining function calls on the same object after them.

val numberList = mutableListOf()
 numberList.also { println("Populating the list") }
     .apply {
         add(2.71)
         add(3.14)
         add(1.0)
     }
     .also { println("Sorting the list") }
     .sort()

They also can be used in return statements of functions returning the context object.

fun getRandomInt(): Int {
     return Random.nextInt(100).also {
         writeToLog("getRandomInt() generated value $it")
     }
 }
 val i = getRandomInt()

Lambda result

letrun, and with return the lambda result. So, we can use them when assigning the result to a variable, chaining operations on the result, and so on.

val numbers = mutableListOf("one", "two", "three")
 val countEndsWithE = numbers.run { 
     add("four")
     add("five")
     count { it.endsWith("e") }
 }
 println("There are $countEndsWithE elements that end with e.")

Additionally, we can ignore the return value and use a scope function to create a temporary scope for variables.

val numbers = mutableListOf("one", "two", "three")
 with(numbers) {
     val firstItem = first()
     val lastItem = last()        
     println("First item: $firstItem, last item: $lastItem")
 }

We can analyze the common scope functions difference summary as below diagram:

Scoped Functions Summary

Five Scope Functions In Kotlin

To help we choose the right scope function for our case, we’ll describe them in detail and provide usage recommendations. Technically, functions are interchangeable in many cases, so the examples show the conventions that define the common usage style.

There are five scoped functions in Kotlin: letrunwithalso and apply. 

Let’s go through them one by one.

Scope Function – let

The context object is available as an argument (it). The return value is the lambda result.

let can be used to invoke one or more functions on results of call chains. For example, the following code prints the results of two operations on a collection:

val numbers = mutableListOf("one", "two", "three", "four", "five")
 val resultList = numbers.map { it.length }.filter { it > 3 }
 println(resultList)    

With let, we can rewrite it:

val numbers = mutableListOf("one", "two", "three", "four", "five")
 numbers.map { it.length }.filter { it > 3 }.let { 
     println(it)
     // and more function calls if needed
 } 

If the code block contains a single function with it as an argument, we can use the method reference (::) instead of the lambda:

val numbers = mutableListOf("one", "two", "three", "four", "five")
 numbers.map { it.length }.filter { it > 3 }.let(::println)

let is often used for executing a code block only with non-null values. To perform actions on a non-null object, use the safe call operator ?. on it and call let with the actions in its lambda.

val str: String? = "Hello"   
 //processNonNullString(str)       // compilation error: str can be null
 val length = str?.let { 
     println("let() called on $it")        
     processNonNullString(it)      // OK: 'it' is not null inside '?.let { }'
     it.length
 }

Another case for using let is introducing local variables with a limited scope for improving code readability. To define a new variable for the context object, provide its name as the lambda argument so that it can be used instead of the default it.

val numbers = listOf("one", "two", "three", "four")
 val modifiedFirstItem = numbers.first().let { firstItem ->
     println("The first item of the list is '$firstItem'")
     if (firstItem.length >= 5) firstItem else "!" + firstItem + "!"
 }.toUpperCase()
 println("First item after modifications: '$modifiedFirstItem'")

Scope Function – with

A non-extension function: the context object is passed as an argument, but inside the lambda, it’s available as a receiver (this). The return value is the lambda result.

We recommend with for calling functions on the context object without providing the lambda result. In the code, with can be read as “with this object, do the following.

val numbers = mutableListOf("one", "two", "three")
 with(numbers) {
     println("'with' is called with argument $this")
     println("It contains $size elements")
 }

Another use case for with is introducing a helper object whose properties or functions will be used for calculating a value.

val numbers = mutableListOf("one", "two", "three")
 val firstAndLast = with(numbers) {
     "The first element is ${first()}," +
     " the last element is ${last()}"
 }
 println(firstAndLast)

It is convenient when we have to call multiple different methods on the same object. Instead of repeating the variable containing this object on each line, we can use withThis function is used to change instance properties without the need to call dot operator over the reference every time.

Scope Function – run

The context object is available as a receiver (this). The return value is the lambda result.

run does the same as with but invokes as let – as an extension function of the context object.

run is useful when our lambda contains both the object initialization and the computation of the return value.

val service = MultiportService("https://example.kotlinlang.org", 80)
 val result = service.run {
     port = 8080
     query(prepareRequest() + " to port $port")
 }
 // the same code written with let() function:
 val letResult = service.let {
     it.port = 8080
     it.query(it.prepareRequest() + " to port ${it.port}")
 }

Besides calling run on a receiver object, we can use it as a non-extension function. Non-extension run lets us execute a block of several statements where an expression is required.

val hexNumberRegex = run {
     val digits = "0-9"
     val hexDigits = "A-Fa-f"
     val sign = "+-"
 Regex("[$sign]?[$digits$hexDigits]+")
 }
 for (match in hexNumberRegex.findAll("+1234 -FFFF not-a-number")) {
     println(match.value)
 }

run is actually a combination of with() and let().

Scope Function – apply

The context object is available as a receiver (this). The return value is the object itself.

Use apply for code blocks that don’t return a value and mainly operate on the members of the receiver object. The common case for apply is the object configuration. Such calls can be read as “apply the following assignments to the object.

val adam = Person("Adam").apply {
     age = 32
     city = "London"        
 }
 println(adam)

Having the receiver as the return value, we can easily include apply into call chains for more complex processing.

Scope Function – also

The context object is available as an argument (it). The return value is the object itself.

also is good for performing some actions that take the context object as an argument. Use also for actions that need a reference rather to the object than to its properties and functions, or when we don’t want to shadow this reference from an outer scope.

When we see also in the code, we can read it as “and also do the following with the object.

val numbers = mutableListOf("one", "two", "three")
 numbers
     .also { println("The list elements before adding new one: $it") }
     .add("four")

Scope Functions – run vs let

run is similar to let in terms of accepting any return value , but this is different in the context of the object terms. run function refers to the context of the object as “this” and not “it”. That is the reason we did not use “${this.name}” as it would be redundant here since the block of code understands that “name” is used here concerning the Person object.

Scope Functions – run redundant this

Another point here is that since the context is referred to as “this”, it cannot be renamed to a readable lambda parameter. So depending on the use case and requirement , we have to choose between the let and the run operator. The “run” operator also helps in easy null checks similar to the “let” operator.

var name: String? = "Abcd" 
private fun performRunOperation() {     
val name = Person().name?.run {         
"The name of the Person is: $this"     
}     
print(name) 
} 

Scope Functions – with vs run

Let’s consider a case where a Person object can be nullable.

Scope Functions With nullable Value

we can see that the context of the object referred to as “this” is a nullable type of Person. And hence, to correct this, we need to change the code as:

private fun performWithOperation() {     
val person: Person? = null     
with(person) {         
  this?.name = "asdf"         
  this?.contactNumber = "1234"         
  this?.address = "wasd"         
  this?.displayInfo()     
 } 
}

So performing a null check using a “with” operator is difficult and this is where we can replace it with “run” as follows:

private fun performRunOperation() {     
 val person: Person? = null     
 person?.run {         
   name = "asdf"         
   contactNumber = "1234"         
   address = "wasd"         
   displayInfo()     
 } 
}

This looks a lot cleaner.

Scope Functions – run vs apply

So let’s see the difference between run and apply functions.

Scope Functions – apply-vs-run

We can see that run accepts a return statement whereas apply does not accept a return statement(we can see the error thrown by the IDE in the image) and always returns the same object which it is referring to.

Scope Functions – let vs also

So let’s see the difference between let and also functions.

Scope Functions – let-vs-also

We can see that let accepts a return statement whereas “also” does not accept a return statement(we can see the error thrown by the IDE in the image) and always returns the same object which it is referring to.

Standard Library Scope Functions – takeIf and takeUnless

In addition to scope functions, the standard library contains the functions takeIf and takeUnless. These functions let us embed checks of the object state in call chains.

When we called on an object with a predicate provided, takeIf returns this object if it matches the predicate. Otherwise, it returns null. So, takeIf is a filtering function for a single object. In turn, takeUnless returns the object if it doesn’t match the predicate and null if it does. The object is available as a lambda argument (it).

val number = Random.nextInt(100)
val evenOrNull = number.takeIf { it % 2 == 0 }
val oddOrNull = number.takeUnless { it % 2 == 0 }
println("even: $evenOrNull, odd: $oddOrNull")

When we do chaining other functions after takeIf and takeUnless, we don’t forget to perform the null check or the safe call (?.) because their return value is nullable.

val str = "Hello"
 val caps = str.takeIf { it.isNotEmpty() }?.toUpperCase()
 //val caps = str.takeIf { it.isNotEmpty() }.toUpperCase() //compilation error
 println(caps)

takeIf and takeUnless are especially useful together with scope functions. A good case is chaining them with let for running a code block on objects that match the given predicate. To do this, call takeIf on the object and then call let with a safe call (?). For objects that don’t match the predicate, takeIf returns null and let isn’t invoked.

fun displaySubstringPosition(input: String, sub: String) {
     input.indexOf(sub).takeIf { it >= 0 }?.let {
         println("The substring $sub is found in $input.")
         println("Its start position is $it.")
     }
 }
 displaySubstringPosition("010000011", "11")
 displaySubstringPosition("010000011", "12")

This is how the same function looks without the standard library functions:

fun displaySubstringPosition(input: String, sub: String) {
     val index = input.indexOf(sub)
     if (index >= 0) {
         println("The substring $sub is found in $input.")
         println("Its start position is $index.")
     }
 }
 displaySubstringPosition("010000011", "11")
 displaySubstringPosition("010000011", "12")

The Selection Of Scope Functions

To help we choose the right scope function for our purpose, we provide the table of key differences between them.

FunctionObject referenceReturn valueIs extension function
letitLambda resultYes
runthisLambda resultYes
runLambda resultNo: called without the context object
withthisLambda resultNo: takes the context object as an argument.
applythisContext objectYes
alsoitContext objectYes
Key differences between Scope Function

Here is a short guidelines for choosing scope functions depending on the intended purpose:

  • Executing a lambda on non-null objects: let
  • Introducing an expression as a variable in local scope: let
  • Object configuration: apply
  • Object configuration and computing the result: run
  • Running statements where an expression is required: non-extension run
  • Additional effects: also
  • Grouping function calls on an object: with

The use cases of different scope functions overlap, so that we can choose the functions based on the specific conventions used in our project or team.

That’s all about in this article.

Related Other Articles / Posts

Conclusion

In this article, we understood about how to select Scope Functions in Kotlin. Although the scope functions are a way of making the code more concise, avoid overusing them: it can decrease our code readability and lead to errors. Avoid nesting scope functions and be careful when chaining them: it’s easy to get confused about the current context object and the value of this or it. This article showed the detailed descriptions of the differences between scope functions and the conventions on their usage in Kotlin with some authentic examples.

Thanks for reading! I hope you enjoyed and learned about Scope Functions concepts in Kotlin. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find other articles of CoolMonkTechie as below link :

You can also follow official website and tutorials of Android as below links :

If you have any comments, questions, or think I missed something, leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???

Android – How To Apply Manual Dependency Injection In A Real Android Application ?

Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Apply Manual Dependency Injection In A Real Android Application ?).

In this article, we will learn about how to apply manual dependency injection in a real android application. Dependency Injection is a good technique for creating scalable and testable Android applications. When our application gets larger, we will start seeing that we write a lot of boilerplate code (such as factories), which can be error-prone. We also have to manage the scope and lifecycle of the containers ourself, optimizing and discarding containers that are no longer needed in order to free up memory. Doing this incorrectly can lead to subtle bugs and memory leaks in our app. This article reviews an iterated approach of how we might start using manual dependency injection in our application.

A famous quote about learning is :

” Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young. The greatest thing in life is to keep your mind young. “

So Let’s begin.

Manual Dependency Injection

Android’s recommended app architecture encourages dividing our code into classes to benefit from separation of concerns, a principle where each class of the hierarchy has a single defined responsibility. This leads to more, smaller classes that need to be connected together to fulfill each other’s dependencies.

Source : Android Developers – A Model Of An Android App’s Application Graph

The dependencies between classes can be represented as a graph, in which each class is connected to the classes it depends on. The representation of all our classes and their dependencies makes up the application graph. In figure 1, we can see an abstraction of the application graph. When class A (ViewModel) depends on class B (Repository), there’s a line that points from A to B representing that dependency.

Dependency injection helps make these connections and enables us to swap out implementations for testing. For example, when testing a ViewModel that depends on a repository, we can pass different implementations of Repository with either fakes or mocks to test the different cases.

The approach improves until it reaches a point that is very similar to what Dagger would automatically generate for us.

Example – Login Flow For A Typical Android Application

Consider a flow to be a group of screens in our app that correspond to a feature. Login, registration, and checkout are all examples of flows.

When covering a login flow for a typical Android application, the LoginActivity depends on LoginViewModel, which in turn depends on UserRepository. Then UserRepository depends on a UserLocalDataSource and a UserRemoteDataSource, which in turn depends on a Retrofit service.

Source : Android Developers –  A Login Flow For A Typical Android Application

LoginActivity is the entry point to the login flow and the user interacts with the activity. Thus, LoginActivity needs to create the LoginViewModel with all its dependencies.

The Repository and DataSource classes of the flow look like this:

class UserRepository(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) { ... }

class UserLocalDataSource { ... }
class UserRemoteDataSource(
    private val loginService: LoginRetrofitService
) { ... }

Here’s what LoginActivity looks like:

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // In order to satisfy the dependencies of LoginViewModel, you have to also
        // satisfy the dependencies of all of its dependencies recursively.
        // First, create retrofit which is the dependency of UserRemoteDataSource
        val retrofit = Retrofit.Builder()
            .baseUrl("https://example.com")
            .build()
            .create(LoginService::class.java)

        // Then, satisfy the dependencies of UserRepository
        val remoteDataSource = UserRemoteDataSource(retrofit)
        val localDataSource = UserLocalDataSource()

        // Now you can create an instance of UserRepository //that LoginViewModel needs
        val userRepository = UserRepository(localDataSource, remoteDataSource)

        // Lastly, create an instance of LoginViewModel with //userRepository
        loginViewModel = LoginViewModel(userRepository)
    }
}

There are issues with this approach:

  • There’s a lot of boilerplate code. If we wanted to create another instance of LoginViewModel in another part of the code, we’d have code duplication.
  • Dependencies have to be declared in order. We have to instantiate UserRepository before LoginViewModel in order to create it.
  • It’s difficult to reuse objects. If we wanted to reuse UserRepository across multiple features, we’d have to make it follow the singleton pattern. The singleton pattern makes testing more difficult because all tests share the same singleton instance.

Example Solutions

Managing Dependencies With A Container

To solve the issue of reusing objects, we can create our own dependencies container class that we use to get dependencies. All instances provided by this container can be public. In the example, because we only need an instance of UserRepository, we can make its dependencies private with the option of making them public in the future if they need to be provided:

// Container of objects shared across the whole app
class AppContainer {

    // Since you want to expose userRepository out of the container, you need to satisfy
    // its dependencies as you did before
    private val retrofit = Retrofit.Builder()
                            .baseUrl("https://example.com")
                            .build()
                            .create(LoginService::class.java)

    private val remoteDataSource = UserRemoteDataSource(retrofit)
    private val localDataSource = UserLocalDataSource()

    // userRepository is not private; it'll be exposed
    val userRepository = UserRepository(localDataSource, remoteDataSource)
}

Because these dependencies are used across the whole application, they need to be placed in a common place all activities can use: the application class. Create a custom application class that contains an AppContainer instance.

// Custom Application class that needs to be specified
// in the AndroidManifest.xml file
class MyApplication : Application() {

    // Instance of AppContainer that will be used by all the Activities of the app
    val appContainer = AppContainer()
}

We aware that AppContainer is just a regular class with a unique instance shared across the app placed in our application class. However, AppContainer is not following the singleton pattern; in Kotlin, it’s not an object, and in Java, it’s not accessed with the typical Singleton.getInstance() method.

Now we can get the instance of the AppContainer from the application and obtain the shared of UserRepository instance:

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Gets userRepository from the instance of AppContainer in Application
        val appContainer = (application as MyApplication).appContainer
        loginViewModel = LoginViewModel(appContainer.userRepository)
    }
}

In this way, we don’t have a singleton UserRepository. Instead, we have an AppContainer shared across all activities that contains objects from the graph and creates instances of those objects that other classes can consume.

If LoginViewModel is needed in more places in the application, having a centralized place where we create instances of LoginViewModel makes sense. We can move the creation of LoginViewModel to the container and provide new objects of that type with a factory. The code for a LoginViewModelFactory looks like this:

// Definition of a Factory interface with a function to create objects of a type
interface Factory<T> {
    fun create(): T
}

// Factory for LoginViewModel.
// Since LoginViewModel depends on UserRepository, in order to create instances of
// LoginViewModel, you need an instance of UserRepository that you pass as a parameter.
class LoginViewModelFactory(private val userRepository: UserRepository) : Factory {
    override fun create(): LoginViewModel {
        return LoginViewModel(userRepository)
    }
}

We can include the LoginViewModelFactory in the AppContainer and make the LoginActivity consume it:

// AppContainer can now provide instances of LoginViewModel with LoginViewModelFactory
class AppContainer {
    ...
    val userRepository = UserRepository(localDataSource, remoteDataSource)

    val loginViewModelFactory = LoginViewModelFactory(userRepository)
}

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Gets LoginViewModelFactory from the application instance of AppContainer
        // to create a new LoginViewModel instance
        val appContainer = (application as MyApplication).appContainer
        loginViewModel = appContainer.loginViewModelFactory.create()
    }
}

This approach is better than the previous one, but there are still some challenges to consider:

  • We have to manage AppContainer ourself, creating instances for all dependencies by hand.
  • There is still a lot of boilerplate code. We need to create factories or parameters by hand depending on whether we want to reuse an object or not.

Managing Dependencies In Application Flows

AppContainer gets complicated when we want to include more functionality in the project. When our app becomes larger and we start introducing different feature flows, there are even more problems that arise:

  • When we have different flows, we might want objects to just live in the scope of that flow. For example, when creating LoginUserData (that might consist of the username and password used only in the login flow) we don’t want to persist data from an old login flow from a different user. We want a new instance for every new flow. We can achieve that by creating FlowContainer objects inside the AppContainer as demonstrated in the next code example.
  • Optimizing the application graph and flow containers can also be difficult. We need to remember to delete instances that we don’t need, depending on the flow we’re in.

Imagine we have a login flow that consists of one activity (LoginActivity) and multiple fragments (LoginUsernameFragment and LoginPasswordFragment). These views want to:

  • Access the same LoginUserData instance that needs to be shared until the login flow finishes.
  • Create a new instance of LoginUserData when the flow starts again.

We can achieve that with a login flow container. This container needs to be created when the login flow starts and removed from memory when the flow ends.

Let’s add a LoginContainer to the example code. We want to be able to create multiple instances of LoginContainer in the app, so instead of making it a singleton, make it a class with the dependencies the login flow needs from the AppContainer.

class LoginContainer(val userRepository: UserRepository) {

    val loginData = LoginUserData()

    val loginViewModelFactory = LoginViewModelFactory(userRepository)
}

// AppContainer contains LoginContainer now
class AppContainer {
    ...
    val userRepository = UserRepository(localDataSource, remoteDataSource)

    // LoginContainer will be null when the user is NOT in the login flow
    var loginContainer: LoginContainer? = null
}

Once we have a container specific to a flow, we have to decide when to create and delete the container instance. Because our login flow is self-contained in an activity (LoginActivity), the activity is the one managing the lifecycle of that container. LoginActivity can create the instance in onCreate() and delete it in onDestroy().

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel
    private lateinit var loginData: LoginUserData
    private lateinit var appContainer: AppContainer


    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        appContainer = (application as MyApplication).appContainer

        // Login flow has started. Populate loginContainer in AppContainer
        appContainer.loginContainer = LoginContainer(appContainer.userRepository)

        loginViewModel = appContainer.loginContainer.loginViewModelFactory.create()
        loginData = appContainer.loginContainer.loginData
    }

    override fun onDestroy() {
        // Login flow is finishing
        // Removing the instance of loginContainer in the AppContainer
        appContainer.loginContainer = null
        super.onDestroy()
    }
}

Like LoginActivity, login fragments can access the LoginContainer from AppContainer and use the shared LoginUserData instance.

Because in this case we’re dealing with view lifecycle logic, using lifecycle observation makes sense.

That’s all about in this article.

Related Other Articles / Posts

Conclusion

In this article, we understood about how to apply manual dependency injection in a real android application. Dependency injection is a good technique for creating scalable and testable Android applications. Use containers as a way to share instances of classes in different parts of our application and as a centralized place to create instances of classes using factories. This article reviewed an iterated approach of how we might start using manual dependency injection in our android application.

Thanks for reading! I hope you enjoyed and learned about Manual Dependency Injection (DI) concepts in Android. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find other articles of CoolMonkTechie as below link :

You can also follow official website and tutorials of Android as below links :

If you have any comments, questions, or think I missed something, leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???

Android – An Overview Of Dependency Injection In Android

Hello Readers, CoolMonkTechie heartily welcomes you in this article (An Overview Of Dependency Injection In Android).

In this article, we will learn about Dependency Injection in android. Dependency Injection (DI) is a technique widely used in programming and well suited to Android development. By following the principles of DI, we lay the groundwork for good app architecture. This article explains an overview of how Dependency Injection (DI) works in Android.

A famous quote about learning is :

” Wisdom is not a product of schooling but of the lifelong attempt to acquire it.”

So let’s begin.

An Overview Of Dependency Injection

Dependency injection is based on the Inversion of Control principle in which generic code controls the execution of specific code.

Classes often require references to other classes. For example, a Car class might need a reference to an Engine class. These required classes are called dependencies, and in this example the Car class is dependent on having an instance of the Engine class to run.

There are three ways for a class to get an object it needs:

  1. The class constructs the dependency it needs. In the example above, Car would create and initialize its own instance of Engine.
  2. Grab it from somewhere else. Some Android APIs, such as Context getters and getSystemService(), work this way.
  3. Have it supplied as a parameter. The app can provide these dependencies when the class is constructed or pass them in to the functions that need each dependency. In the example above, the Car constructor would receive Engine as a parameter.

With this Dependency Injection (DI) approach, we take the dependencies of a class and provide them rather than having the class instance obtain them itself.

Example Without Dependency Injection

This example is representing a Car that creates its own Engine dependency in code looks like this:

class Car {

    private val engine = Engine()

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.start()
}

This is not an example of dependency injection because the Car class is constructing its own Engine.

Source : Android Developers – Example Car Engine Without DI

This can be problematic because:

  • Car and Engine are tightly coupled – an instance of Car uses one type of Engine, and no subclasses or alternative implementations can easily be used. If the Car were to construct its own Engine, we would have to create two types of Car instead of just reusing the same Car for engines of type Gas and Electric.
  • The hard dependency on Engine makes testing more difficult. Car uses a real instance of Engine, thus preventing us from using a test double to modify Engine for different test cases.

Example With Dependency Injection

With this example, instead of each instance of Car constructing its own Engine object on initialization, it receives an Engine object as a parameter in its constructor. The code looks like this.

class Car(private val engine: Engine) {
    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val engine = Engine()
    val car = Car(engine)
    car.start()
}

The main function uses Car. Because Car depends on Engine, the application creates an instance of Engine and then uses it to construct an instance of Car.

Source : Android Developers – Example Car Engine With DI

The benefits of this DI-based approach are:

  • Reusability of Car: We can pass in different implementations of Engine to Car. For example, we might define a new subclass of Engine called ElectricEngine that we want Car to use. If we use DI, all we need to do is pass in an instance of the updated ElectricEngine subclass, and Car still works without any further changes.
  • Easy testing of Car: We can pass in test doubles to test our different scenarios. For example, we might create a test double of Engine called FakeEngine and configure it for different tests.

Major Ways to do Dependency Injection

There are two major ways to do dependency injection in Android:

  • Constructor Injection. This is the way described above. We pass the dependencies of a class to its constructor.
  • Field Injection (or Setter Injection). Certain Android framework classes such as activities and fragments are instantiated by the system, so constructor injection is not possible. With field injection, dependencies are instantiated after the class is created. The code would look like this:
class Car {
    lateinit var engine: Engine

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.engine = Engine()
    car.start()
}

Automated Dependency Injection

In the previous example, we created, provided, and managed the dependencies of the different classes ourself, without relying on a library. This is called dependency injection by hand, or manual dependency injection. In the Car example, there was only one dependency, but more dependencies and classes can make manual injection of dependencies more tedious. Manual dependency injection also presents several problems:

  • For big apps, taking all the dependencies and connecting them correctly can require a large amount of boilerplate code. In a multi-layered architecture, in order to create an object for a top layer, we have to provide all the dependencies of the layers below it. As a concrete example, to build a real car we might need an engine, a transmission, a chassis, and other parts; and an engine in turn needs cylinders and spark plugs.
  • When we’re not able to construct dependencies before passing them in — for example when using lazy initializations or scoping objects to flows of our app — we need to write and maintain a custom container (or graph of dependencies) that manages the lifetimes of our dependencies in memory.

Dependency Injection Libraries

There are libraries that solve this problem by automating the process of creating and providing dependencies. They fit into two categories:

  • Reflection-based solutions that connect dependencies at runtime.
  • Static solutions that generate the code to connect dependencies at compile time.

Dagger is a popular dependency injection library for Java, Kotlin, and Android that is maintained by Google. It facilitates using DI in our app by creating and managing the graph of dependencies for us. It provides fully static and compile-time dependencies addressing many of the development and performance issues of reflection-based solutions such as Guice.

Alternatives To Dependency Injection

An alternative to dependency injection is using a service locator. The service locator design pattern also improves decoupling of classes from concrete dependencies. We create a class known as the service locator that creates and stores dependencies and then provides those dependencies on demand.

object ServiceLocator {
    fun getEngine(): Engine = Engine()
}

class Car {
    private val engine = ServiceLocator.getEngine()

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.start()
}

Dependency Injection Vs Service Locator Pattern

The service locator pattern is different from dependency injection in the way the elements are consumed. With the service locator pattern, classes have control and ask for objects to be injected; with dependency injection, the app has control and proactively injects the required objects.

The Comparisons between dependency injection and Service Locator Pattern are:

  • The collection of dependencies required by a service locator makes code harder to test because all the tests have to interact with the same global service locator.
  • Dependencies are encoded in the class implementation, not in the API surface. As a result, it’s harder to know what a class needs from the outside. As a result, changes to Car or the dependencies available in the service locator might result in runtime or test failures by causing references to fail.
  • Managing lifetimes of objects is more difficult if we want to scope to anything other than the lifetime of the entire app.

Use Hilt in Android Application

Hilt is Jetpack’s recommended library for dependency injection in Android. It defines a standard way to do DI in our application by providing containers for every Android class in our project and managing their lifecycles automatically for us.

Hilt is built on top of the popular DI library Dagger to benefit from the compile time correctness, runtime performance, scalability, and Android Studio support that Dagger provides.

Benefits Of Dependency Injection

Dependency injection provides our app with the following advantages:

  • Reusability of classes and decoupling of dependencies: It’s easier to swap out implementations of a dependency. Code reuse is improved because of inversion of control, and classes no longer control how their dependencies are created, but instead work with any configuration.
  • Ease of refactoring: The dependencies become a verifiable part of the API surface, so they can be checked at object-creation time or at compile time rather than being hidden as implementation details.
  • Ease of testing: A class doesn’t manage its dependencies, so when you’re testing it, you can pass in different implementations to test all of your different cases.

That’s all about in this article.

Related Other Articles / Posts

Conclusion

In this article, we understood about Dependency Injection fundamental in android. This article reviewed an overview of how Dependency Injection (DI) works in Android.

Thanks for reading! I hope you enjoyed and learned about DI concepts in Android. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find other articles of CoolMonkTechie as below link :

You can also follow official website and tutorials of Android as below links :

If you have any comments, questions, or think I missed something, leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???

Android – How To Manage Core App Quality In Android ?

Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Manage Core App Quality In Android ?).

In this article, we will learn about how to manage Core App Quality in Android application. Android users expect high-quality apps. App quality directly influences the long-term success of our app – in terms of installs, user rating and reviews, engagement, and user retention. This article reviews about the core aspects of quality (Core App Quality Guidelines) in our android application, through a compact set of quality criteria and associated tests. All Android apps should meet these criteria.

A famous quote about learning is :

“One learns from books and example only that certain things can be done. Actual learning requires that you do those things.”

So let’s begin.

Overview

Android users expect high-quality apps that should meet the core aspects of quality, through a compact set of quality criteria and associated tests criteria which provides in Core App Quality Guidelines.

Before publishing our apps, we need to test them against these criteria to ensure that application function works well on many devices and meets Android standards for navigation and design, and are prepared for promotional opportunities in the Google Play store.

Core App Quality Guidelines

Handle Visual Design and User Interaction

These criteria ensure that our application provides standard Android visual design and interaction patterns from core app quality guidelines where appropriate, for a consistent and intuitive user experience.

Standard Design

The application follows Android Design guidelines and uses common UI patterns and icons:

  • This does not redefine the expected function of a system icon (such as the Back button).
  • The application does not replace a system icon with a completely different icon if it triggers the standard UI behavior.
  • If the application provides a customized version of a standard system icon, the icon strongly resembles the system icon and triggers the standard system behavior.
  • The application does not redefine or misuse Android UI patterns, such that icons or behaviors could be misleading or confusing to users.

Navigation

  • The application supports standard system Back button navigation and does not make use of any custom, on-screen “Back button” prompts.
  • All dialogs are dismissible using the Back button.
  • Pressing the Home button at any point navigates to the Home screen of the device.

Notifications

  • Notifications follow Android Design guidelines. In particular:
    • Multiple notifications are stacked into a single notification object, where possible.
    • Notifications are persistent only if related to ongoing events (such as music playback or a phone call).
    • Notifications do not contain advertising or content unrelated to the core function of the app, unless the user has opted in.
  • The application uses notifications only to:
    • Indicate a change in context relating to the user personally (such as an incoming message), or
    • Expose information/controls relating to an ongoing event (such as music playback or a phone call).

Manage Functionality

These criteria ensure that our application provides the expected functional behavior, with the appropriate level of permissions.

Permissions

  • The application requests only the absolute minimum permissions that it needs to support core functionality.
  • The application does not request permissions to access sensitive data (such as Contacts or the System Log) or services that can cost the user money (such as the Dialer or SMS), unless related to a core capability of the application.

Install Location

The application functions normally when installed on SD card (if supported by application). Supporting installation to SD card is recommended for most large apps (10MB+).

Audio

  • Audio does not play when the screen is off, unless this is a core feature (for example, the app is a music player).
  • It does not play behind the lock screen, unless this is a core feature.
  • Audio does not play on the home screen or over another application, unless this is a core feature.
  • Audio resumes when the application returns to the foreground, or indicates to the user that playback is in a paused state.

UI and Graphics

  • The application supports both landscape and portrait orientations (if possible). Orientations expose largely the same features and actions and preserve functional parity. Minor changes in content or views are acceptable.
  • The application uses the whole screen in both orientations and does not letterbox to account for orientation changes. Minor letterboxing to compensate for small variations in screen geometry is acceptable.
  • The application correctly handles rapid transitions between display orientations without rendering problems.

User/App State

  • The application should not leave any services running when the app is in the background, unless related to a core capability of the application. For example, the application should not leave services running to maintain a network connection for notifications, to maintain a Bluetooth connection, or to keep the GPS powered-on.
  • The application correctly preserves and restores user or application state. The application preserves user or application state when leaving the foreground and prevents accidental data loss due to back-navigation and other state changes. This must restore the preserved state and any significant stateful transaction that was pending, such as changes to editable fields, game progress, menus, videos, and other sections of the application or game, when returning to the foreground.
    • The application returns the user to the exact state in which it was last used, when the application is resumed from the Recents application switcher.
    • When this is resumed after the device wakes from sleep (locked) state, the application returns the user to the exact state in which it was last used.
    • When the application is relaunched from Home or All Applications, the application restores the application state as closely as possible to the previous state.
    • On Back keypresses, the application gives the user the option of saving any application or user state that would otherwise be lost on back-navigation.

Manage Compatibility, Performance and Stability

These criteria ensure that applications provide the compatibility, performance, stability, and responsiveness expected by users.

Stability

The application does not crash, force close, freeze, or otherwise function abnormally on any targeted device.

Performance

  • The application loads quickly or provides onscreen feedback to the user (a progress indicator or similar cue) if the application takes longer than two seconds to load.
  • With StrictMode enabled, no red flashes (performance warnings from StrictMode) are visible when exercising the application, including during game play, animations and UI transitions, and any other part of the application.

Software Development Kit (SDK)

  • The application runs on the latest public version of the Android platform without crashing or loss of core function.
  • This targets the latest SDK by setting the targetSdk value to minimize the use of any platform-provided compatibility fallbacks.
  • The application is built with the latest SDK by setting the compileSdk value.

Battery

The Android application supports power management features in Android 6.0+ (Doze and App Standby) properly. In the case where core functionality is disrupted by power management, only qualified apps may request an exemption.

Media

Music and video playback is smooth, without crackle, stutter, or other artifacts, during normal app use and load.

Visual Quality

  • The application displays graphics, text, images, and other UI elements without noticeable distortion, blurring, or pixelation.
    • The application provides high-quality graphics for all targeted screen sizes and form factors.
    • No aliasing at the edges of menus, buttons, and other UI elements is visible.
  • The application displays text and text blocks in an acceptable manner.
    • Composition is acceptable in all supported form factors.
    • No cut-off letters or words are visible.
    • No improper word wraps within buttons or icons are visible.
    • Sufficient spacing between text and surrounding elements.

Handle Application Security

These criteria ensure that apps handle user data and personal information safely. In addition to this checklist, applications published on the Google Play Store must also follow the User Data policies to protect users’ privacy.

Data

  • All private data is stored in the application’s internal storage.
  • External storage data is verified before being accessed.
  • All intents and broadcasts follow secure best practices:
    • Intents are explicit if the destination application is known.
    • These intents enforce and use appropriate permissions.
    • Intents that contain data and payload are verified before use.
  • No personal or sensitive user data is logged to the system or app-specific log.

App Components

  • Only application components that share data with other applications, or components that should be invoked by other applications, are exported. This includes activities, services, broadcast receivers, and especially content providers. Always set the android:exported attribute explicitly, regardless of whether or not we export any of your application’s components.
  • All application components that share content with other applications define (and enforce) appropriate permissions. This includes activities, services, broadcast receivers, and especially content providers.
  • All content providers that share content between our applications use android:protectionLevel="signature".

Networking

  • All network traffic is sent over SSL.
  • Application declares a network security configuration.
  • If the application uses Google Play services, the security provider is initialized at application startup.

Libraries

All libraries, SDKs, and dependencies are up to date.

WebViews

  • JavaScript is disabled in all WebViews (unless required).
  • WebViews only load allow listed content if possible.
  • WebViews do not use addJavaScriptInterface() with untrusted content. On Android M and above, HTML message channels can be used instead.

Execution

The app does not dynamically load code from outside the app’s APK.

Cryptography

  • The application uses strong, platform-provided cryptographic algorithms and does not implement custom algorithms.
  • The application uses a properly secure random number generator, in particular to initialize cryptographic keys.

Google Play

These criteria ensure that our applications are ready to publish on Google Play.

Policies

  • The application strictly adheres to the terms of the Google Play Developer Content Policy and does not offer inappropriate content, does not use the intellectual property or brand of others, and so on.
  • The maturity level of the application is set appropriately, based on the Content Rating Guidelines.
  • The application supports power management features in Android 6.0+ (Doze and App Standby) properly. In the case where core functionality is disrupted by power management, only qualified applications may request an exemption.

App Details Page

  • The application’s feature graphic follows the guidelines outlined. Make sure that:
    • The application listing includes a high-quality feature graphic.
    • The feature graphic does not contain device images, screenshots, or small text that will be illegible when scaled down and displayed on the smallest screen size that our application is targeting.
    • The feature graphic does not resemble an advertisement.
  • The application’s screenshots and videos do not show or reference non-Android devices.
  • The application’s screenshots or videos do not represent the content and experience of our application in a misleading way.

User Support

Common user-reported bugs in the Reviews tab of the Google Play page are addressed if they are reproducible and occur on many different devices. If a bug occurs on only a few devices, we should still address it if those devices are particularly popular or new.

Setting Up A Test Environment

To assess the quality of our application, we need to set up a suitable hardware or emulator environment for testing. The ideal test environment would include a small number of actual hardware devices that represent key form factors and hardware/software combinations currently available to consumers. It’s not necessary to test on every device that’s on the market — rather, we should focus on a small number of representative devices, even using one or two devices per form factor.

If we are not able to obtain actual hardware devices for testing, we should set up emulated devices (AVDs) to represent the most common form factors and hardware/software combinations.

To go beyond basic testing, we can add more devices, more form factors, or new hardware/software combinations to our test environment. We can also increase the number or complexity of tests and quality criteria.

Test Procedures

These test procedures help us discover various types of quality issues in our app. We can combine the tests or integrate groups of tests together in our own test plans.

Core Suite

  • Navigate to all parts of the application — all screens, dialogs, settings, and all user flows.
    • If the application allows for editing or content creation, game play, or media playback, make sure to enter those flows to create or modify content.
    • While exercising the application, we introduce transient changes in network connectivity, battery function, GPS availability, system load, and so on.
  • From each application screen, we press the device’s Home key, then re-launch the application from the All Applications screen.
  • We switch to another running application and then return to the application under test using the Recents application switcher from each application screen.
  • From each application screen (and dialogs), we press the Back button.
  • From each application screen, we rotate the device between landscape and portrait orientation at least three times.
  • Switch to another application to send the test application into the background. Go to Settings and check whether the test application has any services running while in the background. In Android 4.0 and higher, we go to the Applications screen and find the application in the “Running” tab.
  • We press the power button to put the device to sleep, then press the power button again to wake the screen.
  • We set the device to lock when the power button is pressed. Press the power button to put the device to sleep, then press the power button again to wake the screen, then unlock the device.
  • For devices that have slide-out keyboards, we slide the keyboard in and out at least once. For devices that have keyboard docks, we attach the device to the keyboard dock.
  • We plug-in the external display for those devices that have an external display port.
  • Trigger and observe in the notifications drawer all types of notifications that the application can display. Expand notifications where applicable (Android 4.1 and higher), and tap all actions offered.

Install On SD Card

Repeat Core Suite with the application installed to a device’s SD card (if supported by application). To move the application to SD card, we can use Settings > App Info > Move to SD Card.

Hardware Acceleration

Repeat Core Suite with hardware acceleration enabled. To force-enable hardware acceleration (where supported by device), add hardware-accelerated="true"to the <application> in the application manifest and recompile.

Performance and Stability

Review the Android manifest file and build configuration to ensure that the application is built against the latest available SDK (targetSdk and compileSdk).

Performance Monitoring

Repeat Core Suite with StrictMode profiling enabled. Pay close attention to garbage collection and its impact on the user experience.

Battery

Repeat Core Suite across Doze and App Standby cycles. Pay close attention to alarms, timers, notifications, syncs, and so on.

Security

  • Review all data stored in external storage.
  • We review how data loaded from external storage is handled and processed.
  • Review all content providers defined in the Android manifest file for appropriate protectionLevel.
  • All permissions review that our application requires, in the manifest file, at runtime and in the application settings (Settings > App Info) on the device.
  • Review all application components defined in the Android manifest file for the appropriate export state. The export property must be set explicitly for all components.
  • Review the application’s Network Security configuration, ensuring that no lint checks on the configuration fail.
  • For each WebView, navigate to a page that requires JavaScript.
  • For each WebView, attempt to navigate to sites and content that are outside of our control.
  • Declare a Network Security Configuration that disables cleartext traffic then execute the application.
  • Run the application and exercise all core functionality, while observing the device log. No private user information should be logged.

Google Play

  • Sign into the Google Play Developer Console to review developer profile, app description, screenshots, feature graphic, content rating and user feedback.
  • Download feature graphic and screenshots and scale them down to match the display sizes on the devices and form factors we are targeting.
  • Review all graphical assets, media, text, code libraries, and other content packaged in the application or expansion file download.
  • Review Support for other use cases in Doze and App Standby.

Payments

Navigate to all screens of our app and enter all in-app purchase flows.

Testing with StrictMode

For performance testing, we recommend enabling StrictMode in our app and using it to catch operations on the main thread and other threads that could affect performance, network accesses, file reads/writes, and so on.

We can set up a monitoring policy per thread using StrictMode.ThreadPolicy.Builder and enable all supported monitoring in the ThreadPolicy using detectAll().

Make sure to enable visual notification of policy violations for the ThreadPolicy using penaltyFlashScreen().

That’s all about in this article.

Conclusion

In this article, we understood about how to manage Core App Quality in Android application. This article reviewed about the core aspects of quality (Core App Quality) in our android application, through a compact set of quality criteria and associated tests.

Thanks for reading! I hope you enjoyed and learned about Core App Quality Guidelines concepts in Android. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find Other articles of CoolMonkTechie as below link :

You can also follow official website and tutorials of Android as below links :

If you have any comments, questions, or think I missed something, leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???

Android – An Overview Of Property Animation In Android

Hello Readers, CoolMonkTechie heartily welcomes you in this article (An Overview Of Property Animation In Android).

In this article, we will learn about Property Animation Overview in Android. The property animation system is a robust framework that allows us to animate almost anything. We can define an animation to change any object property over time, regardless of whether it draws to the screen. A property animation changes a property’s (a field in an object) value over a specified length of time. To animate something, we specify the object property that we want to animate, such as an object’s position on the screen, how long we want to animate it for, and what values we want to animate between. This article shows the Property Animation related concepts in Android.

A famous quote about learning is :

” Develop a passion for learning. If you do, you will never cease to grow. “

So let’s begin.

Characteristics Of Property Animation

The property animation system lets us define the following characteristics of an animation:

  • Duration: We can specify the duration of an animation. The default length is 300 ms.
  • Time interpolation: This specify how the values for the property calculate as a function of the animation’s current elapsed time.
  • Repeat count and behavior: This specify whether to have an animation repeat when it reaches the end of a duration and how many times to repeat the animation. We can also specify whether we want the animation to play back in reverse. Setting it to reverse plays the animation forwards then, backwards repeatedly, until it reaches the number of repeats.
  • Animator sets: We can group animations into logical sets that play together or sequentially or after specified delays.
  • Frame refresh delay: This specify how often to refresh frames of our animation. The default is set to refresh every 10 ms, but the speed in which our application can refresh frames is ultimately dependent on how busy the system is overall and how fast the system can service the underlying timer.

The Work Flow of Property Animation

Linear Animation

First, we see how an animation works with a simple example.

Source: Android Developer – The Example Of Linear Animation

In this above linear animation figure, it depicts a hypothetical object animates with its x property, which represents its horizontal location on a screen. It sets the duration of the animation to 40 ms and the distance to travel is 40 pixels. Every 10 ms, which is the default frame refresh rate, the object moves horizontally by 10 pixels. At the end of 40ms, the animation stops, and the object ends at horizontal position 40. This is an example of an animation with linear interpolation, meaning the object moves at a constant speed.

Non-Linear Animation

We can also specify animations to have a non-linear interpolation.

Source: Android Developer – The Example of a non-linear animation

In this above non-linear animation figure, it illustrates a hypothetical object that speeds up at the beginning of the animation and decelerates at the end of the animation. The object still moves 40 pixels in 40 ms, but non-linearly. In the beginning, this animation accelerates up to the halfway point, then decelerates from the halfway point until the end of the animation. As this non-linear animation figure shows the distance traveled at the beginning and end of the animation is less than in the middle.

Animations Calculation Using Property Animation

We understood how the important components of the property animation system would calculate animations like the ones. Now we will discuss how the main classes work with one another.

Source: Android Developer – How animations are calculated

In this figure, The ValueAnimator object keeps track of our animation’s timing, such as how long the animation has been running, and the current value of the property that it is animating.

The ValueAnimator encapsulates

  • TimeInterpolator, which defines animation interpolation, and
  • TypeEvaluator, which defines how to calculate values for the property being animated.

For example, in non-linear animation figure, the TimeInterpolator used would be AccelerateDecelerateInterpolator and the TypeEvaluator would be IntEvaluator.

To start an animation, we create a ValueAnimator and give it the starting and ending values for the property that we want to animate, along with the duration of the animation. When we call start(), the animation begins. During the whole animation, the ValueAnimator calculates an elapsed fraction between 0 and 1, based on the duration of the animation and how much time has elapsed. The elapsed fraction represents the percentage of time that the animation has completed, 0 meaning 0% and 1 meaning 100%. For example, in linear animation figure , the elapsed fraction at t = 10 ms would be .25 because the total duration is t = 40 ms.

When the ValueAnimator calculates an elapsed fraction, it calls the TimeInterpolator that is currently set to calculate an interpolated fraction. An interpolated fraction maps the elapsed fraction to a new fraction that takes into account the time interpolation that is set. For example, in non-linear animation figure, because the animation slowly accelerates, the interpolated fraction, about .15, is less than the elapsed fraction, .25, at t = 10 ms. In linear animation figure, the interpolated fraction is always the same as the elapsed fraction.

When the interpolated fraction calculates, the ValueAnimator calls the TypeEvaluator to calculate the value of the property that you are animating, based on the interpolated fraction, the starting value, and the ending value of the animation. For example, in non-linear figure, the interpolated fraction was .15 at t = 10 ms, so the value for the property would be .15 × (40 – 0), or 6.

Property Animation Vs View Animation

View Animation

” The View Animation system provides the capability to only animate View objects.”

So if we wanted to animate non-View objects, we have to implement our own code to do so.

“The View Animation system constrains because it only exposes a few aspects of a View object to animate, such as the scaling and rotation of a View but not the background color, for instance.”

“Another disadvantage of the View Animation system is that it only modified where the View drew, and not the actual View itself.”

For instance, if we animated a button to move across the screen, the button draws correctly, but the actual location where we can click the button does not change, so we have to implement our own logic to handle this.

Property Animation

“With the property animation system, these constraints removed completely, and we can animate any property of any object (Views and non-Views) and the object they modify it.”

The property animation system is also more robust in the way it carries out animation. At a high level, we assign animators to the properties that we want to animate, such as color, position, or size and can define aspects of the animation such as interpolation and synchronization of multiple animators.

The View Animation system, however, takes less time to set up and requires less code to write. If View Animation accomplishes everything that we need to do, or if our existing code already works the way we want, there is no need to use the Property Animation system. It also might make sense to use both animation systems for different situations if the use case arises.

The Main Components of Property Animation System

We can find most of the property animation system’s APIs in android.animation. Because the View Animation system already defines many interpolators in android.view.animation, we can use those interpolators in the property animation system.

The Main Components of Property Animation System are :

  • Animators
  • Evaluators
  • Interpolators

Animators

The Animator class provides the basic structure for creating animations. We normally do not use this class directly, as it only provides minimal functionality that must be extended to fully support animating values. The following subclasses extend Animator:

  • ValueAnimator
  • ObjectAnimator
  • AnimatorSet

ValueAnimator

The main timing engine for property animation that also computes the values for the property to be animated. It has all the core functionality that calculates animation values and contains the timing details of each animation, information about whether an animation repeats, listeners that receive update events, and the ability to set custom types to evaluate.

There are two pieces to animating properties: 

  • calculating the animated values and
  • setting those values on the object and property that is being animated.

 ValueAnimator does not carry out the second piece, so we must listen for updates to values calculated by the ValueAnimator and modify the objects that want to animate with our own logic.

ObjectAnimator

A subclass of ValueAnimator that allows us to set a target object and object property to animate. This class updates the property accordingly when it computes a new value for the animation.

We want to use ObjectAnimator most of the time, because it makes animating values on target objects much easier. However, we sometimes want to use ValueAnimator directly because ObjectAnimator has a few more restrictions, such as requiring specific accessor methods to be present on the target object.

AnimatorSet

This provides a mechanism to group animations together so they run in relation to one another. We can set animations to play together, sequentially, or after a specified delay. 

Evaluators

Evaluators tell the property animation system how to calculate values for a property. They take the timing data that an Animator class provides, the animation’s start and end value, and calculate the animated values of the property based on this data.

The property animation system provides the following evaluators:

  • IntEvaluator: The default evaluator to calculate values for int properties.
  • FloatEvaluator: The default evaluator to calculate values for float properties.
  • ArgbEvaluator: The default evaluator to calculate values for color properties that represents as hexadecimal values.
  • TypeEvaluator: An interface that allows us to create our own evaluator. If we are animating an object property that is not an intfloat, or color, we must implement the TypeEvaluator interface to specify how to compute the object property’s animated values. We can also specify a custom TypeEvaluator for intfloat, and color values, if we want to process those types differently than the default behavior.

Interpolators

A time interpolator defines how specific values in an animation are calculated as a function of time.

For example, we can specify animations to happen linearly across the whole animation, meaning the animation moves evenly the entire time, or we can specify animations to use non-linear time, for example, accelerating at the beginning and decelerating at the end of the animation.

The property animation system provides the following interpolators:

  • AccelerateDecelerateInterpolator: An interpolator whose rate of change starts and ends slowly but accelerates through the middle.
  • AccelerateInterpolator: An interpolator whose rate of change starts out slowly and then accelerates.
  • AnticipateInterpolator: An interpolator whose change starts backward, then flings forward.
  • AnticipateOvershootInterpolator: An interpolator whose change starts backward, flings forward and overshoots the target value, then finally goes back to the final value.
  • BounceInterpolator: An interpolator whose change bounces at the end.
  • CycleInterpolator: An interpolator whose animation repeats for a specified number of cycles.
  • DecelerateInterpolator: An interpolator whose rate of change starts out quickly and then decelerates.
  • LinearInterpolator: An interpolator whose rate of change is constant.
  • OvershootInterpolator: An interpolator whose change flings forward and overshoots the last value then comes back.
  • TimeInterpolator: An interface that allows you to implement your own interpolator.

Animate Using ValueAnimator

The ValueAnimator class lets us animate values of some type for the duration of an animation by specifying a set of intfloat, or color values to animate through. We get a ValueAnimator by calling one of its factory methods: ofInt()ofFloat(), or ofObject(). For example:

ValueAnimator.ofFloat(0f, 100f).apply {
    duration = 1000
    start()
}

In this code, the ValueAnimator calculates the values of the animation, between 0 and 100, for a duration of 1000 ms, when the start() method runs.

We can also specify a custom type to animate by doing the following code:

ValueAnimator.ofObject(MyTypeEvaluator(), startPropertyValue, endPropertyValue).apply {
    duration = 1000
    start()
}

In this code, the ValueAnimator calculates the values of the animation, between startPropertyValue and endPropertyValue using the logic supplied by MyTypeEvaluator for a duration of 1000 ms, when the start() method runs.

We can use the values of the animation by adding an AnimatorUpdateListener to the ValueAnimator object, as shown in the following code:

ValueAnimator.ofObject(...).apply {
    ...
    addUpdateListener { updatedAnimation ->
        // You can use the animated value in a property that uses the
        // same type as the animation. In this case, you can use the
        // float value in the translationX property.
        textView.translationX = updatedAnimation.animatedValue as Float
    }
    ...
}

In the onAnimationUpdate() method, we can access the updated animation value and use it in a property of one of our views.

Animate Using ObjectAnimator

The ObjectAnimator is a subclass of the ValueAnimator and combines the timing engine and value computation of ValueAnimator with the ability to animate a named property of a target object. This makes animating any object much easier, as we no longer need to implement the ValueAnimator.AnimatorUpdateListener, because the animated property updates automatically.

Instantiating an ObjectAnimator is like a ValueAnimator, but we also specify the object and the name of that object’s property (as a String) along with the values to animate between:

ObjectAnimator.ofFloat(textView, "translationX", 100f).apply {
    duration = 1000
    start()
}

To have the ObjectAnimator update properties correctly, we must do the following steps:

  • The object property that we are animating must have a setter function (in camel case) in the form ofset<PropertyName>(). Because the ObjectAnimator automatically updates the property during animation, it must be able to access the property with this setter method. For example, if the property name is foo, we need to have a setFoo() method. If this setter method does not exist, we have three options:
    • Add the setter method to the class if we have the rights to do so.
    • Use a wrapper class that we have rights to change and have that wrapper receive the value with a valid setter method and forward it to the original object.
    • Use ValueAnimator instead.
  • If we specify only one value for the values... parameter in one of the ObjectAnimator factory methods, we assume it to be the ending value of the animation. Therefore, the object property that we are animating must have a getter function that is used to get the starting value of the animation. The getter function must be in the form of get<PropertyName>(). For example, if the property name is foo, we need to have a getFoo() method.
  • The getter and setter methods of the property that we are animating must operate on the same type as the starting and ending values that specify to ObjectAnimator. For example, we must have targetObject.setPropName(float) and targetObject.getPropName() if we construct the following ObjectAnimator:
ObjectAnimator.ofFloat(targetObject, "propName", 1f)
  • Depending on what property or object we are animating, we might need to call the invalidate() method on a View to force the screen to redraw itself with the updated animated values. We do this in the onAnimationUpdate() callback.

Animate Using AnimatorSet

In many cases, we want to play an animation that depends on when another animation starts or finishes. The Android system lets us bundle animations together into an AnimatorSet, so that we can specify whether to start animations simultaneously, sequentially, or after a specified delay. We can also nest AnimatorSet objects within each other.

val bouncer = AnimatorSet().apply {
    play(bounceAnim).before(squashAnim1)
    play(squashAnim1).with(squashAnim2)
    play(squashAnim1).with(stretchAnim1)
    play(squashAnim1).with(stretchAnim2)
    play(bounceBackAnim).after(stretchAnim2)
}
val fadeAnim = ObjectAnimator.ofFloat(newBall, "alpha", 1f, 0f).apply {
    duration = 250
}
AnimatorSet().apply {
    play(bouncer).before(fadeAnim)
    start()
}

In this code snippet, the following Animator objects in the following manner :

  • Plays bounceAnim.
  • Plays squashAnim1squashAnim2stretchAnim1, and stretchAnim2 at the same time.
  • Plays bounceBackAnim.
  • Plays fadeAnim.

Animation Listeners

We can listen for important events during an animation’s duration with the listeners described below.

  • Animator.AnimatorListener
  • ValueAnimator.AnimatorUpdateListener

Animator.AnimatorListener

  • onAnimationStart() : This method called when the animation starts.
  • onAnimationEnd(): This called when the animation ends.
  • onAnimationRepeat(): This method called when the animation repeats itself.
  • onAnimationCancel(): Called when the animation is canceled. A cancelled animation also calls onAnimationEnd(), regardless of how they were ended.

ValueAnimator.AnimatorUpdateListener

onAnimationUpdate(): This method called on every frame of the animation. Listen to this event to use the calculated values generated by ValueAnimator during an animation.

Animate Layout Changes to ViewGroup Objects

The property animation system provides the capability to animate changes to ViewGroup objects as well as provide an easy way to animate View objects themselves.

We can animate layout changes within a ViewGroup with the LayoutTransition class. Views inside a ViewGroup can go through an appearing and disappearing animation when we add them to or remove them from a ViewGroup or when we call a View’s setVisibility() method with VISIBLEINVISIBLE, or GONE. The remaining Views in the ViewGroup can also animate into their new positions when we add or remove Views.

We can define the following animations in a LayoutTransition object by calling setAnimator() and passing in an Animator object with one of the following LayoutTransition constants:

  • APPEARING : This flag indicating the animation that runs on items that are appearing in the container.
  • CHANGE_APPEARING : A flag indicating the animation that runs on items that are changing due to a new item appearing in the container.
  • DISAPPEARING : This flag indicating the animation that runs on items that are disappearing from the container.
  • CHANGE_DISAPPEARING : A flag indicating the animation that runs on items that are changing due to an item disappearing from the container.

Animate View State Changes Using StateListAnimator

The StateListAnimator class lets us define animators that run when the state of a view changes. This object behaves as a wrapper for an Animator object, calling that animation whenever the specified view state (such as “pressed” or “focused”) changes.

The StateListAnimator can be defined in an XML resource with a root <selector> element and child <item> elements that each specify a different view state defined by the StateListAnimator class. Each <item> contains the definition for a property animation set.

For example, the following file creates a state list animator that changes the x and y scale of the view when it’s pressed:

res/xml/animate_scale.xml

<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <!-- the pressed state; increase x and y size to 150% -->
    <item android:state_pressed="true">
        <set>
            <objectAnimator android:propertyName="scaleX"
                android:duration="@android:integer/config_shortAnimTime"
                android:valueTo="1.5"
                android:valueType="floatType"/>
            <objectAnimator android:propertyName="scaleY"
                android:duration="@android:integer/config_shortAnimTime"
                android:valueTo="1.5"
                android:valueType="floatType"/>
        </set>
    </item>
    <!-- the default, non-pressed state; set x and y size to 100% -->
    <item android:state_pressed="false">
        <set>
            <objectAnimator android:propertyName="scaleX"
                android:duration="@android:integer/config_shortAnimTime"
                android:valueTo="1"
                android:valueType="floatType"/>
            <objectAnimator android:propertyName="scaleY"
                android:duration="@android:integer/config_shortAnimTime"
                android:valueTo="1"
                android:valueType="floatType"/>
        </set>
    </item>
</selector>

To attach the state list animator to a view, add the android:stateListAnimator attribute as follows:

<Button android:stateListAnimator="@xml/animate_scale"
        ... />

Now the animations defined in animate_scale.xml are used when this button’s state changes.

Or, to instead assign a state list animator to a view in our code, use the AnimatorInflater.loadStateListAnimator() method, and assign the animator to our view with the View.setStateListAnimator() method.

Use a TypeEvaluator

If we want to animate a type unknown to the Android system, we can create our own evaluator by implementing the TypeEvaluator interface. The types that are known by the Android system are intfloat, or a color, which are supported by the IntEvaluatorFloatEvaluator, and ArgbEvaluator type evaluators.

There is only one method to implement in the TypeEvaluator interface, the evaluate() method. This allows the animator that we are using to return an appropriate value for our animated property at the current point of the animation. The FloatEvaluator class shows how to do this:

private class FloatEvaluator : TypeEvaluator<Any> {

    override fun evaluate(fraction: Float, startValue: Any, endValue: Any): Any {
        return (startValue as Number).toFloat().let { startFloat ->
            startFloat + fraction * ((endValue as Number).toFloat() - startFloat)
        }
    }

}

Use Interpolators

An interpolator define how calculate specific values in an animation as a function of time. For example, we can specify animations to happen linearly across the whole animation, meaning the animation moves evenly the entire time, or we can specify animations to use non-linear time, for example, using acceleration or deceleration at the beginning or end of the animation.

Interpolators in the animation system receive a fraction from Animators that represent the elapsed time of the animation. Interpolators modify this fraction to coincide with the type of animation that it aims to provide. The Android system provides a set of common interpolators in the android.view.animation package. If none of these suit our needs, we can implement the TimeInterpolator interface and create our own.

For example, we will see that how to compare the default interpolator AccelerateDecelerateInterpolator and the LinearInterpolator that calculates interpolated fractions. The LinearInterpolator has no effect on the elapsed fraction. The AccelerateDecelerateInterpolator accelerates into the animation and decelerates out of it.

AccelerateDecelerateInterpolator

override fun getInterpolation(input: Float): Float =
        (Math.cos((input + 1) * Math.PI) / 2.0f).toFloat() + 0.5f

LinearInterpolator

override fun getInterpolation(input: Float): Float = input

Specify Keyframes

Keyframe object consists of a time/value pair that lets us define a specific state at a specific time of an animation. Each keyframe can also have its own interpolator to control the behavior of the animation in the interval between the previous keyframe’s time and the time of this keyframe.

To instantiate a Keyframe object, we must use one of the factory methods, ofInt()ofFloat(), or ofObject() to get the appropriate type of Keyframe. We then call the ofKeyframe() factory method to get a PropertyValuesHolder object. Once we have the object, we can get an animator by passing in the PropertyValuesHolder object and the object to animate. 

val kf0 = Keyframe.ofFloat(0f, 0f)
val kf1 = Keyframe.ofFloat(.5f, 360f)
val kf2 = Keyframe.ofFloat(1f, 0f)
val pvhRotation = PropertyValuesHolder.ofKeyframe("rotation", kf0, kf1, kf2)
ObjectAnimator.ofPropertyValuesHolder(target, pvhRotation).apply {
    duration = 5000
}

Animate Views

The Property Animation system allows streamlined animation of View objects and offers a few advantages over the view animation system. The View Animation system transformed View objects by changing the way that they were drawn. This was handled in the container of each View, because the View itself had no properties to manipulate. This resulted in the View being animated, but caused no change in the View object itself. This led to behavior such as an object still existing in its original location, even though it was drawn on a different location on the screen.

The property animation system can animate Views on the screen by changing the actual properties in the View objects. In addition, Views also automatically calls the invalidate() method to refresh the screen whenever its properties are changed. The new properties in the View class that facilitate property animations are:

  • translationX and translationY: These properties control where the View is located as a delta from its left and top coordinates, which are set by its layout container.
  • rotationrotationX, and rotationY: These properties control the rotation in 2D (rotation property) and 3D around the pivot point.
  • scaleX and scaleY: These properties control the 2D scaling of a View around its pivot point.
  • pivotX and pivotY: These properties control the location of the pivot point, around which the rotation and scaling transforms occur. By default, the pivot point is located at the center of the object.
  • x and y: These are simple utility properties to describe the final location of the View in its container, as a sum of the left and top values and translationX and translationY values.
  • alpha: Represents the alpha transparency on the View. This value is 1 (opaque) by default, with a value of 0 representing full transparency (not visible).

To animate a property of a View object, such as its color or rotation value, all we need to do is create a property animator and specify the View property that we want to animate. For example:

ObjectAnimator.ofFloat(myView, "rotation", 0f, 360f)

Animate Using ViewPropertyAnimator

The ViewPropertyAnimator provides a simple way to animate several properties of a View in parallel, using a single underlying Animator object. It behaves much like an ObjectAnimator, because it modifies the actual values of the view’s properties, but is more efficient when animating many properties at once. In addition, the code for using the ViewPropertyAnimator is much more concise and easier to read.

The following code snippets show the differences in using multiple ObjectAnimator objects, a single ObjectAnimator, and the ViewPropertyAnimator when simultaneously animating the x and y property of a view.

Multiple ObjectAnimator objects

val animX = ObjectAnimator.ofFloat(myView, "x", 50f)
val animY = ObjectAnimator.ofFloat(myView, "y", 100f)
AnimatorSet().apply {
    playTogether(animX, animY)
    start()
}

One ObjectAnimator

val pvhX = PropertyValuesHolder.ofFloat("x", 50f)
val pvhY = PropertyValuesHolder.ofFloat("y", 100f)
ObjectAnimator.ofPropertyValuesHolder(myView, pvhX, pvhY).start()

ViewPropertyAnimator

myView.animate().x(50f).y(100f)

Declare Animations in XML

The property animation system lets us declare property animations with XML instead of doing it programmatically. By defining our animations in XML, we can easily reuse our animations in multiple activities and more easily edit the animation sequence.

The following property animation classes have XML declaration support with the following XML tags:

ValueAnimator - <animator>
ObjectAnimator - <objectAnimator>
AnimatorSet - <set>

The following example plays the two sets of object animations sequentially, with the first nested set playing two object animations together:

<set android:ordering="sequentially">
    <set>
        <objectAnimator
            android:propertyName="x"
            android:duration="500"
            android:valueTo="400"
            android:valueType="intType"/>
        <objectAnimator
            android:propertyName="y"
            android:duration="500"
            android:valueTo="300"
            android:valueType="intType"/>
    </set>
    <objectAnimator
        android:propertyName="alpha"
        android:duration="500"
        android:valueTo="1f"/>
</set>

In order to run this animation, we must inflate the XML resources in our code to an AnimatorSet object, and then set the target objects for all of the animations before starting the animation set. Calling setTarget() sets a single target object for all children of the AnimatorSet as a convenience.

(AnimatorInflater.loadAnimator(myContext, R.animator.property_animator) as AnimatorSet).apply {
    setTarget(myObject)
    start()
}

We can also declare a ValueAnimator in XML, as shown in the following example:

<animator xmlns:android="http://schemas.android.com/apk/res/android"
    android:duration="1000"
    android:valueType="floatType"
    android:valueFrom="0f"
    android:valueTo="-100f" />

To use the previous ValueAnimator in our code, we must inflate the object, add an AnimatorUpdateListener, get the updated animation value, and use it in a property of one of our views, as shown in the following code:

(AnimatorInflater.loadAnimator(this, R.animator.animator) as ValueAnimator).apply {
    addUpdateListener { updatedAnimation ->
        textView.translationX = updatedAnimation.animatedValue as Float
    }

    start()
}

That’s all about in this article.

Related Other Articles / Posts

Conclusion

In this article, we understood about Property Animation Overview in Android. This article described about Property Animation related concepts like Workflow, benefits, Animates View using ValueAnimator, ObjectAnimator and AnimatorSet in Android.

Thanks for reading! I hope you enjoyed and learned about Property Animation concepts in Android. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find Other articles of CoolMonkTechie as below link :

You can also follow official website and tutorials of Android as below links :

If you have any comments, questions, or think I missed something, leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???

Android – Is Awesome Design Patterns Valuable In Kotlin?

Hello Readers, CoolMonkTechie heartily welcomes you in this article (Is Awesome Design Patterns Valuable In Kotlin?).

In this article, we will learn about why design patterns are valuable and frequently used in Kotlin. When we are new in programming languages, we don’t know which design patterns we should use with it and how to implement them. Design Patterns determine certain factors to differentiate between a good code and a bad code in Kotlin. This may be the code structure or the comments used or the variable names or something else. Being able to use a relevant design pattern is a prerequisite to creating functional, high-quality, and secure applications in Android with use of Kotlin. 

So every developer should follow Design Patterns while writing the Kotlin code of an Android application.

A famous quote about learning is :

” One learns from books and example only that certain things can be done. Actual learning requires that you do those things. “

So Let’s begin.

Design Patterns: What they are and why know them ?

A software design pattern is a solution to a particular problem we might face when designing an app’s architecture. But unlike out-of-the-box services or open-source libraries, we can’t paste a design pattern into our application because it isn’t a piece of code. Rather, it’s a general concept for how to solve a problem. A design pattern is a template that tells us how to write code, but it’s up to us to fit our code to this template.

Design patterns bring several benefits:

  • Tested solutions. We don’t need to waste time and reinvent the wheel trying to solve a particular software development problem, as design patterns already provide the best solution and tell us how to implement it.
  • Code unification. Design patterns provide us with typical solutions that have tested for drawbacks and bugs, helping us make fewer mistakes when designing our app architecture.
  • Common vocabulary. Instead of providing in-depth explanations of how to solve this or that software development problem, we can say what design pattern we used and other developers will immediately understand what solutions we implemented.

Design Patterns: What is it ?

A Design Pattern is a general, reusable solution to a commonly occurring problem within a given context.

So, Design Patterns are a pattern solution that follows to solve a particular feature. These are the best practices that any programmer can use to build an application.

We use Design Patterns that makes our code easier to understand and more reusable in Android.

Design Patterns: Patterns Types In Kotlin

Before we describe the most common architecture patterns in Android Kotlin, we should first learn the three types of software design patterns and how they differ:

  • Creational Design Patterns
  • Structural Design Patterns
  • Behavioral Design Patterns

1. Creational Design Patterns

Creational software design patterns deal with object creation mechanisms, which increase flexibility and reuse of existing code. They try to instantiate objects in a manner suitable for the particular situation. 

This Pattern is used to create some object without showing the logic or the steps that involves in creating the object. So, every time we want an object, we need not instantiate the object by using the new operator. So, this makes creating an object easier and can be easily created again and again.

Here are several creational design patterns:

  • Builder Pattern
  • Singleton Pattern
  • Factory Method Pattern
  • Abstract Factory

2. Structural Design Patterns

Structural design patterns aim to simplify the design by finding a simple way of realizing relationships between classes and objects. These patterns explain how to assemble objects and classes into larger structures while keeping these structures flexible and efficient.

In this Design Pattern, we concern about the structure of the code. Here, we follow some particular structural pattern that will help in understanding the code and the working of code just by looking at the structure of the code. These are some structural architecture patterns:

  • Adapter Pattern
  • Facade Pattern
  • Decorator Pattern
  • Composite Pattern
  • Protection Proxy Pattern

3. Behavioral Design Patterns

Behaviour design patterns identify common communication patterns between entities and implement these patterns. This Patterns mainly tells how the objects of the classes will communicate with each other. These patterns help us in understanding the code in a better way because by viewing the code we can identify the pattern and then we can understand the code in a better way.

  • Observer / Listener Pattern
  • Command Pattern
  • Strategy Pattern
  • State Pattern
  • Chain of Responsibility Pattern
  • Visitor Pattern
  • Mediator Pattern
  • Memento Pattern

Most Frequently Used Design Patterns In Kotlin

We’re going to provide only the essential information about each software design pattern–namely, how it works from the technical point of view and when it should be applied. We’ll also give an illustrative example in the Kotlin programming language.

1. Creational: Builder Pattern

The builder pattern is used to create complex objects with constituent parts that must be created in the same order or using a specific algorithm. An external class controls the construction algorithm.

Example

For example, Let’s assume that external library provides Dialog class, and we have only accessed to Dialog Public interface, which can not be changed.

class Dialog {

    fun showTitle() = println("showing title")

    fun setTitle(text: String) = println("setting title text $text")

    fun setTitleColor(color: String) = println("setting title color $color")

    fun showMessage() = println("showing message")

    fun setMessage(text: String) = println("setting message $text")

    fun setMessageColor(color: String) = println("setting message color $color")

    fun showImage(bitmapBytes: ByteArray) = println("showing image with size ${bitmapBytes.size}")

    fun show() = println("showing dialog $this")
}

//Builder:
class DialogBuilder() {
    constructor(init: DialogBuilder.() -> Unit) : this() {
        init()
    }

    private var titleHolder: TextView? = null
    private var messageHolder: TextView? = null
    private var imageHolder: File? = null

    fun title(init: TextView.() -> Unit) {
        titleHolder = TextView().apply { init() }
    }

    fun message(init: TextView.() -> Unit) {
        messageHolder = TextView().apply { init() }
    }

    fun image(init: () -> File) {
        imageHolder = init()
    }

    fun build(): Dialog {
        val dialog = Dialog()

        titleHolder?.apply {
            dialog.setTitle(text)
            dialog.setTitleColor(color)
            dialog.showTitle()
        }

        messageHolder?.apply {
            dialog.setMessage(text)
            dialog.setMessageColor(color)
            dialog.showMessage()
        }

        imageHolder?.apply {
            dialog.showImage(readBytes())
        }

        return dialog
    }

    class TextView {
        var text: String = ""
        var color: String = "#00000"
    }
}

Usage

//Function that creates dialog builder and builds Dialog
fun dialog(init: DialogBuilder.() -> Unit): Dialog {
    return DialogBuilder(init).build()
}

val dialog: Dialog = dialog {
	title {
    	text = "Dialog Title"
    }
    message {
        text = "Dialog Message"
        color = "#333333"
    }
    image {
        File.createTempFile("image", "jpg")
    }
}

dialog.show()

Output

setting title text Dialog Title
setting title color #00000
showing title
setting message Dialog Message
setting message color #333333
showing message
showing image with size 0
showing dialog Dialog@5f184fc6

AlertDialog Example

One of the common examples of Builder pattern that we all use in our daily life is that of AlertDialog. In AleartDialog, we call only the required methods like:

AlertDialog.Builder(this)
    .setTitle("This is a title")
    .setMessage("This is some message")
    .show()

2. Creational: Singleton Pattern

The singleton pattern ensures that only one object of a particular class is ever created. All further references to objects of the singleton class refer to the same underlying instance. There are very few applications, do not overuse this pattern!

Example

object PrinterDriver {
    init {
        println("Initializing with object: $this")
    }

    fun print() = println("Printing with object: $this")
}

Usage

println("Start")
PrinterDriver.print()
PrinterDriver.print()

Output

Start
Initializing with object: PrinterDriver@6ff3c5b5
Printing with object: PrinterDriver@6ff3c5b5
Printing with object: PrinterDriver@6ff3c5b5

3. Creational: Factory Method Pattern

The factory pattern is used to replace class constructors, abstracting the process of object generation so that the type of the object instantiated can be determined at run-time.

Example

sealed class Country {
    object USA : Country()
}

object Spain : Country() 
class Greece(val someProperty: String) : Country()
data class Canada(val someProperty: String) : Country() 

class Currency(
    val code: String
)

object CurrencyFactory {

    fun currencyForCountry(country: Country): Currency =
        when (country) {
            is Greece -> Currency("EUR")
            is Spain -> Currency("EUR")
            is Country.USA -> Currency("USD")
            is Canada -> Currency("CAD")
        }  
}

Usage

val greeceCurrency = CurrencyFactory.currencyForCountry(Greece("")).code
println("Greece currency: $greeceCurrency")

val usaCurrency = CurrencyFactory.currencyForCountry(Country.USA).code
println("USA currency: $usaCurrency")

assertThat(greeceCurrency).isEqualTo("EUR")
assertThat(usaCurrency).isEqualTo("USD")

Output

Greece currency: EUR
US currency: USD

4. Creational: Abstract Factory Pattern

The abstract factory pattern is used to provide a client with a set of related or dependant objects. The “family” of objects created by the factory are determined at run-time.

Example

interface Plant

class OrangePlant : Plant

class ApplePlant : Plant

abstract class PlantFactory {
    abstract fun makePlant(): Plant

    companion object {
        inline fun <reified T : Plant> createFactory(): PlantFactory = when (T::class) {
            OrangePlant::class -> OrangeFactory()
            ApplePlant::class  -> AppleFactory()
            else               -> throw IllegalArgumentException()
        }
    }
}

class AppleFactory : PlantFactory() {
    override fun makePlant(): Plant = ApplePlant()
}

class OrangeFactory : PlantFactory() {
    override fun makePlant(): Plant = OrangePlant()
}

Usage

val plantFactory = PlantFactory.createFactory<OrangePlant>()
val plant = plantFactory.makePlant()
println("Created plant: $plant")

Output

Created plant: OrangePlant@4f023edb

5. Structural: Adapter Pattern

The adapter pattern is used to provide a link between two otherwise incompatible types by wrapping the “adaptee” with a class that supports the interface required by the client.

Example

interface Temperature {
    var temperature: Double
}

class CelsiusTemperature(override var temperature: Double) : Temperature

class FahrenheitTemperature(var celsiusTemperature: CelsiusTemperature) : Temperature {

    override var temperature: Double
        get() = convertCelsiusToFahrenheit(celsiusTemperature.temperature)
        set(temperatureInF) {
            celsiusTemperature.temperature = convertFahrenheitToCelsius(temperatureInF)
        }

    private fun convertFahrenheitToCelsius(f: Double): Double = (f - 32) * 5 / 9

    private fun convertCelsiusToFahrenheit(c: Double): Double = (c * 9 / 5) + 32
}

Usage

val celsiusTemperature = CelsiusTemperature(0.0)
val fahrenheitTemperature = FahrenheitTemperature(celsiusTemperature)

celsiusTemperature.temperature = 36.6
println("${celsiusTemperature.temperature} C -> ${fahrenheitTemperature.temperature} F")

fahrenheitTemperature.temperature = 100.0
println("${fahrenheitTemperature.temperature} F -> ${celsiusTemperature.temperature} C")

Output

36.6 C -> 97.88000000000001 F
100.0 F -> 37.77777777777778 C

6. Structural: Facade Pattern

The facade pattern is used to define a simplified interface to a more complex subsystem.

Example

class ComplexSystemStore(val filePath: String) {

    init {
        println("Reading data from file: $filePath")
    }

    val store = HashMap<String, String>()

    fun store(key: String, payload: String) {
        store.put(key, payload)
    }

    fun read(key: String): String = store[key] ?: ""

    fun commit() = println("Storing cached data: $store to file: $filePath")
}

data class User(val login: String)

//Facade:
class UserRepository {
    val systemPreferences = ComplexSystemStore("/data/default.prefs")

    fun save(user: User) {
        systemPreferences.store("USER_KEY", user.login)
        systemPreferences.commit()
    }

    fun findFirst(): User = User(systemPreferences.read("USER_KEY"))
}

Usage

val userRepository = UserRepository()
val user = User("coolmonktechie")
userRepository.save(user)
val resultUser = userRepository.findFirst()
println("Found stored user: $resultUser")

Output

Reading data from file: /data/default.prefs
Storing cached data: {USER_KEY=coolmonktechie} to file: /data/default.prefs
Found stored user: User(login=coolmonktechie)

7. Structural: Decorator Pattern

The decorator pattern is used to extend or alter the functionality of objects at run-time by wrapping them in an object of a decorator class. This provides a flexible alternative to using inheritance to change behaviour.

Example

interface CoffeeMachine {
    fun makeSmallCoffee()
    fun makeLargeCoffee()
}

class NormalCoffeeMachine : CoffeeMachine {
    override fun makeSmallCoffee() = println("Normal: Making small coffee")

    override fun makeLargeCoffee() = println("Normal: Making large coffee")
}

//Decorator:
class EnhancedCoffeeMachine(val coffeeMachine: CoffeeMachine) : CoffeeMachine by coffeeMachine {

    // overriding behaviour
    override fun makeLargeCoffee() {
        println("Enhanced: Making large coffee")
        coffeeMachine.makeLargeCoffee()
    }

    // extended behaviour
    fun makeCoffeeWithMilk() {
        println("Enhanced: Making coffee with milk")
        coffeeMachine.makeSmallCoffee()
        println("Enhanced: Adding milk")
    }
}

Usage

val normalMachine = NormalCoffeeMachine()
    val enhancedMachine = EnhancedCoffeeMachine(normalMachine)

    // non-overridden behaviour
    enhancedMachine.makeSmallCoffee()
    // overriding behaviour
    enhancedMachine.makeLargeCoffee()
    // extended behaviour
    enhancedMachine.makeCoffeeWithMilk()

Output

Normal: Making small coffee

Enhanced: Making large coffee
Normal: Making large coffee

Enhanced: Making coffee with milk
Normal: Making small coffee
Enhanced: Adding milk

8. Structural: Composite Pattern

The composite pattern is used to compose zero-or-more similar objects so it can manipulate them as one object.

Example

open class Equipment(private var price: Int, private var name: String) {
    open fun getPrice(): Int = price
}


/*
[composite]
*/

open class Composite(name: String) : Equipment(0, name) {
    val equipments = ArrayList<Equipment>()

    fun add(equipment: Equipment) {
        this.equipments.add(equipment)
    }

    override fun getPrice(): Int {
        return equipments.map { it.getPrice() }.sum()
    }
}


/*
 leafs
*/

class Cabbinet : Composite("cabbinet")
class FloppyDisk : Equipment(80, "Floppy Disk")
class HardDrive : Equipment(250, "Hard Drive")
class Memory : Equipment(280, "Memory")

Usage

var cabbinet = Cabbinet()
cabbinet.add(FloppyDisk())
cabbinet.add(HardDrive())
cabbinet.add(Memory())
println(cabbinet.getPrice())

Output

610

9. Structural: Protection Proxy Pattern

The proxy pattern is used to provide a surrogate or placeholder object, which references an underlying object. Protection proxy is restricting access.

Example

interface File {
    fun read(name: String)
}

class NormalFile : File {
    override fun read(name: String) = println("Reading file: $name")
}

//Proxy:
class SecuredFile : File {
    val normalFile = NormalFile()
    var password: String = ""

    override fun read(name: String) {
        if (password == "secret") {
            println("Password is correct: $password")
            normalFile.read(name)
        } else {
            println("Incorrect password. Access denied!")
        }
    }
}

Usage

val securedFile = SecuredFile()
securedFile.read("readme.md")

securedFile.password = "secret"
securedFile.read("readme.md")

Output

Incorrect password. Access denied!
Password is correct: secret
Reading file: readme.md

10. Behavioral: Observer / Listener Pattern

The observer pattern is used to allow an object to publish changes to its state. Other objects subscribe to be immediately notified of any changes.

Example

interface TextChangedListener {

    fun onTextChanged(oldText: String, newText: String)
}

class PrintingTextChangedListener : TextChangedListener {
    
    private var text = ""
    
    override fun onTextChanged(oldText: String, newText: String) {
        text = "Text is changed: $oldText -> $newText"
    }
}

class TextView {

    val listeners = mutableListOf<TextChangedListener>()

    var text: String by Delegates.observable("<empty>") { _, old, new ->
        listeners.forEach { it.onTextChanged(old, new) }
    }
}

Usage

val textView = TextView().apply {
    listener = PrintingTextChangedListener()
}

with(textView) {
    text = "old name"
    text = "new name"
}

Output

Text is changed <empty> -> old name
Text is changed old name -> new name

11. Behavioral: Command Pattern

The command pattern is used to express a request, including the call to be made and all of its required parameters, in a command object. The command may then be executed immediately or held for later use.

Example

interface OrderCommand {
    fun execute()
}

class OrderAddCommand(val id: Long) : OrderCommand {
    override fun execute() = println("Adding order with id: $id")
}

class OrderPayCommand(val id: Long) : OrderCommand {
    override fun execute() = println("Paying for order with id: $id")
}

class CommandProcessor {

    private val queue = ArrayList<OrderCommand>()

    fun addToQueue(orderCommand: OrderCommand): CommandProcessor =
        apply {
            queue.add(orderCommand)
        }

    fun processCommands(): CommandProcessor =
        apply {
            queue.forEach { it.execute() }
            queue.clear()
        }
}

Usage

CommandProcessor()
    .addToQueue(OrderAddCommand(1L))
    .addToQueue(OrderAddCommand(2L))
    .addToQueue(OrderPayCommand(2L))
    .addToQueue(OrderPayCommand(1L))
    .processCommands()

Output

Adding order with id: 1
Adding order with id: 2
Paying for order with id: 2
Paying for order with id: 1

12. Behavioral: Strategy Pattern

The strategy pattern is used to create an interchangeable family of algorithms from which the required process is chosen at run-time.

Example

class Printer(private val stringFormatterStrategy: (String) -> String) {

    fun printString(string: String) {
        println(stringFormatterStrategy(string))
    }
}

val lowerCaseFormatter: (String) -> String = { it.toLowerCase() }
val upperCaseFormatter = { it: String -> it.toUpperCase() }

Usage

val inputString = "OLD name NEW name "

val lowerCasePrinter = Printer(lowerCaseFormatter)
lowerCasePrinter.printString(inputString)

val upperCasePrinter = Printer(upperCaseFormatter)
upperCasePrinter.printString(inputString)

val prefixPrinter = Printer { "Prefix: $it" }
prefixPrinter.printString(inputString)

Output

old name new name
OLD NAME NEW NAME
Prefix: OLD name NEW name

13. Behavioral: State Pattern

The state pattern is used to alter the behaviour of an object as its internal state changes. The pattern allows the class for an object to apparently change at run-time.

Example

sealed class AuthorizationState

object Unauthorized : AuthorizationState()

class Authorized(val userName: String) : AuthorizationState()

class AuthorizationPresenter {

    private var state: AuthorizationState = Unauthorized

    val isAuthorized: Boolean
        get() = when (state) {
            is Authorized -> true
            is Unauthorized -> false
        }

    val userName: String
        get() {
            val state = this.state //val enables smart casting of state
            return when (state) {
                is Authorized -> state.userName
                is Unauthorized -> "Unknown"
            }
        }

    fun loginUser(userName: String) {
        state = Authorized(userName)
    }

    fun logoutUser() {
        state = Unauthorized
    }

    override fun toString() = "User '$userName' is logged in: $isAuthorized"
}

Usage

val authorizationPresenter = AuthorizationPresenter()

authorizationPresenter.loginUser("admin")
println(authorizationPresenter)

authorizationPresenter.logoutUser()
println(authorizationPresenter)

Output

User 'admin' is logged in: true
User 'Unknown' is logged in: false

14. Behavioral: Chain of Responsibility Pattern

The chain of responsibility pattern is used to process varied requests, each of which may be dealt with by a different handler.

Example

interface HeadersChain {
    fun addHeader(inputHeader: String): String
}

class AuthenticationHeader(val token: String?, var next: HeadersChain? = null) : HeadersChain {

    override fun addHeader(inputHeader: String): String {
        token ?: throw IllegalStateException("Token should be not null")
        return inputHeader + "Authorization: Bearer $token\n"
            .let { next?.addHeader(it) ?: it }
    }
}

class ContentTypeHeader(val contentType: String, var next: HeadersChain? = null) : HeadersChain {

    override fun addHeader(inputHeader: String): String =
        inputHeader + "ContentType: $contentType\n"
            .let { next?.addHeader(it) ?: it }
}

class BodyPayload(val body: String, var next: HeadersChain? = null) : HeadersChain {

    override fun addHeader(inputHeader: String): String =
        inputHeader + "$body"
            .let { next?.addHeader(it) ?: it }
}

Usage

//create chain elements
val authenticationHeader = AuthenticationHeader("123456")
val contentTypeHeader = ContentTypeHeader("json")
val messageBody = BodyPayload("Body:\n{\n\"username\"=\"coolmonktechie\"\n}")

//construct chain
authenticationHeader.next = contentTypeHeader
contentTypeHeader.next = messageBody

//execute chain
val messageWithAuthentication =
    authenticationHeader.addHeader("Headers with Authentication:\n")
println(messageWithAuthentication)

val messageWithoutAuth =
    contentTypeHeader.addHeader("Headers:\n")
println(messageWithoutAuth)

Output

Headers with Authentication:
Authorization: Bearer 123456
ContentType: json
Body:
{
"username"="coolmonktechie"
}

Headers:
ContentType: json
Body:
{
"username"="coolmonktechie"
}

15. Behavioral: Visitor Pattern

The visitor pattern is used to separate a relatively complex set of structured data classes from the functionality that may be performed upon the data that they hold.

Example

interface ReportVisitable {
    fun <R> accept(visitor: ReportVisitor<R>): R
}

class FixedPriceContract(val costPerYear: Long) : ReportVisitable {
    override fun <R> accept(visitor: ReportVisitor<R>): R = visitor.visit(this)
}

class TimeAndMaterialsContract(val costPerHour: Long, val hours: Long) : ReportVisitable {
    override fun <R> accept(visitor: ReportVisitor<R>): R = visitor.visit(this)
}

class SupportContract(val costPerMonth: Long) : ReportVisitable {
    override fun <R> accept(visitor: ReportVisitor<R>): R = visitor.visit(this)
}

interface ReportVisitor<out R> {

    fun visit(contract: FixedPriceContract): R
    fun visit(contract: TimeAndMaterialsContract): R
    fun visit(contract: SupportContract): R
}

class MonthlyCostReportVisitor : ReportVisitor<Long> {

    override fun visit(contract: FixedPriceContract): Long =
        contract.costPerYear / 12

    override fun visit(contract: TimeAndMaterialsContract): Long =
        contract.costPerHour * contract.hours

    override fun visit(contract: SupportContract): Long =
        contract.costPerMonth
}

class YearlyReportVisitor : ReportVisitor<Long> {

    override fun visit(contract: FixedPriceContract): Long =
        contract.costPerYear

    override fun visit(contract: TimeAndMaterialsContract): Long =
        contract.costPerHour * contract.hours

    override fun visit(contract: SupportContract): Long =
        contract.costPerMonth * 12
}

Usage

val projectAlpha = FixedPriceContract(costPerYear = 10000)
val projectGamma = TimeAndMaterialsContract(hours = 150, costPerHour = 10)
val projectBeta = SupportContract(costPerMonth = 500)
val projectKappa = TimeAndMaterialsContract(hours = 50, costPerHour = 50)

val projects = arrayOf(projectAlpha, projectBeta, projectGamma, projectKappa)

val monthlyCostReportVisitor = MonthlyCostReportVisitor()

val monthlyCost = projects.map { it.accept(monthlyCostReportVisitor) }.sum()
println("Monthly cost: $monthlyCost")
assertThat(monthlyCost).isEqualTo(5333)

val yearlyReportVisitor = YearlyReportVisitor()
val yearlyCost = projects.map { it.accept(yearlyReportVisitor) }.sum()
println("Yearly cost: $yearlyCost")
assertThat(yearlyCost).isEqualTo(20000)

Output

Monthly cost: 5333
Yearly cost: 20000

16. Behavioral: Mediator Pattern

Mediator design pattern is used to provide a centralized communication medium between different objects in a system. This pattern is very helpful in an enterprise application where multiple objects are interacting with each other.

Example

class ChatUser(private val mediator: ChatMediator, val name: String) {
    fun send(msg: String) {
        println("$name: Sending Message= $msg")
        mediator.sendMessage(msg, this)
    }

    fun receive(msg: String) {
        println("$name: Message received: $msg")
    }
}

class ChatMediator {

    private val users: MutableList<ChatUser> = ArrayList()

    fun sendMessage(msg: String, user: ChatUser) {
        users
            .filter { it != user }
            .forEach {
                it.receive(msg)
            }
    }

    fun addUser(user: ChatUser): ChatMediator =
        apply { users.add(user) }

}

Usage

val mediator = ChatMediator()
val user1 = ChatUser(mediator, "User1")

mediator
    .addUser(ChatUser(mediator, "User2"))
    .addUser(ChatUser(mediator, "User3"))
    .addUser(user1)
user1.send("Hello everyone!")

Output

User1: Sending Message= Hello everyone!
User2: Message received: Hello everyone!
user3: Message received: Hello everyone!

17. Behavioral: Memento Pattern

The memento pattern is a software design pattern that provides the ability to restore an object to its previous state (undo via rollback).

Example

data class Memento(val state: String)

class Originator(var state: String) {

    fun createMemento(): Memento {
        return Memento(state)
    }

    fun restore(memento: Memento) {
        state = memento.state
    }
}

class CareTaker {
    private val mementoList = ArrayList<Memento>()

    fun saveState(state: Memento) {
        mementoList.add(state)
    }

    fun restore(index: Int): Memento {
        return mementoList[index]
    }
}

Usage

val originator = Originator("initial state")
val careTaker = CareTaker()
careTaker.saveState(originator.createMemento())

originator.state = "State #1"
originator.state = "State #2"
careTaker.saveState(originator.createMemento())

originator.state = "State #3"
println("Current State: " + originator.state)
assertThat(originator.state).isEqualTo("State #3")

originator.restore(careTaker.restore(1))
println("Second saved state: " + originator.state)
assertThat(originator.state).isEqualTo("State #2")

originator.restore(careTaker.restore(0))
println("First saved state: " + originator.state)

Output

Current State: State #3
Second saved state: State #2
First saved state: initial state

That’s all about in this article.

Related Other Articles / Posts

Conclusion

In this article, we understood about why design patterns are valuable and most frequently used in Kotlin. This article shows the most frequently used design patterns in Kotlin with an authentic example.

Thanks for reading! I hope you enjoyed and learned about Valuable Design Patterns concepts in Kotlin. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find Other articles of CoolMonkTechie as below link :

You can also follow official website and tutorials of Android as below links :

If you have any comments, questions, or think I missed something, leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???

Exit mobile version