x：在UWP中绑定（通用Windows平台）

Question

Right. So moving from WPF to UWP, I'm trying to use x:Bind to get compile-time benefits. Simple scenarios work fine; however I have found a number of issues that I was not able to solve. They are all related, so I thought I'd post them in one place:

1. I haven't been able to make Intellisense work with x:Bind . I have set DataContext (as well as d:DataContext just as we do in WPF) both in XAML and in the constructor, but it won't show members no matter what. Has anyone done this successfully?
2. Then I read somewhere that in UWP, DataContext is always set to Page 's code-behind (really??) and that I need to define a ViewModel type property in the code-behind and then use that property in x:Bind . Is this correct? I tried it and it works but gives rise to the next question.
3. If I define a property of ViewModel type in Page's code-behind, Any sub-properties that raise PropertyChanged notifications do not update the UI. For example, if the code-behind property is named Game (of type GameVM ) and there is a public property in GameVM named Player (of type GamePlayer ), and in turn GamePlayer contains a property named Name , the x:Bind path will look like {x:Bind Path=Game.Player.Name} . But if I do this, any change notifications raised from within Name property do not update Page's UI.

One alternate I tried was to listen to PropertyChanged at each level and then bubble it up the hierarchy, but that hasn't worked. Even if it does, doing this seems a bit too much work. In WPF sub-properties like Game.Player.Name work properly without having to doing property change bubbling. Or am I missing something?

Answer 1

Right. After playing with it for a few days and searching numerous references, here are my findings:

1. {x:Bind} lacks design-time support. The feature is on the wishlist though. You may want to upvote it there. (The new version of Visual Studio 15.4.4 does support Intellisense in {x:Bind}in the required way.)
2. {x:Bind} uses code-behind as its DataContext. So you need to define a public property of your ViewModel type in the code-behind and then use it in your {x:Bind} path.
3. As pointed out by IInspectable, the default mode for {x:Bind} is OneTime , unlike {Binding} which uses OneWay or TwoWay in almost all cases. So you need to explicitly specify Mode in your binding. People coming from WPF should take special care of it.
4. Sub-properties that implement notification change work perfectly fine in {x:Bind} . There is no need of bubbling these notifications upwards in the property hierarchy. The problem I was facing (#3 in the question) was because my sub-property was of type List<T> . I changed it to ObservableCollection<T> and it started working.

Hope this works somebody down the road.

Answer 2

Well as a beginner, the only question I can answer for you is the first one. Intellisense does not work inside the {x:Bind}. The members are never shown there in UWP for some unknown reasons. As for the next two questions of yours, I am still working on them.

Answer 3

I ran into the same challenge that you have seen. In my experience, in order to create the compile-time binding and have it update with custom objects as properties, the Page class seems to need to know about the data context and custom objects... all you need to do is reference them in the code behind, and then bind to them in the XAML. This creates the code generation objects it needs.

For example, I have a viewmodel, CustomerViewModel that is bound in XAML. That viewmodel also has a property of type IGuest. In order to use the guest object and have it update properly, I came up with this in the code behind...

        CustomerViewModel vm
        {
            get
            {
                return (CustomerViewModel)DataContext;
            }
        }
      IGuest g
        {
            get
            {
                return vm.CurrentGuest;
            }
        }
        public CartGuestControl()
        {
            this.InitializeComponent();
        }

You don't need to assign any of the UI data contexts from the code behind... simply reference the datacontext that is bound in XAML. When binding to any straight viewmodel properties, I use {x:Bind Path=vm.IsEditing, Mode=OneWay }. For binding to any of the guest properties, it looks like this, {x:Bind Path=g.FirstName, Mode=TwoWay}. You could do something like this for your Player object.

I have run into times where x:Bind simply won't do what I expect it to do no matter what I try. This can usually be solved by breaking things out into smaller user controls with more specific data contexts or by using "regular" Binding.