Set value of a field without calling set method - Kotlin

Question

I've been using Kotlin to develop some apps in Android and what i want to do currently is to set a field value inside the defining class without calling the setter method.

Here is the code inside my class:

var projectList: List<Project>? = null
    set(value) {
        saveProjects(value as ArrayList<Project>)
        field = value
    }

//GO to the database and retrieve list of projects
fun loadProjects(callback: Project.OnProjectsLoadedListener) {
   database.projectDao().getAll().subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread())
            .subscribe(

                    { success ->
                        callback.onProjectsLoaded(success)
                    //Here i don't want to save the projects, because i've loaded them from the database
                        this.projectList = success
                    },
                    { error -> GenericErrorHandler.handleError(error,callback.retrieveContext())}

                    )
}

Does anybody know a way to do this without calling the set(value) method?

Answer 1

You can only gain access to the field directly from the setter. Inside a setter, the field can be accessed through the invisible field variable.

There are perhaps some other ways around your requirements though. Here are 2 examples. You wouldn't have to follow them exactly, but could instead also combine them to make whatever solution you want.

You could use another shell property to act as the setter for your actual property:

class Example1 {
  var fieldProperty: Int = 0

  var setterPropertyForField: Int
    get() = fieldProperty
    set(value) { 
      fieldProperty = value 
    }
}

You could use setters as you actually would in Java with a JVM field and a set method. The @JvmField is probably not necessary.

class Example2 {
  @JvmField var fieldProperty: Int = 0

  fun setField(value: Int) {
    fieldProperty = value
  }
}

You could probably access the field and change it through reflection, but I don't recommend that approach. That would likely only lead to problems.