ExRam/ExRam.MvvmCross.ObservableBinding — pull request #1 by slodge (2014-02-09 18:58:26+00:00)
Title: My attempt....

Hi Daniel

Here was my "quick hack" to get the observables working.

I'm afraid I hit a lot of nuget, PCL and test project issues so the project files are in a bit of a mess.... but the actual changes I've made are very small and the Droid example project works with just one change (the change in registered extension)

Thanks again for the interesting chats and for your patience and skill explaining stuff to me. See you online somewhere to discuss more :)

Stuart

Here also is my overall feeling after the last 2 days of talking:

-----------

The current binding extension interface is based on:

public interface IMvxSourceBindingFactoryExtension
{
bool TryCreateBinding(object source, MvxPropertyToken propertyToken, List remainingTokens, out IMvxSourceBinding result);
}

The `TryCreateBinding` method here was designed on the INPC requirements.

These requirements led to this interface being designed to mean:

- try to build the binding step for `propertyToken` which is a child of `source` and which will have the children in `remainingTokens`

This is how this interface is implemented by **all of** the existing extensions:

- property (including INPC)
- field (including INC)
- method (for ICommand)

Within this interface it is perfectly possible to implement an `IObservable` binding factory - but this **requires** that binding factory to do the reflection to get the PropertyInfo (or FieldInfo) for `propertyToken`. This is what I recommend for the short term.

To show how simple this could be I've added a quick `OldSkoolObsevableExtension` class.

----

Longer term, other implementations are possible. These could involve replacement of the `IMvxSourceBindingFactoryExtension` with some other extension interface and/or replacement of the default `MvxSourceBindingFactory` and INPC binders within MvvmCross.

These implementations might offer the advantages:

- improved "separation of concerns" - so that the `IObservable` module does not have to use reflection to get the Property values
- improved nestability - so that it's possible to use properties which participate in all of INPC, INC and IObservable simultaneously - e.g.a property really could be defined as `public INC>>>> Bar { get;set; }` and all layers would be resolved by Mvx binding.
- improved efficiency - because a little less reflection would be needed

There are also potential disadvantages - especially in:

- the nestability could cause user confusion - currently each step in a binding `Foo.Bar.Fo.Fum` corresponds to one binding step, but this would not be the case with nestability.
- there's new code to write, test and debug :)

If going for a new implementation, I'd personally prefer to build this around a new source binding factory interface (or new interfaces) rather than trying to squeeze this into the existing interface which is currently well-defined (IMO), but which might be built too closely to `INPC` fundamentals. It feels like this should be possible to do this via recursion (or flattened recursion using tail-calls) without adding things like a list of "don't call me again" extensions. If the advantages are good enough, then I'm happy to look at how to do this :)