ios-viper-xcode-templates icon indicating copy to clipboard operation
ios-viper-xcode-templates copied to clipboard

Using unowned reference in Presenter class

Open hahuja opened this issue 5 years ago • 4 comments

I have a scenario where user goes to next page, by pushing view controller. The next page has a collectionView and an API call, if user goes to next page, API is called and based on response collectionView is reloaded. Now, if user clicks back button very quickly(before response comes), so view controller is destroyed from memory, but since the view reference was unowned private unowned let view: KBPlusMemberDetailViewInterface, it still exists. Now, user is on the previous page and the API gives data on next page, and self.view.collectionView.reloadData() is called on the next page(which is not in memory anymore), but since self is destroyed, so the app is crashed. How can we solve this?

hahuja avatar Oct 07 '20 09:10 hahuja

Hi @hahuja ,

I'm really sorry that it took us this long to answer.

What you have just described here is memory leek. Your api call should not have a strong reference to your presenter / interactor / view. You should weakify self in the callback.

Also you should cancel the api call when the view / presenter / interactor delocates since you don't want to waste resources.

Truba avatar Feb 15 '21 08:02 Truba

Hi @hahuja,

is this issue still apparent or did you manage to fix this afterwards? If it was fixed, I would like to close the issue. If it's not, please, don't hesitate to continue the discussion and we'll try to help. 🙂

kvaljeva avatar Jun 16 '21 14:06 kvaljeva

i think this relates to my PR before

https://github.com/infinum/iOS-VIPER-Xcode-Templates/pull/40 We've tried to weakify the presenter inside the callback. but it still got this issue. that's why everytime we generate the files, we always weakify the presenter

mazmik25 avatar Jul 02 '21 06:07 mazmik25

@mazmik25 By definition, an unowned reference in this use case should be safe unless you have memory leaks/retain cycles. If the API call you were using on a pushed view controller had a callback, which had a strong reference to that controller then it makes sense why the crash happens, as described. View was deallocated, but the presenter was retained until the closure wrapped up the execution, tried to reload data and didn't find an object.

To fix this, you should ideally do two things:

  1. References to the presenter in any of the callbacks needs to be weak. Since you mentioned you tried doing this, a code sample of the issue would be much appreciated, since this shouldn't end up happening if there are no references.
  2. API call should ideally be cancelled on the module that was removed from the stack. Since the object no longer exists, there is no point to wait for the API.

If it still happens then we'd definitely need a code sample (either in a sample project or a direct copy/paste from where you're encountering the issue). We'll then try checking that out and reproducing to see if there's a programmer error involved.

kvaljeva avatar Oct 10 '21 19:10 kvaljeva