Xamarin.forms: Update Dependency Resolver to include Dependency Type

[dansiegel]

Description

Due to the need to include an Android.Content.Context for Android Renderers, the DependencyResolver uses Resolve(Type type, params object[] args) The problem with these args is that they are ultimately meant to be used by a DI Container to pass in as constructor arguments but we have no way of knowing that args[0] is meant to be Context without explicitly checking for the type which is not something that we can really do from shared code. It also means that this is not flexible to easily use across other platforms.

This becomes an issue as injecting a dependency at Resolve time generally requires that we know what the type is supposed to be.

// Autofac
parameters.Add(new TypedParameter(typeof(Android.Content.Context), context));
container.Resolve(type, parameters.ToArray());

// DryIoc
var resolver = container.Resolve<Func<Android.Content.Context, object>>(type);
resolver.Invoke(context);

// Unity
overrides.Add(new DependencyOverride(typeof(Android.Content.Context), context));
container.Resolve(type, overrides.ToArray());

Proposal

Change object[] to another type that can be can wrap both the expected type and instance.

public class DependencyObject
{
    public Type Type { get; set; }
    public object Instance { get; set; }
}

DependencyResolver.Resolve(typeof(BoxRenderer), new DependencyObject{ Type = typeof(Context), Instance = someInstance });

This ensures that most DI Containers should be able to support this, and that it will be extensible from shared code moving forward regardless of what changes are made regardless of platform.

Basic Information

• Version with issue: 3.1
• Last known good version: n/a
• IDE: n/a

[hartez]

I like everything about this except calling it DependencyObject, since that term already has another meaning in UWP/WPF. I think maybe I like the the Autofac naming (TypedParameter) - that expresses the intent pretty well.

[dansiegel]

@hartez TypedParameter works for me... it was more to express intent than the hardest part of programming... naming... Any chance we can sneak this in for the 3.1 release since DependencyResolver is a new feature for 3.1?

[hartez]

3.1 probably isn't an option (we're too close to the release date), but 3.2 is doable.

[hartez]

I may have spoken too soon on getting this into 3.2.

[StephaneDelcroix]

We plan to deprecate our DependencyService in the near future. merging this now would send the wrong signal. So I'm closing this for now.

If our plans change and we keep our DependencyService, we'll reopen this.

[AdamDiament]

We plan to deprecate our DependencyService in the near future. merging this now would send the wrong signal. So I'm closing this for now.

If our plans change and we keep our DependencyService, we'll reopen this.

@StephaneDelcroix I use the dependency service a lot for injecting the correct implementation of cross platform service interfaces on iOS/Android into my PCL. I find it easier and less overhead than using a full blown iOC container, and less bug prone for hard to find release only / linker bugs in autofac etc. I'd be really sad to see DependencyService leave xamarin forms. Is there a drop in replacement planned or is Microsoft wanting everyone to move to an IOC container for this?

[StephaneDelcroix]

@AdamDiament there's a drop in lightweight replacement planned