Configurator in ViewController

[Darko Damjanovic]

Why does the configurator have to be part of the ViewController? I see no reason for it. The call to configure which wires up the presenter into the ViewController could also be done directly on creation of the Configurator.

One additional problem because of that - all instance variables hold by the Configurator are kept alive during the whole lifetime of the ViewController. But they are anyway passed during the configure() call to the right places. So they are kept twice.

But maybe there is something I am not aware of.

Thanks.

[Cosmin Stirbu]

Hi @DarkoDamjanovic

I guess the reason behind making the Configurator an instance property of the ViewController was to make the ViewController as self contained as possible.

The alternative would be to have the presenting Router create the Configurator for the presented ViewController and call configure right before presenting it. This means that all Routers would have to make an additional call to configure. I guess it doesn't make much of a difference.

I don't see a problem with the Configurator keeping alive any objects for he whole lifetime of the ViewController, as long as they are not leaked when the ViewController is deallocated.

Hopefully this answers some of your questions.

Regards,
Cosmin

[Darko Damjanovic]

Thanks Cosmin.

All in all the whole architecture looks quite good to me. Currently I just can't get over the need to have the configurator in the view controller. And also the fact the view controller creates it's own configurator. (which is also semantically somehow strange). The configurators are a kind off dependency injection container. But all the dependencies re-created over and over again on each "configure" call for each view controller. Currently I am thinking about an dependency injection container which is created once at startup (not a singleton) and then passed from router to router. In this way the dependencies do not need to be recreated every time and could be reused. But maybe I am on the wrong track, I first need to implement a real-app in this way to see how good it works.

Maybe you have an opinion about such an approach?

Thanks.

Br,
Darko

[Cosmin Stirbu]

BooksTableViewController creating its own configurator is actually an exception, since it is the initial view controller and I didn't want to mess around with didFinishLaunching for simplicity reasons.

Normally, the view controller shouldn't create its own configurator (none of the other view controllers do it).

You are right, the configurators are a kind of dependency injection container. In this sample, each view controller has it's own instances of collaborators, and you're right, most of the times this might not be the case.

You might want a single ApiClient instance that should be shared by all the other objects in your application. I took the approach of creating a new instance for each scene for simplicity reasons.

In a more complex application, the object graph of your application might contain shared collaborators, and that's perfectly fine. You should abstract that away though, behind the configurator classes and probably using a container that's shared by all configurators.

So no, you are not on the wrong track, it's just that the sample doesn't properly highlight this, and I am not sure to what degree it should.

Regards,
Cosmin

[Darko Damjanovic]

Thanks! If I ever create such a sample template project here on GitHub I will link to your project as the biggest "inspiration" for it. :)

Keep on!