Short Excerpts

When working with strings in Kotlin, you may encounter scenarios where you need to find the first character that does not repeat. This problem is common in text processing, competitive programming, and software development.

In this blog, we’ll walk through an efficient approach to finding the first non-repeating character in a string using Kotlin. We’ll also explore a detailed explanation of the logic, why it works, and how it can be optimized for better performance.

Understanding the Problem

Given a string, our goal is to identify the first character that appears only once. If all characters are repeated, we should return null or a suitable indicator that no unique characters exist.

Input: "abcdhbac"
Output: 'd'

Here, ‘a’, ‘b’, and ‘c’ are repeated, but ‘d’ appears only once, making it the first non-repeating character.

Step-by-Step Approach (HashMap-based )

To solve this problem efficiently, we follow these steps:

1. Use a HashMap (Mutable Map in Kotlin) to count occurrences of each character.
2. Loop through the string to populate the frequency map.
3. Loop through the string again to find the first character with a count of 1.
4. Return the first unique character found; otherwise, return null.

Kotlin Implementation

Now, let’s implement this approach in Kotlin:

fun findNonRepeatedLetter(str: String): Char? {
    val charCount = mutableMapOf<Char, Int>()

    // Count occurrences of each character
    for (char in str) {
        charCount[char] = charCount.getOrDefault(char, 0) + 1
    }
    // Find the first character with a count of 1
    for (char in str) {
        if (charCount[char] == 1) {
            return char
        }
    }
    
    return null // Return null if no unique character exists
}

fun main() {
    val str = "abcdhbac"
    val result = findNonRepeatedLetter(str)
    
    println("First non-repeating character: ${result ?: "None"}")
}

Here,

• Step 1: We create a mutable map charCount to store character frequencies.
• Step 2: We iterate over the string, updating the map with each character’s occurrence count.
• Step 3: We loop through the string again to check which character appears only once.
• Step 4: If found, we return it; otherwise, we return null.

Output

First non-repeating character: d

Why This Approach Works Efficiently

This method ensures an optimal time complexity of O(n):

• First loop (O(n)) — Counts character occurrences.
• Second loop (O(n)) — Finds the first unique character.
• Overall Complexity: O(n) + O(n) = O(n), making it very efficient.

Edge Cases to Consider

1. All Characters Repeated: Input: "aabbcc" Output: None
2. String with Only One Character: Input: "x" Output: x
3. Empty String: Input: "" Output: None
4. String with Multiple Unique Characters: Input: "kotlin" Output: k

Alternative Optimized Approach (Array-based)

Instead of using a HashMap, we can use an Array of size 256 (for ASCII characters) to store occurrences, making it even more memory-efficient for large-scale data.

fun findNonRepeatedLetterOptimized(str: String): Char? {
    val charArray = IntArray(256) // For ASCII characters
    
    for (char in str) {
        charArray[char.toInt()]++
    }
    
    for (char in str) {
        if (charArray[char.toInt()] == 1) {
            return char
        }
    }
    
    return null
}

Let’s walk through code and try to dry run it.

Step 1: Initialize charArray

The charArray will look like this initially (all zeros):

[0, 0, 0, 0, ..., 0]  // 256 zeros

Step 2: Count the characters

For each character in "abcdhbac", the array will be updated based on their ASCII values:

• ‘a’ has an ASCII value of 97, so charArray[97]++ (now charArray[97] = 1).
• ‘b’ has an ASCII value of 98, so charArray[98]++ (now charArray[98] = 1).
• ‘c’ has an ASCII value of 99, so charArray[99]++ (now charArray[99] = 1).
• ‘d’ has an ASCII value of 100, so charArray[100]++ (now charArray[100] = 1).
• ‘h’ has an ASCII value of 104, so charArray[104]++ (now charArray[104] = 1).
• ‘b’ has an ASCII value of 98 again, so charArray[98]++ (now charArray[98] = 2).
• ‘a’ has an ASCII value of 97 again, so charArray[97]++ (now charArray[97] = 2).
• ‘c’ has an ASCII value of 99 again, so charArray[99]++ (now charArray[99] = 2).

Now, the charArray looks like this (only showing relevant indexes):

charArray[97] = 2  // 'a' appears 2 times
charArray[98] = 2  // 'b' appears 2 times
charArray[99] = 2  // 'c' appears 2 times
charArray[100] = 1 // 'd' appears 1 time
charArray[104] = 1 // 'h' appears 1 time

Step 3: Find the first non-repeating character

• Now, we iterate through the string again:
• ‘a’: charArray[97] == 2 → Skip.
• ‘b’: charArray[98] == 2 → Skip.
• ‘c’: charArray[99] == 2 → Skip.
• ‘d’: charArray[100] == 1 → Return ‘d’ (First non-repeating character).

Thus, the output will be 'd'.

Execution Flow:

1. First loop: Count character occurrences in the string.
2. Second loop: Check for the first character that appears only once.
3. Return: Return the first non-repeating character or null if there are no non-repeating characters.

This approach is very efficient, with a time complexity of O(n), where n is the length of the string.

Why this approach is optimized?

• Space is constant: The array size is fixed (256), regardless of the length of the input string. This means the space complexity of the solution is O(1) (constant space), as the array size does not grow with the input size, and you can use it regardless of whether the string is long or short.
• No need for dynamic data structures like HashMap: The use of a fixed-size array eliminates the need for dynamically resizing a hash map as new characters are added, which would typically require reallocation of memory.

Conclusion

Finding the first non-repeating character in a string is a common problem, and Kotlin provides powerful tools like mutableMapOf and IntArray to solve it efficiently. The HashMap-based approach is easy to understand and works well in most cases, while the Array-based approach can be optimized for performance in certain situations.

Kotlin’s coroutines have revolutionized asynchronous programming on the JVM. They make concurrent operations simpler and more efficient. However, without proper control, coroutines can become chaotic, leading to memory leaks, unhandled errors, and debugging nightmares. This is where structured concurrency in coroutines comes to the rescue.

Structured concurrency ensures that coroutines are launched, supervised, and cleaned up properly. It keeps your code maintainable, predictable, and safe. In this post, we’ll explore how structured concurrency works in Kotlin, why it matters, and how you can implement it effectively.

What is Structured Concurrency in Coroutines?

Structured concurrency in coroutines is a principle that ensures all coroutines launched in an application have a well-defined scope and lifecycle. Instead of launching coroutines in an unstructured, free-floating manner, structured concurrency ensures they:

• Are tied to a specific scope.
• Get automatically canceled when their parent scope is canceled.
• Avoid memory leaks by ensuring proper cleanup.
• Provide predictable execution and error handling.

Kotlin achieves this by leveraging CoroutineScope, which acts as a container for coroutines.

import kotlinx.coroutines.*

fun main() = runBlocking {
    launch {
        delay(1000L)
        println("Coroutine completed!")
    }
    println("Main function ends")
}

Here,

• runBlocking creates a coroutine scope and blocks execution until all coroutines inside it complete.
• launch starts a new coroutine inside runBlocking.
• The coroutine delays for 1 second before printing the message.
• The main function waits for all coroutines (here only one) to finish before exiting.

Without structured concurrency, coroutines would run freely, possibly outliving their parent functions. This can lead to unpredictable behavior.

Kotlin enforces structured concurrency using CoroutineScope, which defines the lifecycle of coroutines. Every coroutine must be launched within a scope, ensuring proper supervision and cleanup.

Implementing Structured Concurrency in Kotlin

Using CoroutineScope

Every coroutine in Kotlin should be launched within a CoroutineScope. The CoroutineScope ensures that all launched coroutines get canceled when the scope is canceled.

Example using CoroutineScope:

class MyClass {
    private val scope = CoroutineScope(Dispatchers.IO)

    fun fetchData() {
        scope.launch {
            val data = fetchFromNetwork()
            println("Data received: $data")
        }
    }

    fun cleanup() {
        scope.cancel() // Cancels all coroutines within this scope
    }

    private suspend fun fetchFromNetwork(): String {
        delay(1000L)
        return "Sample Data"
    }
}

Here,

• CoroutineScope(Dispatchers.IO) creates a scope for background operations.
• fetchData launches a coroutine within the scope.
• cleanup cancels the scope, stopping all running coroutines inside it.

This ensures that all coroutines are properly managed and do not outlive their intended use.

Parent-Child Relationship in Coroutines

One of the key features of structured concurrency in coroutines is the parent-child relationship. When a parent coroutine is canceled, all of its child coroutines are automatically canceled.

import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch {
        launch {
            delay(1000)
            println("Child Coroutine - Should not run if parent is canceled")
        }
    }
    
    delay(500) // Give some time for coroutine to start
    job.cancelAndJoin() // Cancel parent coroutine and wait for completion
    println("Parent Coroutine Canceled")
    delay(1500) // Allow time to observe behavior (not necessary)
}


///////// OUTPUT //////////

Parent Coroutine Canceled

The child coroutine should never print because it gets canceled before it can execute println()

SupervisorScope: Handling Failures Gracefully

A common issue in coroutines is that if one child coroutine fails, it cancels the entire scope. To handle failures gracefully, Kotlin provides supervisorScope.

suspend fun main() = coroutineScope {
    supervisorScope {
        launch {
            delay(500L)
            println("First coroutine running")
        }
        launch {
            delay(300L)
            throw RuntimeException("Error in second coroutine")
        }
    }
    println("Scope continues running")
}


///////////// OUTPUT //////////////////////

Exception in thread "DefaultDispatcher-worker-1" java.lang.RuntimeException: Error in second coroutine
First coroutine running
Scope continues running

Here,

• supervisorScope ensures that one coroutine’s failure does not cancel others.
• The first coroutine completes successfully even if the second one fails.
• Without supervisorScope, the whole scope would be canceled when an error occurs.

Unlike coroutineScope, supervisorScope ensures that one failing child does not cancel the entire scope.

Benefits of Structured Concurrency

Using structured concurrency in coroutines offers several benefits:

1. Automatic Cleanup: When the parent coroutine is canceled, all child coroutines are also canceled, preventing leaks.
2. Error Propagation: If a child coroutine fails, the exception propagates to the parent, ensuring proper handling.
3. Scoped Execution: Coroutines only exist within their intended scope, making them predictable and manageable.
4. Better Debugging: With clear parent-child relationships, debugging coroutine issues becomes easier.

Best Practices for Structured Concurrency in Coroutines

1. Use CoroutineScope for proper lifecycle management.
2. Avoid GlobalScope unless absolutely necessary.
3. Use supervisorScope to prevent one failure from affecting all coroutines.
4. Always cancel unused coroutines to free up resources.
5. Handle exceptions properly to prevent crashes.

Conclusion

Conclusion

Kotlin’s structured concurrency in coroutines ensures that coroutines are properly managed, reducing memory leaks and making concurrent programming more predictable. By using CoroutineScope, enforcing the parent-child relationship, and leveraging supervisorScope when necessary, you can build robust and efficient Kotlin applications.

Mastering structured concurrency will not only make your code more maintainable but also help you avoid common pitfalls of asynchronous programming. Start applying these best practices today and take full advantage of Kotlin’s coroutine capabilities..!

Kotlin’s type system offers robust features for managing generics, including the concepts of covariance and contravariance. A common question among developers is how constructor parameters influence variance in Kotlin. Let’s explore this topic in a straightforward and approachable manner.

Generics and Variance in Kotlin

Before diving into the Role of Constructor Parameters in Kotlin Variance, it’s essential to grasp the basics of generics and variance:

Generics allow classes and functions to operate on different data types while maintaining type safety.

Variance defines how subtyping between more complex types relates to subtyping between their component types. In Kotlin, this is managed using the in and out modifiers.

• The out modifier indicates that a type parameter is covariant, meaning the class can produce values of that type but not consume them.
• The in modifier denotes contravariance, where the class can consume values of that type but not produce them.

The Role of Constructor Parameters

In Kotlin, constructor parameters are not considered to be in the “in” or “out” position when it comes to variance. This means that even if a type parameter is declared as “out,” you can still use it in a constructor parameter declaration without any restrictions.

For example:

class Herd<out T: Animal>(vararg animals: T) { ... }

The type parameter T is declared as “out,” but it can still be used in the constructor parameter vararg animals: T without any issues. The variance protection is not applicable to the constructor because it is not a method that can be called later, so there are no potentially dangerous method calls that need to be restricted.

However, if you use the val or var keyword with a constructor parameter, it declares a property with a getter and setter (if the property is mutable). In this case, the type parameter T is used in the “out” position for a read-only property and in both “out” and “in” positions for a mutable property.

For example:

class Herd<T: Animal>(var leadAnimal: T, vararg animals: T) { ... }

Here, the type parameter T cannot be marked as “out” because the class contains a setter for the leadAnimal property, which uses T in the “in” position. The presence of a setter makes it necessary to consider both “out” and “in” positions for the type parameter.

It’s important to note that the position rules for variance in Kotlin only apply to the externally visible API of a class, such as public, protected, and internal members. Parameters of private methods are not subject to the “in” or “out” position rules. The variance rules are in place to protect a class from misuse by external clients and do not affect the implementation of the class itself.

For instance:

class Herd<out T: Animal>(private var leadAnimal: T, vararg animals: T) { ... }

In this case, the Herd class can safely be made covariant on T because the leadAnimal property has been made private. The private visibility means that the property is not accessible from external clients, so the variance rules for the public API do not apply.

Conclusion

In Kotlin, constructor parameters are neutral regarding variance. This neutrality ensures that you can use generic types in constructors without affecting the covariant or contravariant nature of your classes. Understanding this aspect of Kotlin’s type system enables you to write more robust and flexible generic classes.

By keeping constructor parameters and variance separate, Kotlin provides a type-safe environment that supports both flexibility and clarity in generic programming.

Memory management is a crucial aspect of Java programming, ensuring that unused objects are efficiently cleared to free up resources. While Java’s built-in garbage collector (GC) handles most of this automatically, advanced scenarios require finer control. This is where PhantomReference in Java comes into play.

In this blog post, we will explore PhantomReference in Java, how it differs from other reference types, and how it can be used to enhance memory management. Let’s dive in!

What is PhantomReference in Java?

A PhantomReference is a type of reference in Java that allows you to determine precisely when an object is ready for finalization. Unlike SoftReference and WeakReference, a PhantomReference does not prevent an object from being collected. Instead, it serves as a mechanism to perform post-mortem cleanup operations after the object has been finalized.

Key Characteristics:

• No Direct Access: You cannot retrieve the referenced object via get(). It always returns null.
• Used for Cleanup: It is typically used for resource management, such as closing files or releasing memory in native code.
• Works with ReferenceQueue: The object is enqueued in a ReferenceQueue when the JVM determines it is ready for GC.

How PhantomReference Differs from Other References

Java provides four types of references:

• Strong Reference: The default type; prevents garbage collection.
• Weak Reference: Allows an object to be garbage collected if no strong references exist.
• Soft Reference: Used for memory-sensitive caches; objects are collected only when memory is low.
• Phantom Reference: Unlike other references, it does not prevent garbage collection at all. Instead, it is used to run cleanup actions after an object has been collected, often in conjunction with a ReferenceQueue.

Implementing PhantomReference in Java

To use PhantomReference in Java, we must associate it with a ReferenceQueue, which holds references to objects that have been marked for garbage collection.

import java.lang.ref.PhantomReference;
import java.lang.ref.Reference;
import java.lang.ref.ReferenceQueue;

public class PhantomReferenceExample {
    public static void main(String[] args) throws InterruptedException {
        ReferenceQueue<Resource> queue = new ReferenceQueue<>();
        Resource resource = new Resource();
        PhantomReference<Resource> phantomRef = new PhantomReference<>(resource, queue);

        // Remove strong reference
        resource = null;
        System.gc(); // Suggest GC
       
        // Wait for the reference to be enqueued
        while (queue.poll() == null) {
            System.gc();
            Thread.sleep(100);
        }
        
        System.out.println("PhantomReference enqueued, performing cleanup...");
    }
}

class Resource {
    void cleanup() {
        System.out.println("Cleaning up resources...");
    }
}

Here,

1. We create a ReferenceQueue to hold PhantomReference objects after GC determines they are unreachable.
2. A PhantomReference to a Resource object is created and linked to the queue.
3. The strong reference to the Resource object is removed (resource = null), allowing it to be garbage collected.
4. The garbage collector runs (System.gc()), and after a delay (Thread.sleep(1000)), we check the ReferenceQueue.
5. If the PhantomReference is enqueued, we perform cleanup operations before removing the reference completely.

Why Use PhantomReference?

The main reason for using PhantomReference in Java is to gain better control over memory cleanup beyond what the garbage collector offers. Some use cases include:

1. Monitoring Garbage Collection: Detect when an object is about to be collected.
2. Resource Cleanup: Free up native resources after Java objects are finalized.
3. Avoiding finalize() Method: finalize() is discouraged due to its unpredictable execution; PhantomReference provides a better alternative.

Conclusion

PhantomReference in Java is a powerful tool for managing memory efficiently. While it may not be needed in everyday development, understanding how it works helps in writing better memory-aware applications. By combining PhantomReference with a ReferenceQueue, you can ensure timely resource cleanup and improve your application’s performance.

If you’re working with large objects, native resources, or need to track garbage collection behavior, PhantomReference in Java provides a robust and flexible solution.

Generics in Kotlin can seem complex at first, but once you understand their power, they make your code more flexible and reusable. In this blog, we’ll break down generics in a simple way, focusing on generic functions and properties and best practices.

What Are Generics in Kotlin?

Generics allow you to write code that works with different data types without sacrificing type safety. Instead of specifying an exact type, you define a placeholder type that gets replaced with a real type at runtime.

For example, consider a function that prints any type of element. Instead of writing separate functions for Int, String, and other types, you can use generics to make it work for any type.

without generics, you might write:

fun printInt(value: Int) {
    println(value)
}

fun printString(value: String) {
    println(value)
}

With generics, you can simplify this:

fun <T> printValue(value: T) {
    println(value)
}

Now, printValue works with any type!

Generic Functions in Kotlin

A generic function uses a type parameter to make it more flexible. The type parameter is placed inside angle brackets (<>) before the function’s parameter list.

A Simple Generic Function

fun <T> printItem(item: T) {
    println(item)
}

fun main() {
    printItem(42)       // Works with Int
    printItem("Hello")  // Works with String
    printItem(3.14)     // Works with Double
}

• <T> is the type parameter.
• T is used as the parameter type inside the function.
• The function can now accept any type, making it more reusable.

Generic Function with Multiple Parameters

fun <T, U> pairItems(first: T, second: U): Pair<T, U> {
    return Pair(first, second)
}

fun main() {
    val pair = pairItems("Hello", 100)
    println(pair) // Output: (Hello, 100)
}

Here, we define two generic types, T and U, making the function even more flexible.

Generic Properties in Kotlin

You can also use generics with properties in classes.

class Box<T>(var content: T)

fun main() {
    val intBox = Box(42)
    val stringBox = Box("Hello, Kotlin Generics!")
    
    println(intBox.content)   // Outputs: 42
    println(stringBox.content) // Outputs: Hello, Kotlin Generics!
}

Here, Box<T> is a generic class where T represents any type. This allows us to create boxes for different types without duplicating code.

Read-Only Generic Properties

If you want a read-only generic property:

class ReadOnlyBox<T>(private val content: T) {<br>    fun getContent(): T = content<br>}

Since content is private, it can only be accessed via getContent().

Best Practices

Use Meaningful Type Parameter Names: Instead of <T>, consider using <Item> or <Element> for better readability.

Prefer Read-Only Properties: If a property doesn’t need modification, keep it read-only (val) to improve safety.

Avoid Unnecessary Generics: If a function doesn’t require type flexibility, don’t use generics unnecessarily. It can make the code harder to read.

Read the full article here: [Main Article URL]

Conclusion

Kotlin’s generics allow for reusable and type-safe code. By understanding generic functions and properties, you can write cleaner and more efficient Kotlin programs. Follow best practices, use it wisely, and keep your code readable.

Now that you have a solid grasp, try using generic functions and properties in your own Kotlin projects!

When writing Java programs, handling errors is an essential part of creating robust and reliable applications. One important concept in Java’s error-handling mechanism is checked exceptions. If you’re new to Java or need a refresher, this guide will walk you through what checked exceptions are, how they work, and how to handle them effectively.

What Are Checked Exceptions in Java?

Checked exceptions in Java are a category of exceptions that must be either caught or declared in the method signature using the throws keyword. They are part of Java’s mechanism to enforce error handling at compile-time, ensuring that developers acknowledge and manage potential problems before running the program.

Unlike unchecked exceptions, which arise due to programming errors (such as NullPointerException or ArrayIndexOutOfBoundsException), checked exceptions typically indicate recoverable conditions like missing files, failed network connections, or invalid user input.

Let’s understand this with a simple example.

Imagine you are booking a flight online. There are two possible situations:

1. You enter correct details, and the ticket is booked successfully.
2. You enter an incorrect credit card number, and the system stops the booking process, showing an error.

In Java terms:

• Booking the flight successfully is like a normal method execution.
• Entering an invalid card number is like a checked exception, because the system knows this issue could happen and forces you to handle it (e.g., by showing an error message).

How Does Java Enforce Checked Exceptions?

When writing Java code, some operations have a high chance of failing, like:

• Reading a file (the file may not exist) → IOException
• Connecting to a database (the database might be down) → SQLException
• Waiting for a thread to complete → InterruptedException

Since these errors are expected, Java forces you to either:

• Handle them using try-catch
• Declare them using throws in the method signature

Let’s say we want to read a file. There’s a chance the file doesn’t exist, so Java forces us to handle this situation.

Without Handling (Compilation Error)

import java.io.FileReader;

public class CheckedExceptionExample {
    public static void main(String[] args) {
        FileReader file = new FileReader("path\data.txt"); // Compilation Error!
    }
}

Error: Unhandled exception: java.io.FileNotFoundException
 Java stops compilation because we didn’t handle the exception. Also the compiler suggests two options: the first one is to surround the code with a try-catch block, and the second is to declare the exception using the throws keyword in the method signature.

Handling with try-catch

We handle the error inside the method using try-catch:

import java.io.FileReader;
import java.io.IOException;

public class CheckedExceptionExample {
    public static void main(String[] args) {
        try {
            FileReader file = new FileReader("path\data.txt"); 
            System.out.println("File opened successfully.");
        } catch (IOException e) {
            System.out.println("Error: File not found.");
        }
    }
}

Output if file exists: File opened successfully.
Output if file is missing: Error: File not found.

Handling with throws (Delegating the Exception)

Instead of handling it inside the method, we can let the caller handle it by declaring throws in the method signature.

import java.io.FileReader;
import java.io.IOException;

public class CheckedExceptionExample {
    public static void main(String[] args) throws IOException {
        FileReader file = new FileReader("path\data.txt"); 
        System.out.println("File opened successfully.");
    }
}

This approach is useful for propagating exceptions to higher-level methods where they can be handled appropriately.

Why Are Checked Exceptions Important?

Checked exceptions serve an important role in Java by enforcing better error handling. Here’s why they matter:

1. Compile-Time Safety: They prevent runtime failures by ensuring errors are anticipated and handled during development.
2. Encourages Robust Code: Developers are forced to think about possible failure scenarios and how to deal with them.
3. Improves Code Maintainability: Explicit exception declarations make it clear which methods can fail, improving readability and maintainability.

Conclusion

Checked exceptions in Java play a crucial role in enforcing proper error handling at compile-time. By understanding how they work and following best practices, you can write cleaner, more reliable Java code. Whether you use try-catch blocks or declare exceptions with throws, handling checked exceptions properly ensures your applications run smoothly and recover gracefully from potential issues.

By integrating these techniques into your Java development workflow, you’ll be better prepared to handle unexpected situations, making your applications more robust and user-friendly.

Android Studio Meerkat is officially here — and it’s more than just a cute name. This release introduces powerful updates that aim to speed up development, enhance debugging, and improve the overall Jetpack Compose experience. Whether you’re building complex apps or just starting out, Meerkat brings features that can seriously boost your productivity.

Let’s explore the 10 most game-changing features you absolutely must know.

1. Live Edit for Jetpack Compose Is Now Stable

Live Edit is no longer experimental! You can now see real-time changes in Compose previews or even on a device/emulator without restarting the app. This drastically speeds up your UI development workflow.

No more rebuilding. Just tweak and watch it update live.

2. IntelliJ Platform Upgrade (2023.3)

Meerkat includes the IntelliJ IDE platform version 2023.3, bringing in:

• Smarter code completion
• Better navigation tools
• Performance enhancements

This makes the entire experience smoother and more intelligent, especially with Kotlin and Gradle support.

3. Device Mirroring (Now on Stable)

You can now mirror a physical device’s screen directly inside Android Studio — wirelessly or via USB. Use it to:

• Interact with your app in real time
• Drag and drop files
• Take screenshots and screen recordings

Super useful for quick testing and demos.

4. Improved Compose State Inspection

The Compose State Inspector is now more powerful, letting you:

• View recompositions
• Understand state relationships
• Debug UI performance issues with clarity

No more guessing which state triggered a recomposition!

5. Updated Profiler UI

Performance profiling got a visual refresh with:

• Cleaner timeline views
• Easier navigation between CPU, memory, and network usage
• Better flame graphs

Perfect for finding those sneaky bottlenecks.

6. Version Catalog Support in New Project Wizard

Using libs.versions.toml? You’re in luck. Meerkat’s New Project Wizard now supports Version Catalogs out of the box. This helps:

• Keep dependencies consistent
• Share versions across modules
• Simplify upgrades

7. Updated Layout Inspector for Compose

Compose developers can now enjoy:

• Enhanced real-time tree views
• Better performance when inspecting deep hierarchies
• A cleaner UI for navigating views and modifiers

This turns debugging complex UIs into a visual breeze.

8. AI-Powered Code Suggestions (Experimental)

Meerkat brings in early-stage AI code assistance features — like smart suggestions, code completions, and intent-aware quick fixes.

Experimental, but promising! Great for productivity bursts or learning APIs.

9. Gradle Sync & Build Speed Improvements

Google has optimized how Meerkat interacts with Gradle:

• Faster sync times
• Reduced memory usage
• Improved project indexing

The result? Less waiting, more coding.

10. Enhanced Privacy Sandbox Tools

If you’re developing apps that integrate with the Privacy Sandbox on Android, Meerkat introduces new SDK Runtime tools to:

• Inspect runtime behavior
• Debug SDK communications
• Ensure privacy-first design patterns

Conclusion

Android Studio Meerkat isn’t just a minor update — it’s a leap forward in usability, performance, and Jetpack Compose support. From Live Edit going stable to device mirroring and AI-assisted coding, this release is packed with value.

So if you haven’t upgraded yet, now is the time to install Meerkat and explore these productivity-boosting features.

Kotlin is a powerful language that puts a strong emphasis on null safety. However, when working with generics, it’s easy to accidentally allow nullability, even when you don’t intend to. If you’re wondering how to enforce non-null type parameters properly, this guide will walk you through the right approach.

Why Enforcing Non-Null Type Parameters Matters

Kotlin’s type system prevents null pointer exceptions by distinguishing between nullable and non-nullable types. However, generics (T) are nullable by default, which can lead to unintended issues if not handled correctly.

For example, consider the following generic class:

class Container<T>(val value: T)

Here, T can be any type—including nullable ones like String?. This means that Container<String?> is a valid type, even if you don’t want to allow null values.

Making type parameters non-null

In Kotlin, when you declare a generic class or function, you can substitute any type argument, including nullable types, for its type parameters. By default, a type parameter without an upper bound specified will have the upper bound of Any? which means it can accept both nullable and non-nullable types.

Let’s take an example to understand this. Consider the Processor class defined as follows:

class Processor<T> {
    fun process(value: T) {
        value?.hashCode()     // value” is nullable, so you have to use a safe call
    }
}

In the process function of this class, the parameter value is nullable, even though T itself is not marked with a question mark. This is because specific instantiations of the Processor class can use nullable types for T. For example, you can create an instance of Processor<String?> which allows nullable strings as its type argument:

val nullableStringProcessor = Processor<String?>()  // String?, which is a nullable type, is substituted for T
nullableStringProcessor.process(null)              // This code compiles fine, having “null” as the “value” argument

If you want to ensure that only non-null types can be substituted for the type parameter, you can specify a constraint or an upper bound. If the only restriction you have is nullability, you can use Any as the upper bound instead of the default Any?. Here’s an example:

class Processor<T : Any> {         // Specifying a non-“null” upper bound
    fun process(value: T) {
        value.hashCode()          // “value” of type T is now non-“null”
    }
}

In this case, the <T : Any> constraint ensures that the type T will always be a non-nullable type. If you try to use a nullable type as the type argument, like Processor<String?>(), the compiler will produce an error. The reason is that String? is not a subtype of Any (it’s a subtype of Any?, which is a less specific type):

val nullableStringProcessor = Processor<String?>()

// Error: Type argument is not within its bounds: should be subtype of 'Any'

It’s worth noting that you can make a type parameter non-null by specifying any non-null type as an upper bound, not only Any. This allows you to enforce stricter constraints based on your specific needs.

The Wrong Way: Using T : Any?

Some developers mistakenly try to restrict T by writing:

class Container<T : Any?>(val value: T)

However, this does not enforce non-nullability. The bound Any? explicitly allows both Any (non-null) and null. This approach is unnecessary since T is already nullable by default.

The Right Way: Enforcing Non-Null Type Parameters

To ensure that a type parameter is always non-null, you should use an upper bound of Any instead:

class Container<T : Any>(val value: T)

Why This Works

• The constraint T : Any ensures that T must be a non-nullable type.
• Container<String?> will not compile, preventing unintended nullability.
• You still maintain type safety and avoid potential null pointer exceptions.

Here’s a quick test:

fun main() {
    val nonNullContainer = Container("Hello") // Works fine
    val nullableContainer = Container<String?>(null) // Compilation error
}

Applying Non-Null Type Parameters in Functions

If you’re defining a function that uses generics, you can apply the same constraint:

fun <T : Any> printNonNullValue(value: T) {
    println(value)
}

This ensures that T cannot be null:

fun main() {
    printNonNullValue("Kotlin") // Works fine
    printNonNullValue(null) // Compilation error
}

Using Non-Null Type Parameters in Interfaces and Classes

You can also enforce non-nullability in interfaces:

interface Processor<T : Any> {
    fun process(value: T)
}

And in abstract classes:

abstract class AbstractHandler<T : Any> {
    abstract fun handle(value: T)
}

These patterns ensure that all implementations respect non-nullability.

Conclusion

Making type parameters non-null in Kotlin is essential for writing safer, more predictable code. Instead of leaving T nullable or mistakenly using T : Any?, enforce non-nullability using T : Any. This simple yet powerful technique helps prevent unexpected null values while maintaining the flexibility of generics.

By applying this Kotlin tip, you can improve your code’s safety and avoid common pitfalls related to nullability.

Debugging can be frustrating, especially when a bug appears in a large codebase and you have no idea when it was introduced. Instead of manually sifting through commits, Git Bisect can help you track down the exact commit that introduced the bug efficiently. In this blog, we’ll explore how Git Bisect works, walk through a practical example, and provide useful tips to make debugging smoother.

What is Git Bisect?

It is a built-in Git tool that helps you perform a binary search through your commit history to find the exact commit that introduced a bug. Instead of checking each commit one by one, it narrows down the search range quickly by repeatedly dividing the history in half.

This makes Git Bisect extremely powerful, especially in large repositories where manually checking each commit would be time-consuming.

How Does It Work?

The process is simple:

1. You start a bisect session.
2. Mark a known good commit where the bug is absent.
3. Mark a bad commit where the bug is present.
4. Git automatically checks out a commit between those two.
5. You test the code at that commit and mark it as either “good” or “bad.”
6. Git continues this process, narrowing the search until it finds the exact problematic commit.

This approach significantly reduces the number of commits you need to check manually.

Step-by-Step Guide to Using It

Imagine you’re working on a project and notice a feature is broken, but you’re not sure when the bug was introduced.

1. Start the Git Bisect Session

$ git bisect start

This command initiates a Git Bisect session, putting Git in bisect mode.

2. Mark a “Good” and “Bad” Commit

You need to tell Git where the bug exists and where it doesn’t.

• Identify a commit where the bug exists and mark it as bad:

$ git bisect bad

• Find a commit where the bug didn’t exist and mark it as good:

$ git bisect good <commit-hash>

Git will now start checking commits between these two points.

3. Git Picks a Commit for You to Test

Git automatically checks out a commit in the middle of the range. Now, test your code to see if the bug is present.

• If the bug is present, mark it as bad:

$ git bisect bad

• If the bug is not present, mark it as good:

$ git bisect good

Each time you mark a commit as good or bad, Git Bisect picks another commit in between to test.

4. Repeat Until the Problematic Commit is Found

Git will continue selecting commits until it pinpoints the exact commit that introduced the bug. Once identified, Git will display the commit hash and message of the problematic commit.

// something like this

<commit-hash> is the first bad commit  

5. End the Bisect Session

Once you’ve found the bad commit, exit bisect mode:

$ git bisect reset

This restores your repository to its original state before the bisect process.

Automating with a Script

If testing the bug manually is tedious, you can automate the process using a script. Here’s how:

$ git bisect start
$ git bisect bad
$ git bisect good <commit-hash>
$ git bisect run ./test-script.sh

Replace ./test-script.sh with your actual test script that returns 0 for good commits and 1 for bad commits. Git Bisect will run the script automatically and stop when the bad commit is found.

Best Practices

• Choose accurate good/bad commits: Ensure your “good” commit is actually bug-free to avoid misleading results.
• Use automation when possible: Automating the testing process speeds up bisecting significantly.
• Document findings: Keep notes on what you find to avoid redoing the process later.
• Reset after bisecting: Always run git bisect reset to return to the original branch.

Why Use Git Bisect?

• Saves time: Finds the problematic commit quickly using a binary search.
• Works with any Git project: No additional tools or setup required.
• Automatable: Can integrate with test scripts to remove manual testing effort.
• Accurate: Pinpoints the exact commit that introduced a bug, reducing debugging guesswork.

Conclusion

Git Bisect is an essential tool for any developer who wants to debug efficiently. By leveraging binary search, it drastically cuts down the time spent hunting for a bug in large codebases. Whether you’re using it manually or automating the process, it’s a powerful addition to your Git workflow.

Next time you’re stuck debugging a mysterious issue, give Git Bisect a try — it’ll make you look like a pro..!

Reification is a powerful concept in Kotlin that allows us to retain generic type information at runtime. However, it comes with a significant limitation: it only works for inline functions. But why is that the case? Let’s explore the reasons behind this restriction and understand how reification truly works.

Understanding Reification

In most JVM-based languages, including Kotlin and Java, generic type parameters are erased at runtime due to type erasure. This means that when a function or class uses generics, the type information is not available at runtime. For example, the following function:

fun <T> printType(value: T) {
    println(value::class) // Error: Type information is erased
}

The above code won’t work as expected because T is erased and does not retain type information.

How Reification Works

Reification in Kotlin allows us to retain generic type information at runtime when using inline functions. It enables us to work with generics in a way that would otherwise be impossible due to type erasure.

To make a generic type reified, we use the reified keyword inside an inline function:

inline fun <reified T> printType(item: T) {
    println(T::class)  // Works because T is reified
}

Now, if we call:

printType("Hello")

The output will be:

class kotlin.String

Unlike the earlier example, this works because T is no longer erased. But why does this work only for inline functions?

Why reification works for inline functions only?

Reification works for inline functions because the compiler inserts the bytecode implementing the inline function directly at every place where it is called. This means that the compiler knows the exact type used as the type argument in each specific call to the inline function.

Let’s understand this concept with the filterIsInstance() function from the Kotlin standard library.

inline fun <reified T> Iterable<*>.filterIsInstance(): List<T> {
    val destination = mutableListOf<T>()
    for (element in this) {
        if (element is T) {
            destination.add(element)
        }
    }
    return destination
}

When you call an inline function with a reified type parameter, the compiler can generate a bytecode that references the specific class used as the type argument for that particular call. For example, in the case of the filterIsInstance<String>() call, the generated code would be equivalent to:

for (element in this) {
    if (element is String) { 
        destination.add(element)
    }
}

The generated bytecode references the specific String class, not a type parameter, so it is not affected by the type-argument erasure that occurs at runtime. This allows the reified type parameter to be used for type checks and other operations at runtime.

What Happens if You Try Reification in a Non-Inline Function?

If you try to use a reified type parameter in a non-inline function, you’ll get a compilation error:

fun <reified T> printNonInlineType(value: T) { // Error
    println(T::class)
}

Error:

Error: Only type parameters of inline functions can be reified or Reified type parameters can only be used in inline functions

This error occurs because, without inlining, the type information would be erased, making T::class invalid.

Workarounds for Non-Inline Functions

If you need to retain type information in a non-inline function, consider using class references or passing a KClass<T> parameter:

fun <T: Any> printType(clazz: KClass<T>, value: T) {
    println(clazz)
}

printType(String::class, "Hello")

This approach ensures the type is explicitly provided and prevents type erasure.

Conclusion

Reification is a powerful feature in Kotlin, but it is only possible within inline functions due to JVM type erasure. Inline functions allow type parameters to be substituted at compile time, preserving the type information at runtime. If you need to work with generic types in non-inline functions, you’ll need alternative solutions like KClass references.

Understanding this limitation helps developers write more effective and optimized Kotlin code while leveraging the benefits of reification where necessary.