Thank you because I learned Java in Eclipse and it was obvious we were pretending memory didn’t exist. That’s fine for python scripts but I want to move into real apps!
Yes, I have also some confusion, as video tutorial states that the code doesn’t give any error but if give weak self then it will not leak the memory. Then how do we know when n where memory will leak?
Tell me if I’m wrong.. but I think it’s because the AlertController is not owned by the “ViewController”. Once dismissed, the AlertController has no reference pointing it and it is released.
The answer is simple, what this youtuber said is not correct about the alert controller. The alert controller is not owned by "self", so there is no retain cycle. He is misleading others.
You give wrong examples about reference cycles. In all your examples, you use a local reference type variable of functions. Such variables do not hold by class it is in the function scope. If you move your alert var in class scope, then you will get ref cycle. You can easily check that by using the deinit in your class for checking did you viewcontroller call it or not.
Hi westo127! My response may not be the most precise or accurate as I am also still learning, but this is my understanding of iOS memory management. To address your question, the object's data type (i.e. Struct) isn't the concern. A retain cycle occurs when two separate objects are strongly pointing to (referencing) each other; if one of the objects is deallocated (removed) from memory while another object is still strongly referencing it, the object that is referencing the deallocated object will still exist in memory somewhere, pointing to (or otherwise linked to) some object that no longer exists in memory - taking up space while serving no purpose. The goal of proper memory management is to ensure that objects that are added to memory are deallocated if they are no longer being used. In the example provided, there are two objects: ViewController and Alert. The parent ViewController object is strongly pointing to a child Alert object because the Alert object is defined within the ViewController object; this Alert object is a separate object from the ViewController object though it is defined in the ViewController class. If memory is properly managed, the Alert object should be deallocated from memory if the ViewController gets deallocated from memory. Before the edit was made to the Alert object's handler, the Alert object was strongly referencing the parent ViewController class by calling the parent ViewController's method 'doSomething()'. Since the ViewController object strongly references the Alert object and the Alert object is strongly referencing the ViewController by calling the ViewControllers doSomething() method, this causes a retain cycle. To prevent a retain cycle, you want the child Alert object to weakly reference the ViewController's doSomething method; that way when the user dismisses the Alert object from the View - an action that should deallocate the Alert object from memory - the strong reference to the ViewController won't prevent that from happening. Hope this was helpful and not just a reiteration of what was previously discussed in the video. :)
It doesn't seem that iOS is going to pick up on memory leaks. I haven't delved into this subject much more than this video, but surely Swift should have built in tools to help pinpoint memory leaks ?
When you want to ref to your current variable inside VC, for example in init u can assign what u get as a param into your local variable. for exmaple - self.count = count(the param that u get from the user). btw there's self in every programming langue :)
Strong is default because you don’t want your object to just disappear when you need it, do you? So figure out how you want to handle it, and then use weak.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
![When do we REALLY need to use [weak self]? 🤔](/img/1.gif)
Clearest explanation out there for this :)
Thanks! Did you like my balloon example hahaha
Awesome! I was really looking forward to a video on this topic from you. Thank you for making it.
Youre welcome!
Great! The explanation is so clear and easy to understand. But it seems that the audio volume is a quite low. Keep up the good work!
Thank you!
Not even a month ago, did I think the topic is incredibly hard to understand. It's a piece of cake now.
Glad to hear it
Very unique way to define weak and strong also handle memory leakage.
omg Thank you so much for explaining this out.! i love ur content btw. :)
Youre welcome!
It was awesome, best explanation ever scene on this topic!
Thanks!
Thank you because I learned Java in Eclipse and it was obvious we were pretending memory didn’t exist. That’s fine for python scripts but I want to move into real apps!
Youre welcome! Glad i could help
wow! was reading about this the other day and can't really understand. lol. Thank you for this.
Ha ha you’re welcome, glad I could help. Don’t forget to subscribe!
I tried AlertConroller example and checked in instruments but didn't get leaks indicator. Can you please tell me why is it happening?
Yes, I have also some confusion, as video tutorial states that the code doesn’t give any error but if give weak self then it will not leak the memory. Then how do we know when n where memory will leak?
Tell me if I’m wrong.. but I think it’s because the AlertController is not owned by the “ViewController”.
Once dismissed, the AlertController has no reference pointing it and it is released.
The answer is simple, what this youtuber said is not correct about the alert controller. The alert controller is not owned by "self", so there is no retain cycle. He is misleading others.
You give wrong examples about reference cycles. In all your examples, you use a local reference type variable of functions. Such variables do not hold by class it is in the function scope. If you move your alert var in class scope, then you will get ref cycle. You can easily check that by using the deinit in your class for checking did you viewcontroller call it or not.
Please do a follow up video
Coming soon
Thanks bro, really helped a lot👌🏽
Glad it helped
12:00 It would be the same even if func getData() wasnt private?
Very Helpful video...Thanks Bro.. :)
Your welcomd! Dont forget to subscribe and like
Great explanation !
Thanks!
Super awesome!
Thanks
Still the best
Thanks!
Thank you very much for the content! Can you do one for core data and saving and retrieving in an ios file system?
Youre welcome & sure! Added to my list
In SomeDelegate example you wrote weak var delegate : SomeDelegate? is weak necessary? I think making it optional is already weak right?
Weak is needed to avoid retain cycle.
iOS Academy but optional doesn't already have weak reference?
Great explanation! Make a video on Local DB in IOS App with SQLite.
Will do soon
cool, cool. so what about dog holding a balloon scenario?
You are the best
haha thanks!
What if the "self" in a closure was of Struct type; Is it still possible to have a retain cycle?
Hi westo127!
My response may not be the most precise or accurate as I am also still learning, but this is my understanding of iOS memory management.
To address your question, the object's data type (i.e. Struct) isn't the concern.
A retain cycle occurs when two separate objects are strongly pointing to (referencing) each other; if one of the objects is deallocated (removed) from memory while another object is still strongly referencing it, the object that is referencing the deallocated object will still exist in memory somewhere, pointing to (or otherwise linked to) some object that no longer exists in memory - taking up space while serving no purpose. The goal of proper memory management is to ensure that objects that are added to memory are deallocated if they are no longer being used.
In the example provided, there are two objects: ViewController and Alert. The parent ViewController object is strongly pointing to a child Alert object because the Alert object is defined within the ViewController object; this Alert object is a separate object from the ViewController object though it is defined in the ViewController class. If memory is properly managed, the Alert object should be deallocated from memory if the ViewController gets deallocated from memory. Before the edit was made to the Alert object's handler, the Alert object was strongly referencing the parent ViewController class by calling the parent ViewController's method 'doSomething()'. Since the ViewController object strongly references the Alert object and the Alert object is strongly referencing the ViewController by calling the ViewControllers doSomething() method, this causes a retain cycle. To prevent a retain cycle, you want the child Alert object to weakly reference the ViewController's doSomething method; that way when the user dismisses the Alert object from the View - an action that should deallocate the Alert object from memory - the strong reference to the ViewController won't prevent that from happening.
Hope this was helpful and not just a reiteration of what was previously discussed in the video. :)
It doesn't seem that iOS is going to pick up on memory leaks. I haven't delved into this subject much more than this video, but surely Swift should have built in tools to help pinpoint memory leaks ?
thank you !
Youre welcome
One small question, when to use self and when not?
Swlf is needed in closures
When you want to ref to your current variable inside VC, for example in init u can assign what u get as a param into your local variable. for exmaple - self.count = count(the param that u get from the user). btw there's self in every programming langue :)
Thanks for sharing but it seems to me like there is no point in using a strong reverence . Why wouldn’t we use a weak reference ?
Strong is default because you don’t want your object to just disappear when you need it, do you? So figure out how you want to handle it, and then use weak.
For some reason I'm having a hard time replicating this on swiftUI rather than UIKit. Any chance anyone can help me out here?
So should use [weak self] in all closures?
Yes, almost 99 percent of time
I feel pretty embarrassed 🤭. I made whole project with memory leaks 😂. Thanks, I'm gonna fix it right now
We’ve all been there!
self? as an optional makes sense ~
Agreed
weak selfムズすぎる😭
Yep haha
#suddenlyitalian
completino hahaha
but great video! very informative!!
Not a good explanation. Did not understand it at all.
Thanks for the feedback
very very complex.. please dont upload this kind of videos create more confusion