Advantages of TyphoonFactoryProvider over runtime args?

[jasperblues]

What are the advantages of TyphoonFactoryProvider over runtime args? (if any).

We were able to get runtime args in sooner than expected. Would it make sense to deprecate TyphoonFactoryProvider in favor of runtime args?

[alexgarbarev]

I think that runtime args + new category TyphoonDefinition+Option can replace FactoryProvider for most cases.

[drodriguez]

The only benefit, and why I build the system originally, is that the user code is not “tainted” by Typhoon, so stripping Typhoon away should be easier. Obviously this is my requirement, not something everyone “lives by”. I really don’t know how many people uses it besides me (and my old team), and I actually not using actively anymore, so I will not fight if you want to remove it.

[jasperblues]

With regards to tainting/non-invasive the following is possible:

• Create a protocol for the factory
• Have the assembly conform to that protocol.
• Inject the assembly, posing as that protocol.

Quite a few folks have reported using this feature, but now that we've got the runtime args, I figured they might be happy enough with that feature. . . if we can support just one, then we might see a few more weekends.

[jervine10]

@jasperblues
Thanks for answering my question on StackOverflow. I'm currently using FactoryProviders, but run time arguments with Assemblies looks a little sleeker to me. What you just described with the assembly conforming to the protocol is what I was thinking about doing. This way I can change the implementation to anything I want with minimal effort.

[jasperblues]

Link to SO question: http://stackoverflow.com/questions/23935878/typhoon-injection-with-run-time-arguments-or-factory-providers

[jasperblues]

OK. I mashed the docs from the original TyphoonFactoryProvider onto the runtime args feature. For simplicity I think it makes sense to deprecate this in favor of the new runtime-args feature.

As @jervine10 points out we can still decouple Typhoon, by creating a protocol and having the assembly conform to it.

[PabloLerma]

Hi @jasperblues !

I'm looking for a migration guide between version because we were in 1.8.2 and want to updated (to 3.4.5).
Basically we were using tons of [TyphoonFactoryProvider withProtocol:dependencies:factory] and some [TyphoonFactoryProvider withProtocol:dependencies:factories].
Please could you tell me how could I migrate the following example code:

- (id)loginWebViewControllerProvider {
return [TyphoonFactoryProvider withProtocol:@protocol(EXLoginWebViewControllerProvider) dependencies:^(TyphoonDefinition *definition) {
    [definition injectProperty:@selector(webViewFacade)];

    definition.scope = TyphoonScopeSingleton;
} factory:^(id<EXLoginWebViewControllerProvider> provider, NSURL *url) {
    return [[EXLoginWebViewController alloc] initWithWebViewFacade:provider.webViewFacade
                                                               url:url];
}];
}

I am lost :(

[jasperblues]

Was it not clear after reading about: https://github.com/appsquickly/Typhoon/wiki/Types-of-Injections#injection-with-run-time-arguments

If not could you provide some more code? The code for your factory provider, etc?