Avoid redundant property round-trips between platform and xplat across multiple controls #29970

bhavanesh2001 · 2025-06-12T18:42:29Z

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Description of Change

This is an follow up of #29887 , addressing the root issue that caused that issue.

The Problem

When the platform updates a property (e.g. user selects an item, types text, etc), the new value is propagated to the xplat property (BindableProperty) — which is correct.

However, as part of that BindableProperty update, the system would re-map the value back to the platform view, causing a full unnecessary round-trip:

Example (CollectionView):

User selects an item on native platform view
The native handler updates the xplat SelectedItem property
PropertyChanged callback fires, re-applies the value back to the platform view
Native view updates again (even though it's already in the correct state)

This unnecessary round-trip results in:

Redundant platform calls
Extra property mapping
Possible race conditions during fast user interactions

Controls/Properties fixed in this PR

Note: These are the properties I have observed so far; there may be others as well.

Control	Property	Fixed in this?
CollectionView (iOS, Windows)	SelectedItem	✅
CollectionView (Android)	SelectedItem	❌
CollectionView	SelectedItems	❌
CheckBox	IsChecked	✅
DatePicker	Date	✅
Editor	Text	✅
Entry	Text	✅
Picker	SelectedIndex	✅
RadioButton	IsChecked	✅
SearchBar	Text	✅
Slider	Value	✅
Stepper	Value	✅
Switch	IsOn	❌
TimePicker	Time	✅

Fix

For most controls, we already set SetterSpecificity.FromHandler when setting a property’s value. We can utilize this to skip the mapping and avoid the unnecessary round-trip.

Follow-up Work

In Android CollectionView, the actual selection currently happens during the round-trip; this needs to be fixed.
Switch.IsOn still needs to be handled. Things are tangled with IsToggled, which is invoking the mapper on its own.
CollectionView.SelectedItems requires special handling since it’s a collection and we are not reassigning a new value directly.

Issues Fixed

Contributes to #22585

dotnet-policy-service · 2025-06-12T18:42:54Z

Hey there @@bhavanesh2001! 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 · 2025-06-12T18:57:45Z

/azp run

azure-pipelines · 2025-06-12T18:58:05Z

Azure Pipelines successfully started running 3 pipeline(s).

MartyIX · 2025-06-13T11:46:38Z

Could your PR affect performance of creating a complex grid (i.e. #21787) please?

bhavanesh2001 · 2025-06-15T14:01:06Z

Could your PR affect performance of creating a complex grid (i.e. #21787) please?

I don’t think this will have any effect on load time or layouts. This mainly affects controls, especially when values are set from platform to xplat ,although, based on the CI results, things aren’t looking very good 😞.

bhavanesh2001 · 2025-06-18T10:44:29Z

src/Controls/src/Core/Element/Element.cs

+			var specificity = GetContext(property).Values.GetSpecificity();
+			if (specificity == SetterSpecificity.FromHandler)
+			{
+				return;


@StephaneDelcroix
Currently, SetterSpecificity.FromHandler is used in several places where the value is not actually coming from the handler, and this is blocking what we're trying to achieve here.

Here are the locations where it's used:

maui/src/Controls/src/Core/BindableObject.cs

Lines 288 to 289 in af4b90c

public void SetBinding(BindableProperty targetProperty, BindingBase binding)

=> SetBinding(targetProperty, binding, binding != null && targetProperty != null && binding.GetRealizedMode(targetProperty) == BindingMode.TwoWay ? SetterSpecificity.FromHandler : SetterSpecificity.FromBinding);

maui/src/Controls/src/Core/BindableObjectExtensions.cs

Lines 27 to 28 in af4b90c

// support normal/code properties

self.SetValue(property, value, SetterSpecificity.FromHandler);

Wouldn't it make more sense to introduce a separate, low-priority fallback specificity for these cases instead of overloading FromHandler, which is intended for platform-set values?

@StephaneDelcroix thoughts?

the new name is very confusing. could you pick a good, self-explanatory one, so we know what this is supposed to do when we come back here next time ?

PureWeen · 2025-06-19T17:25:19Z

/azp run

azure-pipelines · 2025-06-19T17:25:40Z

Azure Pipelines successfully started running 3 pipeline(s).

mattleibow · 2025-06-19T18:12:04Z

src/Controls/src/Core/BindableObjectExtensions.cs

-				self.SetValue(property, value, SetterSpecificity.FromHandler);
+				self.SetValue(property, value, SetterSpecificity.FromDontKnow);


Maybe we should be re-firing using the same that is in there? Why a new value when we could re-use the old one? Would that make more sense?

context can be null here, especially during initialization, so maybe we should stick to setting the specificity explicitly?

StephaneDelcroix

this either need a better name, or a ton of doc (I prefer the former)

oh, and some tests

StephaneDelcroix · 2025-06-19T19:53:07Z

src/Controls/src/Core/SetterSpecificity.cs

+		public static readonly SetterSpecificity FromHandler = new SetterSpecificity(ExtrasHandler, 0, 0, 0, 0, 0, 0, 0);
+
+		// New specificity, intended to behave like FromHandler
+		public static readonly SetterSpecificity FromDontKnow = new SetterSpecificity(ExtrasDontKnow, 0, 0, 0, 0, 0, 0, 0); // New


FromUnknown

Yeah, sorry about that, I just wanted to check the CI results quickly, so I went with the first name that came to mind

@StephaneDelcroix I’ve moved the specificity changes into a separate PR: #30122

StephaneDelcroix · 2025-06-19T19:55:36Z

src/Controls/src/Core/SetterSpecificity.cs

@@ -133,6 +143,7 @@ public SetterSpecificity(byte extras, ushort manual, byte isDynamicResource, byt
 			// 6. Id                 0x0000000000FF0000
 			// 7. Class              0x000000000000FF00
 			// 8. Type               0x00000000000000FF
+			// 9. InternalFallback   0xFEFEFEFEFEFEFEFE // New


so it has the highest priority ?

or a random value?

Yeah, my intention is for it to behave identically to FromHandler in terms of priority but still be distinguishable. The value 0xFEFEFEFEFEFEFEFE is just slightly below 0xFFFFFFFFFFFFFFFF (FromHandler)

StephaneDelcroix · 2025-06-19T19:59:07Z

src/Controls/src/Core/Element/Element.cs

+			var specificity = GetContext(property).Values.GetSpecificity();
+			if (specificity == SetterSpecificity.FromHandler)
+			{
+				return;


the new name is very confusing. could you pick a good, self-explanatory one, so we know what this is supposed to do when we come back here next time ?

This reverts commit 0f9a218.

bhavanesh2001 added 2 commits June 12, 2025 20:30

Skip mapping if value is set from handler

eecedf3

set selecteditem with FromHandler specificity on ios

5c76217

dotnet-policy-service bot added the community ✨ Community Contribution label Jun 12, 2025

remove count

a3466e8

bhavanesh2001 commented Jun 18, 2025

View reviewed changes

add a dummy specificity

0f9a218

mattleibow reviewed Jun 19, 2025

View reviewed changes

StephaneDelcroix requested changes Jun 19, 2025

View reviewed changes

This was referenced Jun 22, 2025

InputView with TextTransform="Uppercase" triggers TextChanged twice per character #30084

Open

Introduce SetterSpecificity.FromUnknown to avoid misuse of FromHandler #30122

Open

bhavanesh2001 added 2 commits June 24, 2025 22:31

Revert "add a dummy specificity"

570f503

This reverts commit 0f9a218.

Merge branch 'main' into avoid_round_trips

044c288

	public void SetBinding(BindableProperty targetProperty, BindingBase binding)
	=> SetBinding(targetProperty, binding, binding != null && targetProperty != null && binding.GetRealizedMode(targetProperty) == BindingMode.TwoWay ? SetterSpecificity.FromHandler : SetterSpecificity.FromBinding);

	// support normal/code properties
	self.SetValue(property, value, SetterSpecificity.FromHandler);

Avoid redundant property round-trips between platform and xplat across multiple controls #29970

Are you sure you want to change the base?

Avoid redundant property round-trips between platform and xplat across multiple controls #29970

Conversation

bhavanesh2001 commented Jun 12, 2025

Description of Change

The Problem

Example (CollectionView):

Controls/Properties fixed in this PR

Fix

Follow-up Work

Issues Fixed

Uh oh!

dotnet-policy-service bot commented Jun 12, 2025

Uh oh!

PureWeen commented Jun 12, 2025

Uh oh!

azure-pipelines bot commented Jun 12, 2025

Uh oh!

MartyIX commented Jun 13, 2025

Uh oh!

bhavanesh2001 commented Jun 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PureWeen commented Jun 19, 2025

Uh oh!

azure-pipelines bot commented Jun 19, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

StephaneDelcroix left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bhavanesh2001 Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bhavanesh2001 Jun 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bhavanesh2001 commented Jun 15, 2025 •

edited

Loading

bhavanesh2001 Jun 19, 2025 •

edited

Loading

bhavanesh2001 Jun 22, 2025 •

edited

Loading