#dependency-injection

What is dependency injection?

Dependency Injection is passing dependency to other objects or framework( dependency injector). Dependency injection makes testing easier. The injection can be done through constructor. SomeClass() has its constructor as following: public SomeClass() { myObject = Factory.getObject(); } Problem: If myObject involves complex tasks such as disk access or network access, it is hard to do unit…

Calling native platform code in your portable class library (PCL) is achievable via Dependency Injection. It’s a common question for people starting out, who are using a PCL or .NET Standard Library for developing their Xamarin apps. Dependency Injection involves creating an interface that can be commonly applied across all native platforms, then coding the actual implementation, or the native platform code, on each platform. This interface and instance is then given to a container. The PCL or .NET Standard Library, then goes to the container with only the interface known, to retrieve the instance. It doesn’t know where the instance came from, just that it has a specific interface.

Xamarin Dependency Injection

Interface

The first thing we must do to enable dependency injection is define an interface. For this example, lets say we have to get a unique identifier for the mobile phone. There are specific calls you can make on a each platform to get this, but its not available in our PCL. Hence we would define this interface to return a string of unique identifier.

public interface IDeviceInfo { string GetUniqueIdentifier(); }

This interface would be placed in your PCL and hence accessible from your PCL and each platform project.

Implementation

Next we need to actually define the implementation of this interface in each platform.

iOS

public class DeviceInfo : IDeviceInfo { public string GetUniqueIdentifier() { return UIDevice.CurrentDevice.IdentifierForVendor.AsString(); } }

Android

public class DeviceInfo : IDeviceInfo { public string GetUniqueIdentifier() { return Android.Provider.Settings.Secure.GetString(Xamarin.Forms.Forms.Context.ContentResolver, Android.Provider.Settings.Secure.AndroidId); } }

UWP

public class DeviceInfo: IDeviceInfo { public string GetUniqueIdentifier() { var token = HardwareIdentification.GetPackageSpecificToken(null); var hardwareId = token.Id; var dataReader = Windows.Storage.Streams.DataReader.FromBuffer(hardwareId); byte[] bytes = new byte[hardwareId.Length]; dataReader.ReadBytes(bytes); return BitConverter.ToString(bytes); } }

Dependency Injection Container Registration

Next we want to register this implementation with the Dependency Injection Framework. For this example, I will just use Xamarin Forms inbuilt dependency injection container. Place the following above each implementation of the DeviceInfo, above the namespace declaration.

[assembly: Xamarin.Forms.Dependency(typeof(DeviceInfo))] namespace Mobile.Platform { ...

You can also register it via a line of code, and this is actually need for UWP, as the assembly registration has issues with UWP under Native Compilation.

Xamarin.Forms.DependencyService.Register<DeviceInfo>();

Retrieve Dependency

Lets now retrieve that dependency in code. All we need to do is call this line, referencing the interface we want the implementation of.

DependencyService.Get<IDeviceInfo>().GetUniqueIdentifier();

Now we can call the GetUniqueIdentifier and it will return a string. The PCL or .NET Standard Library doesn’t know anything about the platform, and just interact with the instance via the interface definition.

AutoFac

The Xamarin Forms Dependency Service is a nice simple dependency injection framework, but it lacks many features, including the ability to do constructor injection. Using something more advanced such as AutoFac offers you many more features. There are many other Dependency Injection Frameworks out there, and they all provide very similar functionality.

To create the container, implement the following code.

ContainerBuilder _builder = new ContainerBuilder();

Now you can add dependencies as needed.

_builder.RegisterInstance<IDeviceInfo>(new DeviceInfo()).SingleInstance();

Finally you need to call the Build function to finish the building of the container.

_builder.Build();

The Container should be accessible in the PCL and native platforms, as is the interface. Similar to Xamarin Forms implementation, you can also get the

Constructor Injection

The benefits of using a Dependency Injection Framework such as AutoFac, is you can inject dependencies into a constructor. For example.

public class MyViewModel { private readonly IDeviceInfo _deviceInfo; public MyViewModel(IDeviceInfo deviceInfo) { _deviceInfo = deviceInfo; } }

If you had registered your ViewModel and DeviceInfo, in AutoFac, when AutoFac creates an instance of your ViewModel, it will automatically detect constructors with parameters and try to fill them in as needed. This has immense benefits for readability and unit testing. No longer is a dependency in your class, hidden via a line of code, its clearly apparent, as you can only create the class, if you inject the dependency into it.

Other Frameworks

You might be wondering what other frameworks are out there. First they are some MVVM frameworks that come with one included such as FreshMVVM and MVVMLight. If you prefer to keep your MVVM frameworks and Dependency Injection Framework separate, you can also use Ninject, TinyIoc, Unity, Castle Project, StructureMap and Spring.NET, just to name a few. You can do some research to find the one that best meets your needs. Personally, I prefer AutoFac, as its recent speed improvements, along with powerful interface, features and maturity make it great to work with.

The post Xamarin Forms Dependency Injection appeared first on PureSourceCode.

Xamarin Forms Dependency Injection

Calling native platform code in your portable class library (PCL) is achievable via Dependency Injection. It’s a common question for people starting out, who are using a PCL or .NET Standard Library for developing their Xamarin apps. Dependency Injection involves creating an interface that can be commonly applied across all native platforms, then coding the actual implementation, or the native…

Spring framework 5 : Uso de los scopes (prototype y singleton) utilizando la anotación @Scope #geek #devs4j #spring #spring5 #java

El scope de un bean define su ciclo de vida, en los posts anteriores hemos creado beans pero no hemos definido su scope, al hacer esto Spring le asigna uno por defecto, a continuación se muestran los scopes disponibles:

ScopeDescripciónSingletonCrea una sola instancia del bean por contenedor de SpringPrototypeCrea una nueva instancia cada vez que se solicitaRequestCrea una nueva instancia por…

Spring framework 5 : Uso de la anotación @Primary #java #spring-boot #springframework5 #devs4j

En el ejemplo anterior vimos como utilizar la anotación @Qualifier y como nos ayuda cuando tenemos multiples implementaciones de una interfaz. El problema de esa solución es cuando se utiliza @Autowired sin especificar el qualifier dado que Spring falla con el siguiente error:

Field userService in com.devs4j.qualifier.UserController required a single bean, but 2 were found

Esto se resuelve…

Spring framework 5 : Dependency Injection utilizando Spring #java #spring #springframework #springboot #dependency-injection #devs4j

Una vez que entendimos como funciona dependency injection e inversion of control el siguiente paso es aprender a utilizarlo con Spring framework.

Crear un Service de ejemplo

El primer paso será crear un service de ejemplo, a continuación se muestra la interfaz y su implementación:

MathService.java

/** * * @author raidentrance * */ public interface MathService { /** * Receives a set of…

Spring framework 5 : Conceptos básicos sobre DI (Dependency Injection) #devs4j #springframework #java #geek #tutorials

En el post anterior se explicó como crear un proyecto de Spring framework 5 desde cero https://devs4j.com/2019/01/28/spring-framework-5-creando-un-proyecto-de-spring, ahora toca el turno de hablar sobre inyección de dependencias en Spring framework 5.

Introducción

La definición más simple de Dependency Injection es cuando una un objeto necesita una dependencia y esta es inyectada por otro…

I have added a new service to exiting solution. It was diligently registered in entry (startup) project like:

container.Register(Lifestyles.Scoped);

I injected it in an Web API controller, pressed F5 and boo… got this exception:

SimpleInjector.DiagnosticVerificationException occurred HResult=0x80131500 Message=The configuration is invalid. The following diagnostic warnings were reported: -[Short Circuited Dependency] FabulousApiController might incorrectly depend on unregistered type FabulousConcept (Transient) instead of IFabulousConcept (Web Request). -[Ambiguous Lifestyles] The registration for FabulousConcept (Transient) maps to the same implementation (FabulousConcept) as the registration for IFabulousConcept (Web Request) does, but the registration maps to a different lifestyle. This will cause each registration to resolve to a different instance. -[Ambiguous Lifestyles] The registration for IFabulousConcept (Web Request) maps to the same implementation (FabulousConcept) as the registration for FabulousConcept (Transient) does, but the registration maps to a different lifestyle. This will cause each registration to resolve to a different instance. See the Error property for detailed information about the warnings. Please see https://simpleinjector.org/diagnostics how to fix problems and how to suppress individual warnings. Source=SimpleInjector StackTrace: at SimpleInjector.Container.ThrowOnDiagnosticWarnings() at SimpleInjector.Container.Verify(VerificationOption option) at Fabulous.Website.Startup.ConfigureDependencyResolution() in C:\Source\Fabulous.Website\App_Start\Startup.DI.cs:line 31 at Fabulous.Website.Startup.Configuration(IAppBuilder app) in C:\Source\Fabulous.Website\Startup.cs:line 24

I was baffeled, as I think I know a bit about SimpleInjector. After beating around the bush for sometime, I hit it.

It was rather innocent (really?) mistake of declaring:

private readonly FabulousConcept _fc;

and then using Resharper to take care of initing it from constructor of the function. There it was! Instead of interface IFabulousConcept

, which was registered with SimpleInjector, I was asking for FabulousConcept class which was unregistered and thus treated as a transient lifestyle.

Changing above declaration (and initializing code in constructor) to following fixed it:

private readonly IFabulousConcept _fc;