RefreshView: add new internal property IsRefreshAllowed to fix #14350

[cpraehaus]

Description of Change

Add new internal property IsRefreshAllowed to RefreshView to avoid that change in Command.CanExecute cancels refresh animation.

Implementations of ICommand - like AsyncCommand - usually set CanExecute() based on command state. If command execution starts CanExecute() is often set to false to avoid that command is executed multiple times in parallel. If such a command is used for RefreshView.RefreshCommand then the refresh indication is stopped immediately - even if refresh command is still running.

RefreshView sets its IsEnabled property depending on RefreshCommand.CanExecute(). Two things happen regarding refresh indicator when IsEnabled is set to false:

1. RefreshView sets IsRefreshing to false, thereby stopping the refresh indicator
2. On Android, disabling the RefreshView (through IsEnabled = false) also immediately stops the refresh indicator
   since the Android SwipeRefreshLayout is also disabled (this happens through standard XF view/renderer interactions).

Idea is to introduce a new property RefreshView.IsRefreshAllowed instead of setting RefreshView.IsEnabled - similar to ListView.
RefreshView.IsRefreshAllowed is set depending on RefreshCommand.CanExecute(). Platform renderers need to consider
IsRefreshAllowed and disable swipe to refresh AFTER finishing current refresh activity/indication.

Issues Resolved

• fixes [Bug] RefreshView to completes instantly when using AsyncCommand or Command with CanExecute functionality #14350

API Changes

Added:

• bool RefreshView.IsRefreshAllowed { get; set; } // INTERNAL bindable Property

Platforms Affected

• iOS
• Android
• UWP

Behavioral/Visual Changes

None

Before/After Screenshots

Not applicable

Testing Procedure

Launch Xamarin.Forms.ControlGallery.Android and navigate to issue 14350. Follow the steps there to test the issue.

PR Checklist

• Targets the correct branch
• Tests are passing (or failures are unrelated)

[jfversluis]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jfversluis]

@cpraehaus could you have a look at the failing tests please? :)

[cpraehaus]

@jfversluis Thanks for the hint - fixed unit tests for RefreshView.

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[PureWeen]

@jfversluis I don't know if this fix needs so many parts. This is fixed on MAUI so we could just back port that code. Unless my fix is being naive.

Unit Test
https://github.com/dotnet/maui/pull/2027/files#diff-01279e4d50b79e7507ba57cb5cf82e76b7d3c2f70892f863fcf1253a626d2113R57

Code Fix
https://github.com/dotnet/maui/pull/2027/files#diff-4ea8e3bcdd1fa32231c4d330c595279017142f8e67fbc71ff604b38b026e3f4bR130

[cpraehaus]

@PureWeen Wasn't aware the this is being worked in in MAUI already. I also had the feeling that my PR is bigger than needed, but more in the direction that I wanted the change to be localized in RefreshView core class without affecting platform renderers.

Your approach is simpler, which is good :-). However, I see two disadvantages (just took an overview, so maybe I overlooked something):

1. If Command remains disabled after refresh is done the RefreshControls' Pull-to-Refresh function will not be disabled. Although command will not be executed if user attempts to refresh its still strange for the user (s:he sees the usual PTR animation but is confused since nothing happens).
2. Its questionable if RefreshControl.IsDisabled is the right property for this task. It disables the entire View, potentially including child elements (there I'm not 100 % sure), see [Bug] RefreshView "disabling" does not work on UWP #13749. Don't know if this is by design or not. but I would assume the latter. In my opinion a new property IsRefreshAllowed make sense, since its clearer for the XF user, has less unwanted side-effects. and is consistent with the ListView control.

[jfversluis]

Now that we're so close to the sunsetting of Xamarin.Forms unfortunately we won't be able to take this in anymore, we're really sorry about that. Nevertheless, thank you so much for your time and effort that you have put into this PR.

Please have a look at the evolution of Xamarin.Forms, .NET MAUI. A lot of development has been going on there. Hopefully this issue was already fixed in that codebase. If not, feel free to port this over to there.

Again, thank you so much for being a contributor and Xamarin.Forms user!