Xamarin.forms: Decouple Forms Init from DepenedencyService init.

[awattar]

https://github.com/xamarin/Xamarin.Forms/blob/39263f2e6009724394d30e54a2f805bb19e72063/Xamarin.Forms.Platform.iOS/Forms.cs#L102

Is there a plan to separate Dependency Service initialization form forms initialization. There are several cases when developers would like to take advantage from working DependencyService before rest of the Forms is initialized.

[PureWeen]

What's your use case?

I'm pretty sure the code you are referencing doesn't really deal with the DependencyService that's more for setting up Platform Specific implementations for each platform

The Dependency Service is it's own thing
https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Core/DependencyService.cs

Does this issue relate to what you need?
https://github.com/xamarin/Xamarin.Forms/issues/1739

[awattar]

Hi Shane,

Thanks for the answer. The main issue is that we cannot use
DependencyService before forms init because DS is checking some internal
things that are set in Forms Init method. The only way now to deal with it
is to replace DS with other container - for example unity. What I'm
suggesting is to move DS related init from Forms init to some other place
that will be available to DS without need to cal Forms init so de devs
would be able to use it earlier.

Regards,
Michal

On Thu, Feb 1, 2018 at 1:34 AM, Shane Neuville [e-mail]
wrote:

What's your use case?

I'm pretty sure the code you are referencing doesn't really deal with the
DependencyService that's more for setting up Platform Specific
implementations for each platform

The Dependency Service is it's own thing
https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Core/
DependencyService.cs

Does this issue relate to what you need?

1739 https://github.com/xamarin/Xamarin.Forms/issues/1739

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/xamarin/Xamarin.Forms/issues/1725#issuecomment-362118528,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALB8awsREFc7DjyFxRDQpaDuwtgNc5kks5tQQaSgaJpZM4Rwh98
.

[weitzhandler]

I'd vote for taking this a step further, having some static Xamarin classes (e.g. DeviceService, DependencyService and other such services to instead be exposed as an interface, so we're able to:

• Reimplement them and reregister them with the current container
• Process them before resolving
• Inject them and use them with the current IoC container

So let's take Device as an example.

• Device class should become non-static, and should be implemented as a non-static class implementing IDevice.
• It should expose a static property Current that returns the IDevice resolved by the container (which defaults to DependencyService.Current, which again, is an instance of IDependencyService.
• All its current static functionality should redirect to their instance match (via the Current property), and perhaps (or not) become obsolete.

But in general I'd hope for as many XF static service to be replaced by pluggable interfaces offering their default implementation from in a static Current property resolved from the container.

@PureWeen @samhouts
I'd be glad to open a new detailed issue instead of this one, as I see it was labeled s/needs-info and s/needs-repro.

@brianlagunas @dansiegel wouldn't this issue be of any interest to you?

[awattar]

We ended up using Unity just to resolve a few dependences before Xamarin Forms init.

[brianlagunas]

@weitzhandler Yes, it would be amazing if Xamarin would start adding interfaces to some of their classes. Unfortunately, some people at Xamarin would never let that happen as they do not believe in having well maintainable and testable code using patterns such as IoC which can be achieved via DI. You have a better chance of winning the lottery than having the Xamarin team add interfaces to anything no matter how much more useful it would make their framework.