search

moxy-community / Moxy

Moxy is MVP library for Android with incremental annotation processor and ktx features
MIT License
327 stars 33 forks source link

Add option to enable isolating incremental annotation processing mode #121

Closed bejibx closed 4 years ago

bejibx commented 4 years ago

This fixes https://github.com/moxy-community/Moxy/issues/38

aasitnikov commented 4 years ago

It seems like if I edit View interfaces, Gradle just removes all files in generated folder and builds them again, but it does not break incremental builds for further tasks. In other words, Gradle will use isolating mode, if you edit presenters or fragments/activities, and fallback to something like aggregating mode, if you edit View interfaces, which is fine

bejibx commented 4 years ago

I have an idea. What if we annotate MvpView with some @Repeated annotation as well? This way we can generate ViewState's separately from presenters.

aasitnikov commented 4 years ago

I have an idea. What if we annotate MvpView with some @Repeated annotation as well? This way we can generate ViewState's separately from presenters.

Yeah, that could work (if you talking about @Inherited)

alaershov commented 4 years ago

I have an idea. What if we annotate MvpView with some @Repeated annotation as well? This way we can generate ViewState's separately from presenters.

@bejibx @aasitnikov how does that combine with our troubles with duplicate generated ViewStates for MvpView classes? Currently it's "fixed" by not generating ViewStates for abstract presenters, and if we annotate Views, this fix would no longer work. We may experiment with further optimisations, but for now I'd rather not break anything. Besides, View interfaces don't change that often)

bejibx commented 4 years ago

I changed my mind - this idea not gonna optimize anything because presenters are transitively dependent on view interfaces. What this mean is if view interface is changed, presenter will be recompiled no matter what. You can find more explanation about transitive dependency analysis from this thread (starting from here especially). The only way to separate presenter and view state compilation is to remove view interface from presenter AST completely, which seems impossible for us.

Also, I think you are not right about ... fallback to something like aggregating mode .... Again, presenter is dependent on view interface, so if you change view, ViewStateProvider for presenter have also to be recompiled but that's all. If you look at ViewStates and ViewStateProviders for other views/presenters - they're not being recompiled at this point.

That being said, I don't plan to add more changes to this PR.