### Collection

The source generator will inject all bound instances of a type if the dependency declared is one of the following types `List` `IList` `IReadOnlyList` `IEnumerable`
The resolved dependencies will be resolved using `ResolveAll`
If the whole collection is nullable, the provided collection will always have `Count > 0` otherwise null.
If the underlying `T` is nullable, the resulting list will be converted from `T` to `T?`. This is not recommended, the nullable values will never be null.

The differences between `TCollection` and `TCollection?`:
- `TCollection` does a single resolution but allocates a list every time
- `TCollection?` does a dry resolution at build time and thus may not allocate the list

```csharp
public class A
{
[Inject] List ListObj {get; set;}
[Inject] IList IListInt {get; set;}
[Inject] IReadOnlyList IReadOnlyListObj {get; set;}
[Inject] IEnumerable IEnumerableInt {get; set;}
[Inject] List? NullableList {get; set;} //Either null or Count > 0
[Inject] List NullableGenericList {get; set;} //Valid but NOT recommended
}

### Lazy

The source generator will lazily inject dependencies if the dependency is lazy itself.
Lazy dependencies may have nullable contents.
Lazy dependencies are also compatible with collection .
Lazy Collection dependencies are also supported
Nullable lazy will only provide a lazy if resolving the lazy would provide a value
Nullable lazy with nullable generic value is not recommended. The nullable values will never be null

The differences between `Lazy` and `Lazy?`:
- `Lazy` does a single resolution but allocates a lazy every time
- `Lazy?` does a dry resolution at build time and thus may not allocate the lazy

```csharp
public class A
{
[Inject] Lazy Obj {get; set;}
[Inject] Lazy NullableObj {get; set;}
[Inject] Lazy Value {get; set;}
[Inject] Lazy NullableValue {get; set;}
[Inject] Lazy> LazyObjectList {get; set;}

[Inject] Lazy? NullableObj {get; set;} //Null lazy when container does not have binding
[Inject] Lazy? NullableObj {get; set;} //Possible but not recommended
}

# Resolving

Notice that resolution can only be done on apparent types, not concrete types. Concrete types are there so the container can provide a type safe fluent API.

If you use the source generated methods, you will usually not interact with the Resolution methods.

Resolutions can be done in the following ways:

## Resolve

Resolve an instance from the container. An exception is thrown if it can't be resolved.

```csharp
SomeService service = container.Resolve();
```

## ResolveNullable

Resolve a reference type instance from the container. Returns null if it can't be resolved.

```csharp
SomeService? service = container.ResolveNullable();
```

## ResolveNullableValue

Resolve a value type instance from the container. Returns null if it can't be resolved.

```csharp
int? service = container.ResolveNullableValue();
```

## TryResolve

Resolve an instance from the container. Returns true if found and false if not.

```csharp
bool found = container.TryResolve(out SomeService someService);
```

## ResolveAll

Resolve all the registered instance from the container. If no instances are available the list is empty.

```csharp
List services = container.ResolveAll();
```

# Startups

The container also provides an extension method so it can queue some delegate to be run during the Startups lifecycle of the container.
This step is useful to make sure that some object's method is run after all the NonLazy objects have been created and initialized.

```csharp
class Startup
{
public Startup(...) { ... }
public void Start() { ... }
}

class SomeNonLazy
{
public void Initialize() { ... }
}

b.Bind().Default().FromConstructor().NonLazy()
b.Bind().Default().FromConstructor();
b.WithStartup(o => o.Start());
```

In the snippet above, the following will happen once the container is built:
- `SomeNonLazy` is created
- `SomeNonLazy`'s `Initialize` method is called
- `Startup` is created
- `Startup`'s `Start` method is called

# ManualDi.Unity3d

When using the container in unity, do not rely on Awake / Start. Instead, rely on Inject / Initialize.
You can still use Awake / Start if the classes involved are not injected through the container.

## Installers

The container provides two specialized Installers
- `MonoBehaviourInstaller`
- `ScriptableObjectInstaller`

This is the idiomatic Unity way to have both the configuration and engine object references in the same place.
These classes just implement the `IInstaller` interface, there is no requirement for these classes to be used, so feel free to use IInstaller directly if you want.

```csharp
public class SomeFeatureInstaller : MonoBehaviourInstaller
{
public Image Image;
public Toggle Toggle;
public Transform Transform;

public override void Install(DiContainerBindings b)
{
b.Bind().FromInstance(Image);
b.Bind().FromInstance(Toggle);
b.Bind().FromInstance(Transform);
}
}
```

## Binding

When using the container in the Unity3d game engine the library provides specialized extensions for object construction

- `FromGameObjectGetComponentInParent`: Retrieves a component from the parent of a GameObject.
- `FromGameObjectGetComponentsInParent`: Retrieves all components of a specific type from the parent of a GameObject.
- `FromGameObjectGetComponentInChildren`: Retrieves a component from the children of a GameObject.
- `FromGameObjectGetComponentsInChildren`: Retrieves all components of a specific type from the children of a GameObject.
- `FromGameObjectGetComponent`: Retrieves a component from the current GameObject.
- `FromGameObjectAddComponent`: Adds a component to the current GameObject.
- `FromGameObjectGetComponents`: Retrieves all components of a specific type from the current GameObject.
- `FromInstantiateComponent`: Instantiates a component and optionally sets a parent.
- `FromInstantiateGameObjectGetComponent`: Instantiates a GameObject and retrieves a specific component from it.
- `FromInstantiateGameObjectGetComponentInChildren`: Instantiates a GameObject and retrieves a component from its children.
- `FromInstantiateGameObjectGetComponents`: Instantiates a GameObject and retrieves all components of a specific type.
- `FromInstantiateGameObjectGetComponentsInChildren`: Instantiates a GameObject and retrieves all components from its children.
- `FromInstantiateGameObjectAddComponent`: Instantiates a GameObject and adds a component to it.
- `FromObjectResource`: Loads an object from a Unity resource file by its path.
- `FromInstantiateGameObjectResourceGetComponent`: Instantiates a GameObject from a resource file and retrieves a component from it.
- `FromInstantiateGameObjectResourceGetComponentInChildren`: Instantiates a GameObject from a resource and retrieves a component from its children.
- `FromInstantiateGameObjectResourceGetComponents`: Instantiates a GameObject from a resource and retrieves all components of a specific type.
- `FromInstantiateGameObjectResourceGetComponentsInChildren`: Instantiates a GameObject from a resource and retrieves all components from its children.
- `FromInstantiateGameObjectResourceAddComponent`: Instantiates a GameObject from a resource and adds a component to it.

Use them like this

```csharp
public class SomeFeatureInstaller : MonoBehaviourInstaller
{
public Transform canvasTransform;
public string ResourcePath;
public Toggle TogglePrefab;
public GameObject SomeGameObject;

public override Install(DiContainerBindings b)
{
b.Bind().FromInstantiateComponent(TogglePrefab, canvasTransform);
b.Bind().FromInstantiateGameObjectResourceGetComponent(ResourcePath);
b.Bind().FromGameObjectGetComponent(SomeGameObject);
}
}
```

Most methods have several optional parameters.

Also, special attention to `Transform? parent = null`. This one will define the parent transform used when instantiating new instances.

Special attention to `bool destroyOnDispose = true` one. This one will be available on creation strategies that create new instances.
If the parameter is left as `true`, when the container is disposed, it will first destroy the instance.
This is the necessary default behaviour due to the game likely needing those resources cleaned up for example from shared Additive scenes and wanting the default behaviour to be the safest.
If the scene the resource is created on will then be deleted, there is no need to destroy it during the disposal of the container, so feel free to set the parameter as `false`.

## EntryPoints

An entry point is a place where some context of your application is meant to start.
In the case of ManualDi, it is where the object graph is configured and then the container is started.

The last binding of an entry point will usually make use of WithStartable, to run any logic necessary after the container is created.

### RootEntryPoint

Root entry points will not depend on any other container.
This means that all dependencies will be registered in the main container itself.

Use the appropriate type depending on how you want to structure your application:
- `MonoBehaviourRootEntryPoint`
- `ScriptableObjectRootEntryPoint`

```csharp
public class Startup
{
public Startup(Dependency1 d1, Dependency2 d2) { ... }
public void Start() { ... }
}

class InitialSceneEntryPoint : MonoBehaviourRootEntryPoint
{
public Dependency1 dependency1;
public Dependency2 dependency2;

public override void Install(DiContainerBindings b)
{
b.Bind().Default().FromInstance(dependency1);
b.Bind().Default().FromInstance(dependency2);
b.Bind().Default().FromConstructor();
b.WithStartup(o => o.Start());
}
}
```

### SubordinateEntryPoint

Subordinate entry points will depend on other container or require other data.
This means that these entry points cannot be started by themselves. They need to be started by some other part of your application.

If the data provided to these entry points, implements `IInstaller`, then the data will also be installed to the container.
Otherwise, it will just be available through the `Data` property of the EntryPoint.
If the subordinate container requires all the dependencies of the parent container, it is recommended to set the parent container on the EntryPointData object.

```csharp
public class EntryPointData : IInstaller
{
public IDiContainer ParentDiContainer { get; set; }

public void Install(DiContainerBindings b)
{
b.WithParentContainer(ParentDiContainer);
}
}
```

These entry points may also optionally return a `TContext` object resolved from the container.

Doing such a thing is useful to provide a facade to the systems created.

Use the appropriate type depending on how you want to structure your application:
- `MonoBehaviourSubordinateEntryPoint`
- `MonoBehaviourSubordinateEntryPoint`
- `ScriptableObjectSubordinateEntryPoint`
- `ScriptableObjectSubordinateEntryPoint`

```csharp
public class Startup
{
public Startup(Dependency1? d1, Dependency2 d2) { ... }
public void Start() { ... }
}

public class EntryPointData : IInstaller
{
public Dependency1? Dependency1 { get; set; }

public void Install(DiContainerBindings b)
{
if(Dependency1 is not null)
{
b.Bind().FromInstance(Dependency1).DontDispose();
}
}
}

public class Facade : MonoBehaviour
{
[Inject] public Dependency1? Dependency1 { get; set; }
[Inject] public Dependency2 Dependency2 { get; set; }

public void DoSomething1()
{
Dependency1?.DoSomething1();
}

public void DoSomething2()
{
Dependency2.DoSomething2();
}
}

class InitialSceneEntryPoint : MonoBehaviourSubordinateEntryPoint
{
public Dependency2 dependency2;
public Facade Facade;

public override void Install(DiContainerBindings b)
{
b.Bind().Default().FromInstance(dependency2);
b.Bind().Default().FromInstance(Facade);
b.Bind().Default().FromConstructor();
b.WithStartup(o => o.Start());
}
}
```

And this is how a subordinate entry point on a scene could be started

```csharp
public class Data
{
public string Name { get; set; }
}

public class SceneFacade
{
[Inject] Data Data { get; set; }

public void DoSomething()
{
Console.WriteLine(Data.Name);
}
}

public class SceneEntryPoint : MonoBehaviourSubordinateEntryPoint
{
public override void Install(DiContainerBindings b)
{
b.Bind().Default().FromInstance(Data);
b.Bind().Default().FromConstructor();
}
}

class Example
{
IEnumerator Run()
{
yield return SceneManager.LoadSceneAsync("TheScene", LoadSceneMode.Additive);

var entryPoint = Object.FindObjectOfType();
var data = new Data() { Name = "Charles" };
var facade = entryPoint.Initiate(data)

facade.DoSomething();
}
}
```

and this is an example of how you could use a subordinate prefab

```csharp
class Example : MonoBehaviour
{
public SceneEntryPoint EntryPoint;

void Start()
{
var data = new Data() { Name = "Charles" };
var facade = entryPoint.Initiate(data)

facade.DoSomething();
}
}
```

The container provides you with the puzzle pieces necessary. The actual composition of these pieces is up to you to decide.
Feel free to ignore the container classes and implement your custom entry points if you have any special need.

## Link

Link methods are a great way to interconnect different features right from the container.
The library provides a few, but adding your own custom ones for your use cases is a great way to speed up development.

- `LinkDontDestroyOnLoad`: The object will have don't destroy on load called on it when the container is bound. Behaviour can be customized with the optional parameters

```csharp
class Installer : MonoBehaviourInstaller
{
public SomeService SomeService;

public override void Install(DiContainerBindings b)
{
b.Bind()
.Default()
.FromInstance(SomeService)
.LinkDontDestroyOnLoad();
}
}
```

# Async dependencies

Creation of the container is a synchronous process, if you need to do any kind of asynchronous work you can do the following:
- Simple but with delayed construction: Load the asynchronous data before creating the container, then provide it synchronously.
```csharp
SomeConfig someConfig = await GetSomeConfig();

IDiContainer container = new DiContainerBindings()
.InstallSomeFunctionality(someConfig)
.Build();
```

- Avoids delayed construction but complex: Handle asynchronous loading after the object graph is built, the design should take into account that those dependencies are not available from the beginning

```csharp
IDiContainer container = new DiContainerBindings()
.InstallSomeFunctionality()
.Build();

var initializer = container.Resolve();

await initializer.StartApplication();
```

# Unsafe Binding (Experimental)

The following is experimental and might be removed.

The bindings may also be done with a non type safe interface. This variant should only be used when implementing programmatic driven configuration. Use the type safe variant when all the types involved are known.

```csharp
List someTypes = GetSomeTypesWithReflection();
foreach(var type in someTypes)
{
b.Bind(type)....
}
```

Using reflection to do such bindings will slow down your application due to the runtime Type metadata analysis necessary.

If the reduced performance is not desired, [source generation](https://github.com/PereViader/ManualDi/tree/develop/ManualDi.Main/ManualDi.Main.Generators) of equivalent code that avoids reflection can be done to do the analysis at build time.

Some platforms may not even be compatible with reflection. If you target any such platform, using source generators is the only approach.