Autofac-style parameter injection.

[trydis]

I just started looking at IoC containers for iPhone today and have been testing Typhoon for a bit now.

I noticed it only accepts parameterless methods in the TyphoonAssembly subclass. What is the recommended way of working with things that take blocks? For instance a HTTP request that take blocks for success/failure.

Is the only option to let Typhoon instantiate them and set them afterwards, when returned from the container? Or do i have to create a factory?

[jasperblues]

That's an interesting question. . . To be honest I haven't thought about this much yet. So I guess it could be anything you want it to be, and I'll build it for you.

There is a feature request that's been in the issue-log for a while now, and that's to allow the block-style assembly to specify an arbitrary object for injection. This would be very easy to implement and it would also allow injecting blocks. . . this way all the configuration related information stays together as intended.

If you need this I'd be happy to implement it for you. . .

@IvanUshakov recently volunteered to implement this, but I don't think he's finished yet.

[IvanUshakov]

I'm not finished, but you can use already. I am have not the time now for implementing tests and write doc for that.
Just use injectParameterWithValue
Examle:

- (id)analiticsKeys
{
    return [TyphoonDefinition withClass:[NSDictionary class] initialization:^(TyphoonInitializer *initializer) {
        initializer.selector = @selector(initWithDictionary:);
        [initializer injectParameterWithValue:@{ ARCrashlyticsAPIKey: @"xxx",
                                                 ARGoogleAnalyticsID: @"xxx" }];
    }];
}

[jasperblues]

Thanks @IvanUshakov . . . I'll finish off the docs and test case.

To inject a block it would be:

[initializer injectParameterWithValue:^{some block}];

[trydis]

Thanks for replies guys.

I don't think we're talking about the same thing here. What I was thinking of was the ability to specify parameters when resolving things from the container, something like this:

[assembly someRequestWithSuccess:^{some block} failure:^{another block}];

This would make it possible to specify different parameters (in this case blocks) when resolved in different classes, making it more reusable/flexible.

At the moment I'm resolving them and setting the completion blocks after that, which is not a big problem. In C# projects I've done I've used factories that accepts parameters when resolving components, but as far as I can see the factories here only accepts TyphoonDefinition, which can' take parameters.

[IvanUshakov]

Oh, sorry. As I know, it's impossible now. I'm too would like this feature. Maybe when I would have more time, I will try implement this.

[trydis]

Here's some documentation for AutoFac, the C# container I'm using, showing how to pass parameters to a factory:
https://code.google.com/p/autofac/wiki/DelegateFactories

[jasperblues]

Ah, I see what you mean.

So instead of:

MyRequestType* request = [assembly myRedRequest];
[request setSuccess:^{}];
[request setOnFailre:^{}];

You'd like it all in one line? With the DI container knowing what to do with the extra parameters when we ask for the component?

We'd have to 'annotate' the arguments that are set at run-time. It would also involve forgoing some compiler checking on the method names. (Unless tool support could be added).

Would the extra parameters be mutable properties or calls to an init method. . Or both? (If an init method, you would be forgoing the use of another initiializer. ).

[jasperblues]

Thanks. . . I'm happy to implement this as soon as I get time. . (All of it is currently being taken up on a bunch of projects).

If you're not happy to wait, I will certainly accept a contribution from yourself of Ivan.

[trydis]

Thanks. I'm afraid I'll have to wait, since I currently only do iPhone development a few times a year. Most of the time it's C#, so I'm not an Objective-C ninja :) It's not that big of a deal to inject stuff manually or resolve and set things manually for now.

[jasperblues]

Ok - thanks for your feedback and your suggestions.

[jasperblues]

Besides any bug fixes, this feature is now top priority. . . will implement ASAP. . (currently busy with client projects).

[jasperblues]

I've been working on this today. . . coming out nicely 🎱

[jasperblues]

Duplicated by #47

[jasperblues]

@trydis Here ya go! http://jasperblues.github.io/Typhoon/api/Classes/TyphoonFactoryProvider.html

[trydis]

Thanks, appreciate it! Love the docs as well 👍 Will take a look at it for our next project, had to go with Objection back then. A great day as the new MacBook Pro arrived as well!

[jasperblues]

@trydis I recall you mentioned Objection had something like this. . . my (incorrect?) understanding was that it does. . though I haven't used it in a while.

Please do take a look at this feature! We're really excited about how it removes the need for custom boiler-plate code. . . we'd love to hear your feedback.

New docs (wip - w're working out a few doxygen issues): http://jasperblues.github.io/Typhoon/api/interface_typhoon_factory_provider.html