@@TheBooban Great question. Closures are a really easy way to accidentally introduce retain cycles in code. That's why you see so many. I don't have an example of one not using a closure handy. But with some Googling I am sure you could find one. Cheers.
if you have one or two closures this might save some typing but I think using a protocol delegate starts to make more sense. Plus it makes sure you don't forget a func. It's always good to be exposed to different approaches though. Thank you.
I agree Avocado. I generally prefer protocol-delegate. Apple seems to be pushing closure more with Swift however, so I wanted to try and see what it looked like. Agree 100% its good to try different things and see what you like. All the best.
At 5:18, since your weatherService is a struct instance, instead of capturing [weak self] you can simply capture [weatherService]. This way you capture only exactly what you need and nothing more. And being a value type you don’t have to worry about retain cycles. And in the closure you aren’t mutating weatherService in any way so you won’t create unnecessary copies of the value at this point or worry about keeping mutations made inside the closure in sync with the value outside. Refer www.swiftbysundell.com/articles/swifts-closure-capturing-mechanics/#capturing-values
Hi Prathamesh - good points. Here the retain cycle isn't between the ViewController and the WeatherService. It's between the ViewController and the extracted View - which are both classes. Hence the need for [weak self] as both use reference semantics. Thanks for sharing. Cheers - Jonathan
@@swiftarcade7632 Thanks Jonathan. My point is you don’t need to capture self at all if you only have to use one of its properties inside the closure. You can capture the property instead.
Great example with a clear fix explanation.
Clean and strightforward.
Thank you sir.
Awesome stuff! I really liked your closure video and totally missed that retain cycle too. Thanks for the transparency and follow-up!
Ya no problem. That was a bit embarrassing. But it happens! Thanks for the comment.
@@swiftarcade7632 Every example I see is with a closure. Why is it always a closure? Is there an example without a closure?
@@TheBooban Great question. Closures are a really easy way to accidentally introduce retain cycles in code. That's why you see so many. I don't have an example of one not using a closure handy. But with some Googling I am sure you could find one. Cheers.
@@swiftarcade7632 i googled. Can’t find one. In a class, what does var a = self do? I think thats a retain cycle too?
@@TheBooban I found one here: medium.com/mackmobile/avoiding-retain-cycles-in-swift-7b08d50fe3ef
Thank you.
Clean and Straightforward.
if you have one or two closures this might save some typing but I think using a protocol delegate starts to make more sense. Plus it makes sure you don't forget a func. It's always good to be exposed to different approaches though. Thank you.
I agree Avocado. I generally prefer protocol-delegate. Apple seems to be pushing closure more with Swift however, so I wanted to try and see what it looked like. Agree 100% its good to try different things and see what you like. All the best.
Thanks Jonathan...
Most welcome.
Why couldn’t you just make the WeatherView properties that point back to the WeatherViewController “weak var”?
At 5:18, since your weatherService is a struct instance, instead of capturing [weak self] you can simply capture [weatherService]. This way you capture only exactly what you need and nothing more. And being a value type you don’t have to worry about retain cycles. And in the closure you aren’t mutating weatherService in any way so you won’t create unnecessary copies of the value at this point or worry about keeping mutations made inside the closure in sync with the value outside. Refer www.swiftbysundell.com/articles/swifts-closure-capturing-mechanics/#capturing-values
Hi Prathamesh - good points. Here the retain cycle isn't between the ViewController and the WeatherService. It's between the ViewController and the extracted View - which are both classes. Hence the need for [weak self] as both use reference semantics. Thanks for sharing. Cheers - Jonathan
@@swiftarcade7632 Thanks Jonathan. My point is you don’t need to capture self at all if you only have to use one of its properties inside the closure. You can capture the property instead.
@@p16r Ah my apologies - sorry I misunderstood. Yes you are correct - always best to only capture what you need. Thx for pointing out.