Xamarin.forms: [Enhancement] Compiled bindings

[andreinitescu]

Rationale

Compile bindings is a way to have compiler generate static code for a data binding rather than using dynamic data binding that depends on reflection (which is notoriously slow).

Have something similar to the "x:Bind" compiled bindings in Windows 10. This would bring some very very nice performance improvements.

See https://channel9.msdn.com/Events/Build/2015/3-635

Implementation

I don't have any implementation details but I assume a lot of what is currently being used in XAML-C can be used for this one too.

Next, I will just show an example, (shamelessly stealing example from http://danielhindrikes.se/windows-10/using-compiled-bindings-in-your-windows-10-universal-app/)

<ListView ItemsSource="{x:Bind ViewModel.Items}">
 <ListView.ItemTemplate>
   <DataTemplate x:DataType="model:ItemModel">
     <TextBlock Text="{x:Bind Title}" />
   </DataTemplate>
 </ListView.ItemTemplate>
</ListView>

The Page class must implement the strongly typed property which will be used to compile bindings at compile time:

public class ItemsPage : Page
{
   public ItemsViewModel ViewModel { get { return DataContext as ItemsViewModel; } }     
}

public class ItemsViewModel 
{
      public IEnumerable<ItemModel> Items { get; set; }
}

public class ItemsViewModel 
{
      public IEnumerable<ItemModel> Items { get; set; }
}

public class ItemModel 
{
      public string Title { get; set; }
}

Implications for CSS

TBD

Backward Compatibility

N/A (it's a new feature)

Difficulty : TBD

[adrianknight89]

This is actually on the roadmap.

[andreinitescu]

@adrianknight89 perfect. It will bring great speed improvements I think. I wish much of the vNext2 roadmap replaced the vNext.

[adrianknight89]

I think it'd be great if there was a voting system so we could help decide what's on vNext. Right now, it's entirely up to the team to decide which features have priority.

[andreinitescu]

@adrianknight89 I hope you agree compiled bindings needs no voting. But I see what you're saying and I agree.

[davidortinau]

We already have Compiled Bindings and x:Bind is in progress.

Is there more to this proposal that wouldn't be covered on those?

@StephaneDelcroix thoughts?

[davidortinau]

@adrianknight89 I'm open to seeing some voting. @pauldipietro has some ideas we are entertaining.

it's entirely up to the team to decide

You're accounting for the direct feedback from hundreds of developers, working hands-on with companies, talking to the community and contributors here, the forums, and of course the twitter-verse, right? ;) You make it sound like we're huddled off in an underground bunker (though I don't dismiss it may feel that way at times).

Really, we are listening and trying hard to co-plan the roadmap and these releases. The f100 and community-sprint are a direct result of that.

[adrianknight89]

@davidortinau I apologize if my wording came out wrong, but I actually did not mean the team ignores everybody and goes cowboy shooting bugs/features on its own. Obviously, there is a lot of feedback mechanism, and I'd claim that this repository is one of the most welcoming / least dismissing of community contributions on GitHub.

However, I still stand by the team having the ultimate say (which is natural of course) even after all those things you listed. While the community is able to give feedback, I think a voting mechanism of some sort would make this much easier. Not everybody comments on forums, sends PMs, asks questions, etc., but a voting button requires minimal effort and can help you (us) pick out the hottest bugs/features people want fixed/implemented. The goal here is to get feedback even from the most passive/idle users and create a more accurate picture of public demand.

There is also the fact that some recent work like CSS and FlexLayout seemed to have required months of development, and I'm still not convinced these were the most sought-after features with the highest priority needed to be given.

Then, there is the widening breadth of platform support (which is a good thing in the very long run) that will inevitably slow down the team (even if PRs are being driven entirely by the community or third-parties) because it requires more code reviews, analyzing test results, and preparing release packages.

When XF first came out, it was a cross platform mobile development framework. Now, it's evolving to become a cross platform mobile and desktop framework, which ultimately reduces work on the most important bits: Android, iOS, and UWP (used to be only Windows phone). The first two account for 98% market share and should be the most attention-grabbers in the team no matter what.

I don't have full visibility into what each team member is responsible for, but from what I could tell, different people tend to focus on different parts like Stephane doing most of the XAML work, Rui and Elija being jack of all trades, and Samantha focusing on iOS. If I were you, I'd add an additional Android dev, another iOS dev, and finally somebody whose job is to write lots and lots of automated UI tests to help speed up development and increase robustness. :)

Sorry about the little rant. We all love the team in the end!

[StephaneDelcroix]

@StephaneDelcroix thoughts?

close this, for the reason you invoked, and because the thread has seriously derailed, again.

[andreinitescu]

A bit of a turnoff. I wish this discussion didn't exist and I wish this ticket remained open even if it's on the roadmap. Doesn't roadmap items need tickets too?

[davidortinau]

@adrianknight89 I hear you and I'm always looking for ways to improve.

I'd claim that this repository is one of the most welcoming / least dismissing of community contributions on GitHub.

Awesome! I'm very pleased to hear that. Not everything is going to be rainbows and butterflies, but as long as we're all working towards the better of the project then we'll have success.

the most sought-after features with the highest priority

One does not necessarily mean the other in every case. Some work, such as CSS and FlexLayout, may have occurred over the course of months, but it's inaccurate to say they "required months of development".

This is a more complicated discussion than can be had here, so perhaps we can take it up elsewhere. Suffice to say I'm always looking for stronger "signals" to inform our priorities, evaluating the quality of those signals, and open to adjusting.

the widening breadth of platform support

A quick plug, I posted a Platform Support wiki a few weeks back to show who is maintaining each platform and the state.

I'd add an additional Android dev, another iOS dev, and finally somebody whose job is to write lots and lots of automated UI tests

Bring it on! I wouldn't turn away more help. :)

Sorry about the little rant. We all love the team in the end!

I thought you kept it constructive and that's all I could ask for! We love the community and contributors!

[davidortinau]

@andreinitescu I think this is something caught in the transition from managing dev tasks internally to GitHub Issues and Projects. We definitely have some room to improve. I'll see what needs to be done to get in sync.

[migueldeicaza]

Voting wise: we discussed a possibility- we can add reactions to the top post.

As for actual feature scheduling that is a more complex topic, it is a decision based on how much time we devote, when it stabilizes, and what vehicle we ship it on. In recent years we have embraced developing features in branches and merging when they are ready.

[andreinitescu]

@davidortinau @migueldeicaza Supporting everything from the compiled bindings in Windows 10 might take longer, but adding at least the basic support for x:Bind to XF should be more than beneficially.

The work which was done for XAML-C should provide more than enough background and knowledge to be able to at least generate static code which calls a public property defined on the derived Page class:
{x:Bind MyProperty.AnotherProperty}

I'm sure you can see the benefit of not having to use reflection used by the current data binding.

[andreinitescu]

Also, like I said above, there should be issues created for items on the roadmap. And I wish this ticket wasn't closed and didn't become a place for conversation....