Description
Description
The behavior of Color and VisualStateManager in MAUI is sufficiently different that migration is challenging. I've commented on some aspects of this before (see issue #1668) but the combination of several design decisions makes migration especially painful.
The attached example, a simple single page application with a label and 3 entry fields shows some of the issues.
Steps to Reproduce
- Unzip the Xamarin solution from Simple-VisualStateManager-Xamarin.zip
- Compile and run it on Android, you should see what's below. Click on the three entry lines in succession to see the first and second highlighted in yellow when they are selected. Completely independently, the label should change color every 3 seconds):
- Unzip the MAUI project from: Simple-VisualStateManager-MAUI.zip
- Compile and run it under Android then click on the three entry lines in succession and you should see this:
- Repeat under Windows and you should see this:
Comparing the code in MainPage.xaml.cs
between Xamarin and MAUI the significant changes are:
-
Color
literals becomeColors
literals, this is annoying, but relatively easy to change, still it would be nice to provide migration code and it's not clear to me why this change was necessary at all (see Issue [Enhancement] Provide Migration guidance for Xamarin.Forms.Color #1668 for more on this). -
There is no direct equivalent of
Color.Default
, pull request Don't extract native defaults, meaning users can no longer reset a color back to a platform theme #1485 says this is by design but that makes migrating platform independent code difficult (new code is obviously easier). I suggest some migration scheme at least be provided rather than punting to the MAUI programmer to learn enough device dependencies to extract the value for themselves. I expect there's a similar problem withColor.Accent
. Issue Don't extract native defaults, meaning users can no longer reset a color back to a platform theme #1485 says "For now we are going to operate on the premise that users don't use the behavior ofColor.Default
enough to warrant the effort of implementation and the performance implications of pulling those values during startup." But delaying evaluating it until it is requested would remove that overhead for programs that did not use it (written as a man who doesn't have to code it, I agree).
The other issues are with the XAML and especially with the VisualStateManager implementations. The first VisualStateManager sets an Entry background color in a Focused
state and specifies nothing for a Normal
state which means switching back to a Normal
state sets BackGroundColor to null. Taken in conjunction with pull request #1485 this means the switch back is ignored and the Selected
background color persists. Again for new code there's a fairly easy workaround, for existing code it's trickier.
Finally, there are the other functional differences in the MAUI version of the sample:
- On Android the second entry field is not underlined.
- On Android the placeholder text begins slightly to the left of where it should on the second entry line.
- On Android in Xamarin forms the selected Entry gets a red underline, on MAUI it does not.
- On Windows the VisualStateManager specifications seem to have no effect at all.
Version with bug
Release Candidate 1 (current)
Last version that worked well
Unknown/Other
Affected platforms
Android, Windows, I was not able test on other platforms
Affected platform versions
Android 11, Windows 10
Did you find any workaround?
Sometimes. See above (and the code)
Relevant log output
No response