Xamarin & .NET Developer Events in August
Late last summer I wrote a post on creating a custom bindable property using Xamarin.Forms. I titled it “Back to School” because I wrote it around … well … back to school time. Since then however, the Xamarin.Forms team has seen fit to deprecate the function I wrote about that creates the bindable property … and we’re still in the middle of summer!
Ugh – it hasn’t even been a year!
Well, I guess it’s only right of me to update a partially out of date post with the name “back to school” in it … So welcome to Back to School Part 2: Revenge of the Custom Bindings!
I won’t go as in-depth as I did in Part 1, as the details I talk about in that post still stand – however, the API signature to create the binding has changed a bit, and that’s what I want to talk about here.
The API Changes
For the sake of example, I’m going to call the non-deprecated API the “new” API, although it has been around for a while.
New API
BindableProperty.Create (NEW)
C#
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
publicstaticBindableProperty Create(
stringpropertyName,
Type returnType,
Type declaringType,
objectdefaultValue,
BindingMode defaultBindingMode=BindingMode.OneWay,
BindableProperty.ValidateValueDelegate validateValue=null,
BindableProperty.BindingPropertyChangedDelegate propertyChanged=null,
BindableProperty.BindingPropertyChangingDelegate propertyChanging=null,
BindableProperty.CoerceValueDelegate coerceValue=null,
BindableProperty.CreateDefaultValueDelegate defaultValueCreator=null);
|
Old API
BindableProperty.Create (OLD)
C#
|
1
2
3
4
5
6
7
8
9
10
11
|
publicstaticBindableProperty Create<TDeclarer,TPropertyType>(
Expression<Func<TDeclarer,TPropertyType>>getter,
TPropertyType defaultValue,
BindingMode defaultBindingMode=BindingMode.OneWay,
BindableProperty.ValidateValueDelegate<TPropertyType>validateValue=null,
BindableProperty.BindingPropertyChangedDelegate<TPropertyType>propertyChanged=null,
BindableProperty.BindingPropertyChangingDelegate<TPropertyType>propertyChanging=null,
BindableProperty.CoerceValueDelegate<TPropertyType>coerceValue=null,
BindableProperty.CreateDefaultValueDelegate<TDeclarer,TPropertyType>defaultValueCreator=null)where TDeclarer:BindableObject;
|
Buy Why?!?
At first glance the old API looks a bit messier, but once you dig in you find that in fact it really is more elegant. The generics in the old signature provide a means to strongly type everything that follows (plus the added bonus of IDE provided intellisense). Not to mention there are less parameters – we don’t have to explicitly define the return and declaring type.
So if the old API was so great – then why did it change? That’s exactly what I asked Twitter. And Twitter did what Twitter does … Adam Patridge (fellow Xamarin MVP) came back with the answer:
@CodeMillMatt I did love the syntax. I think it was an iOS AOT bloat issue. `nameof` to the rescue, though! https://t.co/TNHZ6W9dSJ
— Adam Patridge (@PatridgeDev) July 21, 2016
If you click on through to Jason Smith’s & Adam’s conversation, it turns out that there’s a ton of bloat introduced with the old BindableProperty.Create() API by iOS and its AOT compiling (interested in Xamarin.iOS at that level? Here you go.)
OK – so the API is deprecated for our own (and our app’s) good! So let’s now look at using the other / new one.
Creating the Bindable Property
The API signature is pretty straight forward, with the first 4 parameters being required (and I always specify the default binding mode, the fifth parameter, as well – if only to be explicit).
For this example, imagine that we’re extending a normal Label control, and adding a boolean property to it that we want to be able to bind to our view model. The class will be called NewLabel and the property will be called IsNew . (Original, I know.)
The bare minimum we have to do to create the binding is the following:
Bare minimum binding
C#
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
publicboolIsNew
{
get{return(bool)GetValue(IsNewProperty);}
set{SetValue(IsNewProperty,value);}
}
publicstaticreadonlyBindableProperty IsNewProperty=BindableProperty.Create(
nameof(IsNew),
typeof(bool),
typeof(NewLabel),
false,
BindingMode.TwoWay
);
|
After that in the BindableProperty.Create function are all of the delegates. Their purpose stays exactly the same. The only thing that changes is that the parameters representing the value of the binding (in our case the boolean) are no longer strongly typed.
Let’s take a quick look at them:
- publicdelegate boolValidateValueDelegate(BindableObject bindable,objectvalue);
- publicdelegate voidBindingPropertyChangedDelegate(BindableObject bindable,objectoldValue,objectnewValue);
- publicdelegate voidBindingPropertyChangingDelegate(BindableObject bindable,objectoldValue,objectnewValue);
- publicdelegate objectCoerceValueDelegate(BindableObject bindable,objectvalue)
- publicdelegate objectCreateDefaultValueDelegate(BindableObject bindable);
So when implementing these delegates, BindableObject will always be the thing that’s getting bound to … or our NewLabel instance. Then we’ll have to cast any “value” parameters to the type of value we’re dealing with. For a full explanation of what each of these delegates does and the order they are invoked – see the original post.
Summary
That’s it! The API signature that provided the ability to create a bindable property, including delegates to handle the verification and changing of the value of the property in a strongly typed manner is gone. It’s gone for a good reason – it led to bloating app sizes.
We’re still able to create the custom binding – but not in a strongly typed manner any longer. So we’re trading off having to do a lot of casting in exchange for smaller app sizes.
I’ll take it.
Matthew Soucoup
Matthew is a Xamarin MVP and Certified Xamarin Developer from Madison, WI. He started Code Mill Technologies and is the founder of the Madison Mobile .Net Developer’s Group.
Matt regularly speaks on .Net and Xamarin development at user groups, code camps and conferences throughout the Midwest, including Xamarin Dev Days – Madison, That Conference, St. Louis Days of .Net, and CodeMash.
When he’s not developing cross platform apps, writing blog posts, or creating the next great talk, Matt enjoys brewing beer with jalapeños from his garden and playing 80s tunes on the piano.
Related posts
