-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retain cycles #2
Comments
You are correct. This was a simple oversight. I haven't though of a way to make this foolproof. In general, you should the following references. We know that the iOS view controller mechanism will keep the view controller properly referenced. From the point of view of the view controller (i.e. View), the Presenter is just an implementation detail. In that regard, the View is the parent and the Presenter is the child. Following standard parent–child relationships, the parent should strongly reference the child and the child should weakly reference the parent. Similarly, the Interactor is just an implementation detail of the Presenter, so the Presenter is the parent and the Interactor is the child. |
The Wireframe is responsible for wiring up all of the components for a screen, e.g. View, Presenter and Interactor. This is usually done in a lazy fashion; at the time a screen is requested. |
Will you update the demo code to fix the question? |
Everything in the VIPER TODO example is using strong references.
Unless i'm missing something this will result in nothing being released from memory. Is this behaviour intended?
I we are allocating all the dependancies, wireframes, presenters, etc in the app delegate how does this scale to a large application. Is there room in this architecture for lazy initialisation?
The text was updated successfully, but these errors were encountered: