android
Why in Kotlin MVP example there is not takeView and dropView methods in Presenter?
Hi,
I have noticed that in Kotlin MVP example there is not takeView() and dropView() methods, there is only start() method wherein Java example there are both of these methods. Could someone please explain to me why is it like this?
Branch is todo-mvp-kotlin
Sincerely,
Egor
The Difference In Java todo-mvp The Presenter interface includes:
void takeView(T view); void dropView(); These methods are called by the View (Activity/Fragment) to attach/detach itself to the Presenter — usually in onResume() and onPause()/onDestroyView().
This pattern:
Allows the same Presenter instance to be reused for multiple View instances.
Keeps a clear lifecycle for attaching and detaching the view reference.
Prevents memory leaks by nulling out the reference in dropView().
In Kotlin todo-mvp-kotlin Instead, they simplified the contract:
interface BasePresenter { fun start() } And the presenter keeps a non-nullable view reference passed via constructor:
class TasksPresenter( private val tasksRepository: TasksRepository, private val tasksView: TasksContract.View ) : TasksContract.Presenter {
override fun start() {
loadTasks(false)
}
} So the Presenter never needs takeView()/dropView() — it already gets the View when created and assumes it lives for the Presenter’s entire lifetime.
Why They Did This in Kotlin Kotlin favors immutability – the view reference is passed in the constructor and marked val.
Simpler sample code – fewer lifecycle methods to explain to beginners.
Sample scope – in todo-mvp-kotlin, the Presenter is created fresh in each Activity/Fragment and destroyed with it, so there’s no need for dynamic reattachment.
Less boilerplate – takeView()/dropView() mainly matter when the Presenter outlives the View (e.g., retained presenter, background work).
Downsides of Omitting takeView() / dropView() Less flexibility if you later want the Presenter to survive configuration changes (you’d need to reintroduce them).
Harder to prevent leaks if you accidentally keep the Presenter beyond the View’s lifecycle.
Tighter coupling between Presenter and View lifecycle.
Summary: The Kotlin version drops takeView()/dropView() for simplicity because in that branch, each Presenter instance is tied to exactly one View and has the same lifecycle, making explicit attach/detach unnecessary. The Java version keeps them because it demonstrates a more reusable and lifecycle-safe pattern.
