MVP for Android Part 3 — Moxy Strategies

Welcome to my 3rd article about MVP on Android. As promised today we’ll be looking into Moxy a little more in-depth. In the previous article, I covered what Moxy is and how helps with MVP implementation. In this article, we’ll cover how the out of the box solutions provided by Moxy work and we’ll determine which strategy works with which use case.

So, let’s get started.

Command queue (methods that are called by the View) in the presenter are defined by the View states after their re-creation. Storing commands in the queue follows the specified strategy by the View interface method. The ViewState itself is generated at compile time. This is determined by the View interface and the annotations used in it. Using strategies incorrectly can result in inaccurate application behaviour and memory overflow Commands can only be applied to the View when it is in the active state — in the time interval between calls to the getMvpDelegate (). OnAttach () and getMvpDelegate (). OnDetach () methods from the Activity, Fragment, or custom android.view.View.

Solutions provided by Moxy out of the box

Moxy by default provides the following strategies:

• AddToEndStrategy — execute the command and add the command to the end of the queue
• AddToEndSingleStrategy — execute the command, add it to the end of the queue and delete all its previous instances
• SingleStateStrategy — execute the command, clear the queue and add the command to it
• SkipStrategy — execute the command
• OneExecuteStrategy — execute the command as soon as possible

Now let’s take into consideration how each works and when each should be used.

AddToEndStrategy

AddToEndStrategy is the simplest strategy, Simply put you add a command to the end of the queue. While the presenter calls a command with the AddToEndStrategy strategy:

1. The command is added to the end of the ViewState
2. The command is applied to the View, if it is in the active state

When recreating View:

1. View is used to consistently apply commands from the ViewState queue

AddToEndSingleStrategy

This strategy differs from AddToEndStrategy in that only one instance of each command marked with this strategy can be in the ViewState’s queue. So when the presenter calls the command with the AddToEndSingleStrategy strategy:

1. The command is added to the end of the ViewState queue.
2. In the case where a command was already in the queue, the old command is removed from the queue
3. The command is applied to the View, if it is in the active state

When recreating View:

1. View is used to consistently apply commands from the ViewState queue

SingleStateStrategy

This strategy is similar in its operating principle to AddToEndSingleStrategy. The difference is that when the ViewState gets a command with this strategy, the command queue is completely cleared. In other words, When the presenter calls the command with the SingleStateStrategy strategy the following steps are taken:

1. The command queue is completely cleared.
2. The command is added to the end of the ViewState queue.
3. The command is applied to the View, if it is in the active state

When recreating View:

1. View is used to consistently apply commands from the ViewState queue

SkipStrategy

Skip strategy does not change the ViewState stack. The command is applied to the View, only if it is in the active state. The command behaves differently, depending on whether the view is active.

• If there is a View in the active state:

The following occurs when the presenter calls the command with the SkipStrategy strategy and View is in the active state:

1. The command applies to View
2. The command queue remains unchanged

When recreating View:

1. View is used to consistently apply commands from the ViewState queue

• If there is no View in active state:

When the presenter calls the command with the SkipStrategy strategy, in the absence of the View in the active state:

1. The command does not apply to View
2. The command queue remains unchanged

When recreating View:

1. View is used to consistently apply commands from the ViewState queue

OneExecuteStrategy

This strategy is very similar to SkipStrategy. The difference is that if there is no view in active state,the command waits for its appearance, and then it is used just once. The command behaves differently, depending on whether the view is active.

• If there is a View is in active state:

When the presenter calls the command with the OneExecuteStrategy strategy, if the View is active (the Behavior is basically the same as SkipStretegy):

1. The command applies to View
2. The command queue remains unchanged

When recreating View:

1. View is used to consistently apply commands from the ViewState queue

• If there is no View in the active state:

When the presenter calls the command with the OneExecuteStrategy strategy, in the absence of the View in active state:

1. The command is added to the end of the ViewState
2. When the View appears in the active state:
3. View is used to consistently apply commands from the ViewState queue

When the command is executed, it is removed from the command queue. If you later recreate View, the command will not be called.

When there isn’t a OOTB strategy for the method you’re working with

In the absence of an explicit indication of a strategy for a particular method generally leads to its automatic conclusion based on the strategy for the entire interface and the default strategy. Generally, the default strategy is AddToEndStrategy.

Command scope

AddToEndStrategy — is used when you need to consistently apply several commands that must be reapplied when recreating the View.

Example: The organization screen consists of 3 blocks: general information, stocks, and purchase history. These parts can be downloaded and displayed on the screen asynchronously. After recreation it is important to display information in all the blocks. All methods will be marked with the AddToEndStrategy strategy

AddToEndSingleStrategy — is used in the case when the command should be used when recreating the view no more than once.

Example: There is a progress bar on the screen, the visibility of which is changed by calling View: toggleLoading (visible: Boolean). This method will have an AddToEndSingleStrategy strategy.

SingleStrategy — is used if the result of the teams that worked to is not important to us.

Example: The profile screen data is downloaded from the network. The screen has 3 mutually exclusive states: loading, displaying data and a stub screen. Accordingly, View has showLoading (), showData (), and showStub () methods. All three commands will have a SingleStateStrategy strategy.

SkipStrategy — used in case we need to perform an action, immediatly and only if there is a View in the active state.

Example 1: There is a screen for editing user data. When you click the save button, the download indicator is displayed by calling toggleLoading (show = true). On unsuccessful loading, the screen returns to its original state with the toggleLoading (show = false) command and the SnackBar with the error information is shown with the showLoadingError () command. The last command will have a SkipStrategy strategy, because the result of its execution is needed only when the screen is active and should not be saved when the configuration is changed.

OneExecuteStrategy — used in the case of needing to perform an action when the View first appears in the active state.

Example 1: Opens the next screen, launching a new Activity, Fragment, or FragmentDialog is easiest with this strategy. In this case, we will have a guaranteed 1 start.

Strategies in Moxy are fairly flexible tools but using them carelessly and without careful consideration of their functionality can result in logic errors. I hope that all I covered in this article will make using Moxy clearer and shows how it’s inner workings are quite sensible.

In this article we looked at OOTB strategies, in the next instalment, we’ll look at creating custom strategies. See you soon!

Sergey Trufanov