Kotlin Data Class Default Constructor and Optional Parameters in Android

By the end of this page, you will understand how Kotlin handles constructors in data classes, why all primary constructor values are required by default, and how to make object creation easier using default parameter values and nullable types when needed. You will also see cleaner alternatives such as named arguments and learn when an "empty constructor" is appropriate in Kotlin.

In Kotlin, a data class is designed to hold data and usually defines its properties directly in the primary constructor. If a constructor parameter has no default value, Kotlin requires you to provide it every time you create an object.

That is why this fails:

val activity = Activity()

Your class currently says that every property is required:

data class Activity(
    var updated_on: String,
    var tags: List<String>,
    var description: String,
    var user_id: List<Int>,
    var status_id: Int,
    var title: String,
    var created_at: String,
    var data: HashMap<*, *>,
    var id: Int,
    var counts: LinkedTreeMap<*, *>
)

Kotlin's usual solution is not to add a Java-style empty constructor manually. Instead, you give properties default values in the primary constructor. Then Kotlin can generate a no-argument style call like Activity().

Example:

data  (
     updated_on: String = ,
     tags: List<String> = emptyList(),
     description: String = ,
     user_id: List<> = emptyList(),
     status_id:  = ,
     title: String = ,
     created_at: String = ,
     : HashMap<*, *> = hashMapOf<Any?, Any?>(),
     id:  = ,
     counts: LinkedTreeMap<*, *> = LinkedTreeMap<Any?, Any?>()
)

Think of a Kotlin data class constructor like a form you must fill out.

• If every field is marked required, you must complete them all before submitting.
• If some fields have pre-filled default values, you can leave them alone and only change what matters.
• If some fields are nullable, it means "this field can be left blank."

So instead of building a Java-style empty object first and filling it later, Kotlin prefers one of these approaches:

• create an object with sensible defaults
• provide only the values you need
• explicitly mark optional fields as nullable

That makes your data model more honest and easier to reason about.

Core syntax

Use default parameter values in the primary constructor:

data class Activity(
    var updatedOn: String = "",
    var tags: List<String> = emptyList(),
    var description: String = "",
    var userIds: List<Int> = emptyList(),
    var statusId: Int = 0,
    var title: String = "",
    var createdAt: String = "",
    var data: HashMap<String, Any> = hashMapOf(),
    var id: Int = 0
)

Now you can create it with no arguments:

val activity = Activity()
activity.title = "New Computer"

Using named arguments

Kotlin also lets you set only what you care about at creation time:

val activity = Activity(title = "New Computer")

This is usually cleaner than creating an empty object and mutating it later.

Using nullable properties when values may be absent

Consider this example:

data class Activity(
    var title: String = "",
    var statusId: Int = 0,
    var description: String? = null
)

val activity = Activity(title = "New Computer")

What happens step by step

1. Kotlin sees the Activity constructor has default values for all properties.

2. You call:

   Activity(title = "New Computer")
   

3. Kotlin assigns title to "New Computer".

4. Kotlin uses the default value 0 for statusId.

5. Kotlin uses the default value null for description.

6. The final object becomes:

Default constructor-like behavior in Kotlin is useful in many practical situations:

• Form models in Android apps
  • Start with empty values and fill fields as the user types.
• API request bodies
  • Create a request object with a few known fields and leave the rest as defaults.
• JSON parsing models
  • Some fields may be missing in server responses, so defaults or nullable fields help.
• Local state objects
  • UI state in ViewModels often starts with empty strings, empty lists, or null.
• Testing
  • Build objects quickly without passing every field each time.

Example in an Android ViewModel:

val draft = Activity(title = "New Computer")
repository.sendToServer(draft)

This is much clearer than passing ten null values.

In real projects, developers usually combine default values with a few common Kotlin patterns.

1. Named arguments

Instead of relying on positional arguments:

val activity = Activity("", emptyList(), "", emptyList(), 0, "New Computer", "", hashMapOf(), 0, LinkedTreeMap())

developers prefer:

val activity = Activity(title = "New Computer")

This is easier to read and safer.

2. Validation before sending data

A model may allow defaults, but the app still validates required fields:

if (activity.title.isBlank()) {
    throw IllegalArgumentException("Title is required")
}

3. copy() for updates

Data classes support copy(), which is heavily used in real codebases:

val original = Activity(title = "Draft")
val updated = original.copy(title = )

1. Using null with non-nullable types

This does not work:

data class Activity(
    var title: String,
    var id: Int
)

val activity = Activity(null, null)

Why it fails:

• String is not String?
• Int is not Int?

Fix it by either:

• making the property nullable, or
• providing a real default value

data class Activity(
    var title: String = "",
    var id: Int = 0
)

2. Making everything nullable without a reason

Broken design:

data  (
     title: String? = ,
     id: ? = 
)

Quick reference

Create a data class with default values

data class Activity(
    var title: String = "",
    var id: Int = 0,
    var tags: List<String> = emptyList()
)

Call it with no arguments

val activity = Activity()

Set only one property using named arguments

val activity = Activity(title = "New Computer")

Make a field optional with null

var description: String? = null

Prefer these defaults

• String -> ""
• Int -> 0 if valid in your domain
• List<T> ->

Can a Kotlin data class have an empty constructor?

Yes, effectively. If all constructor parameters have default values, you can call the class with no arguments using Activity().

Should I use null for every field to simulate Java behavior?

Usually no. Prefer sensible default values and only use nullable types when null has a real meaning.

What is the idiomatic Kotlin way to create an object with only one changed field?

Use default values plus named arguments, for example:

val activity = Activity(title = "New Computer")

Can I add a secondary constructor instead?

Yes, but it is usually unnecessary for this case. Default parameter values are the standard Kotlin solution.

Why does Kotlin not allow null for String or Int automatically?

Because Kotlin distinguishes between nullable and non-nullable types to reduce null-related bugs.

Is Activity() or Activity(title = "New Computer") better?

Activity(title = "New Computer") is usually better because it expresses intent clearly at creation time.

• Primary constructor — Data class properties are usually declared here, so constructor rules matter.
• Default parameter values — This is the main Kotlin feature that replaces many Java-style empty constructors.
• Nullable types — Useful when a field may legitimately be absent.
• Named arguments — Makes object creation much easier to read when a class has many parameters.
• Data classes — Provide copy(), toString(), equals(), and hashCode() automatically.
• Secondary constructors — Sometimes used for compatibility, but less common than defaults in Kotlin.
• Immutability with val — Encourages safer object design than mutable setter-heavy models.
• copy() function — Common for updating data class instances without mutating the original.