Any chance you could make the application cache thread safe?

In general I only let the strict necessary on the main thread and I use Texture so everything runs in the background except for strict UIKit and some SwiftUI stuff

Maybe implementing a lock on the cachedServices would help:

            cachedServices[registration.cacheKey]

I couldn't find a way to use the @InjectedObjected property wrapper to act as a @StateObject in the view, after I checked the docs it turned out that @InjectedObject is actually an ObservedObject.

is there a way to inject an observable object in a SwiftUI view to act as a @StateObject ?

What would be the best way to use Resolver in SwiftUI previews? I don't want to use real data (Xcode previews fail anyway when doing that..sometimes) I've been thinking on this and I'm not really sure how to go about it. Ideas?

Add context registration mutator

Introduction

Introducing the new context registration mutator function in ResolverOptions. This mutator allows the @*Injected propertyWrappers to resolve from non-static, user defined container.

Motivation

The usage of injection property wrappers is a convenient and safe way of using the framework. Unfortunately there is a compile time issue when the user tries to pass a non-static container to be used for resolution.

Resolver conveniently avoids this topic by suggesting to use staticly declared containers. For example the following works nicely:

extension Resolver {
	static let myFeatureContainer = Resolver(parent: .main)
	static func registerMyFeatureServices() {
		myFeatureContainer.register { MyFeatureService() }
	}
}

class MyFeatureService { }
class MyFeature {
	@Injected(container: .myFeatureContainer) var service: MyFeatureService
}

Static containers work fine for some projects, but not for others. For example: running more than 1 instance of a feature might cause problems in more complex cases.

A clean solution is to use non static containers.

For example:

extension Resolver {
	static func registerMyFeatureServices(container: Resolver) {
		container.register { MyFeatureService() }
	}
}

class MyFeatureService { }
class MyFeature {
	let container: Container
	var service: MyFeatureService
	init() {
		let container = Resolver(parent: .main)
		Resolver.registerMyFeatureServices(container: container)
		self.container = container
		self.service = container.resolve()
	}
}

Although this approach is totally functional, produces a lot of boilerplate code (large initialisers).

The goal is to combine the clean approach of non-static containers, and the convenience of propertyWrapper injection.

Proposed solution

Create a new registration mutator function, that takes a container as its argument. When applied to a registration, the dependencies of the resolved service can access the given container via a static getter that is dedicated for this purpose.

Example usage:

extension Resolver {
	static func registerMyFeatureServices(container: Resolver) {
		container.register { MyFeatureService() }
			.context(container)
	}
}

class MyFeatureService { }
class MyFeature {
	@Injected(container: .context) var service: MyFeatureService
}

The static container named Resolver.context is read only for the user, references another static container that is not exposed for the user and temporary has the correct value (during resolution).

While it can be said that it is not very elegant when we look under the hood, looking it from outside feels easy and intuitive to use.

Effect on API

The suggested solution is small and backward compatible.

Alternatives considered

ProperyWrappers to access a container instance from _enclosingSelf. This has several issues, such as:

• no official support in Swift for the _enclosingSelf keyword

If I make an XCFramework and try to inject a dependency from that library into another project I will get this error: Fatal error: RESOLVER: 'Service:NONAME' not resolved. To disambiguate optionals use resolver.optional().

I call Service's register the same why I would if it wasn't an XCFramework but when I switch it to a binary it doesn't work.

Does Resolver work with binary frameworks?

I've got

@WeakLazyInjected(container: .api) var userAuthAPI: UserAuthenticationAPIType?

and

public protocol UserAuthenticationAPIType: class {

however I still receive

Generic struct 'WeakLazyInjected' requires that 'UserAuthenticationAPIType' be a class type

What's going on? Class-only protocols generally work with Weak.

I'm developing a SwiftUI app with a framework structure like in this picture. The Presentation, Domain and Data Layers are frameworks and the App Layer is the main app.

I'm registering all dependencies in the main app and it's working fine in simulator or real devices but in preview it gets tricky. When previewing views of the main app (where all the dependencies get registered) everything is fine, too.

But when trying to preview views of the Presentation layer, the preview crashes because no dependencies are registered. I think this happens because in preview not the complete app runs but only the framework (and it's sub frameworks) of the view your previewing gets executed. Therefore the ResolverRegistering extension doesn't run which registers the dependencies. (At least this would explain why it's only working in the preview of views implemented in the main app.)

I also tried to register all dependencies in the presentation layer but this only works for the dependencies implemented in this framework and not for these which are implemented in data framework, which the presentation framework has no access to.

So my question is how to make Resolver notice the dependencies registered in the main app from sub frameworks like presentation layer if running in preview mode?

When you try to build for x86_64 simulator, Resolver can't be found, because it does not appear to be built for this architecture. Is there a way to add this to the supported architectures?

To reproduce:

1. Add Resolver swift package to your project and import it into a file.
2. Add "arm64" in the "Excluded Architectures" build setting for your project. (this is needed when 3rd party libraries have not yet been built for Apple Silicon)
3. Attempt to build your application.

Simplified example:

extension Resolver {
    static var context: Resolver!
}

class A { }

class B {
    @LazyInjected(container: .context) var a: A
}

func assemble(container: Resolver) {
    container.register { A() }
    container.register { resolver -> B in
        Resolver.context = resolver
        defer { Resolver.context = nil }
        return B()
    }
    .scope(.container)
}

// Example viewcontroller

import UIKit
import Resolver

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        let container = Resolver(child: .root)
        assemble(container: container)
        let _ = container.resolve(B.self)
    }
}

Experienced: Memory leak occours due to the following circular references: container -> container.cache -> B -> B.@LazyInjected(container: .context) var a: A -> container

Suggested fix: A possible way to resolve this is to mark the public var container: Resolver? property inside LazyInjected and WeakLazyInjected as weak.

Resolver's registration dictionary uses ObjectIdentifier's hashValue as its keys, but hash values shouldn't be assumed to be unique. There's a risk of overwriting a value in the registrations dictionary.

Note that for two arbitrary types SomeService and SomeOtherService,

ObjectIdentifier(SomeService.self) != ObjectIdentifier(SomeOtherService.self) // true

but

ObjectIdentifier(SomeService.self).hashValue != ObjectIdentifier(SomeOtherService.self).hashValue // may be false

The issue would manifest when registering services in the snippets below:

public final class Resolver {
    @discardableResult
    public final func register<Service>(_ type: Service.Type = Service.self, name: Resolver.Name? = nil,
                                        factory: @escaping ResolverFactory<Service>) -> ResolverOptions<Service> {
        lock.lock()
        defer { lock.unlock() }
        let key = ObjectIdentifier(Service.self).hashValue  **<- extracted key is another Hashable's hashvalue; not unique**
        let registration = ResolverRegistrationOnly(resolver: self, key: key, name: name, factory: factory)
        add(registration: registration, with: key, name: name)
        return registration
    }

    ...
    private var registrations = [Int : [String : Any]]() *<- subject to overwriting values where hash values from upstream ObjectIdentifiers are the same*
}

Since ObjectIdentifier itself is Hashable, I'd propose using ObjectIdentifier itself as the key to the registrations dictionary, and not hashValues extracted from ObjectIdentfier objects.

Introduction

After working with this library for a while, I noticed a shortcoming in it: Multi Injection Suppose we need an injectable array of a specific type, If this dependency is already registered somewhere as an array once, everything will work fine. But what if we want the elements of this array to be registered in different parts of the code? 

Explain the scenario

In this scenario we have an injectable array of interceptors in the NetworkManager class which is defined in our network layer:

public protocol Interceptor {
  func intercept(_ request: Request) -> Response
}

public class NetworkManager {
 public var interceptors: [Interceptor]
}

We need to register various interceptors in different modules and we expect these interceptors to be injected as an array to our NetworkManager

Resolver.register(multi: true) { SetAuthHeaderInterceptor() as Interceptor }
Resolver.register(multi: true) { ActivityIndicatorInterceptor() as Interceptor }.scope(.application)

public class NetworkManager {
 @MultiInjected public var interceptors: [Interceptor]
}

In such a case we should tell the DI to register our Service with a different strategy.

Let me continue in the code...

Sorry, my app crash and get this error.
And this is my code.

@objc protocol Animal {
    var name: String { get }
    @objc optional var running: Bool { get }
}

class Horse: Animal {
    let name: String
    let running: Bool

    init(name: String, running: Bool) {
        self.name = name
        self.running = running
    }

    convenience init(name: String) {
        self.init(name: name, running: false)
    }
}

class ResolverParameterInjectionVC: UIViewController, Resolving {

    override func viewDidLoad() {
        super.viewDidLoad()

        let smallHorse: Animal = Resolver.resolve(name: "small", args: "Spirit")
        let bigHorse: Animal = Resolver.resolve(name: "big", args: ["name": "Lucky", "running": true])        
    }
    
}

extension Resolver {
    public static func registerResolverParameterInjectionVC() {
        
        register { (_, args) in
            Horse(name: args.get())
        }.implements(Animal.self, name: "small")
    
        register { (_, args) in
            Horse(name: args("name"), running: args("running"))
        }.implements(Animal.self, name: "big")
    }
}

This PR adds the ability to resolve all registered implementations for a given type, where the implementations are differentiated by names. Please let me know what I can optimize.