-
Notifications
You must be signed in to change notification settings - Fork 88
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
Use [weak self] when loading image in detail view. #15
Comments
just also come across too know about [unowned self] but [weak self] is better to use in Asynchronous call and closures
|
I am passing a function handleDownloadPosterImage(data:error) instead of closure. Now my question is how do I make weak self in the function instead of closure? Do I have save issue or not? |
[weak self] when loading image in movie detail view controller. This ensures the image view no longer exists if we did not need it or call it in order to safe memory app . Am I right? |
instead of referring to self.imageview in your function, create a variable:
you can also use the keyword unowned instead of weak. Here is an overview of the differences: |
Thanks @BrentMifsud for taking time and answering this. 🙏 |
Remember how we accessed the global image view property in
downloadPosterImage
's completion handler?When reviewing the code, one of our iOS Engineers at Udacity, @jsvatek, noted the following.
While the specific discussion of memory management issues on iOS is more than can be explained in a single GitHub issue, you may want to consider the advice that it's better "safe than sorry" when writing code. Because we're accessing
self.imageView
, which belongs to the detail view controller, from the completion handler, we do indeed need[weak self]
here. This ensures the image view is not retained after the detail view (and therefore the image view) no longer exists.What is
[weak self]
? How does one use it? A good discussion can be found here, and this is definitely something to pay attention to in the future.https://blog.bobthedeveloper.io/swift-retention-cycle-in-closures-and-delegate-836c469ef128
And you may also find Apple's discussion of Automatic Reference Counting worth a read to avoid memory issues in the future.
https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html
The text was updated successfully, but these errors were encountered: