Nested contexts about adic HOT 5 CLOSED

That kind of scenario is something that DI can help a lot!

Considering that "context" in Adic could be translated to a container (an instance of InjectionContainer, created inside the SetupContainers() method of a GameRoot) you could have a specific container for each of your ships. However, I don't think this would be the best approach.

You could place specific configurations of your ships in the same container using different conditional identifiers (see Conditions) and also bind any common configurations or objects that are shared among all ships in that same container. So, in your modules (MonoBehaviours or not), you inject the configurations using these identifiers.

I don't know exactly what happen when the ship is docked (whether e.g. the "mothership" will then be controlled by the player). But, if that's the case, or even to ensure some communication between the ship and the (for the lack of a better word) "mothership", you could dispatch a command (see Using commands) to pass the control to the "mothership" by configuring the necessary modules (and also to dock the ship).

I hope that can help!

from adic.

Thanks for the info! I missed the parentInstance field of the context in the conditions section when reading earlier. Using that instance I could do something like:

//Players created before container setup
foreach (var player in players)
{
    int playerID = player.ID;
    PlayerInput input = player.Input;

    container.Bind<PlayerInput>().ToGameObject(input).When(c => 
        ((MonoBehaviour)c.parentInstance)
        .transform
        .root
        .GetComponent<Ship>()
        .Player
        .ID == playerID
    );
}

Which would inject the input object for all modules of a ship.

I also guess it would work for players joining mid-game if I just create all players (in the above foreach) beforehand - since it is not possible to update the container after the initial SetupContainers()?

Is it possible to redo injection at a later stage (long after object creation)? Say I create a ship module at start and later on it changes owner, could I redo the injection to get a new player input instance? Perhaps by doing this.Inject()?

from adic.

That should do the trick if new instances of the Player component have the correct IDs (and the player list contains the unique inputs for each player), and should also work when a new player joins mid-game.

It's a complex binding, but looks like an acceptable approach that Adic can handle just fine.

However, I don't feel this approach is the best for your problem. Why not use a factory to decide which input object to use based on the same conditions (a factory receives the same InjectionContext object as the condition)? The main use of a factory is to customize the way an object is created.

Analyzing your code, looks like the Input is a MonoBehaviour. Have you thought about making it a regular class? This way it doesn't need to be attached to any game object and new instances could be created directly by the container itself.

Obviously I don't know how your code is organized, so I can't really say that it could be a proper solution.

And, although not recommended, you could add bindings to a container after SetupContainers() by either holding a reference to it or by injecting the container through an IInjectionContainer constructor parameter or class field - but that not necessarily will help you on solving the input problem described above.

from adic.

To make the use of factories more pleasurable, I opened the issue #4 to allow them to be created by the container, so they can have any dependencies resolved (currently factories don't support injection, so you could not e.g. receive the container as a dependency to resolve other types when manually creating an object).

from adic.

Thanks, very good suggestions! #4 seems like a smart way of handling this, I'll try the factory approach.

from adic.