Mvvmcross: IMvxAndroidBindingResource singleton refactor

[fedemkr]

🏗 Enhancement Proposal

Change IMvxAndroidBindingResource registration and use to be changed with a particular implementation.

Pitch

Nowadays the IMvxAndroidBindingResource is implemented like:

```c#
MvxAndroidBindingResource
: MvxSingleton
, IMvxAndroidBindingResource

and it's used like:

`MvxAndroidBindingResource.Instance.ListViewStylableGroupId` which doesn't allow changing the implementation of `IMvxAndroidBindingResource`.

In my opinion the interface should be resolved and then used so that anyone can have their own implementation which would be more performant than the generic one of MvvmCross like:

```c#
public class CustomMvxAndroidBindingResource : MvxSingleton<IMvxAndroidBindingResource>, IMvxAndroidBindingResource
{
    public static void Initialize()
    {
        if (Instance != null)
            return;

        var androidBindingResource = new CustomMvxAndroidBindingResource();
    }

    public int BindingTagUnique => Resource.Id.MvxBindingTagUnique;

    public int[] BindingStylableGroupId => Resource.Styleable.MvxBinding;
    public int BindingBindId => Resource.Styleable.MvxBinding_MvxBind;
    public int BindingLangId => Resource.Styleable.MvxBinding_MvxLang;

    public int[] ControlStylableGroupId => Resource.Styleable.MvxControl;
    public int TemplateId => Resource.Styleable.MvxControl_MvxTemplate;

    public int[] ListViewStylableGroupId => Resource.Styleable.MvxListView;
    public int ListItemTemplateId => Resource.Styleable.MvxListView_MvxItemTemplate;
    public int DropDownListItemTemplateId => Resource.Styleable.MvxListView_MvxDropDownItemTemplate;

    public int[] ExpandableListViewStylableGroupId => Resource.Styleable.MvxExpandableListView;
    public int GroupItemTemplateId => Resource.Styleable.MvxExpandableListView_MvxGroupItemTemplate;
}

In an app that I'm testing now, changing this decreases ~300ms the startup time of the application in DEBUG, by overriding InitializeBindingResources with the initiailzation of this CustomMvxAndroidBindingResource

So, I think there are different ways to solve it:

• Resolve the interface every time it's needed in the code
• Use another class to cache the implementation of the interface and call it from there without needing to resolve it everytime (just the first one in that particular cache class)
• Change the MvxSingleton implementation to somehow replace the Instance of the singleton with a different one (but it may break the general pattern)

Platforms affected (mark all that apply)

• [ ] :iphone: iOS
• [x] :robot: Android
• [ ] :checkered_flag: WPF
• [ ] :earth_americas: UWP
• [ ] :apple: MacOS
• [ ] :tv: tvOS
• [ ] :monkey: Xamarin.Forms

[Cheesebaron]

Not sure why this was implemented this way, since there is, as you say, no opportunity for someone to swap out this singleton, unless you also swap out IMvxAndroidViewBinder.

I would argue that these Id's will probably never change and we don't really need to reflect over the Styleables, but simply use the Id's the Resource.Stylable class provides.

If you really want to, you could probably remove MvxSingleton from this class and just register this as any other interface. Then as you propose yourself resolve this in MvxAndroidViewBinder when needed. I would probably cache the instance in there.

Do you want to make a PR for this?

[fedemkr]

I think even if you swap out the IMvxAndroidViewBinder it's still not possible because of how the MvxAndroidBindingResource singleton is directly used, e.g. in https://github.com/MvvmCross/MvvmCross/blob/bdaa09299714d94cf3f2c548a465d994c20d52f0/MvvmCross/Platforms/Android/Binding/Views/MvxAttributeHelpers.cs#L22-L24

However, yes, I'll make the PR as soon as I can 😄

[jstawski]

Thank you @fedemkr for working on this. We are in need of this change to be able to improve performance of the FishAngler app. @Cheesebaron do you think this can be implemented as part of a minor release as it shouldn't break existing apps if nothing is changed by the developers of the app?

[Cheesebaron]

In terms of API this won't be breaking, since none of the interfaces are changing. So I guess this is good to go in a minor release.