android
todo‑mvp not sure this is intentional or something else
Notice 2 onClick() callbacks, the mPresenter.addNewTask() is basicly call view#showAddTask(). Should we call mPresenter.addNewTask() in these 2 callbacks or I'm missing something?
https://github.com/googlesamples/android-architecture/blob/30f7c5a16bb0854e003530e81403e922e745d311/todoapp/app/src/main/java/com/example/android/architecture/blueprints/todoapp/tasks/TasksFragment.java#L120-L137
https://github.com/googlesamples/android-architecture/blob/30f7c5a16bb0854e003530e81403e922e745d311/todoapp/app/src/main/java/com/example/android/architecture/blueprints/todoapp/tasks/TasksPresenter.java#L185-L188
Issue Summary: @ghost noticed two onClick() callbacks both ultimately call mPresenter.addNewTask(), which only calls view.showAddTask() internally. This raises the question:
Is there a reason why mPresenter.addNewTask() exists at all, if it simply calls view.showAddTask() without any business logic?
Relevant Code: TasksFragment.java: lines 120–137
mAddTaskFab.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { mPresenter.addNewTask(); } }); TasksPresenter.java: lines 185–188
@Override public void addNewTask() { mTasksView.showAddTask(); } Answer: It is intentional. This is a result of following the MVP (Model-View-Presenter) architectural pattern strictly. Even though addNewTask() just calls view.showAddTask() now, its purpose is abstraction and future flexibility.
Reasons for using Presenter.addNewTask() instead of directly calling view.showAddTask(): Separation of concerns:
View delegates all actions to the presenter, never handling navigation or logic directly.
Even if the presenter does nothing complex now, the view doesn't "know" that.
Testability:
You can unit test that calling addNewTask() results in a navigation call without needing UI instrumentation tests.
Future-proofing:
You might later decide to:
Log analytics (Analytics.logAddTaskClicked();)
Check for unsaved changes before allowing task creation
Show confirmation dialogs
All that would live in the presenter, not the view.
Conclusion No, you're not missing anything — but this is a textbook application of clean MVP principles. Even a single-line delegation through the presenter is intentional and useful when maintaining clean separation and testability in codebases.
