Forem: Waqas Younis

Canceling a Coroutine Simplified ❌

Waqas Younis — Sat, 14 Sep 2024 23:45:28 +0000

Just like making a function main safe, you are also responsible for making it cancelable. It won’t do it itself.

In lifecycle dependent environment like Android, you should try to make each suspend function cancelable. Because any job can be cancelled at any time.

Why is that important?

Allow me to explain via an example, suppose you wrote a nice-shinny main-safe function that compresses the image to show it to user.

Take this code snippet as an example:

class BitmapCompressor(
    private val context: Context
) {

    suspend fun compressImage(
        contentUri: Uri,
        compressionThreshold: Long
    ): Bitmap? {
        return withContext(Dispatchers.IO) {
            val inputBytes = context
                .contentResolver
                .openInputStream(contentUri)?.use { inputStream ->
                    inputStream.readBytes()
                } ?: return@withContext null


            withContext(Dispatchers.Default) {
                val bitmap = BitmapFactory.decodeByteArray(inputBytes, 0, inputBytes.size)


                var outputBytes: ByteArray
                var quality = 100
                do {
                    ByteArrayOutputStream().use { outputStream ->
                        bitmap.compress(Bitmap.CompressFormat.JPEG, quality, outputStream)
                        outputBytes = outputStream.toByteArray()
                        quality -= (quality * 0.1).roundToInt()
                    }
                } while (outputBytes.size > compressionThreshold && quality > 5)


                BitmapFactory.decodeByteArray(outputBytes, 0, outputBytes.size).also{
                  println("Compression Finished")
                }
            }
        }
    }
}

Don’t get overwhelmed, it’s just a function that compresses the image to a provided compressionThreshold

Now, suppose user opened the screen, which had a viewModel which triggered this function, so that a compressed image can be shown.

Before the function could finish compressing the image, user navigated back, at this point, there is no use of the compressed image. So ideally the function should cancel it’s execution.

But if you actually implement it, you will see it won’t cancel itself, it will execute all the way to last statement which prints “Compression Finished”

Don’t believe me?

Check out this manual cancelation

class MainActivity(): AppCompactActivity(){

  override onCreate(..){
  //some other stuff

    lifecycleScope.launch{
        val job = launch{
          BitmapCompressor(this@MainActivity).compressImage(
          //pass URI of the image & threshold
          )
          println("Inner Job Finished")
        }

        delay(1000)
        println("Canceling the job")
        job.cancel()

    }


  }


}

The compression takes around 5 seconds, on my testing device when provided a good size image. And in code, I am canceling the coroutine after one second.
This is my output:

Canceling the job
Compression Finished

It did not print Canceling the job because the job was canceled BUT strangely enough, it printed Compression Finished

BUT WHY??

Check it out here

Dispatchers.IO vs Dispatchers.Default?

Waqas Younis — Tue, 10 Sep 2024 16:15:04 +0000

I recently learnt about this via a very practical example so sharing it here with you guys.

As you may already know, Dispatchers.IO is optimised for IO related operations like Network call or reading a file etc, and Dispatchers.Default is optimised for CPU intensive task.

But why is that?

How do they work under the hood?

Let me share with you an example. Take a look at the following code snippet:

fun dispatchersTester(){

    //keep track of threads used
    val threads = hashMapOf<Long,String>()


    val job = GlobalScope.launch(Dispatchers.Default) {
        repeat(100){
            launch {
                //storing the threads
                threads[Thread.currentThread().id] = Thread.currentThread().name

                //simulate a network call
                Thread.sleep(1_000)
            }
        }
    }

    //Wait for the above job to finish and 
    //measure the duration
    GlobalScope.launch {
        val timeMs = measureTimeMillis {
            job.join()
        }

        Log.d(TAG, "Took ${threads.keys.size} threads and $timeMs ms ")

    }

}

In a nutshell, we are creating 100 coroutines and launching them in Default dispatcher and simulating the network call by adding a sleep of 1 sec.

After running for couple times, the following results were obtained:

Took 4 threads and 25075 ms 
Took 4 threads and 25048 ms 
Took 4 threads and 25060 ms

As you can see, it uses 4 threads at max and took whooping 25 seconds to complete this task.

It means the system launched a batch of 4 threads simultaneously. As we are creating 100 coroutines, 4 threads at a time with a delay of 1 sec takes around 25 seconds.

Now, let’s change the Dispatcher to IO. And check out the results:

Took 64 threads and 2011 ms
Took 64 threads and 2009 ms
Took 64 threads and 2005 ms

This time the system is using 64 threads to complete the task in just 2 seconds.

Which means it’s launching a batch of 64 threads at a time, and as we are only launching 100 coroutines, so it launched two batches, each with delay of 1 sec and completed the task in roughly 2 seconds

Notice how changing only dispatcher brought this huge difference.
Why is that?

IO Dispatcher is optimised for task where the threads go in a state where they trigger something and wait for the result, like a network request. The optimisation is done in a such a way that it allows them to create multiple threads and when a thread reach the pause state, the system resumes execution on the other thread.

Which is not the case with Default Dispatcher.

Let’s see what Dispatchers.Default is good at.

Instead of simulating the network call, let’s simulate a CPU intensive task.

Replace Thread.sleep(1000) with (1..100_000).map{it*it}

It is going from 1 to 100K and computing square of each number.

Let’s run it with Dispatchers.IO:

Took 51 threads and 249 ms
Took 54 threads and 546 ms
Took 57 threads and 402 ms

Now, let’s change the Dispatcher to Default

Took 4 threads and 154 ms
Took 4 threads and 107 ms
Took 4 threads and 121 ms

Even though the actual difference is not much, but still it took half the amount of time than IO dispatcher.

Hope it helps,
Cheers.

Chrome extension to show the status of tasks from Asana to Google Play Console

Waqas Younis — Thu, 15 Aug 2024 21:15:42 +0000

Hello there, being an Android Developer and mostly working on Crashes reported by Google Play Console, I have to go back and forth to keep track of the status of the crash/anr and see who is working on it,

To overcome this problem, I am creating a Chrome extension that would:

Create a task in Asana with a single click, if already not created

Show the task status, like who is working on it, and whether is it in Progress, Completed, or whatever section you create in Asana.

What do you think about it? Is it worth doing? Would you use such a thing?

To overcome this problem, I am creating a Chrome extension that would:

Create a task in Asana with a single click, if already not created
Show the task status, like who is working on it, and whether it is in Progress, Completed, or whatever section you create in Asana.

What do you think about it? Is it worth doing? Would you use such a thing?

Understanding Cohesion

Waqas Younis — Sun, 14 Jul 2024 01:05:12 +0000

I just finished learning about Cohesion and it's part and here is a summary.

What is it?

It is how your module is structured, not how it communicates/integrates with another module. That is a couple.

There are 7 types of Cohesion

The best one is Function Cohesion, where everything that helps do a specific well-defined task is kept in one module. Like an Authentication Module, which offers functionality like login, logout, forgot password, etc

The worst one is Coincidental Cohesion, where there is no specific relation between the elements, except that they are at the same place. Consider a Utility module that has all sort of functions like String Format, Printing Log, Creating New File, etc.

The other ones didn't look interesting to me, they were like different sides of the same coin.

Find something worth solving, not what you can solve.

Waqas Younis — Sun, 14 Jul 2024 00:52:58 +0000

I follow how software and programs were developed back in the day; one of my favorites is the creation of VisiCalc. When the computer keyboard used to have only left and right keys, no up and down keys, they developed a spreadsheet software. Isn't that amazing?

After reading a couple of articles and watching some videos, I wrote the calculation in my personal-tech diary:
"Don't think of it as if the problem is actually solvable by you or not. Or it must be easy, there could be a possibility that you need to go extra mile to bring it to life."
"The only thing you need to think about is that the problem actually exists and people are willing to pay to get it solved" 20th December 2023

Consider it as a signal to start working on the idea that you think it's too big for you.

Cheers.
PS: Pardon my handwriting, I am better at typing. :)