Allow users to specify resolution method for handlers, effects, and services #1870

hartez · 2018-02-13T00:02:58Z

Description of Change

Forms provides no option for users to construct and provide their own instances of handlers, effects, or services in a Forms application; instead, users must rely on Activator.CreateInstance. This greatly limits user control over the construction and lifetime of components.

This change provides a way for the user to inject their own dependency resolution method into Forms. When Forms needs a component instance of a particular type, the user's resolution method will be given the opportunity to provide the instance.

If no dependency resolution method is provided, Forms falls back to the previous behavior of creating the components as needed. If the dependency resolution method returns null for a requested component, Forms falls back to creating the components itself.

When resolving an Effect or handler (e.g., a customer renderer), specifying the resolution method is sufficient. If the user wants to resolve a service from the DependencyService, they will have to use the new Resolve<T>() method.

A brief example of using this with an IoC container

Bugs Fixed

Fixes [Enhancement] Allow hooking into an App's DI Container #1739

API Changes

Xamarin.Forms.Internals.DependencyResolver (new class)

public delegate object ResolveDelegate(Type type, params object[] args);
public static void ResolveUsing(ResolveDelegate resolveDelegate)
public static void ResolveUsing(Func<Type, object> resolveFunc)

Xamarin.Forms.DependencyService

public static T Resolve<T>(DependencyFetchTarget fallbackFetchTarget = DependencyFetchTarget.GlobalInstance)

Behavioral Changes

None

PR Checklist

Has tests (if omitted, state reason in description)
Rebased on top of master at time of PR
Changes adhere to coding standard
Consolidate commits as makes sense

#1739

dansiegel · 2018-02-13T01:05:19Z

Will the registrar need to be registered before Forms.Init()? Or will it be safe to register the registrar inside the App in shared code?

brianlagunas · 2018-02-13T02:44:36Z

Could you clarify the usage? For example, can we assume that this would be the expected implementation.

public partial class App : Application
{
    IContainer _someContainer = new SomeContainer();
    public App()
    {
        InitializeComponent();
        Registrar.ResolveUsing(type => _someContainer.Resolve(type));
        MainPage = new MainPage();
    }
}

brianlagunas · 2018-02-13T03:03:23Z

By the way, I think the name should be reconsidered. The term Registrar is not an accurate representation of what is happening. You aren't registering anything. You are providing a delegate/Action to be used in place of Activator.CreateInstance to create/resolve objects.

I think there are more appropriate names for this class. Here are some alternatives:

DependencyResolver
FormsResolver
Resolver

I am personally leaning towards DependencyResolver since this more accurately represents the function of the class. It resolves objects and supplies dependencies when using DI.

Really anything other than "Registrar" would be better :)

hartez · 2018-02-13T16:35:57Z

Will the registrar need to be registered before Forms.Init()? Or will it be safe to register the registrar inside the App in shared code?

There's no explicit requirement to set the resolution method before Forms.Init. It can be set any time.

hartez · 2018-02-13T16:54:58Z

Could you clarify the usage?

The example you give in your comment is a valid one.

The only constraint is that the Registrar needs to know about your resolution delegate if you want the Registrar to use it. If there are services in your container which your application needs during startup, you will have to notify the Registrar of your delegate early on. If your container is providing a particular type of Effect, the Registrar will need to know about the delegate before you try to create a control using that Effect. You can set the delegate as early or as late as you want, it just has to be available to the Registrar when the Registrar needs an instance of a type.

hartez · 2018-02-13T17:13:59Z

Adding a DNM; I want to think about some API changes.

dansiegel · 2018-02-13T17:17:01Z

There's no explicit requirement to set the resolution method before Forms.Init. It can be set any time.

@hartez thanks for the clarification, I wasn't 100% sure given the Gist... I would think that as long as you've set this prior to setting MainPage there shouldn't be a Renderer or Effect being created.

I might add, I do agree with @brianlagunas that the naming of Registrar feels a bit misleading.

hartez · 2018-02-13T17:20:58Z

To be clear: I didn't choose the name Registrar; that class has been around for a long time. It just happens to be (for better or worse) the place where (most) dynamic object creation in Forms occurs. It also does other stuff that makes the name of the class make more sense.

That said, as I was responding to @brianlagunas about the name, I realized there might be an opportunity here to split Registrar into more appropriately-named parts. I'm taking a look at that right now.

Remove Reset method; simplify internal API;

hartez · 2018-02-13T19:42:52Z

@dansiegel @brianlagunas I've extracted the dependency resolution / dynamic object creation bits of Registrar into a separate class called DependencyResolver. So now the injection point for your resolution delegate is DependencyResolver.ResolveUsing(), which makes a bit more sense.

rogihee · 2018-02-13T19:57:01Z

Does this PR also enables control/configuration on whether the Registrar will scan all assemblies for all known Effect/Renderer attributes? Still curious about the performance impact of that one.

hartez · 2018-02-13T20:15:23Z

Does this PR also enables control/configuration on whether the Registrar will scan all assemblies for all known Effect/Renderer attributes? Still curious about the performance impact of that one.

This PR doesn't address that.

I actually spent time working up a proof-of-concept on that exact feature a week or so ago. As it turns out, paring down the number of assemblies scanned for custom attributes does very little to affect startup performance. GetCustomAttributes is actually pretty fast. Even on the oldest, creakiest Android device I had available the time spent reflecting for the attributes was sub-millisecond for most assemblies. The overall performance gains of the feature ended up being noise even in a project with over 100 assemblies. (I was very disappointed.)

rogihee · 2018-02-14T16:03:18Z

Bummer! I had high hopes for it :-). Thanks for trying it out though!

kingces95

Will continue review after DependencyResolver L35-46 is covered.

kingces95 · 2018-02-15T23:18:47Z

Xamarin.Forms.Core/DependencyResolver.cs

+			return Resolver?.Invoke(type, args);
+		}
+
+		internal static object ForceResolve(Type type, params object[] args)


Suggest ResolveOrActivate

I went with ResolveOrCreate.

kingces95 · 2018-02-15T23:23:09Z

Xamarin.Forms.Core/DependencyResolver.cs

+{
+	public static class DependencyResolver
+	{
+		public delegate object ResolveDelegate(Type type, params object[] args);


Suggest we use Func<Type, object[], object>; Suggest we conserve the number of new Types introduced at the expense syntactic sugar at our call site; We can just put the args into a new object[] and save ourselves a bit of public surface area, no?

kingces95 · 2018-02-15T23:27:28Z

Xamarin.Forms.Core/DependencyResolver.cs

+		{
+			var result = Resolve(type, args);
+
+			if (result != null) return result;


Suggest we throw if Type is not assignable from the result.

kingces95 · 2018-02-15T23:34:27Z

Xamarin.Forms.Core/Effect.cs

 			{
-				result = (Effect)Activator.CreateInstance(effectType);
+				result = DependencyResolver.ForceResolve(effectType) as Effect;


Suggest considering cast instead of as; The result should either be of effectType or null, no?

kingces95 · 2018-02-15T23:51:02Z

Xamarin.Forms.Core/DependencyResolver.cs

+
+			if (result != null) return result;
+
+			if (args.Length > 0)


I'm not sure what case the following code handles; Suggest we add unit tests to cover 35:46.

The unit test at https://github.com/xamarin/Xamarin.Forms/pull/1870/files#diff-2b39f73ef46da5ad2d33b646bce4def9R150 covers this.

kingces95 · 2018-02-15T23:53:01Z

docs/Xamarin.Forms.Core/Xamarin.Forms.Internals/DependencyResolver+ResolveDelegate.xml

@@ -0,0 +1,31 @@
+<Type Name="DependencyResolver+ResolveDelegate" FullName="Xamarin.Forms.Internals.DependencyResolver+ResolveDelegate">


We might consider if some dev time now drafting some isense docs might preempt questions/confusion in the forums.

…lic delegate type;

* 'master' of https://github.com/xamarin/Xamarin.Forms: (23 commits) [C] use direct cast [Core, iOS, Android, UWP, WPF] Hide scroll view scroll bars (xamarin#1910) Allow users to specify resolution method for handlers, effects, and services (xamarin#1870) fixes xamarin#1739 [Build] Update submodule Capitalization keyboard flag additions for Entry/Editor (xamarin#1683) (xamarin#1833) [Build] Don't specify .net sdk version Simplify event raising invocation pattern (xamarin#1971) [iOS Maps] Pin rendering customization (xamarin#1065) set csharp_space_after_keywords_in_control_flow_statements to true to fit our design guide lines (xamarin#1964) [iOS] Add shadow effect (xamarin#1896) Added support for ListView full width separators on iOS (xamarin#1854) fixes xamarin#1665 Support CascadeInputTransparent to Tizen (xamarin#1916) [Android]?Remove UserVisibleHint (xamarin#1550) fixes xamarin#1438 [iOS] ViewDidLayoutSubviews after removing page (xamarin#1532) fixes xamarin#1426 Use relative URL to support recursive checkout in VSTS (xamarin#1926) [UITest] Fix test for UITest package update (xamarin#1923) Implemented MaxLength property on Entry and Editor (xamarin#1880) [Build]Fix master and build (xamarin#1920) [Build] Fix windows cert Fix to absolute URL ... # Conflicts: # Xamarin.Forms.Controls/CoreGalleryPages/EditorCoreGalleryPage.cs # Xamarin.Forms.Controls/CoreGalleryPages/EntryCoreGalleryPage.cs # Xamarin.Forms.Core/InputView.cs # Xamarin.Forms.CustomAttributes/TestAttributes.cs # Xamarin.Forms.Platform.Android/Renderers/EditorRenderer.cs # Xamarin.Forms.Platform.Android/Renderers/EntryRenderer.cs # Xamarin.Forms.Platform.MacOS/Renderers/EditorRenderer.cs # Xamarin.Forms.Platform.MacOS/Renderers/EntryRenderer.cs # Xamarin.Forms.Platform.Tizen/Renderers/EditorRenderer.cs # Xamarin.Forms.Platform.Tizen/Renderers/EntryRenderer.cs # Xamarin.Forms.Platform.WPF/Renderers/EditorRenderer.cs # Xamarin.Forms.Platform.WPF/Renderers/EntryRenderer.cs # Xamarin.Forms.Platform.iOS/Renderers/EditorRenderer.cs # Xamarin.Forms.Platform.iOS/Renderers/EntryRenderer.cs

dansiegel · 2018-03-22T15:25:40Z

hey guys can we please get this moved from vNext+1 to vNext... would really like to see this in v3.0

jbachelor · 2018-03-22T19:16:06Z

+1 for the suggestion from @dansiegel to move this up to vNext. I know my team could definitely benefit from this.

agriffith · 2018-03-22T20:18:11Z

We could use this sooner rather than later, as well.

hartez added 2 commits February 12, 2018 16:30

Let user set delegate to resolve handlers, effects, and services; closes

e3a8d31

#1739

Remove old comments

e33a440

hartez changed the title ~~Use di container~~ Allow users to specify resolution method for handlers, effects, and services Feb 13, 2018

hartez added the DO-NOT-MERGE-!!! 🛑 This is in progress and needs to be updated before it can be merged. label Feb 13, 2018

hartez added 2 commits February 13, 2018 12:30

Move dependency-resolution-specific code to a separate class;

2eaa4ba

Remove Reset method; simplify internal API;

Update docs to reflect new changes

76391ff

hartez removed the DO-NOT-MERGE-!!! 🛑 This is in progress and needs to be updated before it can be merged. label Feb 13, 2018

rmarinho requested review from jassmith and kingces95 February 14, 2018 16:43

samhouts added t/enhancement ➕ F100 labels Feb 14, 2018

jassmith approved these changes Feb 15, 2018

View reviewed changes

kingces95 suggested changes Feb 15, 2018

View reviewed changes

hartez and others added 3 commits February 16, 2018 17:20

Add type checks closer to resolution; rename ForceResolve; remove pub…

3d42cf8

…lic delegate type;

Update docs

30a8a35

Merge branch 'master' into use-di-container

75dd396

rmarinho merged commit 1030013 into master Feb 26, 2018

rookiejava mentioned this pull request Mar 9, 2018

[Tizen] Refactor the GestureDetector #2059

Merged

4 tasks

hartez deleted the use-di-container branch March 21, 2018 15:22

samhouts added the API-change Heads-up to reviewers that this PR may contain an API change label Apr 3, 2018

samhouts added this to the 3.1.0 milestone May 5, 2018

samhouts modified the milestone: 3.1.0 Jun 1, 2018

AmrAlSayed0 mentioned this pull request Aug 10, 2018

How do I use my own IoC container in DependencyService? #3522

Closed

samhouts added the partner Issue submitted by partner or related open source project label Jun 27, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow users to specify resolution method for handlers, effects, and services #1870

Allow users to specify resolution method for handlers, effects, and services #1870

hartez commented Feb 13, 2018 •

edited by samhouts

Loading

dansiegel commented Feb 13, 2018

brianlagunas commented Feb 13, 2018 •

edited

Loading

brianlagunas commented Feb 13, 2018

hartez commented Feb 13, 2018

hartez commented Feb 13, 2018

hartez commented Feb 13, 2018

dansiegel commented Feb 13, 2018

hartez commented Feb 13, 2018

hartez commented Feb 13, 2018

rogihee commented Feb 13, 2018

hartez commented Feb 13, 2018

rogihee commented Feb 14, 2018

kingces95 left a comment

kingces95 Feb 15, 2018

hartez Feb 17, 2018

kingces95 Feb 15, 2018

hartez Feb 17, 2018

kingces95 Feb 15, 2018

hartez Feb 17, 2018

kingces95 Feb 15, 2018

hartez Feb 17, 2018

kingces95 Feb 15, 2018

hartez Feb 16, 2018

kingces95 Feb 15, 2018

dansiegel commented Mar 22, 2018

jbachelor commented Mar 22, 2018

agriffith commented Mar 22, 2018

		@@ -0,0 +1,31 @@
		<Type Name="DependencyResolver+ResolveDelegate" FullName="Xamarin.Forms.Internals.DependencyResolver+ResolveDelegate">

Allow users to specify resolution method for handlers, effects, and services #1870

Allow users to specify resolution method for handlers, effects, and services #1870

Conversation

hartez commented Feb 13, 2018 • edited by samhouts Loading

Description of Change

Bugs Fixed

API Changes

Xamarin.Forms.Internals.DependencyResolver (new class)

Xamarin.Forms.DependencyService

Behavioral Changes

PR Checklist

dansiegel commented Feb 13, 2018

brianlagunas commented Feb 13, 2018 • edited Loading

brianlagunas commented Feb 13, 2018

hartez commented Feb 13, 2018

hartez commented Feb 13, 2018

hartez commented Feb 13, 2018

dansiegel commented Feb 13, 2018

hartez commented Feb 13, 2018

hartez commented Feb 13, 2018

rogihee commented Feb 13, 2018

hartez commented Feb 13, 2018

rogihee commented Feb 14, 2018

kingces95 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dansiegel commented Mar 22, 2018

jbachelor commented Mar 22, 2018

agriffith commented Mar 22, 2018

hartez commented Feb 13, 2018 •

edited by samhouts

Loading

brianlagunas commented Feb 13, 2018 •

edited

Loading