Discussions

News: Inversion of Control Container for Cocoa & iPhone?

  1. Oxen (aka "the offshore guys") published an Apache 2.0 open source IoC container for Cocoa/iPhone.

     

     

    IoC Container description

    The IoC container provides dependency injection to Cocoa applications. It was created with iPhone development in mind.

    It aims to provide some functionalities from Spring and from Guice (in fact, we're somehow inspired by RoboGuice). But due to the complexity inherent to implementing a full IoC container (as the ones mentioned before), we restricted it to very basic features.

    The basics

    The container has the following characteristics:

    • The container holds definitions about objects. No object is created until somebody request it.
    • Every definition must have a name that must be unique inside the container in order to identify the object.
    • The definition can indicate that the object must be singleton (it is created and stored in a pool when the object is requested the first time). If singleton is specified as FALSE, the object will be created each time (but it can be released when no longer required). This is similar to prototype scope in Spring , an as we learned from using RoboGuice, this behavior would be preferible in many mobile development scenarios.
    • The definition can indicate that the object must lazy. That is, when the object is requested, a proxy to such object is returned. Upon the first method call on such reference, the object is created. This is useful for avoiding creating big object graphs unnecessarily.
    • The object can be injected (this is the main goal of the framework!). It must have properties or at least setters for performing the injection. The definition allows performing the following injections:
      • References to other definitions (by name).
      • Values
    • New factories can be implemented for object creation customization.
    • Container instantiation can be done by code and "annotations" (like Guice/Spring) or by XML (like Spring).

    Read more at:

    http://code.google.com/p/oxeniphonecommons/wiki/Container

    http://blog.oxen.com.ar/2011/08/ioc-container-working-finally.html

     

    Threaded Messages (4)

  2. Don't use IoC Containers[ Go to top ]

    Over the past decade DI proved to be an Anti-Pattern and IoC Containers turned out to be complexity generators without benefit. IoC Containers promote flawed design decisions (e.g. DAOs injected into BOs) and 'solve' problems that wouldn't have existed without them. There's no reason why one should use them any more.

  3. Seriously, I think discussing an IoC container for Cocoa apps here is inappropriate. It's not related to the serverside, and it's not related to the "Enterprise Java Community".

  4. Seriously, I think discussing an IoC container for Cocoa apps here is inappropriate. It's not related to the serverside, and it's not related to the "Enterprise Java Community".

    I think the link is that modern IoC containers largely originated and continue to innovate mainly on the Java platform. So now another platforms copies this approach, it's sort of related to Java. Also, in a very large number of cases, iPhone apps are backed by server-side Java apps (doesn't justify it of course, but it's some explanation).

  5. I do Java server-side, android, and iOS development.  I for one appreciate this kind of information on theserverside.