Add ControllerFactory.

[AngusMorton]

ControllerFactory allows Controllers to be provided dependencies through their constructors after a configuration change. This means field injection is no longer a requirement when injecting dependencies into a Controller.

Usage

Conductor.setControllerFactory(myControllerFactory)

Currently, you have a single ControllerFactory for your entire app. Having a ControllerFactory per Activity/ViewGroup would be better but I don't know enough about Conductors internals to make that change.

Closes #510.

[PaulWoitaschek]

I would make the Factory an interface and make the default factory final and hide the implementation.
That doesn't force the user to extend a class (composition over inheritance).

Then you could also just do a identity check in ensureRequiredConstructor() and perform an early return without the need for reflection:

if(FACTORY != DefaultControllerFactory.instance() {
  return
}

Another approach (which I prefere) would be to pass the factory to conductor upon initialzation:
Conductor.attachRouter(this, controllerContainer, savedInstanceState, factory)

Then in attachRouter you can just set the factory and don't expose the other implementations.
I don't have currently time to check if this could work.

But I really like the idea to get rid of reflection and allow constructor injection.
However this whole approach is quite limited as dagger has no support for assistend injection. That effectively means that once need a bundle in the constructor you either need to do field injection or workaround it.

[AngusMorton]

Thanks for the feedback! I've made the interface change.

If attachRouter accepts a factory, then it follows that you should be able to set a different ControllerFactory per Activity/ViewGroup pair.
I think having a ControllerFactory per Activity/ViewGroup makes sense, but I'm not sure if it'll complicate things too much though.

Dagger doesn't need first-party support for assisted injection, it can be provided through something like AssistedInject or AutoFactory.

[MkhytarMkhoian]

  Controller shouldn't know about any factory

[MkhytarMkhoian]

I think DefaultControllerFactory should implement default logic for creating Controller, but not just be a stub in logic

[AngusMorton]

We could only do that without extra reflection if the first argument for create was a Class.

[AngusMorton]

@PaulWoitaschek I had a look into adding ControllerFactory as an argument to attachRouter, however, we need some way to retrieve the correct ControllerFactory for the Activity when we are restoring the Backstack. I'm not familiar enough with the internals of Conductor to know what the right approach for this would be so I'm keen to hear any thoughts you have.

Assuming we store the ControllerFactory in the LifecycleHandler, we would need some way for a Router to get it's ControllerFactory, which it would then pass that down through to Backstack.restoreInstanceState -> new RouterTransaction.

[AngusMorton]

@EricKuck I'm keen to hear your thoughts on this and move this forward

[Miha-x64]

One more thing: if Factory instantiates Controllers, we need a way to create transaction without instantiating controllers ourselves. RouterTransaction.with(controllerType: Class<out Controller>)

[AngusMorton]

One more thing: if Factory instantiates Controllers, we need a way to create transaction without instantiating controllers ourselves. RouterTransaction.with(controllerType: Class<out Controller>)

ControllerFactory would be in your dependency graph so you can inject it and call it yourself!