How to use weak self in Swift | Continued Learning #18
Вставка
- Опубліковано 8 вер 2024
- Swift uses Automatic Reference Counting (ARC) to manage your app’s memory usage. As a developer, you want to try to keep the ARC count as low as possible, which will keep your app running fast and efficiently. In this video we will learn how to use "weak references" instead of "strong references" to keep our count low!
This can be quite a confusing topic for new developers, so we will first spend some time reviewing the problem before learning how to implement the solution.
Learn more about ARC: docs.swift.org...
Learn more about weak self: www.avanderlee...
*Note: I am aware that Swift also has "unowned self" which is often mentioned with "weak self". However, if you use "unowned" incorrectly, it will crash you app. Therefore I am only teaching "weak self" in this course as it is safer and more common.
Next video: • How to use Typealias i...
Last video: • Multi-threading with b...
🤙 WELCOME BACK 🤙
WEBSITE: www.swiftful-t...
DISCORD: / discord
GITHUB: github.com/Swi...
SAY THANKS: www.buymeacoff...
Very pleased to find a final answer/explanation to the intriguing subject of [weak self]. Your explanation is crystal clear and beginner friendly. I'm really enjoying your video series Swiftful Continued Learning. Many thanks.
Glad this helped. It's probably one of the most difficult concepts in iOS development, to be honest!
@@SwiftfulThinking To second Kenj's comment. it being beginner friendly is such a blessing. Thank you as always Nick. Great video.
Man you explain things better than most tutorials out there. Thanks!
I appreciate that! Thanks Will!
Very simple and clear explanation! Reference counting is something that has always scared me away from Objective-C, and the explanations of ARC I've read in Swift have never really made it any clearer. This is the first time it's ever clicked for me!
BTW, congrats on reaching 1000 subscribers!
Glad to hear this.. I found this topic pretty complicated when learning as well.... and thanks!!! It's been pretty hard to get subscribers so far (I guess there's a lot of competition in this space), but 1,000 is a big milestone 🥳 Thanks for following along Bob
@Nick just a small suggestion. When you are explaining the concept at start of the video, it would be less distracting if the video title fades away. And better yet you show code snippet that you are talking about.
Simplest explanation of retain cycles I could find so far. I actually understand why it happens now and what actually happens. Even discovered "Debug Memory Graph" while tinkering which had as many instances of the VM as the count, so at the very least I know how to check for these.
You have a special gift for teaching Nick! Thanks.
Best explanation on the internet, THANK YOU!
Fantastic stuff. Seems the “strong” self is used in very limited circumstances where you don’t want to lose the action and most of the time use the Weak Self.
Yea, that's pretty much it! Adding a weak reference almost always used in asynchronous code and is usually the safer route.
Go Beyond Nick.... Gratitude for all lessons
Haha thanks again Andrej!
I am so grateful to you Nick! You are so good at explaining. Thanks a lot
Your content is golden ! Hope it stays on for a long time so I can come back to review it when needed !
Very clear, as always! Super grateful for your presence on YT!
Great video. Useful topic and really well explained. Thanks.
Thanks for the comment John!
Dude, thank you! Your explanation was super clear. Brilliant demo to break this down. This has always been confusing to me as I wasn't sure how the relationship was actually connected. I was confused before because I always wondered how you knew what was gonna be a strong reference. I didn't know it was keeping a class in memory just simply by calling self with a strong reference. Had no idea that simply calling self was THE THING that was creating the strong reference. Hard to explain my confusion with all this, but thank you for making that light go off in my head!🙏
Haha yea this is one of the hardest concepts to grasp. Generally, adding weak references will fix a lot of the memory leaks in your app 🥳
Thats a fantastic explanation with an example. I really appreciate your videos. Thanks a lot.
best video about weak self ever, thank you Nick !
thanks man... i m so glad i found ur channel
Thanks for the comment 👍
Thank you so much dude. weak self is very clear now.
Hi Nick, great video as always .
I have a question regarding the init and deinit, following your code example I could see that the view initialize and then deintialize the old one, but If I use navigationStack instead of navigationView, I get a totally different behavior as follows:
- when you visit the second screen it initialize the view.
- when you go back to the first screen, it deinitialize the view instantly
- when you go to the second screen the count goes from 0 to 1 and when you go back the count is 0.
Could you explain why the behavior is different, because I find this behavior more natural and make sense
Of course I understand that when you made this video, NavigationStack was not yet introduced since it's part of iOS 16.
Awesome. Finally it makes sense to me. Thanks you.
Great explanation, Nick. Very clear and concise. Thank you very much for your work
Thank u nick for this awesome video..❤
best explanation ever! I am really grateful for your videos!
Thanks Melvin!
Amazingly Explained. 👏🏻
Amazing explaination !!!!
Very clear thankyou so much
Thanks for watching Mochamad!
Very good explanation, thx for clearing that up!
Thanks Nick, super.
Glad you liked it!
best tutorial!
AMAZING! This was a topic that always confused me, but you made it so simple. Thanks Nick, you're amazing !! :)
Haha glad it finally clicked! This is a pretty hard topic!
swift king !
Great explenation! Thank you for that
Ah...This is so much awesome....Thank you...
Very simple and clear explanation
you have taken approx 3 minutes for the solution. but taken 17 minutes to introduce the problem. you have a unique way of teaching. Thank you
Great tutorial: thank you !!
Thank you so much for this video.. This will help me to build my app more efficiently as possible.❤️
Another great video. 👏
So clear 🙏 thank you!
Great explanation. How do you create a strong self on the first time, but weak after that? I imagine that might be useful to get data and save it to the app on the firs try but not subsequently.
that was very helpful, thank you!
I took maybe 8 years of study on UA-cam really I don't give anyone more than two or three likes, But for your videos must I give it 1k likes.
please we need list talking about architecture as MVP and VIPER, I don't know if I write spell that ok or not 😅
Thank's
Thank you so much. So what happens when the weak self async task is finally finished? To which vm does it return the data back to? The first, I’m guessing? Weak self basically keeps the first vm alive while normally deinting all following vms and views?
I'm thinking about it now, but I've read that you actually don't need a weak self reference when in animation blocks in UIKit for example
Animation blocks usually don’t need weak references. They are almost always done on the main thread and in classes that you don’t deallocate. This is often used for networking and other asynchronous code.
Best!
At around 12:24 mark, when the second view is initialised and the count increases to 1, why when we go back to Screen 1 does Screen 2 not get de-initialised and the count returned to 0?. It only seems to get de-initialised when the Screen 2 is displayed for a second time looking like there will always be a reference held in memory.
same question here
it is a little difficult to apprehend, if I understand it's mean that we have several time the same class in memory without weak
Hey Michel, yea it sounds like you understand. We basically only want the classes we are using in the memory and we want all "old" classes to deinitialize properly.
Hey ! you are very beautiful to explain)) I will watch your video
I believe failing to release views does not technically slow your app down, at least not directly. What it does is increase the apps memory footprint (that could indirectly cause a slow down). More importantly, that could cause a crash if your app has a chance to create too many of these useless references.
Thank you
Somebody knows why print statement dosn't work. I always have an empty console. No worning, no print. nothing? I figured it out. If you have the same issue, it's probably because of the two small buttons in the very right-bottom corner: Show the variables view and Show the consle.
Hey Nick,
thanks for the great explanation of weak self.
So with weak self we are enabling the deinit to be called, when the second view is dismissed with the goal to free up resources and guarantee our app staying a fluent expierence.
With the init we start the execution of getData(), which I put in a background thread. When I call the deinit by dismissing the second view, the app frees up the resource holding the second view, but my background tasks still keeps working.
Since the result of the background task will not be needed, because second views deinit has been called and therefore the second view does not exist anymore, is there a way to cancel the background task within the deinit to free up even more resources?
Hi,
Thank you for your remarkable explanation!
Only one thing that I can't understand... Why do you always say, "It's okay if this class disappear". In my understanding of OPP - a class is instructions for creating an object, correct? An object should disappear - not a class
Oh I see. I'm referring to an instance of the class and not the class itself.
If I do need this data to download, and I leave this second page, and when the data almost download, I come back to this second screen, does the data download from beginning again?
Might be because of swiftUI upadates, but for me, every time I go to a new view count goes up one, and when I go back to old view, it get deinitialized and count goes back to 0
Are you using NavigationStack now?
@@SwiftfulThinking yea
@@alextoma402I think that’s why. That API is lazy by default.
@@SwiftfulThinking gotcha. I still got the gist of the lesson either way 🙏🏼
Sorry I don't understand why use @observable it doesn't work
when you will do about Debugging ?
is it good practise to have only one VM per App? Given it is a simple app, or is it better to have one VM per screen
Usually one VM per screen. It is a “View”-Model because it models the data for that View (aka screen)! Sometimes we can share the VM though if multiple screens share the same data.
Amazing explanation!
I will use weak! But I have a question!
when we use "self.data" ,not use weak
the instance is continuously remain in memory right?
when I try about 5 times try remain in memory on purpose
And then when instance remain in the memory , if I load the data until completely download. the data on the UI that is first instance ? or lately instance?
I'm not sure you can understand my question because I'm not good well English^^
but I'm wondering about that if use the "self" the first second...until n times.
which instance is appear in the end in ui.......um..
I think lately instance appear in the end and another instance is remaining ineffieciently condition in memory..Right?
Do we just use weak self with closures?
Yes
Could you please share an video that how to clean mac files to save enough space for xcode installation. I found always waste time to do that, however always could not save enough space.
This is a stress for all of us lol
Whats the differents between weak and unwoned?
tell obout unowned self
hi nick i was wondering if also using
DispatchQueue.main.async { } needs to be weak self as well? if im refering a variable with self?
We use weak self if there is a chance that “self” gets reallocated before the closure executes. Since DispatchQueue.main.async is happening “almost” immediately, we can assume “self” still exists and therefore do not need it (but it would still work if you have it)