Refactor IsRefreshing property to separate animation and command execution responsibilities

[japarson]

Description of Change

This pull request proposes a modification to the behavior of the RefreshView control.

Currently, setting the IsRefreshing property to true in the RefreshView control not only enables the loading animation but also triggers the associated command.

To address this issue, the proposed change involves separating the responsibilities of the IsRefreshing property to achieve the desired behavior:

1. IsRefreshing will solely control the animation enable/disable feature.
2. Command execution will only be executed when the user initiates the refresh through the control UI or at their discretion within their view model.

But why is separating the responsibilities necessary?

As @janseris notes,

We could set IsRefreshing=true in the ViewModel instead of calling ReloadData to achieve the correct behavior but that is not a good idea because we cannot assume from the ViewModel that setting property IsRefreshing will call the ReloadData method by coincidence (we don't know in ViewModel that IsRefreshing is bound to a RefreshView control in the View which also by coincidence calls ReloadData via a registered Command).

We could possibly rename the IsRefreshing property to better reflect its behavior, but this would create a breaking change. Some possibilities would be:

1. IsAnimating
2. IsAnimationInProgress
3. IsRefreshingAnimationActive
4. IsRefreshAnimationVisible

If this change is accepted, I will also update the documentation which states:

Manually setting the IsRefreshing property to true will trigger the refresh visualization, and will execute the ICommand defined by the Command property.

Source: learn.microsoft.com/en-us/dotnet/maui/user-interface/controls/refreshview?view=net-maui-7.0

Issues Fixed

Fixes #6456
Fixes #1171

[ghost]

Hey there @japarson! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[PureWeen]

The initial spec called for a visualization property

public static readonly BindableProperty VisualizationStateProperty;
	public RefreshVisualizationState VisualizationState { get; set; }

public enum RefreshVisualizationState
{
	Idle,
	Active
}

Could we use that instead of causing breaking changes?

[PureWeen]

We don't need to pull ICommand into core for this. This can instead be something like void UserRefreshing and the commanding is all handled in controls.

Similar to IButton

maui/src/Core/src/Core/IButton.cs

Line 6 in 3b08c20

public interface IButton : IView, IPadding, IButtonStroke

[jsuarezruiz]

@japarson Could you rebase to fix the conflicts?. Let me know if you need help with anything.

[japarson]

We will review the overall design of the RefreshView control in the .NET 9 timeline.

[janseris]

We will review the overall design of the RefreshView control in the .NET 9 timeline.

What about NET 8? NET 9 is really far away. You should really reconsider the change for this year.

[japarson]

We will review the overall design of the RefreshView control in the .NET 9 timeline.

What about NET 8? NET 9 is really far away. You should really reconsider the change for this year.

The plan is to only document a workaround for #6456 right now. In the future, we will fix the issue as part of a larger set of improvements to the RefreshView control. Unfortunately, we don't have the time/resources to implement these improvements for .NET 8. I'll publish the workaround on the original issue soon - please let me know if it's not valid.