Somehow I ended up being the first view of this video. I started as an iOS developer following Sean's interview videos 5 years ago, I ended up being a Backend/Cloud developer now. by viewing this video I realize how much I changed and how much Sean's video got better over the time. Keep it up Sean, looking at these swift videos make me want to switch back somehow to iOS developement.
you know what, Sean you are awesome. I was confused about what dependency injection was until the first 20 seconds of the video. Can't thank you enough!!
Great vid! Nice to confirm what I thought I understood with better words. BTW, I like the very short simple code technique so we can focus on the theory.
Happy to hear you liked it. I try to remove as much non-topic stuff from my videos to keep them focused. When I was learning I found this to be clearer for me as I wouldn't get confused by all the other things going on in the code. Glad you like that style too 😀
Great video as always Sean, just one thing in the company I work we prefer to use the init injection instead of the property wrapper that Resolver provides, don’t get me wrong the property wrapper work fine and it’s probably easier, but we prefer the init to avoid couple our app to that library in case anything went wrong and the library stops working, in the case that happen we just can remove it and continue working with initializers.
Absolutely fantastic video as usual, would have been even more valuable for me if you had more content on the "easier testing" I use the dependency injection to pass my view models across different views, but never quite had the practice to use it for "easier tests", as I always just use the simulator build, not llb debugging, but would have ben great to learn more about that. Thanks for the great content as usual!
When running unit test you don’t want to use your real viewmodel to network calls and logic, instead you create a mock, stub, whatever you need, and then in the unit test you pass that mock or stub, and this wouldn’t be possible by letting your views create their own dependencies.
5 years ago I started learning SWIFT and it was the worst decision in my life, this market is so small for juniors that it was such a big waste of my time ..... today I am devops with python/bash etc and I am very happy with that . I remember like I was learning from you videos , liked it but the market overall is shitty in my honest opinion, especially like technology like REACT evolved and would not recommend to anybody go to the mobile sector. It was very good in the begining, today its time of cloud/security/devops/ai not mobile apps.
Is there any downside by creating the new object directly when passing it to the child class? like this... `let viewModel = BurritoIngredientsViewModel(networkManager: NetWorkManager(), bag: Bag())` Less code. Thanks a lot for all of your videos.
Let’s not normalize ‘ER’ names like Manager. It represents a lack of understanding of the actual domain. Also, what Apple is calling Protocol Oriented Programming, is actually just Object Oriented Programming as Protocols (Interfaces in Java) represent Roles in OOP. An object should have a dependency on some sort of Role that it defines, which will also help with naming!
Hi, updating xcode to 14.3 i receive the log "[PipelineLibrary] Mapping the pipeline data cache failed, errno22" when adding the MapView in the viewcontroller. I Receive this error only when i test on a real device not in the simulator. Can i fix it ? Is a common problem? Thanks for the time I appreciate so much.
What is the difference between this and Combine's @EnvironmentObject? Isnt it good to use that wrapper instead of using parameters? I am confused sometimes about that.
@EnvironmentObject is specific to SwiftUI. If you're using SwiftUI @EnvironmentObject can be a good solution when sharing data between views (again, it's situational). I kept my code in the example abstract and vague because there are so many different ways to pass data depending on the situation (UIKit vs. SwiftUI, the types of objects, etc...)
Yes, in SwiftUI passing data via an EnvironmentObject is the likely solution. I mention in the video that my code was "pseudocode" because how you pass the data depends on the situation (UIKit vs. SwiftUI, or the type of objects, etc...), so I kept it abstract to keep that part of the video focused on the Initializer Injection. I didn't want to get bogged down explaining all the various ways to pass the data in various situations.
If you like my teaching style check out my iOS developer courses at seanallen.teachable.com
Somehow I ended up being the first view of this video. I started as an iOS developer following Sean's interview videos 5 years ago, I ended up being a Backend/Cloud developer now. by viewing this video I realize how much I changed and how much Sean's video got better over the time. Keep it up Sean, looking at these swift videos make me want to switch back somehow to iOS developement.
Blast from the past! I cringe a little bit looking back at those videos. Come on back to iOS Dev - it's fun 😀
Perfect timing for this example. I just had Chipotle today. That double meat chicken al pastor was good. 😋
I'm a double steak guy, myself.
you know what, Sean you are awesome. I was confused about what dependency injection was until the first 20 seconds of the video. Can't thank you enough!!
Happy to help 😀
Great vid! Nice to confirm what I thought I understood with better words. BTW, I like the very short simple code technique so we can focus on the theory.
Happy to hear you liked it. I try to remove as much non-topic stuff from my videos to keep them focused. When I was learning I found this to be clearer for me as I wouldn't get confused by all the other things going on in the code. Glad you like that style too 😀
Great video as always Sean, just one thing in the company I work we prefer to use the init injection instead of the property wrapper that Resolver provides, don’t get me wrong the property wrapper work fine and it’s probably easier, but we prefer the init to avoid couple our app to that library in case anything went wrong and the library stops working, in the case that happen we just can remove it and continue working with initializers.
I've never used Resolver so I can't comment on that. When I use dependency injection, 90% of the time it's initializer injection.
Absolutely fantastic video as usual, would have been even more valuable for me if you had more content on the "easier testing" I use the dependency injection to pass my view models across different views, but never quite had the practice to use it for "easier tests", as I always just use the simulator build, not llb debugging, but would have ben great to learn more about that. Thanks for the great content as usual!
When running unit test you don’t want to use your real viewmodel to network calls and logic, instead you create a mock, stub, whatever you need, and then in the unit test you pass that mock or stub, and this wouldn’t be possible by letting your views create their own dependencies.
Glad you enjoyed the video! See Christopher's answer in this thread for your test question.
@@cristopherescorcia3276 thanks so much for the detailed response! appreciate it.
big thanks!
Happy to help!
5 years ago I started learning SWIFT and it was the worst decision in my life, this market is so small for juniors that it was such a big waste of my time ..... today I am devops with python/bash etc and I am very happy with that .
I remember like I was learning from you videos , liked it but the market overall is shitty in my honest opinion, especially like technology like REACT evolved and would not recommend to anybody go to the mobile sector.
It was very good in the begining, today its time of cloud/security/devops/ai not mobile apps.
depends in what country you live in... For example iOS juniors in UK are required everywhere at the base salary starts from £55k-70k
THANK YOU SO MUCH!!!
awesome!!! :)
Good video
Glad you liked it!
Is there any downside by creating the new object directly when passing it to the child class? like this... `let viewModel = BurritoIngredientsViewModel(networkManager: NetWorkManager(), bag: Bag())` Less code. Thanks a lot for all of your videos.
Let’s not normalize ‘ER’ names like Manager. It represents a lack of understanding of the actual domain.
Also, what Apple is calling Protocol Oriented Programming, is actually just Object Oriented Programming as Protocols (Interfaces in Java) represent Roles in OOP.
An object should have a dependency on some sort of Role that it defines, which will also help with naming!
Hi, updating xcode to 14.3 i receive the log "[PipelineLibrary] Mapping the pipeline data cache failed, errno22" when adding the MapView in the viewcontroller. I Receive this error only when i test on a real device not in the simulator. Can i fix it ? Is a common problem? Thanks for the time I appreciate so much.
How auto complete for class init?
I believe thats a new feature in Xcode 14.
What is the difference between this and Combine's @EnvironmentObject? Isnt it good to use that wrapper instead of using parameters? I am confused sometimes about that.
@EnvironmentObject is specific to SwiftUI. If you're using SwiftUI @EnvironmentObject can be a good solution when sharing data between views (again, it's situational). I kept my code in the example abstract and vague because there are so many different ways to pass data depending on the situation (UIKit vs. SwiftUI, the types of objects, etc...)
If you put something in the environment using the @EnvironmentObject, it will be available to each child view after you pass it to the top-level view
@Sean Allen, why not to pass VM's via .environmentObject?
Yes, in SwiftUI passing data via an EnvironmentObject is the likely solution. I mention in the video that my code was "pseudocode" because how you pass the data depends on the situation (UIKit vs. SwiftUI, or the type of objects, etc...), so I kept it abstract to keep that part of the video focused on the Initializer Injection. I didn't want to get bogged down explaining all the various ways to pass the data in various situations.