Search code examples
iostyphoon

Asynchronous dependency resolution using Typhoon

I'd like to add a formal DI component to my app and Typhoon looks like it could do the job. Before I dive in I wanted to see if there's any way to handle the injection of dependencies that must be resolved asynchronously.

To give an example: my Core Data stack is set up in the way recommended here. Since initialising the store can take some time and block the main thread, it's done in a background thread and the main thread is notified when the object is ready to be used.

I have an object that wraps this logic, and my app delegate currently waits on a callback to be notified that the database is ready. The object is then injected into other objects in my graph through property injection.

I'd like to replace this property injection approach with Typhoon Assemblies, but I can't see a way to handle the asynchronous nature of the database object initialisation. If that's not possible, could I keep my database object initialisation out of Typhoon, but manually provide the resulting object to the Assembly for use with the wired graph once it's ready?

Would appreciate any tips!

Solution

  • We don't have any special support for this, however . . .

    Scopes:

    Typhoon provides various scopes. If the objects that are using the asynchronously initalized store are of the following scopes:

    • TyphoonScopeObjectGraph
    • TyphoonScopePrototype
    • TyphoonScopeLazySingleton
    • TyphoonScopeWeakSingleton

    . . . that is, any scope except for TyphoonScopeSingleton, then no special setup should be required, as long as you initial presented view controller does not depend on the core data store.

    To proceed from one object graph to another, you can use this process, or if you're using storyboards and Objective-C just auto-injection.

    Manually provide an object for injection:

    You can register an object that produces another object like this or just provide a custom object to participate in the assembly.

    . . if either of the above don't suit your needs and you have something else in mind that would be of general utility, we'd be happy to implement it for you.

    Here's a sample / example for setting up Typhoon with Core Data, that could be modified to support the pattern in the article that you linked to in your question.