Imagine you have a magical coloring book (the original flow) that can create new coloring pages (inner flows) whenever you want. You have three different ways to color these pages (operators):

1. flatMapConcat: One Page at a Time

This is like coloring one page at a time. Even if the magical book gives you a new page, you’ll finish coloring the current page before moving on to the next one. This way, you color all the pages in the exact order they were given to you.

Kotlin Playground: Edit, Run, Share Kotlin Code Online

import kotlinx.coroutines.flow.*
import kotlinx.coroutines.runBlocking
import kotlinx.coroutines.delay

fun main() = runBlocking {
    val originalFlow = flow {
        emit(1)
        delay(100)
        emit(2)
        delay(100)
        emit(3)
    }

    originalFlow.flatMapConcat { value ->
        flow {
            emit("Page $value: Start coloring")
            delay(200)
            emit("Page $value: Finish coloring")
        }
    }.collect { result ->
        println(result)
    }
}

/*****
Result

Page 1: Start coloring
Page 1: Finish coloring
Page 2: Start coloring
Page 2: Finish coloring
Page 3: Start coloring
Page 3: Finish coloring

*****/

2. flatMapLatest: Always Color the Newest Page

This is like always wanting to color the newest page. If you’re coloring a page and the magical book gives you a new one, you’ll immediately leave the current page, even if it’s not finished, and start coloring the new page. This way, you only focus on the latest page given to you.

Kotlin Playground: Edit, Run, Share Kotlin Code Online

import kotlinx.coroutines.flow.*
import kotlinx.coroutines.runBlocking
import kotlinx.coroutines.delay

fun main() = runBlocking {
    val originalFlow = flow {
        emit(1)
        delay(100)
        emit(2)
        delay(100)
        emit(3)
    }

    originalFlow.flatMapLatest { value ->
        flow {
            emit("Page $value: Start coloring")
            delay(200)
            emit("Page $value: Finish coloring")
        }
    }.collect { result ->
        println(result)
    }
}

/*****
Result

Page 1: Start coloring
Page 2: Start coloring
Page 3: Start coloring
Page 3: Finish coloring

*****/

3. flatMapMerge: Coloring Multiple Pages Simultaneously

This is like being able to color multiple pages at the same time. If the magical book gives you several pages, you can start coloring all of them at once, switching between pages as you wish. This way, you can work on many pages together, finishing them faster.

Kotlin Playground: Edit, Run, Share Kotlin Code Online

import kotlinx.coroutines.flow.*
import kotlinx.coroutines.runBlocking
import kotlinx.coroutines.delay

fun main() = runBlocking {
    val originalFlow = flow {
        emit(1)
        delay(100)
        emit(2)
        delay(100)
        emit(3)
    }

    originalFlow.flatMapMerge(concurrency = 2) { value ->
        flow {
            emit("Page $value: Start coloring")
            delay(200)
            emit("Page $value: Finish coloring")
        }
    }.collect { result ->
        println(result)
    }
}

/*****
Result
​
Page 1: Start coloring
Page 2: Start coloring
Page 1: Finish coloring
Page 3: Start coloring
Page 2: Finish coloring
Page 3: Finish coloring

*****/

Thanks for reading this article. You can learn more about me from here

If you found this article helpful, please recommend it by hitting the clap icon as many times you wish 👏 Let’s enable each other with the power of knowledge.

flatMapConcat vs flatMapMerge vs flatMapLatest — Explained was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Android, everything that appears on the screen undergoes three phases - layout, measurement, and drawing. Ultimately, all views are rendered onto the screen using a Canvas. We can utilize the Canvas to create our own custom views in Android. When it comes to images, Android treats them all as Bitmaps, essentially representations of each pixel on the screen. Think of a bitmap as a blank canvas where the artist creates their art. Fortunately, Android offers basic functionalities for drawing on the canvas, such as drawLine, drawRect, and drawPath. I won’t delve into the specifics of the canvas in this blog post as it’s beyond the scope.

A bitmap can be created with specified height and width, and we can use the canvas object to draw onto the bitmap. We can then convert it into a shareable image, storing it either in publicly accessible directories or our app’s cache.

fun createBitmapFromView(View v): Bitmap {
    val b = Bitmap.createBitmap(v.getLayoutParams().width, v.getLayoutParams().height, Bitmap.Config.ARGB_8888);                
    val c = new Canvas(b);
    v.layout(v.getLeft(), v.getTop(), v.getRight(), v.getBottom());
    v.draw(c);
    return b;
}

//Custom class [repo: amsavarthan/bmi-calculator]
private val cache = Cache(context)

fun saveToCacheAndGetUri(
    bitmap: Bitmap,
    fileNameWithExtension: String
): Uri {
    return cache.saveAndGetUri(bitmap, fileNameWithExtension)
}

The Compose Way

While the onSizeChanged modifier in Jetpack Compose offers one approach to achieve similar functionality, a more efficient method is available using the Picture class, which has been accessible since API Level 1. As outlined in the documentation

A Picture records drawing calls and can then play them back into Canvas. For most content (e.g. text, lines, rectangles), drawing a sequence from a picture can be faster than the equivalent API calls…

class CaptureIntoPicture(
    private val picture: Picture,
    private val drawContent: Boolean = true,
) : DrawCacheModifier {

    private var width: Int = 0
    private var height: Int = 0

    override fun onBuildCache(params: BuildDrawCacheParams) {
        width = params.size.width.toInt()
        height = params.size.height.toInt()
    }

    override fun ContentDrawScope.draw() {
        val pictureCanvas = androidx.compose.ui.graphics.Canvas(
            picture.beginRecording(width, height)
        )

        draw(this, layoutDirection, pictureCanvas, size) internalDraw@{
            this@draw.drawContent()
        }

        picture.endRecording()

        if (!drawContent) return
        drawIntoCanvas { canvas ->
            canvas.nativeCanvas.drawPicture(picture)
        }
    }
}

fun Modifier.captureIntoPicture(picture: Picture, drawContent: Boolean = true): Modifier {
    return this.then(CaptureIntoPicture(picture, drawContent))
}

By simply adding the modifier to the parent of the composable you wish to capture, you can record all draw commands replayed into the bitmap’s canvas, thus obtaining the desired image.

Additionally, you have the option to create a custom composable that won’t be rendered on the screen but will solely serve the purpose of sharing. By setting the drawContent parameter of the modifier to false, you gain the flexibility to distinguish and apply various styles, while also enabling support for previews. This approach enhances customization possibilities and facilitates better management of sharing functionalities within your app.

Sample: https://github.com/amsavarthan/bmi-calculator

In the repository, you’ll find the complete implementation of the custom composable and its integration for sharing purposes, providing a comprehensive example for your reference.

That concludes this article for now. Stay tuned for more intriguing topics in the next blog. Until then, Your friendly neighbourhood Android Developer 👨🏻‍💻💚

Thanks for reading this article. You can learn more about me from here

As of February 7, 2023 - There exists a bug where the drawText function fails to be recorded within the Picture, resulting in the absence of text in the resulting bitmap. https://issuetracker.google.com/issues/323403942

Taking screenshot of a composable — Composable to Bitmap was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Stealing API keys — Security in Android

Disclaimer:
For educational purposes only, I request that you refrain from imitation, and I explicitly state that I will not assume responsibility for any potential issues arising from such actions.

In this blog post, I’ll demonstrate the steps I took to gain access to a vulnerable application and obtain control of its API. To follow along, make sure you have the following tools installed on your system:

Prerequisite:

1. apktool
2. jadx-gui
3. Charles
4. Android Studio (emulator, sdk command line tools)

Backstory:

I have always been curious about how Instagram post downloaders functioned, especially in the early days when appending “?__a=1” to an Instagram URL would yield the complete JSON response, allowing access to the media URLs. However, nowadays, this endpoint simply redirects to the login page. Recently, I discovered that adding “?__a=1&__d=bis” still provides the desired response, but it is restricted to 200 calls per hour and subsequently requires authentication.

While exploring on GitHub, I came across a Python library called instaloader, and upon inspecting its code, I realized it also followed the same procedure mentioned above. Initially, I gave up on my quest, but then I stumbled upon certain web applications and Android apps that could achieve the same goal without requiring login credentials. Intrigued, I sought to understand how they operated.

Analysing network calls proved to be a straightforward task by opening the console in the web browser. However, this approach did not yield a solution due to the use of CORS policies and proxies for internal API calls. As an Android developer, I wished for a tool similar to the network monitor in the web console to scrutinise network requests. This led me to discover Charles Proxy, which allows monitoring of all network calls, even for third-party applications.

Despite multiple attempts, I failed to uncover the inner workings of these tools but unexpectedly embarked on a new learning path in Android development. Join me on this journey, and I will elaborate on the steps in detail.

Overview of the steps:

1. Configuring Charles proxy

Download the tool from the official website. The installation process is straightforward and doesn’t demand extensive knowledge. After installation, launch the application. To stop recording system requests, deactivate your computer’s proxy. On macOS, you can achieve this by navigating to Proxy -> macOS Proxy (disable it).

2. Connecting to proxy

If you don’t have Android studio installed get the latest version from here. Follow the installation steps and configure a new emulator with any android version. You can find the documentation here.

Obtaining our APK file is simple; just install it on your phone. Navigate to the Apps section in Google Files, and share it via email or messaging apps. Afterward, you can transfer it to your system. Drag and drop the apk into the emulator to get it installed.

Go to your Wi-Fi settings in your computer and find your public IP address. Making note of it open the network settings in the emulator and modify the network AndroidWifi by clicking the edit icon at the top.

To confirm whether you’ve done it correctly, you can validate it through the connection request from the Charles Proxy.

If everything is working you can now see requests being made from the emulator showing up. Try using chrome and navigate to any website for confirmation.

3. Enabling SSL proxying

Let’s open the victim application and make a request. You could capture the request but when expanding into it all the data would be encrypted. You will need to decrypt before looking into the content of the request and response.

a. Decompiling the apk

Once you have apktool installed you can use the command to decompile and obtain all of its resources which we will be modifying.

apktool d <app_name>.apk

b. Modifying the network configuration

Save the root certification into the decompiled apk directory app_name -> res -> raw. Rename the file as charles.pem for convenience. Create another file named network_config.xml inside res -> xml folder, If it does not exists.

Modify the AndroidManifest.xml as following by adding the network configuration

c. Building the apk

Once the above configuration is done we can build the apk using the source by executing the following commands.

apktool b <app_name>

You can find the generated apk from <app_name> -> dist -> <app_name>.apk. When you try to install the apk you might get into the following error

Error code: ‘INSTALL_PARSE_FAILED_NO_CERTIFICATES’, message=’INSTALL_PARSE_FAILED_NO_CERTIFICATES: Failed to collect certificates from /data/app/vmdl1372524174.tmp/app.apk: Attempt to get length of null array’

Solution:

You need to execute the following command which aligns and signs the apk using the default debug keystore.

zipalign 4 <build_apk> aligned.apk

apksigner sign --ks ~/.android/debug.keystore --ks-pass pass:android aligned.apk

Once installed you can monitor the requests made from the application once again but now you can enable the SSL proxy to decrypt the requests of the application. To do so you just right click on the request and click Enable SSL Proxy.

4. Stealing the API Secret

Using the jadx cli tool we can look into the compiled code by executing the following command.

jadx-gui <app_name>.apk

Since we now know the api endpoint by monitoring using Charles, We can make a global search to find it. And if you are lucky you could find the secret key hiding over there.

On searching such way I found the application’s auth key (which was constant 🥲). Performing the same for another application I found that they were using JWT keys for authorization but the secret used to generate JWT was easily available.

Certain sensitive data has been obfuscated in the above image until the respective owner has applied the resolution I provided to them to prevent such issue.

In the end, it was a mutually beneficial situation. I discovered how they could extract media links from public Instagram URLs, and they became aware of a security flaw, which will be the focus of my next blog. Until then, Your friendly neighbourhood Android Developer 👨🏻‍💻💚

Thanks for reading this article. You can learn more about me from here

If you found this article helpful, please recommend it by hitting the clap icon as many times you wish 👏 Let’s enable each other with the power of knowledge.

Stealing API keys — Security in Android was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many developers frequently ask about the usage of sealed classes and enums and when to use them. To address this question, it is important to understand the concept of sealed classes.

Sealed classes are a specialized form of abstract classes that allow the definition of abstract functions. They enable other classes to inherit from them and create their own class definitions, but with the constraint that these derived classes must remain within the scope of the sealed class. This characteristic makes sealed classes especially useful during the compilation process. Here is an example of sealed classes

sealed class Month(val shortName: String, val numberOfDays: Int) {
    data object January : Month("Jan", 31)
    data object February : Month("Feb", 28)
    data object March : Month("Feb", 31)
    //Other months
}

On the other hand, enums are used to define constants by providing names for different months. Here is an example of an enum class:

enum class MonthEnum(val shortName: String, val numberOfDays: Int) {
    January("Jan", 31),
    February("Feb", 28),
    March("Mar", 31)
    //Other months
}

Both sealed classes and enums can be accessed using “when” statements, and suggestions are provided for each case, such as the quick action to add remaining branches.

What is the difference if everything is the same?

When using sealed classes, you have more flexibility compared to enums. In addition to creating objects, you can also create data classes inside them, allowing you to provide class-specific parameters, which can be very useful. Here’s an example (inspired from this video):

sealed class HttpError(val code: Int) {
    data class Unauthorized(val reason: String) : HttpError(401)
    object NotFound : HttpError(404)
}

However, this is not possible with enum classes. Therefore, sealed classes are preferred in such cases.

Additionally, one notable distinction between enums and sealed classes is in accessing their values. Enums inherently offer direct access to all their values as a list, simplifying iteration. This convenience arises from their nature as constants. Conversely, sealed classes require the explicit definition of a function to obtain the list of declared classes. This function retrieves the classes within the sealed class hierarchy.

//This provides an array of all the values in the enum
MonthEnum.values()

What about sealed interface?

According to the official Kotlin documentation, sealed interfaces are not significantly more complex to understand. The only difference is that classes implementing the interface must be in the same file. The decision of when to use them is straightforward. Sealed interfaces are suitable when the parent classes within the sealed class do not have any constructor parameters. Here’s a sample use case commonly employed in many applications:

sealed interface Result<out T> {

    data class Success<T>(val data: T) : Result<T>

    data class Error(val exception: Throwable) : Result<Nothing>

}

Based on the different cases, here are the suggested preferences for usage. When easy iteration over values is desired and all cases share a common parameter, it is recommended to use enum classes. On the other hand, for scenarios where flexibility is required, sealed classes or interfaces can be chosen based on the specific use case.

Recently, I launched a campaign called “WebWonders” where I offered website building services starting from just ₹599. However, as an individual running this campaign, I encountered some challenges in effectively managing clients and providing personalized pricing for their specific requirements. I had set clear and impactful goals for my management process:

1. Upon submission of the form, I aimed to curate a personalized price based on the responses, particularly for questions that required a yes/no answer.
2. The curated price would then be sent directly to the user’s email, ensuring a seamless and efficient communication flow.

Despite my initial lack of knowledge on how to achieve those goals, I decided to use Google Forms due to its seamless integration with Google Sheets for gathering client requirements. However, during the process of creating the form, I stumbled upon something intriguing

Yes, I understand. Even though the “Script Editor” feature has been around for a while, it can still be quite intriguing when you first come across it. When I encountered it for the first time, with all these ideas running through my mind, I couldn’t help but ponder the various possibilities of how I could leverage its potential.

However, upon clicking it, I realized that the interface was unfamiliar to me, and I wasn’t sure what steps to take next. But after going through the documentation and exploring resources available online, I was able to gain a better understanding of how to utilize the “Script Editor” effectively. It provided me with a powerful tool to extend the functionality of Google Forms and achieve my goals.

Curating a personalized price for an Individual

 function onFormSubmit() {
  var sheet = SpreadsheetApp.openById("sheet-id").getSheetByName("sheet-name");
  if (sheet!=null) { 
    const orderNumber = insertOrderNumber(sheet)
    Logger.log("Processing order "+ orderNumber)

    const lastRow = sheet.getLastRow();
    const lastColumn = sheet.getLastColumn()
    const lastEntry = sheet.getRange(lastRow, 1, 1, lastColumn).getValues()[0];
    const price = calculatePrice(lastEntry)
    Logger.log("Calculated price is "+ price)
  }
}

function insertOrderNumber(sheet){
  const orderNumber = sheet.getLastRow()-1; 
  const lastCell = sheet.getRange(`A${orderNumber+1}`);
  lastCell.setValue(orderNumber)
  return orderNumber
}

function calculatePrice(entry){
  const isCodeHandoverRequired = entry[12] === "Yes"
  const isQuickDeliveryRequired = entry[13]

  //Calculate the cost
  let baseFare = 599
  if(isQuickDeliveryRequired) baseFare+=499
  if(isCodeHandoverRequired) baseFare+=999

  return baseFare
}

This function, onFormSubmit, is triggered when a form is submitted. It assumes there is a Google Spreadsheet with a specific ID ("sheet-id") and a sheet name ("sheet-name"). It performs the following steps:

1. Open the spreadsheet
2. Insert the order number
3. Get the entries from the sheet and calculate the price accordingly

Sending the email

function sendEmail(name, email, orderNumber, price){

    if(MailApp.getRemainingDailyQuota()===0){
      Logger.log("Mail quota exhausted")
      return false
    }

    Logger.log("Sending mail...")

    var template = HtmlService.createTemplateFromFile("MailTemplate")
    template.orderNumber = orderNumber
    template.name = name
    template.price = price
    var message = template.evaluate().getContent()

    //Send from my alias mail
    var alias = GmailApp.getAliases()
    GmailApp.sendEmail(email ,`Webwonders Order #${orderNumber}`,message,{from:alias[0],name:"Amsavarthan LV",htmlBody:message, noReply:true})

    //Send mail without alias
    //GmailApp.sendEmail(email ,`Webwonders Order #${orderNumber}`,message)

    Logger.log(`Remaining quota : ${MailApp.getRemainingDailyQuota()}`)
    Logger.log(`Mail sent to ${name} for order id ${orderNumber}`)
    return true
}

<!DOCTYPE html>
<html>
  <head>
    <base target="_top">
    <title>WebWonders Order #<?= orderNumber ?></title>
  </head>
  <body>
    <p>Dear <?= name ?>,</p>
    <p>I am pleased to inform you that your response has been received.</p>
    <p>Your personalized website service costs <b>₹<?= cost?></b>.</p>
    <p>Best Regards,<br/>Your friendly neighbourhood developer</p>
    <p>Amsavarthan LV</p>
  </body>
</html>

This function checks the remaining email quota, creates an HTML template, populates it with order information, and sends the email using GmailApp. The function logs the remaining quota and the successful email sending.

By leveraging Google Forms and the “Script Editor,” I overcame initial challenges, improved client management, and provided personalized pricing. The “WebWonders” campaign benefitted from these streamlined processes, enhancing its overall success.

In this blog we will be discussing on the following topics:

• Suspend modifier
• Coroutine scopes
• Coroutine context
• Coroutine builders

Whether you are looking to review or update your existing knowledge, or learn something completely new, this guide will be a valuable resource for you.

The Suspend Modifier

a suspend function is a function that can be paused and resumed at specific points during its execution, without blocking the thread it is running on. To create a suspend function, you simply need to add the suspend modifier before the function signature.

For example, let’s say we have a function that performs a time-consuming task, such as fetching data from a remote server:

fun fetchDataFromServer() {
    // Perform time-consuming task here
}

If we want to make this function suspendable, we simply add the suspend modifier like this:

suspend fun fetchDataFromServer() {
    // Perform time-consuming task here
}

What does the suspend modifier tells us?

When we use suspending functions we don’t block the underlying thread. Each suspendable function is responsible for specific computation which may takes some time to be completed so we allow to pause its execution for some time to release the thread for other tasks and when the computation it’s completed we resume it.

Points to remember:

• Suspend functions can be invoked only inside another suspend function or a coroutine builders
• A suspend function will only return once its execution is complete, meaning that any code following a call to a suspend function will not be executed until the function has finished running.

Best practices in Android:

• Do not expose a suspend function to UI (Activities/Fragments) from ViewModels.

Coroutine Scopes

When working with coroutines, it’s important to keep track of their lifecycle and ensure that they are properly managed.

This is where coroutine scopes come in. A coroutine scope is a way to manage the lifecycle of a set of coroutines. It provides a structured concurrency model that allows you to launch and cancel coroutines as a group.

In Android we have the following scopes available to use

• GlobalScope — This is a scope that is used to launch top-level coroutines which are operating on the whole application lifetime and are not cancelled prematurely.
• LifecycleScope — This is a scope that is tied to the lifecycle of a specific component, such as an activity or fragment. It provides a way to launch coroutines that are automatically cancelled when the component is destroyed.
• ViewModelScope — This is a scope that is tied to the lifecycle of a ViewModel. It is designed to be used in ViewModel classes, and provides a way to launch coroutines that need to run for the duration of the ViewModel’s lifecycle.

Points to remember:

• When ever you create a coroutine it gets attached to a special instance of coroutine scope. Regardless of being a parent or a child coroutine each one has its own unique coroutine scope.

runBlocking { //this refers to an instance of Coroutine Scope
  println("$this")
  launch { //this refers to another instance of Coroutine Scope
    println("$this")
  }
  
  async { //this refers to another instance of Coroutine Scope 
    println("$this")
  }
}

// Output:
//   BlockingCoroutine{Active}@1f89ab83
//   StandaloneCoroutine{Active}@64cee07
//   DeferredCoroutine{Active}@6f79caec

Best practices in Android:

• Do not make use of GlobalScope unless required. It is easy to accidentally create resource or memory leaks when GlobalScope is used.

Coroutine Context

Think of it as a set of rules that tell the coroutine where and how to run. One of the most important rules is the dispatcher, which determines the thread that the coroutine runs on.

By default, there are several dispatchers like Dispatchers.Default, Dispatchers.IO, and Dispatchers.Main, which can be used depending on the requirements of the application.

In addition to the dispatcher, other rules can be added to the CoroutineContext, such as the job that the coroutine is doing and how to handle any exceptions that might occur.

When to use specific dispatchers?

Here are some guidelines to help you decide which dispatcher to use:

1. Dispatchers.Default : This is the dispatcher that is used by default if you don’t specify any other dispatcher. It is optimized for CPU-intensive work and is best suited for computations, sorting, and other similar tasks.
2. Dispatchers.IO : This dispatcher is optimized for IO-bound tasks such as network requests and disk operations. It is best used when you are doing anything that involves waiting for a result from an external system.
3. Dispatchers.Main : This is the dispatcher that is used for UI-related work. It ensures that the coroutine runs on the main thread of the application, which is necessary for updating the UI and handling user input.

Best practices in Android:

• IO dispatcher for any network requests or disk operations
• Default dispatcher for any CPU-intensive work
• Main dispatcher for any UI-related work.

Coroutine Builders

To invoke a suspend function, it must be called from another suspend function. This creates a chain of suspending functions that must be started with a coroutine builder. The coroutine builder acts as a bridge, allowing for the execution of suspending functions within a coroutine, and connecting the normal and suspending worlds of code.

There are several coroutine builders available each with its own unique features and use cases. Here are some of the most commonly used coroutine builders:

1. launch: This coroutine builder launches a new coroutine and returns a Job object that can be used to control the coroutine's lifecycle.
2. async: This coroutine builder launches a new coroutine and returns a Deferred object that represents a value that may not be available yet. The Deferred object can be used to retrieve the value once it becomes available, and can also be used to control the coroutine's lifecycle.
3. withContext: This coroutine builder switches the coroutine's context to a different thread or thread pool. It can be used to perform operations that may block the current thread, such as file I/O or network requests.
4. runBlocking: This coroutine builder blocks the current thread until the coroutine it launches is completed.

Differences between launch and async

• launch is used for running a coroutine without returning any result, while async is used for running a coroutine that returns a result.
• launch is non-blocking and doesn't wait for the coroutine to finish, while async is blocking and waits for the coroutine to finish before moving on.
• async provides an easy way to handle exceptions thrown by a coroutine, while launch does not.

Points to remember:

• In launch, any exception thrown by a coroutine is thrown immediately, whereas with async, the exception is not thrown until await is called.

Best practices in Android:

• runBlocking — Should be used only for unit tests and not in production.
• If you have multiple requests that are independent of each other, you can run them concurrently using async to improve the performance.

Here’s an example that includes all the concepts we’ve discussed so far:

class MainActivity : AppCompatActivity() {

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

        // Start a new coroutine with IO thread
        lifecycleScope.launch(Dispatchers.IO) {
            // Perform a time-consuming operation
            val result = performTimeConsumingOperation()
    
            // Switch back to the UI thread
            withContext(Dispatchers.Main) {
                // Update the UI with the result
                updateUI(result)
            }
        }
    }
}

suspend fun performTimeConsumingOperation(): String {
    // Perform a time-consuming operation
    delay(5000)

    // Return the result
    return "Operation completed"
}

fun updateUI(result: String) {
    // Update the UI with the result
}

In this example, we start a new coroutine using the launch coroutine builder, and then calls the performTimeConsumingOperation() function. This function is marked as suspendable, so it can be called from within a coroutine. It uses the delay function to simulate a time-consuming operation, and then returns a result.

Once the result is available, the coroutine switches back to the main thread using the withContext coroutine builder, and calls the updateUI() function to update the UI with the result.

Additional Resources

• https://kotlinlang.org/docs/coroutines-overview.html
• https://developer.android.com/kotlin/coroutines
• https://developer.android.com/kotlin/coroutines/coroutines-best-practices
• https://developer.android.com/kotlin/coroutines/additional-resources

Thanks for reading. You can connect with me on LinkedIn, Twitter, and Instagram.

If you found this guide helpful, please recommend it by hitting the clap icon as many times you wish 👏

Let’s enable each other with the power of knowledge.

Have you ever inherited a codebase that made you want to pull your hair out? Or have you ever written code that you knew was going to be a nightmare to maintain? As developers, we’ve all been there.

One of the keys to writing maintainable, flexible, and reusable code is to follow the SOLID principles. In this blog post, we’ll explore how SOLID principles can help you write better code in Kotlin, and we’ll walk through some code examples to show you how to apply these principles in practice.

By the end of this article, you’ll have a solid understanding of the SOLID principles and how they can help you become a better developer. So let’s get started!

S — Single Responsibility Principle

The Single Responsibility Principle (SRP) states that each class or module should have only one responsibility. This means that a class or module should do one thing and do it well. If a class or module has more than one responsibility, it becomes harder to maintain and change over time.

Here’s an example of a class that violates the SRP:

class UserService {
    fun registerUser(username: String, password: String) {
        // validation logic
        // database insert logic
        // email sending logic
    }
}

This class has three responsibilities — validating user input, inserting the user into the database, and sending an email. This violates the SRP because if any one of these responsibilities needs to be changed, the entire class needs to be modified.

Here’s an example of how to refactor this class to follow the SRP:

class UserValidator {
    fun validate(username: String, password: String): Boolean {
        // validation logic
    }
}

class UserRepository {
    fun saveUser(username: String, password: String) {
        // database insert logic
    }
}

class EmailService {
    fun sendEmail(to: String, subject: String, body: String) {
        // email sending logic
    }
}

class UserService(
    private val userValidator: UserValidator,
    private val userRepository: UserRepository,
    private val emailService: EmailService
) {
    fun registerUser(username: String, password: String) {
        if (!userValidator.validate(username, password)) {
            // handle validation error
            return
        }

        userRepository.saveUser(username, password)

        emailService.sendEmail(username, "Welcome to our app", "Thanks for registering!")
    }
}

In this refactored code, each class has only one responsibility — validating user input, inserting the user into the database, and sending an email. The UserService class now depends on these three classes instead of having all the responsibilities itself.

O — Open-Closed Principle

The Open-Closed Principle (OCP) states that classes or modules should be open for extension, but closed for modification. This means that you should be able to add new functionality to a class or module without changing its existing code.

Here’s an example of a class that violates the OCP:

class PaymentService {
    fun processPayment(paymentMethod: String, amount: Double) {
        when (paymentMethod) {
            "creditCard" -> {
                // credit card processing logic
            }
            "paypal" -> {
                // PayPal processing logic
            }
        }
    }
}

This class violates the OCP because if a new payment method needs to be added, the processPayment method needs to be modified. Instead, we can use the Strategy pattern to make this class extensible:

interface PaymentMethod {
    fun processPayment(amount: Double)
}

class CreditCardPayment : PaymentMethod {
    override fun processPayment(amount: Double) {
        // credit card processing logic
    }
}

class PaypalPayment : PaymentMethod {
    override fun processPayment(amount: Double) {
        // PayPal processing logic
}

class PaymentService(
  private val paymentMethod: PaymentMethod
) {

    fun processPayment(amount: Double) {
        paymentMethod.processPayment(amount)
     }

}

In this refactored code, we have created an interface called PaymentMethod that defines a processPayment method. We have then created two classes, CreditCardPayment and PaypalPayment that implement the PaymentMethod interface. Finally, we’ve refactored the PaymentService class to take an instance of PaymentMethod in its constructor, so we can pass in any implementation of PaymentMethod at runtime.

L — Liskov Substitution Principle

The Liskov Substitution Principle (LSP) states that objects of a superclass should be able to be replaced with objects of a subclass without affecting the correctness of the program. This means that subclasses should be able to be used in place of their parent classes without breaking the code.

Here’s an example of a class hierarchy that violates the LSP:

open class Shape {
    open fun area(): Double = 0.0
}

class Rectangle(
    private val width: Double,
    private val height: Double
) : Shape() {
    override fun area(): Double = width * height
}

class Square(
    private val side: Double
) : Shape() {
    override fun area(): Double = side * side
}

This class hierarchy violates the LSP because a Square cannot be used in place of a Rectangle - if we try to create a Square with a width and height that are different, we'll get an incorrect area.

Here’s an example of how to refactor this class hierarchy to follow the LSP:

interface Shape {
    fun area(): Double
}

class Rectangle(
    private val width: Double,
    private val height: Double
) : Shape {
    override fun area(): Double = width * height
}

class Square(
    private val side: Double
) : Shape {
    override fun area(): Double = side * side
}

In this refactored code, we’ve created an interface called Shape that defines a area method. Both Rectangle and Square implement this interface, so they can be used interchangeably.

I — Interface Segregation Principle

The Interface Segregation Principle (ISP) states that clients should not be forced to depend on interfaces they don’t use. This means that interfaces should be designed with the specific needs of their clients in mind, and clients should not be required to implement methods they don’t need.

Here’s an example of a class hierarchy that violates the ISP:

interface Car {
    fun startEngine()
    fun stopEngine()
    fun drive()
    fun reverse()
}

class Sedan : Car {
    override fun startEngine() { ... }
    override fun stopEngine() { ... }
    override fun drive() { ... }
    override fun reverse() { ... }
}

class SportsCar : Car {
    override fun startEngine() { ... }
    override fun stopEngine() { ... }
    override fun drive() { ... }
    override fun reverse() { ... }
}

This class hierarchy violates the ISP because not all clients of the Car interface need to implement the reverse method. For example, a client that only needs to drive the car forward would be forced to implement the reverse method, even though it's not needed.

Here’s an example of how to refactor this class hierarchy to follow the ISP:

interface Car {
    fun startEngine()
    fun stopEngine()
    fun drive()
}

interface ReverseableCar : Car {
    fun reverse()
}

class Sedan : Car {
    override fun startEngine() { ... }
    override fun stopEngine() { ... }
    override fun drive() { ... }
}

class SportsCar : ReverseableCar {
    override fun startEngine() { ... }
    override fun stopEngine() { ... }
    override fun drive() { ... }
    override fun reverse() { ... }
}

In this refactored code, we’ve split the Car interface into two separate interfaces - Car and ReverseableCar. The Car interface only includes methods that all clients need to implement, while the ReverseableCar interface includes the additional reverse method. Clients that only need to drive the car forward can use the Car interface, while clients that need to drive the car in both directions can use the ReverseableCar interface.

D — Dependency Inversion Principle

The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules. Instead, both should depend on abstractions. This means that modules should be designed to depend on abstract interfaces or classes, rather than concrete implementations.

Here’s an example of a class hierarchy that violates the DIP:

class UserService {
    private val userRepository = UserRepository()

    fun createUser(user: User) {
        userRepository.save(user)
    }
}

class UserRepository {
    fun save(user: User) {
        // save the user to the database
    }
}

This class hierarchy violates the DIP because the UserService depends directly on the UserRepository class, which is a low-level module. If we later decide to change the way users are stored (e.g. switch to a different database or a web service), we'll need to change the UserService class as well.

Here’s an example of how to refactor this class hierarchy to follow the DIP:

interface UserRepository {
    fun save(user: User)
}

class UserService(
    private val userRepository: UserRepository
) {
    fun createUser(user: User) {
        userRepository.save(user)
    }
}

class DatabaseUserRepository : UserRepository {
    override fun save(user: User) {
        // save the user to the database
    }
}

In this refactored code, we’ve created an abstract UserRepository interface that defines the methods that the UserService needs. We've also created a DatabaseUserRepository class that implements the UserRepository interface and provides the concrete implementation of the save method.

Now, the UserService class depends only on the abstract UserRepository interface, rather than the concrete UserRepository class. This makes the code more flexible and easier to maintain, because we can swap out the DatabaseUserRepository class with a different implementation (e.g. a web service implementation) without needing to change the UserService class.

Advice to Fellow developers

In summary, the SOLID principles are a set of guidelines for writing flexible, maintainable, and reusable code. By following these principles, we can write code that is easier to test, easier to maintain, and less prone to bugs.

While the examples in this article were written in Kotlin, the SOLID principles are applicable to any object-oriented programming language. If you’re new to SOLID, start by focusing on the Single Responsibility Principle, which is the most important of the five principles. Once you’ve mastered SRP, you can move on to the other principles and start applying them to your own code.

SOLID is not a set of hard-and-fast rules — it’s a set of guidelines that can help you write better code. As with any set of guidelines, there will be times when you need to break the rules in order to achieve your goals. But by following the SOLID principles whenever possible, you’ll be able to write code that is more robust, more maintainable, and more reusable.

Thanks for reading this article. You can connect with me on LinkedIn, Twitter, and Instagram.

If you found this article helpful, please recommend it by hitting the clap icon as many times you wish 👏 Let’s enable each other with the power of knowledge.

When working on an Android project, it’s important to understand the difference between the api and implementation configurations in Gradle. These configurations determine how dependencies are handled within the project and can affect the overall structure and performance of the app.

The api configuration is used to declare dependencies that are exposed to consumers of the module. This means that other modules in the project that depend on this one will have access to the classes and methods provided by the api dependencies. For example, if we have a module called library and we want other modules to be able to use the classes and methods provided by the Retrofit library, we would add the following line to the library’s build.gradle file:

api("com.squareup.retrofit2:retrofit:2.9.0")

On the other hand, the implementation configuration is used to declare dependencies that are only used within the module and not exposed to consumers. These dependencies are not available to other modules and are only used by the module itself. For example, if we have a module called app and we want to use the classes and methods provided by the OkHttp library, we would add the following line to the app’s build.gradle file:

implementation("com.squareup.okhttp3:okhttp:4.9.0")

It’s important to note that you can use both api and implementation configuration in the same module, it depends on the use case.

In summary, when declaring dependencies in an Android Gradle script, use the api configuration for dependencies that need to be exposed to other modules and use the implementation configuration for dependencies that are only used within the module. This will help maintain a clean and organized project structure and improve the performance of the app.

Thanks for reading this article. You can connect with me on LinkedIn, Twitter, and Instagram.

If you found this article helpful, please recommend it by hitting the clap icon as many times you wish 👏 Let’s enable each other with the power of knowledge.

Gradle is a powerful build tool that allows developers to easily manage dependencies and configure builds for their projects. However, as projects grow in size and complexity, it can become difficult to maintain and reuse build configurations. This is where Gradle convention plugins come in.

Convention plugins are a way to encapsulate and reuse common build configuration in Gradle. They allow developers to define a set of conventions for a project or module, and then apply those conventions to other projects or modules. This can greatly simplify build management and increase efficiency.

One of the most powerful features of convention plugins is that they can be written in Kotlin, a modern programming language that runs on the Java Virtual Machine. Kotlin provides a number of features that make it well-suited for writing Gradle plugins, such as strong type safety, a concise syntax, and improved support for functional programming.

Creating a convention plugin

plugins { //PluginDependenciesSpecScope
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
}

android { //BaseAppModuleExtension
    compileSdk = 33

    defaultConfig { //ApplicationDefaultConfig
        minSdk = 21
    }

    compileOptions { //CompileOptions
        sourceCompatibility = JavaVersion.VERSION_1_8
        targetCompatibility = JavaVersion.VERSION_1_8
        isCoreLibraryDesugaringEnabled = true
     }
}

dependencies { //DependencyHandlerScope
    implementation("com.android.tools:desugar_jdk_libs:1.2.2")
    //Some more common dependencies used by all libraries we create
}

Consider the above configuration which we needs to be added to each and every library module we create. With the help of convention plugins we can eliminate the boilerplate code.

Let’s first create a folder called build-logic inside which resides the convention module, which can be used to keep a single source of truth for common module configurations.

Paste the following code in AndroidLibraryConventionPlugin.kt

class AndroidLibraryConventionPlugin : Plugin<Project> {
    override fun apply(target: Project) {
        with(target) {
            with(pluginManager) {
                apply("com.android.library")
                apply("org.jetbrains.kotlin.android")
            }

            extensions.configure<LibraryExtension> {
                configureKotlinAndroid(this)
                defaultConfig.targetSdk = 33
            }
        }
    }
}

internal fun Project.configureKotlinAndroid(
    commonExtension: CommonExtension<*, *, *, *>,
) {

    commonExtension.apply {
        compileSdk = 33

        defaultConfig {
            minSdk = 21
        }

        compileOptions {
            sourceCompatibility = JavaVersion.VERSION_1_8
            targetCompatibility = JavaVersion.VERSION_1_8
            isCoreLibraryDesugaringEnabled = true
        }
    }

    //version catalog
    val libs = extensions.getByType<VersionCatalogsExtension>().named("libs")

    dependencies {
        add("coreLibraryDesugaring", libs.findLibrary("android.desugarJdkLibs").get())
    }

}

To share dependency versions between project we can make use of Gradle version catalog. You can learn more about it from the official documentation here.

The above code has nothing different instead the same gradle script configuration written purely as a Kotlin class. Make sure to import classes from org.gradle package

Then, configure the settings.gradle.kts in the convention module

dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
    versionCatalogs {
        create("libs") {
            from(files("../gradle/libs.versions.toml"))
        }
    }
}

rootProject.name = "build-logic"
include(":convention")

Then, we need to provide gradle the details of our plugins. Inside build.gradle.kts (:build-logic:convention)

plugins {
    `kotlin-dsl`
}

group = "com.amsavarthan.buildlogic"

java {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
}

dependencies {
    compileOnly(libs.android.gradlePlugin)
    compileOnly(libs.kotlin.gradlePlugin)
}

gradlePlugin{
    plugins{
        register("androidLibrary"){
            id="amsavarthan.android.library"
            implementationClass="AndroidLibraryConventionPlugin"
        }
    }
}

The libs.versions.toml must have the following

[versions]
androidDesugarJdkLibs = "1.2.2"
androidGradlePlugin = "7.3.1"
kotlin = "1.8.0"

[libraries]
android-gradlePlugin = { group = "com.android.tools.build", name = "gradle", version.ref = "androidGradlePlugin" }
android-desugarJdkLibs = { group = "com.android.tools", name = "desugar_jdk_libs", version.ref = "androidDesugarJdkLibs" }
kotlin-gradlePlugin = { group = "org.jetbrains.kotlin", name = "kotlin-gradle-plugin", version.ref = "kotlin" }

Including in our project

Once the above configuration is done, we can include the plugins into our project by following the below steps. First in our settings.gradle.kts (project level) we need to include our build-logic.

pluginManagement {
    //Include this line
    includeBuild("build-logic")

    repositories {
        //...
    }
}
dependencyResolutionManagement {
    //...
}
rootProject.name = "sample"
include(":app")
//...

In all your libraries we can just make use of the plugin we just created. This is how a module’s build.gradle.kts would usually look with the plugin.

plugins {
    id("amsavarthan.android.library")
}

//Remove block if module doesn't have any extra dependencies
dependencies {
    //module-specific dependencies
}

FYR: Now in Android

You can checkout the Now in Android (NiA) project which uses this approach.

These plugins are additive and composable, and try to only accomplish a single responsibility. Modules can then pick and choose the configurations they need.

Some really good examples from the codebase that show how this is all tied together are the following:

1. The AndroidLibraryConventionPlugin applies the com.android.library and org.jetbrains.kotlin.android plugins, uses the configureKotlinAndroid() function from KotlinAndroid.kt to configure things like your compileSdk , compileOptions, kotlinOptions, and the configureFlavors() function from the Flavor.kt file to configure project flavors.
2. The AndroidFeatureConventionPlugin applies the same plugins from above plus org.jetbrains.kotlin.kapt because all features modules in NiA use libraries like Hilt which require KAPT for code generation. It also adds a lot of common dependencies like the :core modules and some libraries.
3. The AndroidLibraryComposeConventionPlugin uses the configureAndroidCompose() function to configure Compose to work in any module it’s applied to.

The result is a feature module build scrips mostly end up looking like this, which is how they should. No duplication or unnecessary scripts that are hard to understand down the line. Just the things that a module needs.

plugins {
    id("nowinandroid.android.feature")
    id("nowinandroid.android.library.jacoco")
    id("nowinandroid.android.library.compose")
}

dependencies {
    // module-specific dependencies
}

You can immediately see what it means for these plugins to be additive and composable. Want a module that doesn’t use Compose? Just apply the first two plugins. Want to use Compose? Just add the third one.

Thanks for reading this article. You can connect with me on LinkedIn, Twitter, and Instagram.

If you found this article helpful, please recommend it by hitting the clap icon as many times you wish 👏 Let’s enable each other with the power of knowledge.

Cross platform annotations are rather confusing at first glance!

This short article shows you how to work with KMM (Kotlin Multiplatform Mobile) cross-platform annotations, implement a custom @TypeParceler for Android Parcelable interface in a KMM project for any Type or Class including primitives.

The biggest hurdle in implementing cross-platform entities in KMM is properly defining the annotations and setting up the implementation and the “stubs” for each platform. Code needs to be implemented on one platform and ignored on the other platform.

I will show how to implement the Parcelable interface for Android, and stub the Parcelable interface for iOS (so it is properly ignored), as iOS does not need or useParcelable.

In this example, I will use the non-natively parcelable class of LocalDateTime , from the shared Kotlin-native kotlinx-datetime library, as the example of non-primitive ‘Parcelable’ class. After seeing this example, its straightforward to use any non-primitive class, just change the implementation and add the appropriate @TypeParceler .

On Android, this code is very necessary to prevent crashes when the Android app is put into the background, as the Parceler is automatically run (on Android) to save state. Without this implementation, your app will crash when your domain models have custom class types. The iOS platform does not use a Parceler , so it needs to be stubbed out.

Using primitive data types is rather straightforward as you only stub/implement the Parcelable interface and the @Parcelize annotation.

In this article I go a step further and show you how to implement a custom@TypeParceler to use a non-primitive class Parceler. In this example we are making a @TypeParceler for LocalDateTime.

Adding Dependencies

Go to build.gradle.kts in the shared module and add the dependency for kotlix-datetime and kotlin parcelize plugin

plugins {
    kotlin("multiplatform")
    id("com.android.library")
    id("kotlin-parcelize") // add this
    kotlin("plugin.serialization") version "1.5.30" // add this
    //...
}
kotlin {

    android()
    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach {
        it.binaries.framework {
           baseName = "shared"
        }
    }

    sourceSets {
        val commonMain by getting {
        dependencies {
           implementation("org.jetbrains.kotlinx:kotlinx-datetime:0.4.0") // add this
           implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.4.1")
        }
        //...
    }
        //...
  }
    //...
}

Now lets modify the code in Platform.kt file of common module

import kotlinx.datetime.LocalDateTime

@OptIn(ExperimentalMultiplatform::class)
@OptionalExpectation
@Target(AnnotationTarget.CLASS)
@Retention(AnnotationRetention.BINARY)
expect annotation class CommonParcelize()

expect interface CommonParcelable

@OptIn(ExperimentalMultiplatform::class)
@OptionalExpectation
@Retention(AnnotationRetention.SOURCE)
@Repeatable
@Target(AnnotationTarget.CLASS, AnnotationTarget.PROPERTY)
expect annotation class CommonTypeParceler<T, P : CommonParceler<in T>>()

expect interface CommonParceler<T>

expect object LocalDateTimeParceler: CommonParceler<LocalDateTime>

Now, open the Platform.kt file of android module and let’s add our actual implementation

import android.os.Parcel
import android.os.Parcelable
import kotlinx.datetime.LocalDateTime 
import kotlinx.datetime.toLocalDateTime
import kotlinx.parcelize.Parceler // NOTE: kotlinx.parcelize.*
import kotlinx.parcelize.Parcelize
import kotlinx.parcelize.TypeParceler

actual typealias CommonParcelize = Parcelize // defined on Android, skipped on iOS
actual typealias CommonParcelable = Parcelable // defined on Android, skipped on iOS

actual typealias CommonParceler<T> = Parceler<T> // defined on Android, skipped on iOS
actual typealias CommonTypeParceler<T,P> = TypeParceler<T, P> // defined on Android, skipped on iOS

// Performs the type conversion to/from a Parcelable supported type (primitives only)
actual object LocalDateTimeParceler : Parceler<LocalDateTime> {  // defined on Android, skipped on iOS
  override fun create(parcel: Parcel): LocalDateTime {
    val date = parcel.readString()
    return date?.toLocalDateTime()
      ?: LocalDateTime(0, 0, 0, 0, 0)
  }
  override fun LocalDateTime.write(parcel: Parcel, flags: Int) {
    parcel.writeString(this.toString())
  }
}

Modify the Platform.kt file in the ios module as follows

import kotlinx.datetime.LocalDateTime

// Note: no need to define CommonParcelize here because it is @OptionalExpectation
actual interface CommonParcelable // not used on iOS

// Note: no need to define CommonTypeParceler<T,P : CommonParceler<in T>> here because it is @OptionalExpectation
actual interface CommonParceler<T> // not used on iOS
actual object LocalDateTimeParceler : CommonParceler<LocalDateTime> // not used on iOS

Implementing into data classes

I have created a sample data class which has the following members. Let’s annotate with our custom annotation that we have defined to tell android that this needs to be aliased by Parcelable interface

import com.amsavarthan.note.domain.CommonParcelable
import com.amsavarthan.note.domain.CommonParcelize
import com.amsavarthan.note.domain.CommonTypeParceler
import com.amsavarthan.note.domain.LocalDateTimeParceler
import com.amsavarthan.note.domain.time.DateTimeUtil
import kotlinx.datetime.LocalDateTime
import kotlinx.datetime.serializers.LocalDateTimeIso8601Serializer
import kotlinx.serialization.Serializable

@Serializable
@CommonParcelize
data class Note(
    val id: Long? = null,
    val title: String = "Untitled",
    val content: String = "",
    @Serializable(with = LocalDateTimeIso8601Serializer::class)
    @CommonTypeParceler<LocalDateTime, LocalDateTimeParceler>()
    val created: LocalDateTime = DateTimeUtil.now()
) : CommonParcelable

Given this code example you are able to readily extend it for any custom type that needs to use @Parcelize, as well as implement cross platform annotations for other parts of Android and iOS code.

You can checkout the sample project demonstration the usage of the above.

GitHub - amsavarthan/NotesKmm: 🗒️ A minimal Notes app built using KMM and SQLDelight with Jetpack Compose for Android and SwiftUI for iOS following Clean Architecture

Thanks for reading this article. You can connect with me on LinkedIn, Twitter, and Instagram.

If you found this article helpful, please recommend it by hitting the clap icon as many times you wish 👏 Let’s enable each other with the power of knowledge.