Dependency injection framework for Cocoa? [closed]

Question

Interface Builder can be used for basic dependency injection in a Cocoa app, but is anyone aware of more complete dependency injection frameworks for Objective-C/Cocoa for when you don't want to instantiate objects in a NIB file?

Edit

To clarify, I recognize that IB can be used for basic DI, but I'm looking for a framework with more complete functionality, including separate production and testing configurations, along the lines of Groovy or Springs.

Answer 1

What about ObjectivePim? ObjectivePim

Answer 2

I'll go out on a limb and speak on this. Dependency injection as described by the top answer doesn't address the core issue that those seeking to use it are having. We'd like a means of development where component A does not directly instantiate or reference component B. Component A is bound by protocol to component B and is not referenced at all by component A. This allows component B to be replaced at anytime without ever touching component A. I down voted but I will research your references as it seems there are a few who agree with you. I'm not trying to debate, just looking to learn. I'd like to understand more about the "nope you don't need to do that" approach.

Answer 3

Typhoon

Almost one year ago, I released: https://github.com/typhoon-framework/Typhoon

The Typhoon-website lists the key features. A quick summary:

• Non-invasive. No macros or XML required. Uses a powerful Objective-C runtime approach.

• Makes it easy to have multiple configurations of the same base-class or protocol.

• No magic strings - supports IDE refactoring, code-completion and compile-time checking.

• Supports injection of view controllers and storyboard integration.

• Supports both initializer and property injection, plus life-cycle management.

• Powerful memory management features. Provides pre-configured objects, without the memory overhead of singletons.

• Excellent support for circular dependencies.

• Lean. It has a very low footprint, so is appropriate for CPU and memory constrained devices.

• Battle-tested - used in all kinds of Appstore-featured apps

• An internationally distributed core team (we even monitor StackOverflow), so support for any of your questions are never far away :)

API Docs and sample app

• API docs: http://www.typhoonframework.org/docs/latest/api/
• We have a nice sample app: https://github.com/jasperblues/Typhoon-example

Quality Control:

We also maintain a robust quality control system.

• Every commit triggers a series of regression tests
• We maintain high test coverage.

Answer 4

I work with Spring all day and I've checked Groovy. I'm by no means an XCode/Cocoa expert, but IB does only some dependency injection, which Groovy doesn't even really claims to be doing.

I reckon you are not looking for DI, but rather for a well compiled set of integrated libraries which saves you from typing a lot of code which other people also have typed. I think there are no Spring like frameworks for Cocoa because for some reason people tend to see "Open Source" as "not platform dependant" and therefore Cocoa is a bit left out in the cold.

Depending on your needs though, there are some nice free open source libraries available for Cocoa, all listed on CocoaDev in a nice list.

I know it isn't Spring, but I hope it helps.

Answer 5

objection by AtomicObject. It is molded in the image of Guice.

Answer 6

DI is a property of a runtime execution enviroment requiring dynamic binding. I'm very new to Obj-C and Cocoa so I may speak out of turn. Unless I'm missing something, I don't see how one could implement DI except by interpreting Obj C rather than compiling it, or by modifying the runtime environment.

I suspect that the DI like behaviour of IB is because there is a domain specific runtime environment associated with apps that are built with it.

I'm happy to be corrected though.

Categories appear to be an implementation of mixin's, allowing dynamic dispatch of methods to a delegate. Rather cool and similar to Java's interface concept, thought the details differ and from the following, I can't see if constants can be defined in a category, though member fields cannot.

objective-c categories