Kotlin
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Null Safety
-
Section 4: Object-Oriented Kotlin
-
Section 5: Functional Kotlin
-
Section 6: Coroutines
-
Section 7: Collections Deep Dive
-
Section 8: Type System Deep Dive
-
Section 9: Interop and Tooling
-
Section 10: Kotlin DSLs and Patterns
-
Section 11: Testing and Quality
-
Section 12: Server-Side Kotlin
-
Section 13: Practical Projects
-
Section 14: Interview Practice
-
Section 15: More Practice Exercises
-
Section 16: More Standard Library
-
Section 17: Multiplatform Kotlin
-
Section 18: kotlin.collections In Depth
-
Section 19: kotlin.text In Depth
-
Section 20: kotlin.ranges and kotlin.sequences
-
Section 21: kotlin.io and File Handling
-
Section 22: kotlinx.coroutines Deep Dive
-
Section 23: kotlin.reflect
-
Section 24: Android Development with Kotlin Overview
-
Section 25: Kotlin Multiplatform Deep Dive
-
Section 26: Kotlin for Backend Deep Dive
-
Section 27: Kotlin Design Patterns
-
Section 28: Advanced Language Features
-
Section 29: More Practice Exercises
-
Section 30: More Interview Practice
-
Section 31: Kotlin Type System Deep Dive
-
Section 32: Kotlin Null Safety Advanced
-
Section 33: Kotlin Testing Deep Dive
-
Section 34: Kotlin Build Tooling Deep Dive
-
Section 35: Kotlin Serialization
-
Section 36: Kotlin Performance Considerations
-
Section 37: Kotlin Native Overview
-
Section 38: Kotlin for Data and Scripting
-
Section 39: More Coroutines Practice
-
Section 40: More Android-Adjacent Patterns
-
Section 41: More Practical Projects
-
Section 42: More Design and Architecture Practice
-
Section 43: Kotlin Language Evolution
-
Section 44: More Interview and Review
-
Section 45: Kotlin Delegation Patterns Deep Dive
-
Section 46: Kotlin Annotations Deep Dive
-
Section 47: Kotlin for Gradle Plugin Development
-
Section 48: Kotlin Concurrency Beyond Coroutines
-
Section 49: Kotlin Compiler Internals
-
Section 50: Real-World Kotlin Case Studies
-
Section 51: Final Practice Projects
-
Section 52: Kotlin for Server-Side Reactive Programming
-
Section 53: More Practice and Drills
-
Section 54: Kotlin Security Practices
12: Nullable Types
Why can't I just assign null to any variable?
If you're coming from Java or C#, this is usually the first thing that trips you up. In those languages, any object can be null, and you only find out it's a problem when your app crashes with a NullPointerException in production. Kotlin takes a different approach: it makes nullability part of the type system.
By default, types are non-nullable. If I declare a variable as a String, the compiler guarantees it will never be null. If you actually want a variable to be allowed to hold a null value, you have to explicitly mark it with a question mark.
val name: String = "Alex"
// name = null // This won't even compile.
val middleName: String? = "James"
middleName = null // This is perfectly fine.
I like this because it forces you to decide, right at the start, whether a piece of data is optional or required. It moves the "crash" from the user's device to your compiler.
How do I actually use a nullable variable without the compiler screaming at me?
Once you've marked something as nullable (like String?), Kotlin won't let you call methods on it directly. If you try to call middleName.length, the compiler will stop you because it knows middleName might be null, and that would cause a crash.
The most common way to handle this is the safe call operator: ?.. It basically says, "If this is not null, call the method; otherwise, just return null."
val bio: String? = "Software Engineer from NYC"
println(bio?.length) // Prints the length
val emptyBio: String? = null
println(emptyBio?.length) // Prints "null" instead of crashing
It's a clean way to chain calls without nesting a bunch of if (x != null) blocks. You just chain the question marks, and the whole expression evaluates to null if any link in the chain is null.
What if I need a fallback value instead of just getting null back?
Returning "null" to the UI is rarely what you want. Usually, you want a sensible default. This is where the Elvis operator ?: comes in. I call it the Elvis operator because if you tilt your head, the ?: looks like a pompadour hairstyle.
It allows you to provide a fallback value if the expression on the left is null.
val userPhoneNumber: String? = null
val displayPhone = userPhoneNumber ?: "No phone provided"
println(displayPhone) // Prints: No phone provided
You'll see this everywhere in professional Kotlin code. It's the primary tool for cleaning up nullable data before it hits your views or business logic.
Is the double exclamation mark (!!) ever actually useful?
The !! operator is the "not-null assertion." It tells the compiler, "I know you think this could be null, but I swear it isn't. Trust me and just run it." If you're wrong, the app crashes immediately with a NullPointerException.
val input: String? = "Secret Data"
val length = input!!.length // "Trust me, it's not null"
In my experience, you should almost never use this in production code. Using !! is essentially opting out of Kotlin's safety features. The only time I really use it is in unit tests where I'm certain the state is set up correctly, or when dealing with legacy Java libraries that don't have nullability annotations but I've verified the behavior manually.
📋 Practical Task
The User Profile Formatter
You are building a profile display for a social media app. Some users provide a biography and a website, while others leave them blank.
Create a data class UserProfile with the following properties:
username(Non-nullable String)bio(Nullable String)website(Nullable String)
Write a function called formatProfile that takes a UserProfile object and returns a single formatted string. Use the following rules:
- The username should always be displayed.
- If the bio is present, include it. If it's null, use the text "No bio available".
- If the website is present, include it. If it's null, do not include the website section in the string at all (use a safe call or a null check).
Test your function with two users: one who has filled out everything and one who has only provided a username.
There are no comments for now.