VisualStateManager phase 1 #1405

hartez · 2017-12-14T22:15:06Z

Description of Change

Adds the capability to manage properties on Forms VisualElements via declarative states. States can be declared in code or in XAML.

The Xamarin.Forms.Controls\GalleryPages\VisualStateManagerGalleries folder contains example code for using this feature.

Also adds the Platform Specific IsLegacyColorModeEnabled to provide the option of disabling the partial state/color handling introduced in earlier versions of Forms.

Bugs Fixed

Incidentally fixes 37621 – SearchBar BackgroundColor behavior inconsistent on Windows platforms

API Changes

Added:

VisualStateManager:

public static Collection<VisualStateGroup> GetVisualStateGroups(VisualElement visualElement)
public static void SetVisualStateGroups(VisualElement visualElement, Collection<VisualStateGroup> value)
public static bool GoToState(VisualElement visualElement, string name)

AndroidSpecific, iOSSpecific, WindowsSpecific:

public static bool GetIsLegacyColorModeEnabled(BindableObject element)
public static void SetIsLegacyColorModeEnabled(BindableObject element, bool value)
public static bool GetIsLegacyColorModeEnabled(this IPlatformElementConfiguration<Android, VisualElement> config)
public static IPlatformElementConfiguration<Android, VisualElement> SetIsLegacyColorModeEnabled( this IPlatformElementConfiguration<Android, VisualElement> config, bool value)

PR Checklist

Has tests (if omitted, state reason in description)
Rebased on top of master at time of PR
Changes adhere to coding standard
Consolidate commits as makes sense

dnfclas · 2017-12-14T22:15:18Z

All CLA requirements met.

hartez · 2017-12-14T23:06:12Z

build

StephaneDelcroix

api changes part of the description misses VSG
I'd have to do a 2nd pass on this Xaml/XamlC changes
if you do not define your VSM in Style, XamlG will probably try to generate multiple fields with the name "Normal". The x:Name handling and RuntimeNamePropertyAttribute should be handled in the visitor handling x:Name and namescopes (creading a new node, skipping the x:Name setting)

[OOPS, clicked submit to early. continuing in another review]

StephaneDelcroix · 2017-12-15T08:16:13Z

Xamarin.Forms.Build.Tasks/CompiledConverters/BindablePropertyConverter.cs

@@ -41,6 +42,16 @@ public FieldReference GetBindablePropertyFieldReference(string value, ModuleDefi
 							typeName = (ttnode as ValueNode).Value as string;
 						else if (ttnode is IElementNode)
 							typeName = ((ttnode as IElementNode).CollectionItems.FirstOrDefault() as ValueNode)?.Value as string ?? ((ttnode as IElementNode).Properties [new XmlName("", "TypeName")] as ValueNode)?.Value as string;
+					} else if (parent.XmlType.Name == "VisualState") {


check that the Namespace is XFUri to avoid mismatches

Added the check.

StephaneDelcroix · 2017-12-15T08:19:05Z

Xamarin.Forms.Build.Tasks/CompiledValueProviders/SetterValueProvider.cs

@@ -43,5 +47,28 @@ public IEnumerable<Instruction> ProvideValue(VariableDefinitionReference vardefr
 			//set the value
 			yield return Instruction.Create(OpCodes.Callvirt, setValueRef);
 		}
+
+		bool IsSetterCollection(FieldReference bindablePropertyReference, ModuleDefinition module, BaseNode node, ILContext context)


this method doesn't check if this is a Setter at all, I find the name misleading, and I don't understand what this does

The idea of the method is to check whether the setter is for a collection; renamed the method to SetterValueIsCollection to (hopefully) be more clear. It short-circuits ProvideValue if the Setter is for a collection, since the collection will be intialized later when the first item is added.

Currently I have collections in Setters (e.g. IList<VisualStateGroup>) being initialized when the first item is added to them (using EnsureSetterCollectionInitialized). I suspect that this should instead be happening in IValueProvider.ProvideValue/ICompiledValueProvider.ProvideValue, but if there's a simple way to do that, I haven't been able to see it yet.

Any suggestions?

StephaneDelcroix · 2017-12-15T08:21:14Z

Xamarin.Forms.Build.Tasks/SetPropertiesVisitor.cs

+		}
+
+			static bool IsSetterCollection(VariableDefinition parent, string localName, INode node, ILContext context)
+		{


StephaneDelcroix · 2017-12-15T08:22:22Z

Xamarin.Forms.Build.Tasks/SetPropertiesVisitor.cs

+			return true;
+		}
+
+		static bool CanAddToAttachedProperty(FieldReference bpRef, bool attached, INode node, IXmlLineInfo iXmlLineInfo, ILContext context)


I /think/ this is covered already, but I have to check

StephaneDelcroix · 2017-12-15T08:32:30Z

Xamarin.Forms.Core/BindablePropertyConverter.cs

+
+		Type FindTypeForVisualState(List<object> parentObjects)
+		{
+			var obj = parentObjects.Skip(3).Take(1).FirstOrDefault();  // Skip this Setter, VisualState, and VisualStateGroup


you should skip them one by one, and verify their types (content properties)

Added type verification.

StephaneDelcroix

Part 2 of the review:

I only reviewed the Xaml and Core parts.
it misses Xaml unit tests for the xaml changes

Minus the comments, it looks all good. I'd have to make time to review the Xaml and XamlC changes

StephaneDelcroix · 2017-12-15T08:42:24Z

Xamarin.Forms.Core/RuntimeNamePropertyAttribute.cs

+namespace Xamarin.Forms
+{
+	[AttributeUsage(AttributeTargets.Class)]
+	public sealed class RuntimeNamePropertyAttribute : Attribute


can't we reuse the System.Windows.Markup one now that we're on netstandard ? that'd make the life of people writing designers a bit easier.

if not, should be in X.F.Xaml ns

Fixed the namespace.

StephaneDelcroix · 2017-12-15T08:47:48Z

Xamarin.Forms.Core/Setter.cs

-				target.SetValue(Property, Value, fromStyle);
+			{
+				if (Value is Collection<VisualStateGroup> visualStateGroupCollection)
+					target.SetValue(Property, visualStateGroupCollection.Clone(), fromStyle);


i think the cloning should happen in the BP itself

We only want the cloning to happen if the property is being set by a Setter; if it's being set directly on the element in Xaml or in code, we don't want to clone it. Is there some way to determine that a Setter is the source from within the BP?

StephaneDelcroix · 2017-12-15T08:50:25Z

Xamarin.Forms.Core/VisualStateManager.cs

+		}
+
+		public static readonly BindableProperty VisualStateGroupsProperty =
+			BindableProperty.CreateAttached("VisualStateGroups", typeof(Collection<VisualStateGroup>), typeof(VisualElement), 


it should expose ICollection<VSG> as a public api

also, what's the point of a collection vs a list ? the collection is cloned at the time it is applied, so we don't have to handle collectionEventArgs ?

Fixed, using IList now.

StephaneDelcroix · 2017-12-15T08:54:50Z

Xamarin.Forms.Core/VisualStateManager.cs

+
+		static void VisualStateGroupsPropertyChanged(BindableObject bindable, object oldValue, object newValue)
+		{
+			if (bindable is VisualElement visualElement)


is there a case this condition is false ? if it is, it means the user added a VSG to a non VE, and we'd better crash (like we do for all other BP) in direct casting.

at some point in the future, we'll have to modify BO so it validates types...

Fixed - now uses a direct cast.

StephaneDelcroix · 2017-12-15T08:56:06Z

Xamarin.Forms.Core/VisualStateManager.cs

+			if (bindable is VisualElement visualElement)
+			{
+				// Start out in the Normal state, if one is defined
+				GoToState(visualElement, CommonStates.Normal);


a extension method on VE could be handy, if GoToState is meant to be extensively used in user code

StephaneDelcroix · 2017-12-15T09:06:41Z

Xamarin.Forms.Core/VisualStateManager.cs

+
+		internal VisualStateGroup Clone()
+		{
+			var clone =  new VisualStateGroup {TargetType = TargetType, Name = Name, CurrentState = CurrentState};


isn't this the right place to set the CurrentState as "Normal" ?

that seems a right place as well to throw if the name is null (x:Name is mandatory on VSG)

Setters aren't the only way to set the VisualStateGroups for an element. They can also be set directly in Xaml or from code. And we don't want to set CurrentState to normal directly on the property - we need it to be set with GoToState so the values for the Normal state are applied to the element.

StephaneDelcroix · 2017-12-15T09:09:49Z

Xamarin.Forms.Core/VisualStateManager.cs

+		}
+
+		public string Name { get; set; }
+		public Collection<Setter> Setters { get;}


you know...

Yep. Fixed.

StephaneDelcroix · 2017-12-15T09:10:33Z

Xamarin.Forms.Core/VisualStateManager.cs

+	}
+
+	[RuntimeNameProperty("Name")]
+	public class VisualState 


no storyboard, no triggers, right ? if we don't have plans to support them in the future, the ContentProperty could be set to "Setters"

The plan is to support them in the future.

StephaneDelcroix · 2017-12-15T09:10:48Z

Xamarin.Forms.Core/VisualStateManager.cs

+		}
+	}
+
+	[RuntimeNameProperty("Name")]


nameof(Name)

StephaneDelcroix · 2017-12-15T09:12:05Z

Xamarin.Forms.Core/VisualStateManager.cs

+	}
+
+	[RuntimeNameProperty("Name")]
+	[ContentProperty("States")]


nameof for both

StephaneDelcroix · 2017-12-15T21:36:48Z

Xamarin.Forms.Core/RuntimeNamePropertyAttribute.cs

+			Name = name;
+		}
+
+		public string Name { get; private set; }


turn on r#. it'll tell you you don't have to say private set;

I have to turn if off when I'm working in your Xaml code, otherwise it formats everything correctly :)

StephaneDelcroix · 2017-12-15T21:39:39Z

Xamarin.Forms.Core/VisualElement.cs

@@ -88,8 +89,8 @@ public partial class VisualElement : Element, IAnimatable, IVisualElementControl
 		public static readonly BindableProperty MinimumHeightRequestProperty = BindableProperty.Create("MinimumHeightRequest", typeof(double), typeof(VisualElement), -1d, propertyChanged: OnRequestChanged);

 		[EditorBrowsable(EditorBrowsableState.Never)]
-		public static readonly BindablePropertyKey IsFocusedPropertyKey = BindableProperty.CreateReadOnly("IsFocused", typeof(bool), typeof(VisualElement), default(bool),
-			propertyChanged: OnIsFocusedPropertyChanged);
+		public static readonly BindablePropertyKey IsFocusedPropertyKey = BindableProperty.CreateReadOnly("IsFocused", 


I hate that public BP

It was like that when I got here. ¯\(ツ)/¯

StephaneDelcroix · 2017-12-15T21:41:12Z

Xamarin.Forms.Core/VisualElement.cs

 		static void OnIsFocusedPropertyChanged(BindableObject bindable, object oldvalue, object newvalue)
 		{
-			var element = bindable as VisualElement;
+			if (!(bindable is VisualElement element))


check for BO.GetIsDefault(). element will only be a VE, or null

Are you saying that GetIsDefault will be faster than the pattern matching for this?

Using direct cast now.

StephaneDelcroix · 2017-12-15T21:45:18Z

Xamarin.Forms.Xaml/CollectionExtensions.cs

+	public static class CollectionExtensions
+	{
+		public static object EnsureCollectionInitialized(this BindableObject bindable, BindableProperty property)
+		{


it's not up to the Xaml to create collection if not explicitly declared. if you want to add to a collection, that collection has to exists (can be lazily created in the property getter).
we're doing this at other places

Fixed for BindableObject - the collections are now initialized lazily when the value is retrieved.

StephaneDelcroix · 2017-12-15T21:48:34Z

Xamarin.Forms.Xaml.UnitTests/VisualStateManagerTests.xaml.cs

+				var currentState1 = groups1[0].CurrentState;
+				var currentState2 = groups2[0].CurrentState;
+
+				Assert.That(currentState1.Name == "Normal");


either use

Assert.AreEqual(currentState1.Name, "Normal")

or

Assert.That(currentState1.Name, IS.EqualTo("Normal")) // actually my preferred form

or even

Assert.True(currentState1.Name == "Normal")

but try to avoid this

StephaneDelcroix · 2017-12-15T21:49:49Z

Xamarin.Forms.Xaml.UnitTests/VisualStateManagerTests.xaml.cs

+			{
+				Device.PlatformServices = new MockPlatformServices ();
+				Application.Current = new MockApplication ();
+			}


add a TearDown, both of those are static, and could influence the test running next

Added the TearDown.

StephaneDelcroix · 2017-12-15T21:54:06Z

Xamarin.Forms.Core/VisualStateManager.cs

+
+	[RuntimeNameProperty(nameof(Name))]
+	[ContentProperty(nameof(States))]
+	public class VisualStateGroup 


as the Clone is internal, this class should be sealed.

StephaneDelcroix · 2017-12-15T21:54:53Z

Xamarin.Forms.Core/VisualStateManager.cs

+	}
+
+	[RuntimeNameProperty(nameof(Name))]
+	public class VisualState 


seal as well

nickrandolph · 2017-12-16T05:47:55Z

Xamarin.Forms.Core/VisualElement.cs

+
+			var isEnabled = (bool)newValue;
+
+			VisualStateManager.GoToState(element, isEnabled 


Please don't call the VisualStateManager directly. There should be a method such as "UpdateVisualState" that is called whenever the VisualElement thinks the visual state should be updated. This should be avirtual method so that developers can easily sub-class and override the visual state manager behaviour.

StephaneDelcroix · 2017-12-16T06:05:09Z

I misread. Don’t GetIsDefaut. Direct cast and null comparison

…

On 16 Dec 2017, at 00:39, E.Z. Hart ***@***.***> wrote: @hartez commented on this pull request. In Xamarin.Forms.Core/VisualElement.cs: > static void OnIsFocusedPropertyChanged(BindableObject bindable, object oldvalue, object newvalue) { - var element = bindable as VisualElement; + if (!(bindable is VisualElement element)) Are you saying that GetIsDefault will be faster than the pattern matching for this? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

hartez · 2017-12-17T22:50:21Z

if you do not define your VSM in Style, XamlG will probably try to generate multiple fields with the name "Normal".

Tested this, and you are absolutely correct.

The x:Name handling and RuntimeNamePropertyAttribute should be handled in the visitor handling x:Name and namescopes (creading a new node, skipping the x:Name setting)

So in the NameScopeVisitor, should I be creating a new namescope when I've got a VisualStateGroups element which is not part of a Style?

hartez · 2017-12-21T22:41:38Z

if you do not define your VSM in Style, XamlG will probably try to generate multiple fields with the name "Normal".
This should be fixed now.

tpetrina · 2017-12-22T08:52:06Z

Xamarin.Forms.Core/VisualStateManager.cs

+
+		internal VisualState GetState(string name)
+		{
+			foreach (VisualState state in States)


If this method is called often, does it make sense to switch to for loop? Or is this premature optimisation?

I didn't think there'd be a significant difference, since the underlying implementation is using List. But just to be certain I wrote up some quick-and-dirty benchmarking tests to see if for would make any difference vs foreach here.

For the first batch, I created VisualStateGroupLists with 1 group, and the group had 2 states (which I think will be a pretty common scenario). I then had the test run through 100,000 iterations of moving randomly between the states (using the GoToState method). Between the two implementations (foreach and for), the test runs took the same amount of time on average.

For the second batch, I created an uglier scenario with VisualStateGroupLists with 10 groups, each group having 10 states. Running that over 100,000 iterations, the foreach actually ended up being slightly faster.

Looking at the tests in the profiler, the bulk of the time spent in the method (in either implementation) is the string comparison. The looping method doesn't end up making much difference.

So for the time being I think we'll stick with foreach for clarity. If we start running into performance problems with this later, we can revisit it.

The difference isn't in performance but in allocation. foreach generates an iterator which adds some GC pressure. It probably doesn't matter much though.

The enumerator for List is a struct, so it's pretty low-impact.

StephaneDelcroix · 2017-12-22T21:46:20Z

Xamarin.Forms.Build.Tasks/SetNamescopesAndRegisterNamesVisitor.cs

@@ -117,7 +123,7 @@ void SetNameScope(ElementNode node, VariableDefinition ns)
 		void RegisterName(string str, VariableDefinition namescopeVarDef, IList<string> namesInNamescope, VariableDefinition element, INode node)
 		{
 			if (namesInNamescope.Contains(str))
-				throw new XamlParseException($"An element with the name \"{str}\" already exists in this NameScope", node as IXmlLineInfo);
+				throw new XamlParseException($"An element with the name \"{str}\" already exists in this NameScope 1", node as IXmlLineInfo);


rmarinho · 2018-01-02T16:20:37Z

failed test not related

…d colors

Make Background color work on UWP Entry with VSM

…ectly on VisualElements

rmarinho

It's good stuff, i wonder if we should make useLegacy color a Flag instead of PS ..

rmarinho · 2018-01-04T22:23:34Z

Xamarin.Forms.Controls.Issues/Xamarin.Forms.Controls.Issues.Shared/DefaultColorToggleTest.cs

@@ -6,19 +6,19 @@
 namespace Xamarin.Forms.Controls
 {
 	[Preserve (AllMembers=true)]
-	[Issue (IssueTracker.None, 0, "Default colors toggle test", PlatformAffected.All)]
+	[Issue (IssueTracker.None, 9906753, "Default colors toggle test", PlatformAffected.All)]


you can drop the 990 now

No, I like the number 9906753.

* Added the new Contacts.GetAllAsync * Removed the ContactType enum as it was not quite ready (see more #1545) * Added more members to the Contact type Co-authored-by: sung-su.kim <sung-su.kim@samsung.com> Co-authored-by: Matthew Leibowitz <mattleibow@live.com>

hartez added a/Xaml </> p/Android p/iOS 🍎 p/UWP platform-specifics t/enhancement ➕ labels Dec 14, 2017

StephaneDelcroix reviewed Dec 15, 2017

View reviewed changes

StephaneDelcroix suggested changes Dec 15, 2017

View reviewed changes

StephaneDelcroix added this to Ready in v3.1.0 via automation Dec 15, 2017

StephaneDelcroix moved this from Ready to In Review in v3.1.0 Dec 15, 2017

StephaneDelcroix reviewed Dec 15, 2017

View reviewed changes

nickrandolph reviewed Dec 16, 2017

View reviewed changes

tpetrina reviewed Dec 22, 2017

View reviewed changes

StephaneDelcroix reviewed Dec 22, 2017

View reviewed changes

hartez force-pushed the vsm2 branch from 1265f9f to 0e824f1 Compare January 2, 2018 19:43

hartez added 5 commits January 3, 2018 09:39

Port from old VSM branch

d080faf

Add PS and notes

9ea983b

Checkpoint: entry text UWP mostly working, need to check on backgroun…

d0e3294

…d colors

Remove irrelevant samples from the EntryDisabledStatesGallery

dd05ee3

Make Background color work on UWP Entry with VSM

Add platform specific for disabling legacy colors on Android

9ab3ceb

hartez added 13 commits January 3, 2018 09:40

Direct casts

5eddf52

Use GetIsDefault check in GoToState

be5bc25

Validate parents in FindTypeForVisualState

e024981

Validate group and state names on Add

001372a

Fixed check for setter collection

f533120

Fix issues with "duplicate" names when VisualStateGroups declared dir…

acde4e3

…ectly on VisualElements

Add gallery example for VSGs directly on VisualElements

9cdd3be

Update docs

58673eb

Fix bug where initial TextColor isn't set for FastRenderer Button

cfc7a45

Move to explicit VisualStateGroupList in Setter

d84aaf5

Fix return types for unit tests

48ba9e1

Using string.CompareOrdinal in GetState

1a978d5

Update docs

26a240a

hartez force-pushed the vsm2 branch from 0e824f1 to 26a240a Compare January 3, 2018 16:54

jassmith approved these changes Jan 4, 2018

View reviewed changes

rmarinho approved these changes Jan 4, 2018

View reviewed changes

Add check for null/empty VisualState Name properties

84e121a

rmarinho merged commit 28948d7 into master Jan 5, 2018

v3.1.0 automation moved this from In Review to Done Jan 5, 2018

hartez deleted the vsm2 branch January 24, 2018 15:57

samhouts added the API-change Heads-up to reviewers that this PR may contain an API change label Apr 3, 2018

samhouts added this to the 3.0.0 milestone May 5, 2018

samhouts removed this from Done in v3.1.0 May 7, 2018

samhouts modified the milestones: 3.0.0, 2.5.0 Aug 23, 2019

samhouts modified the milestones: 3.0.0, 2.5.0 Oct 29, 2019


		var isEnabled = (bool)newValue;

		VisualStateManager.GoToState(element, isEnabled

VisualStateManager phase 1 #1405

VisualStateManager phase 1 #1405

Conversation

hartez commented Dec 14, 2017 • edited by samhouts Loading

Description of Change

Bugs Fixed

API Changes

PR Checklist

dnfclas commented Dec 14, 2017 • edited Loading

hartez commented Dec 14, 2017

StephaneDelcroix left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

StephaneDelcroix Dec 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

StephaneDelcroix left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hartez Dec 15, 2017 • edited Loading

Choose a reason for hiding this comment

StephaneDelcroix Dec 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

StephaneDelcroix commented Dec 16, 2017 via email

hartez commented Dec 17, 2017 • edited Loading

hartez commented Dec 21, 2017

Choose a reason for hiding this comment

hartez Dec 27, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rmarinho commented Jan 2, 2018

rmarinho left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hartez commented Dec 14, 2017 •

edited by samhouts

Loading

dnfclas commented Dec 14, 2017 •

edited

Loading

StephaneDelcroix left a comment •

edited

Loading

StephaneDelcroix Dec 15, 2017 •

edited

Loading

StephaneDelcroix left a comment •

edited

Loading

hartez Dec 15, 2017 •

edited

Loading

StephaneDelcroix Dec 15, 2017 •

edited

Loading

hartez commented Dec 17, 2017 •

edited

Loading

hartez Dec 27, 2017 •

edited

Loading