Less boilerplate for Path-Presenter-View sample

[almozavr]

Problem

After adopting dagger 2 for mortar-flow sample, we accounted tons of boilerplate for a simple Path which is occurred due to Path-to-Presenter-to-View dagger bindings. Please take a look at solution and share your thoughts.

Solution

1. Use mortar's service to provide presenter to view;
2. Use presenter as inner class to get access to Path's arguments.

   Solution Repo:

https://github.com/techery/mortar-flow-sample/commit/fc817835a8ba69d32d045c0ac62f2d25468cdf71

Path sample:

Caveats

Presenter uses dagger to inject deps into itself ondemand, it means one have to provide dagger component injection graph with presenters. We use separate interface, but we believe it's less hassle comparing to #128: https://github.com/techery/mortar-flow-sample/blob/fc817835a8ba69d32d045c0ac62f2d25468cdf71/app/src/main/java/com/example/mortar/core/ScreenComponent.java

[sergeyzenchenko]

Yeah, mortar is confusing because of a lot of boilerplate code required for simple actions. We would like to hear other dev ideas about how to reduce this.

[lukaspili]

I am using a slight different approach, inspired from https://github.com/pyricau/dagger2-mortar-flow-experiment. I'm using a @WithComponent annotation, and it avoids the boilerplate in the Presenter class.

Here's a sample: https://gist.github.com/lukaspili/fc8d41d0dcd36e149695

[almozavr]

@lukaspili We tried this approach but found it no less boilerplate, because of @Component you have to create for every presenter, and even more: an extra module to provide args from path to presenter. Details are here: #128

[lukaspili]

@almozavr I agree. After having my fill of writing this boilerplate code, I made a pretty simple annotation processor that generates the boilerplate for me: https://github.com/lukaspili/mortar-mvp

It's still very experimental, but works for me so far. Would be cool if I can get your feedback on it, as I don't have many mortar users around me, unfortunately.