SwiftUI by example: @ObservedObject vs. @StateObject. Why Apple had to add a new property wrapper?
Вставка
- Опубліковано 11 вер 2024
- In this video, I am showing an example where we will see the difference between @StateObject and @ObservedObject. What can go wrong.
The declarative nature of SwiftUI makes it easily to setup a working project, but it also does a lot of things in the background. Some of them can have big implications that we will not get aware of until things go wrong.
Views are constantly thrown away and recreated in SwiftUI, because they need to be redrawn whenever values change. I will talk about the view lifecycle and how we can use state to keep view models outside of it.
🖐 You can down load the project from my GitHub and start coding along side me.
github.com/gah...
⬇️ you can find the image here: github.com/gah...
If you liked what you learned and you want to see more, check out one of my courses!
👨💻 my SwiftUI course school.swiftyp...
👨💻 my Core Data and SwiftUI course school.swiftyp...
👩🏻💻 Combine course school.swiftyp...
#SwiftUI #iOSDevelopment #PropertyWrappers
Very valuable inputs, thanks! It kind of clicked now for me what happens when a binding property is recreated because a view is recreated. Well done.
I wish I can give you 100 likes...
Awesome explanation with example!!
Thanks. I like your teaching style. Using Dark mode Xcode on your tutorials would be better.
as someone who finds darkmode difficult to read, I respectfully disagree :-)
Just when I thought I should give dark mode a try 😂
@@SwiftyPlace You do you. It's your channel :-D
+1 for dark mode. Definitely.
Some of the best SwiftUI content on UA-cam. 10/10
Thanks! Very helpful video! Perfect explaining differences where use @StateObject and where @ObservedObject.
Wouldn't it also be possible to wrap the Player in a struct and use @State with that struct?
The struct will be preserved when the view is re-created, and the struct will instantiate the Player in it's constructor, so the Player object will also be preserved between view re-creations.
Thanks Karin, Awesome Explanation.
this is superb!! you like made a shortcut for the gotchas of those property wrappers
I like your explanations! Are you optimistic about SwiftUI for the long term?
I have some mixed feelings about it. SwiftUI gets more stable (that means I don't have to check the app functionality with every new iOS release). The crucial point for me is NavigationView. It keeps on pushing some of my views in an "unexpected behaviour".
As long as I don't have very specific design requirements, SwiftUI is great and fast. But customisation sometimes takes me more time than just UIKit would have taken me. Take MapView for example. For more control (which is most cases), I would need to drop down to UIKit.
For me the new features and evolution of SwiftUI are not moving very fast. During WWDC2021 we got mostly design features e.g. button styles but nothing ground breaking.
@@SwiftyPlace I feel the same, and I also have issues with how Navigation is handled. I hope SwiftUI becomes everything I hope it will. Coming to this from the Android SDK is like a dream, just need it to fill out a bit more.
Thank you. Exactly what I was looking for :-)
And then you'll end up with a lot of environment objects :) Maybe it's my little coding experience, but I feel in pursue to solve some problems of UIKitI, Apple made others with passing data in SwiftUI.
Thank you! Your doing a great content!
Thanks for sharing this. I did a little bit of physics and chemistry in highschool and quickly realized it wasn't for me. I do however derive satisfaction from watching people who know physics. Hope you check us out too
Thanks for the great Video!
At 7:30 Herr Katze is very interested in the fact that @Published properties have a Publisher.
thank you
cool
The example is too obvious. Everyone uses too simple cases. Show something like passing a ViewModel to a cell view as a parameter (the view model also has its parameters) where the cell view should react on different view models passed in. What kind of state will you use? If you use @ObservableObject then you can loose the state of cells. If use @StateObject then a cell view won't react on a new view model because @StateObject initialiser has an @autoclosure
I think it is good to show simple cases for a beginner level tutorial. But it seems you are looking for more advanced discussion.
I might do an example with multiple views that share data between them. Mostly by view models. Just to see the flow of data with @StateObject on the top level and @ObservedObject for all child views. Maybe talking about how to connect multiple view models together.
Did you have any problems with this topic in particular?
Aahahah :) Have fun coding 😂