Does swinject re instantiate the object? - ios

I have a question, I'm using Swinject in a separate framework.
My app get the object from this framework and my appExtension use it too.
But in the Extension the Object is not correctly instantiate. Does Swinject use the first instance of my object or just recreate another one ?
thanks

I have found this in their documentation:
Graph (the default scope)
With ObjectScope.graph, an instance is always created, as in
ObjectScope.transient, if you directly call resolve method of a
container, but instances resolved in factory closures are shared
during the resolution of the root instance to construct the object
graph.
So, If you haven't specified the scope, that's the one that's applying in your case.
Complete documentation: https://github.com/Swinject/Swinject/blob/master/Documentation/ObjectScopes.md

Related

Can I recall a Stateful Class while in the class

I am passing the first object of a List myList[] from Class A to a stateful class B that is a separate page in my application. The passed object is therefore created as immutable since flutter prefers immutable classes and immutable classes need const constructors, variables in which must be final. In the B class, I later call a function that modifies the object from the List, and objects in a list aren't immutable. But since I have already passed the object, I can't see the updated value. I solved this issue by making: the value - non-final, the constructor - not const, and therefore the class - mutable. Another way I could solve it is to just use global variables instead.
My question is - Is there a way to reinstantiate class B? I.e., go to class A, navigate to page B by passing the (now updated) first object of List myList[] ?
Perhaps you could try using a State manager like Provider. From my understanding, you're trying to share variables across different widgets. Using a state management library seems to do exactly what you want.

Swinject factory closure called multiple times when object scope is container

I'm trying to register CoreDataStack as a single instance on a shared container with object scope .container, but its factory closure called multiple times and when I debug memory graph in Xcode several instances of the object are created even when the returned object is not value-type!
Swinject documentation:
The object scope is ignored if the factory closure returns a value type because its instance is never shared per the Swift specification.
What is the root cause of this strange behavior?
Registering a service with a name solve the issue and no more instances created
container.register(CoreDataStack.self, name: "CoreDataStack") {
DefaultCoreDataStack(modelName: "name")
}.inObjectScope(.container)

Maintaining a single instance of a concrete class with unity

When using unity, if i attempt to inject a concrete type that i havent explicitly registered with the container, unity will attempt to locate the current type and will instantiate a new one for me, before injecting it into the class that depends upon it.
How can i ensure that only a single instance of this type is used? Do i need to explicitly register an instance with the container beforehand?
From MSDN:
You can use the Unity container to generate instances of any object that has a public constructor (in other words, objects that you can create using the new operator), without registering a mapping for that type with the container. When you call the Resolve method and specify the default instance of a type that is not registered, the container simply calls the constructor for that type and returns the result.
So simply put, yes, you have to register a mapping for your type to be able to use it as singleton in your app. You can achieve it using RegisterInstance method or RegisterType and providing the ContainerControlledLifetimeManager as the lifetime manager.

Openrasta: Swap instance in dependency resolver

Suppose I register some instance in OpenRasta's dependency resolver using
resolver.AddDependencyInstance(IInterface, instance, DependencyLifetime.Singleton)
Now if I want to swap that instance later, say to reread fresh data from the db, is another call to resolver.AddDependencyInstance the right thing to do?
Checking the InternalDependencyResolver implementation, it seems to be fine. However I'm asking because the behavior is not defined (in openrasta's sources, where I checked), and the method prefix "Add" is suggestive of different behavior.
I wouldn't use Singleton if you have to swap the instance at some point.
Use DependencyLifetime.Transient and have a constructor injection in the class where you need the new instance

Spring.Net/Caliburn v2 Dependency hell?

I'm putting a project together with Spring.NET and Caliburn v2. I have some objects that I'm trying to instantiate, but not sure how to go about it.
I have been using Caliburn's IoC aspect annotations (Singleton and PerRequest) to get objects into the Spring context. The problem with this is that I have two objects, A and B, where Object B is a subclass of Object A (meaning B is also an A). This means that if I register both, Spring complains of ambiguity when an object of type A is requested. To get around this, I could stop using Caliburn's IoC aspects to register the objects and instead register them in the Spring context XML files. That way I can specify a named object in the Spring context file to use in the constructor of object C, which needs an object of type B injected.
However, this creates a new problem. Object B needs the Caliburn window manager to be injected (which is not available to the Spring container at the time when the objects listed in the context XML files are instantiated, but only later, after Caliburn has loaded and added its own objects to the Spring container).
I could simply remove the inheritance and let some code duplication occur between objects A and B, but then what would be the point of doing OO programming? Otherwise I guess I'm looking for a way to specify objects in Spring.NET context XML, but keep them from being resolved until after Caliburn has loaded.
Any ideas?
I'm not familiar with Caliburn but if you want to delay instantiation then you could mark your objects in xml as lazy-init, like this:<object id="foo" type="..." lazy-init="true"/>
This way they will be instantiated when you first request them
I managed to solve this by maintaining a separate list of caliburn-dependent spring context XML files. I loaded these into the ApplicationContext object by adding the following code at the beginning of the overridden DisplayRootView() method in my application's bootstrapper:
var objectDefinitionReader = new XmlObjectDefinitionReader(applicationContext);
objectDefinitionReader.LoadObjectDefinitions(GetCaliburnDependentContextFiles());
applicationContext.Refresh();

Resources