SIDOVSKY / EBind

var binding = new EBinding
{
    () => view.Text == vm.Text,
    () => view.Text == vm.Description.Title.Text,
    () => view.Text == (vm.Text ?? vm.FallbackText),
    () => view.Visible == !vm.TextVisible,
    () => view.Visible == (vm.TextVisible == vm.ImageVisible),
    () => view.Visible == (vm.TextVisible && vm.ImageVisible),
    () => view.Visible == (vm.TextVisible || vm.ImageVisible),
    () => view.FullName == $"{vm.FirstName} {vm.LastName}",
    () => view.FullName == vm.FirstName + " " + vm.LastName,
    () => view.Timestamp == Converter.DateTimeToEpoch(vm.DateTime),

    BindFlag.TwoWay,
    () => view.Text == vm.Text,
    () => view.SliderValueFloat == vm.AgeInt,

    BindFlag.OneTime | BindFlag.NoInitialTrigger,
    () => view.ShowImage(vm.ImageUri),
    () => Dispatcher.RunOnUiThread(() => view.ShowImage(vm.ImageUri)),

    BindFlag.OneTime,
    (view, nameof(view.Click), vm.OnViewClicked),
    (view, nameof(view.TextEditedEventHandler), () => vm.OnViewTextEdited(view.Text)),
    (view, "CustomEventForGesture", vm.OnViewClicked),

    (view, nameof(view.Click), vm.ViewClickCommand),
    (view, nameof(view.Click), () => vm.ViewClickCommand.TryExecute(view.Text)),

    new UserExtensions.CustomEBinding(),
};

binding.Dispose();

^{snippet source | anchor}

Three types of bindings here

• EQUALITY – bind a property or an expression of them to another property.
  Every change of every property on the right (vm.Text) leads to an assignment of the property on the left (view.Text).
  Binding between two properties may work in a Two-Way mode.

  () => view.Text == vm.Text,

• ACTION – bind a method to its target and parameters.
  Every time vm.ImageUri is changed view.ShowImage is invoked with a new value.

  () => view.ShowImage(vm.ImageUri),

• EVENT – bind a method or command to an event.
  Every time view.Click is raised vm.OnViewClicked is called.

  (view, nameof(View.Click), vm.OnViewClicked),

Key points

• The main binding update trigger is INotifyPropertyChanged.PropertyChanged.
  Boilerplate code may be avoided with Fody.PropertyChanged.
  There are some platform-specific pre-configured triggers. Additional ones are easy to configure.

• Bindings invoke immediately after the construction, except for the event binding.
  To skip initial invocation prepend BindFlag.NoInitialTrigger.

• Each property and field in a binding expression triggers the binding update
  

• Default binding mode is One-Way, Source-to-Target (right to left).
  This is the most common use-case. Explicit declaration of a two-way mode will help to avoid unreasonable performance loss.
  May be overridden in EBinding.DefaultConfiguration.DefaultFlag.

• For Target-to-Source binding simply swap operands.
  It seems more natural than bringing in an additional BindFlag.OneWayToSource.

• Expressions of any complexity are supported.
  Even MONSTERS like that:

  () => view.Text == new Func<string?>(() => new Dictionary<string, string?>((int)10.0){ { "Key", vm.Text } }["Key"])(),

  However, the more complex the expression, the longer it takes to create and invoke the binding from it. See benchmarks for the reference.

• BindFlag applies to all subsequent bindings till the next flag.

Configuration and Extensibility

Pre-Configured Triggers

Member Triggers

In Configuration you may specify how to subscribe and unsubscribe for signals of property and field updates that are not tracked out of the box.
There are overloads for the property/field update handler as System.EventHandler, System.EventHandler<TEventArgs> or any other class:

EBinding.DefaultConfiguration.ConfigureTrigger<View, string>(
    v => v.Text,
    (v, h) => v.TextEditedEventHandler += h,
    (v, h) => v.TextEditedEventHandler -= h);

EBinding.DefaultConfiguration.ConfigureTrigger<View, View.TextEditedEventArgs, string>(
    v => v.Text,
    (v, h) => v.TextEditedGenericEventHandler += h,
    (v, h) => v.TextEditedGenericEventHandler -= h);

EBinding.DefaultConfiguration.ConfigureTrigger<View, Action<string>, string>(
    v => v.Text,
    trigger => _ => trigger(),
    (v, h) => v.TextEditedCustomEventHandler += h,
    (v, h) => v.TextEditedCustomEventHandler -= h);

^{snippet source | anchor}

Event Triggers

You may configure your own triggers for event bindings under custom identifiers even if they represent a Pub-Sub pattern differently from C# events (IObservable, Add/RemoveListener methods).

EBinding.DefaultConfiguration.ConfigureTrigger<View, View.GestureRecognizer>(
    "CustomEventForGesture",
    trigger => new View.GestureRecognizer(trigger),
    (v, h) => v.AddGestureRecognizer(h),
    (v, h) => v.RemoveGestureRecognizer(h));

^{snippet source | anchor}

The same identifier (event name) can be used with multiple classes.
For example on Xamarin.iOS a pre-defined Tap event can be used with both UIControl and UIView:

using EBind;
using static EBind.Platform.Configuration.ExtraEventNames;

var binding = new EBinding
{
    (uiButton, Tap, OnButtonClick),
    (uiImageView, Tap, OnImageClick),
};

Configuration of C# events is not required – they can be found by the name: nameof(obj.Event).
But it's recommended to specify subscription and unsubscription delegates to improve cold-start performance and avoid linker errors.

EBinding.DefaultConfiguration.ConfigureTrigger<View>(
    nameof(View.TextEditedEventHandler),
    (v, h) => v.TextEditedEventHandler += h,
    (v, h) => v.TextEditedEventHandler -= h);

EBinding.DefaultConfiguration.ConfigureTrigger<View, View.TextEditedEventArgs>(
    nameof(View.TextEditedGenericEventHandler),
    (v, h) => v.TextEditedGenericEventHandler += h,
    (v, h) => v.TextEditedGenericEventHandler -= h);

EBinding.DefaultConfiguration.ConfigureTrigger<View, Action<string>>(
    nameof(View.TextEditedCustomEventHandler),
    trigger => _ => trigger(),
    (v, h) => v.TextEditedCustomEventHandler += h,
    (v, h) => v.TextEditedCustomEventHandler -= h);

^{snippet source | anchor}

Event triggers configured for a class are available to all its children unless they have their own variation defined.

Triggers may be overwritten by onward setups including the pre-defined ones.

Binding Dispatcher

Sometimes ViewModel properties are set from the background thread that leads to data-binding view update triggering in the non-ui thread.

Establishing a proper thread switching in place is not possible for some code. Also, the risk of missing a thread is not acceptable or not worth caring about for some projects, and delegation of this problem is a good deal.
In this case, data-binding as a point of integration may be a good place to switch threads between the ui-threaded View and the thread-insensitive ViewModel layers.

Dispatchers which force the UI thread are set up in Configuration:

EBinding.DefaultConfiguration.AssignmentDispatchDelegate = Dispatcher.RunOnUiThread;
EBinding.DefaultConfiguration.ActionDispatchDelegate = Dispatcher.RunOnUiThread;

For Xamarin platform Xamarin.Essentials.MainThread.BeginInvokeOnMainThread will be the best option most of the time.

Custom Bindings

EBinding collection initializer accepts any form of IEBinding.
By implementing this simple interface you can create your own binding types and adapters for data-binding components of other systems (e.g. Rx.Net), use them in the same collection initializer, and keep all bindings in one place.

Custom binding creation can be encapsulated inside an extension method Add(this EBinding, ...) so that the binding inputs are accepted in the collection initializer (supported since C# 6).

After a custom binding is created, it must be added to the collection via EBinding.Add(IEBinding) so that it can be disposed along with other bindings.

public class CustomEBinding : IEBinding
{
    public void Dispose()
    {
    }
}

public static void Add(this EBinding bindingHolder, CustomEBinding binding,
    [System.Runtime.CompilerServices.CallerLineNumber] int sourceLineNumber = 0)
{
    try
    {
        if (binding == null)
            throw new ArgumentNullException(nameof(binding));

        if (bindingHolder.CurrentFlag == BindFlag.OneTime)
            throw new NotSupportedException();

        bindingHolder.Add(binding);
    }
    catch (Exception ex)
    {
        throw new Exception(
            $"Error in entry {bindingHolder.Count} at line #{sourceLineNumber}", ex);
    }
}

^{snippet source | anchor}

It's recommended to decorate exceptions during binding creation with additional information about the binding position (EBinding.Count) and its line number (CallerLineNumberAttribute) as debuggers do not highlight that.

Benchmarks

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19041.572 (2004/?/20H1)
AMD Ryzen 5 1600, 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=5.0.202
  [Host]     : .NET Core 5.0.5 (CoreCLR 5.0.521.16609, CoreFX 5.0.521.16609), X64 RyuJIT
  DefaultJob : .NET Core 5.0.5 (CoreCLR 5.0.521.16609, CoreFX 5.0.521.16609), X64 RyuJIT

Linking

The library is linker-safe internally, but some exposed APIs rely on Linq Expression trees and therefore the reflection which have always been hard to process for the mono linker.

Although linker can analyze expression trees and some reflection patterns pretty well, the following code units may not be mentioned in the code, appear unused and end up trimmed away:

• Property setters
• Events (which are not configured)

The most common solution for hinting the linker to keep a member is to imitate its usage with a dummy call and mark it with a [Preserve] attribute. Your project may already have a LinkerPleaseInclude.cs file for that purpose.

EBind.LinkerIncludeGenerator will generate such files for the mentioned members used in EBinding and there wont be any EBind-related linker issues in your project.
Adding its NuGet package is enough for the installation:

AOT Compilation

This library uses C# 9 function pointers to create fast delegates for property accessors. It's the safest solution for AOT compilation so far.
However, Xamarin.iOS AOT compiler used for device builds requires a direct indication of value-types as a generic type parameter for them.
All standard structs are pre-seeded.

If you came across an exception like that:

System.ExecutionEngineException:
  Attempting to JIT compile method 'object EBind.PropertyAccessors.PropertyAccessor`2<..., ...>:Get (object)' while running in aot-only mode.

please add a hint for the compiler:

EBind.Platform.AotCompilerHints.Include<MyStruct>(); // custom struct as a member
// or
EBind.Platform.AotCompilerHints.Include<MyStruct, PropertyType>(); // custom struct as a target

Contributions

If you've found an error, please file an issue.

Patches are encouraged and may be submitted by forking this project and submitting a pull request.
If your change is substantial, please raise an issue or start a discussion first.

Development

Requirements

• C# 9 and .NET 5 workload
• Xamarin.Android and Xamarin.iOS SDKs for device testing

Device Testing

Device tests may run manually from the test app UI or automatically with XHarness CLI.

Android:

xharness android test \
  --app="./EBind.Tests.Android/bin/Release/EBind.Tests.Android-Signed.apk" \
  --package-name="EBind.Tests.Android" \
  --instrumentation="ebind.tests.droid.xharness_instrumentation" \
  --device-arch="x86" \
  --output-directory="./EBind.Tests.Android/TestResults/xharness_android" \
  --verbosity

iOS:

xharness apple test \
  --app="./EBind.Tests.iOS/bin/iPhoneSimulator/Release/EBind.Tests.iOS.app" \
  --output-directory="./EBind.Tests.iOS/TestResults/xharness_apple" \
  --targets=ios-simulator-64 \
  --verbosity \
  -- -app-arg:xharness # to be passed in Application.Main(string[])

It's also a part of the github actions workflow. Check it out!

The Story

Once upon a time, there was a small but powerful library called Bind from the Praeclarum family.

No other library could be compared with it in terms of concision and beauty. Every developer was dreaming about using it in his project. But it had several problems and missed some optimizations. The bravest of us could dare to use it in production.

Beauty was stronger than fear and this is how another fork has begun.
Bugs were fixed, some optimizations were made but it was never enough. That library deserved to SHINE!

So...

• Factory method Create replaced with a collection initializer to make bindings a separate block and utilize more syntax variations.
• Binding chaining became redundant, operator && can be used in binding expressions now.
• Added flags that alter binding behavior, as a part of the collection initializer.
• Added support for binding properties/fields to functions (Action bindings).
• Added support for binding functions and commands to events (Event bindings).
• Binding triggers made configurable, all the basic ones for Xamarin are pre-defined.
• Manual invalidation doesn't seem necessary anymore – removed.
• Thread-safety improved by the means of dispatchers and concurrent collections.
• Performance brought to another level with expression interpretation, fast delegates (incl. C# 9 function pointers), and a different architecture.
• The library became more strict and informative in terms of exceptions and errors.
• Added a Source Generator that hints the mono linker about code usage.
• Unbind replaced by IDisposable, useful for aggregation (e.g. CompositeDisposable).

It ended up being completely rewritten with only some tests remained.

Credits

• @praeclarum & Praeclarum.Bind - ❤️ Code and Inspiration

License

This project is licensed under the Apache License, Version 2.0 - see the LICENSE and NOTICE files for details.