Closed feresr closed 6 years ago
I have thought about this a lot actually and always refrained myself from refactoring the duplicated code.
For someone who'd want to learn what the architecture is about, I think it'd be easier to do so as of now. This repository's main purpose is for people to have a feel of what MVI can look like. Wouldn't it make more difficult to understand with still more abstraction?
You make a valid point, being familiar with MVI makes it hard to say which approach is more friendly to newcomers. Specially because I suspect that people looking at this architecture would be rather experienced in Android. In any case, I took a quick look to the other architectures in googlesamples/android-architecture and they seem to go for the first approach (less abstraction, more code).
Example: In todo-mvp-kotlin each fragment is calling:
override fun onResume() {
super.onResume()
presenter.start()
}
This could be esaily done in a 'BaseFragment' class to prevent users forgetting to call .start() on their presenters, but this is not the case.
So, you are right, I'd say we don't implement the suggested changes for now. Feel free to close this issue and thanks for the prompt reply.
Thank you for the input!
I would like to submit a PR restructuring the code to avoid the duplication of boiler plate code on
MviViewModels
. But I would like you get your approval before I get my hands dirty.My approach would be converting the
MviViewModel
interface into an abstract class like this:With this we can avoid repeating the following code: (which is identical for every single ViewModel)
Creating a new ViewModel is much more straightforward. Can you see any disadvantages to this approach? Please let me know!