I see that internally the SynchronizedResolver class uses container's SpinLock (which is NSLock) to make locks. Can we change the NSLock to NSRecursiveLock here?

BTW, here's my use case (simplified of course - I do have concurrency):

public class A {
    private let b: B
    init(with r: Resolver) {
        b = r.resolve(B.self)    // this dead locks!
    }
}
private class B {}

let c = Container()
let threadSafeResolver = c.synchronize()

c.register(A.self, factory: { _ in return A(with: threadSafeResolver) })
c.register(B.self, factory: { _ in return B() })

threadSafeResolver.resolve(A.self)

In Typhoon we can mark a property as auto-injectable, but it works for Objective-C only. I think Swinject could use the power of Mirror type [1], [2] to find properties we can automatically resolve. I think of UIViewControllers and SwinjectStoryboard enhancement, so we could get rid of setup extension method in favour of the code like this (I tried to patсh SwinjectStoryboard class):

private func injectDependency(viewController: UIViewController) {
        //get the reflection info
        let mirror = Mirror(reflecting: viewController)
        //enumerate properties
        for case let (label?, anyValue) in mirror.children {
            let propMirror = Mirror(reflecting: anyValue)
            //I couldn't find a better way to detect auto-injectable properties =) 
            if label.substringToIndex(label.startIndex.advancedBy(6, limit: label.endIndex)) == "inject" {
                //in here we could use propMirror.subjectType as dynamicType to find the type to be instantiated
               //I tried to register this var with registerForStoryboard with no success, maybe you could help here?:
               //Cannot invoke 'resolve' with an argument list of type '(Any.Type)'
                SwinjectStoryboard.defaultContainer.registerForStoryboard(viewController.dynamicType, initCompleted: { r, c in
                    viewController.setValue(r.resolve(propMirror.subjectType), forKey: label)
                })
            }
        }

        let registrationName = viewController.swinjectRegistrationName
        container.runInitCompleted(viewController.dynamicType, controller: viewController, name: registrationName)

        for child in viewController.childViewControllers {
            injectDependency(child)
        }
    }

If we could solve resolving from mirror.subjectType, then we can later have dynamic property in ViewController like this:

dynamic var injectWeatherFetcher: WeatherFetcher?

dynamic var is important part - setValue works with @objc or dynamic vars.

What do you think?

Hello, first I would like to thank you for this awesome project!

We are using Swinject extensively on our project and are too lazy to write all the code to register our services. I have come up with extension based on generics that makes our life easier:

For my example I have this registration code:

container.register(MasterViewModeling.self) { r in
     MasterViewModeling(api: r.resolve(APIServicing.self)!, geocoder: r.resolve(Geocoding.self)!, locationManager: r.resolve(LocationManaging.self)!, detailModelFactory: r.resolve(DetailViewModelFactory.self)!)
}

If I extend Resolvable I can use power of generics and custom operator

extension Resolvable {
    func resolve<Service>() -> Service? {
       return self.resolve(Service.self)
    }
}

postfix operator ~ {}
postfix func ~ <Service>(r: ResolverType) -> Service {
    return r.resolve()!
}

And my registration can be significantly shorter, given that I resolve nameless services without arguments (which is usually the case):

container.register(MasterViewModeling.self) { r in
     MasterViewModeling(api: r~, geocoder: r~, locationManager: r~, detailModelFactory: r~)
}

This is significantly shorter, but we can do even more. I took inspiration in Curry and find out that we can use initializer's type to infere its dependencies. Creating new register(initializer:service:) method:

func register<Service, A, B, C, D>(initializer initializer: (A, B, C, D) -> Service, service: Service.Type, name: String? = nil) -> ServiceEntry<Service> {
   return self.register(service.self, name: name, factory: { r in 
       initializer(r.resolve()!, r.resolve()!, r.resolve()!, r.resolve()!)
   } as (Resolvable) -> Service)
}

We get registration:

container.register(initializer: MasterViewModel.init, service: MasterViewModeling.self)

This is awesome, because even when I add new dependency I don't have to change my container registration code.

This method have to be generated for every number of dependencies, in a same way as Curry. See generated source code

I have written a script that does exactly that, so the number of dependencies can be dynamically changed. (I am not sure if .erb is strong enough to be able to generate it, so I wrote it in swift, see the script )

I also often pass dynamic arguments to my services, but don't want to write the whole register factory. By creating register(initializer:service:argument:) method:

func resolve<Service, Arg1>(argument argument: (Arg1)) -> Service? {
   return (argument as? Service) ?? self.resolve(Service.self, argument: argument)
}

func register<Service, A, B, C, D, Arg1>(initializer initializer: (A, B, C, D) -> Service, service: Service.Type, name: String? = nil, argument: (Arg1.Type)) -> ServiceEntry<Service> {
   return self.register(service.self, name: name, factory: { r, arg1 in 
       initializer(r.resolve(argument: (arg1))!, r.resolve(argument: (arg1))!, r.resolve(argument: (arg1))!, r.resolve(argument: (arg1))!)
   } as (Resolvable, Arg1) -> Service)
}

we can than register like this. The dynamic argument is tested against all dependencies (in runtime) in initializer and if it fits the type it is passed instead of resolving dependency.

container.register(initializer: MasterViewModel.init, service: MasterViewModeling.self, argument: MyDynamicArgument.self )

This is not compiler safe though, but given that there can be multiple arguments and multiple dependencies on different positions, the number of permutation that would have to be generated is pretty hight. If we would force users to pass dynamic arguments as first and dependencies after them, it could be made compiler safe. But I think it would only lead to confusion.

Now, there are obviously some drawbacks. If you have two initializers in one class, compiler doesn't know which one to choose. Also if you have two inits in same class hierarchy and they have same number of arguments there will be a conflict. (e.g. UIViewController(coder: NSCoder) and MyViewController(viewModel: ViewModel))

You can either create custom named init, and use it for registration:

class func swinit(api: APIServicing, geocoder: Geocoding, locationManager: LocationManaging, detailModelFactory: DetailModelingFactory){
    return self.init(....)
}

~~Or perform some swift magic and convince compiler to use your init. Sometimes during writing it causes bug in compiler which then runs on 200% CPU, but once written it is ok. You have been warned :P.~~

You can force the compiler to choose specific init. This is probably better option.

container.register(initializer: MasterViewModel.init(api:geocoder:locationManager:detailModelFactory:), service: MasterViewModeling.self)

Also, if you have an optional dependency in your init, the autoregistration won't work. For the registration:

func register<Service, A, B, C, D, Arg1>(initializer initializer: (A, B, C, D)

There could be many permutations like (A?, B, C, D), (A?, B?, C, D), (A, B, C, D?) ... which is impossible to generate for more than few dependencies.

And of course, if you have named services, or more complex registration you will have to use current registration factories.

This issue is meant to start discussion whether auto-registration should be part of swinject. On my part, I am pretty happy with the extension, it reduced our container file by a large margin, but we don't use all features of swinject so there might be additional problems.

Hey there,

I'm currently trying to get Swinject running. However, I'm struggling heavily to get the injection up and running. In my Setting.class, the property "dataSource" is always nil as it's not getting injected. What am I doing wrong? Looking for advice :)

Regards, Manuel

extension SwinjectStoryboard {
    class func setup() {

        defaultContainer.registerForStoryboard(SettingsPreferencesController.self) {r, c in
            c.settings = r.resolve(Setting.self)
        }

        defaultContainer.register(DataSource.self) { _ in RealmService() }
        defaultContainer.register(Setting.self) { r in
            let setting = Setting()
            setting.dataSource = r.resolve(DataSource.self)
            return setting
        }
    }
}

protocol SettingType {
    var sourceHost: String? { get set }
    var sourceRoot: String? { get set }
    var dataSource: DataSource? { get set }
}

class Setting : Object , SettingType  {

    var dataSource: DataSource? = nil

    dynamic var sourceHost: String? = nil
    dynamic var sourceRoot: String? = nil

    override static func ignoredProperties() -> [String] {
        return ["dataSource"]
    }

    static func getSetting() -> Setting? {
        return RealmService().realm.objects(Setting).first
    }

    func save() {
        dataSource!.write(self)
    }
}

import Foundation

protocol DataSource {
    func write(itemToWrite : AnyObject)
}

class RealmService : DataSource {

    let realm = try! Realm()

    func write(itemToWrite: AnyObject) {
        let object = itemToWrite as! Object
        try! realm.write() {
            realm.add(object, update: true)
        }
    }
}

When building Swinject with Xcode 9, Swinject causes a segmentation fault in swiftc. I know this isn't your fault (the compiler shouldn't crash) but I thought I should mention it here. I've also filed this with Apple as rdar://32589507

To reproduce: Clone the repo as it is right now. Open Swinject.xcodeproj in Xcode 9. Build. Swiftc will have a segmentation fault and die, causing a build failure.

This is not an issue, but a suggestion/idea.

Assume I have a RootController and RootRouter. The last one is responsible for presenting (modal/push, animation, etc) other controllers. I want to present AnimalController (which has it's own dependencies).

I have the following assemblies diagram:

• RootAssembly
  • RootController AssemblyType
  • Services AssemblyType (api, db, etc)
• AnimalAssembly.

After #50 I can make animal assembly with parent assembly (I really need to access db from AnimalController).

So here is the problem:

class RootControllerContainer: AssemblyType {

    func assemble(container: Container) {

        container.register(RootController.self) { r in
            RootController(router: r.resolve(RootRouter.self)!)
        }

        container.register(RootRouter.self) { _ in
            RootRouter()
        }
    }
}

Now I'd like to create a AnimalController inside RootRouter.swift:

func showDogDetails(dog: Dog) {
    let animalController = ???
    rootController.navigationController.pushViewController(animalController, animated: true)
}

So the question is how do I construct AnimalAssembly with RootAssembly? When we were working with Containers I was able to create new container with given parent.

So I suggest: Pass assembler reference in assemble func, so I can register components, that is dependant on this assembler.

After it took us a while of staring at the code to figure out the source of bug, we've identified a place for possible improvement in Swinject API:

Consider following lines:

container.resolve(SomeType.self, argument:(a, b, c))
container.resolve(SomeType.self, arguments:(a, b, c))

The difference in syntax is IMO much more difficult to spot than it should be, and main problem is that both lines are perfectly valid, except former most often does not capture the intent.

Some alternative syntaxes that come to mind:

// change the param name
container.resolve(SomeType.self, multipleArguments: (a, b, c)) 

// use variadic params
container.resolve(SomeType.self, arguments: a, b, c)`

Thoughts?

After upgrading to CocoaPods 1.0.0 this morning, I've getting a compile time error with Swinject.

/Users/myuser/Documents/Github/myrepo/Pods/Swinject/Sources/Swinject.h:23:9: 'Swinject/_SwinjectStoryboardBase.h' file not found

I found this issue but my target is set to iOS 9.3, so I didn't think it was relevant.

Everything was working on CocoaPods 0.39.0

I have recently been informed about Swinject by other colleges. I do however see that it's been some time since any commits have been made.

Could one of the contributors confirm that this library will be supported over the next coming years.

Thanks

Hello!

In some cases we need to create wrapper like a ViewFactory or something like it. In general it is lazy initialization, so would be nice if Swinject will support lazy initialization. It can be implemented as struct that contains Closure to resolve object. example of implementation below:

// Object will be common if someone have a strong reference
public struct Lazy<Service> {
    private let initClosure: () -> Service?
    private var service: Service?
    
    internal init(initClosure: () -> Service?) {
        self.initClosure = initClosure
    }
    
    public func resolve() -> Service? {
        if service == nil {
            service = initClosure()
        }
        return service
    }
}

What you think about it?

Hi there, I'm investigating a production crash we're experiencing in our app. While going over the crash log provided by Crashlytics, I'm seeing some worrisome lines in the stack trace, stating the app crashed while calling resetObjectScope a few times while trying to add a child view controller by instantiating and injecting its dependancy using SwinjectStoryboard... I'm a bit confused with this as we're only calling resetObjectScope explicitly on specific cases (and not this one).

Thanks in advance, Gil

0 | libsystem_kernel.dylib | __pthread_kill + 8 -- | -- | -- 1 | libsystem_pthread.dylib | pthread_kill$VARIANT$armv81 + 360 2 | libsystem_c.dylib | abort + 140 3 | libsystem_malloc.dylib | szone_size + 634 4 | libswiftCore.dylib | _swift_release_dealloc + 28 5 | Swinject | _T08Swinject16PermanentStorageCAA08InstanceC0A2aDP8instanceypSgfsTW + 84 6 | Swinject | T08Swinject9ContainerC16resetObjectScopeyAA0dE8Protocol_pFyAA012ServiceEntryF0_pcfU0 + 176 7 | Swinject | _T0s8SequencePsE7forEachyy7ElementQzKcKFTfq4gn_nSay8Swinject20ServiceEntryProtocol_pG_Tg5 + 232 8 | Swinject | _T08Swinject9ContainerC16resetObjectScopeyAA0dE8Protocol_pFTf4gn_n + 192 9 | Swinject | _T08Swinject9ContainerC8_resolvexSgSSSg4name_AA16ServiceKeyOption_pSg6optionxq_c7invokertr0_lF + 1700 10 | Swinject | _T08Swinject9ContainerCAA9_ResolverA2aDP8_resolveqd__SgSSSg4name_AA16ServiceKeyOption_pSg6optionqd__qd_0_c7invokertr0_lFTW + 128 11 | SwinjectStoryboard | _T018SwinjectStoryboardAAC16injectDependency33_5D9C018A2F8973BF429DA54A673A2489LLySo16UIViewControllerC2to_tFTf4gn_n + 948 12 | SwinjectStoryboard | _T018SwinjectStoryboardAAC25instantiateViewControllerSo06UIViewE0CSS14withIdentifier_tFTf4gXn_n + 428 13 | SwinjectStoryboard | _T018SwinjectStoryboardAAC25instantiateViewControllerSo06UIViewE0CSS14withIdentifier_tFTo + 52 14 | MyApp | StatusViewController.swift line 34StatusViewChild.controller.getter -- | -- | -- 15 | MyApp | StatusViewController.swift line 370StatusViewController.addController(ofType : StatusViewChild, toSide : StatusViewController.ChildSide) -> () 16 | MyApp | StatusViewController.(setupBindings() -> ()).(closure #11) + 4367383352 17 | MyApp | StatusViewController.swift line 0partial apply for StatusViewController.(setupBindings() -> ()).(closure #13) 18 | MyApp | MapViewController.swift line 0thunk ...

We use Swinject 2.8.0 in production and from the latest version and from iOS 16 (but not only, we have some users from 15.6.1) we have a raising issue. The app is crashing on start. In Xcode I see some crash reports but I can not reporduce the issue (tested on like 20 devices). I'll try 2.8.2 but from the release notes I see it's only typo fixes... so I don't know what to do. Any help? Others maybe have the same problem?

Hi, nazdar,

I make use of the parent child assemblers, which works great to create semantical scopes.

However one thing that is unexpected/dangerous is how unnamed overloaded bindings are resolved, when in a hierarchy

Say I have a alamofire Interceptor registered in app scope, which provides a common middleware for attaching user agent etc container.register(Interceptor.self, name: "app") { _ in Interceptor([ some common interceptors ])

This is then wrapped by RequestHelper as to not expose alamofire types

protocol RequestHelper

final class RequestHelperImpl : RequestHelper {
   private let interceptor: Interceptor
}

...
container.register(RequestHelper.self) { r in
   RequestHelper(r.resolve(name: "app")
}

Then a feature 1 has a api client, whose logical scope is app scope container.register(Feature1ApiClient.self) { r in FeatureApi1Client(requestHelper: r.resolve(RequestHelper.self)

This seems to work fine

Then user scope is added, which obviously needs a way to authenticate the request, while inheriting the app scope behaviour (interceptor)

container.register(Interceptor.self, name: "user") { r in
   let parentInterceptor = r.resolve(Interceptor.self, name: "app")
   return Interceptor([parentInterceptor, AuthenticationInterceptor()
}

container.register(RequestHelper.self) { r in
   RequestHelper(r.resolve(name: "user")
}

Now comes feature 2 which is in the user scope container.register(Feature2ApiClient.self) { r in FeatureApi2Client(requestHelper: r.resolve(RequestHelper.self)

And the assemblers are instantiated like this (so AppScope is parent to UserScope)

let appScopeAssembler = Assembler([Feature1Assembly()], parent: nil)
let userScopeAssembler = Assembler([Feature2Assembly()], parent: appScopeAssembler)

Ooookay, now, the issue is, that both RequestHelpers are registered anonymously, and this I believe should be okay, as both are NOT reqistered in the same scope but different scopes - yes, app scope is parent to user scope, so user scope technically sees 2 bindings, but, the "scope local" should be the first choice - and it mostly behaves in this way, given the sources

fileprivate func getEntry(for key: ServiceKey) -> ServiceEntryProtocol? {
    if let entry = services[key] {
        return entry
    } else {
        return parent?.getEntry(for: key)
    }
}

The unexpected part comes, when user assembler.resolve is used to resolve a app scope binding, which again, is all legal let feature1ApiClient = userScopeAssembler.resolve.resolve(Feature1ApiClient.self)

HOWEVER the RequestHelper instance of FeatureApi1Client(requestHelper: r.resolve(RequestHelper.self) is the one registered in user scope, not app scope as indended!

Obviously this all could be alleviated by naming the RequestHelper bindings, however this then breaks encapsulation, and which RequestHelper instance is uses should only be dictated by where the XAssembly is added to.

I did concede in naming the Interceptor bindings as there I need to explicitly as for parent Interceptor, and this only happens once per scope, so total of 2, which I could live with.

But I'm not keen on breaking the encapsulation everywhere as there are going to be 10s of features per scope, and paying such close attention on which scope the instance is resolved is very error prone.

Thoughts?

Im trying to resolve viewModel in my MVVM architecture

My assembly class

public final class CancelAssembly: Assembly {
    
    public init() {
        
    }
    
    var container: Swinject.Container?
    var viewController: UIViewController!
    
    public func assemble(container: Swinject.Container) {
        container.register(CancelCoordinatorProtocol.self,
                           factory: {(r, assembler: Assembler?, rootViewController: UINavigationController, order: Order) -> CancelCoordinator in CancelCoordinator(rootNavigationController: rootViewController, assembler: assembler, order: order)
        }).inObjectScope(.transient)
        
        container.register(CancelViewControllerProtocol.self, factory: {(r, viewModel: CancelViewModel) -> CancelViewController in
            return CancelViewController(viewModel: viewModel)
        }).inObjectScope(.graph)
        
        container.register(CancelRouterProtocol.self, factory: {(r, routes: StrongRouter<CancelRoute>) -> CancelRouter in
            return CancelRouter(routes: routes)
        }).inObjectScope(.graph)
        
        container.register(CancelViewModelProtocol.self,
                           factory: {(r, router: StrongRouter<CancelRoute>, order: Order, step: Int) -> CancelViewModel in
            let router = r.resolve(CancelRouterProtocol.self, argument: router) as! CancelRouter
            let viewModel = CancelViewModel(router: router, order: order, step: step)
            let vc = r.resolve(CancelViewControllerProtocol.self, argument: viewModel) as? CancelViewController
            viewModel.viewController = vc
            return viewModel
        }).inObjectScope(.graph)
        
    }

}

Trying to resolve this way

let vm = assembler?.resolver.resolve(CancelViewModelProtocol.self, arguments: strongRouter, order, index) as? CancelViewModel

When I resolve it first time all is working correctly But second time it gives me nil in viewModel.viewController I checked that my CancelViewController deinited after 'return viewModel', but in first time it is ok.

viewModel has weak reference to viewController and viewController has strong reference to viewModel

What am I doing wrong?

Coming from android / Dagger side of the world, the thing I'm missing to facilitate a highly modular codebase is multibinding. Essential, what it is, is that the implementation is registered as its protocol type - the usual stuff.

However, I'm then able to be pull out (inject) all these protocol-implementing instances as a set or array, i.e. Set<SomePlugin>

This allows for a plugin architecture which is a necessity in a multi-app modular shared codebase

SwinjectStoryboard depends on Swinject 2.7.1. Since we use SwinjectStoryboard in our project, this has been blocking us from using the latest Swinject version. There is an open issue 169 highlighting this problem. I'm creating this issue here in the hope that SwinjectStoryboard and Swinject might have some common maintainers. Please take a look at it.

Thank you. James