Add state strategy aliases

[aasitnikov]

Allow @StateStrategyType annotation to be placed on other annotation. In that case this annotation becomes alias for @StateStrategyType.

Let's say we have following annotation defined:

@StateStrategyType(OneExecutionStateStrategy::class)
annotation class OneExecution

If that annotation is placed on some view method, it will have the same effect, as placing @StateStrategyType annotation. For example, this two methods will have same strategies.

interface MyView: MvpView {

    @StateStrategyType(OneExecutionStateStrategy::class)
    fun oneExecution()

    @OneExecution
    fun oneExecution2()
}

[aasitnikov]

Should add some annotations to the library for everyone to use? If yes, I propose to include following annotations: OneExecution and AddToEndSingle.

[alaershov]

We should probably add alias annotations for all the strategies we provide, not just for these two. Also, maybe name them with -Strategy suffix? Like OneExecutionStrategy. Helps to distinguish them clearly, and also probably allows autocomplete by the word Strategy.

[goodibunakov]

Also, maybe name them with -Strategy suffix? Like OneExecutionStrategy.

Exactly.

[aasitnikov]

We should probably add alias annotations for all the strategies we provide, not just for these two. Also, maybe name them with -Strategy suffix? Like OneExecutionStrategy. Helps to distinguish them clearly, and also probably allows autocomplete by the word Strategy.

These names are already taken by actual strategies, for example, AddToEndSingleStrategy. In java, one will have to add a fully qualified name, if StateStrategyType annotation and aliases are mixed up in one file. So it should be either without a suffix, or with some other like -Alias.

[aasitnikov]

I think there should be these aliases in the library:

• AddToEndSingle
• OneExecution
• AddToEnd

• Skip

  AddToEndSingleTagStrategy is not included because it implies tag to be provided by StateStrategyType annotation, and SingleStateStrategy is too unpractical.

[alaershov]

I agree on all points. Except maybe we still should add SingleState despite its uncommon usage, someone definiltely uses it and will expect it to be in the library. It's not hard to do, so why not :)