Hi Afraz, first, I thank you for the great content. I've already watched some videos and I've learned a lot. My question is: isn't this Resolver DI kind of anti-pattern? I mean, you only know whether the resolvers "resolves" into a valid / existing class at run time, so you kind of sacrifice the safety of the compiler warnings. What do you address this? Or what are your thoughts about it? Thanks in advance!
Always had trouble trying to understand dependency injection, but this video gives me a really good picture, thanks! Definitely looking forward to more on this topic if you ever decide to make them!
Great video! You make the best content on iOS on RUclips. It would be great to see this di container used in an app with full architecture maybe with a similar implementation to dotnet , I would love to see you convert one of the apps you built on here to use dependency injection instead of singletons
Hi! I'm a big fan of your channel Could you please do a video about how to save images to Realm next time? Thank you for your effort all the time and please keep your channel active :)
Why would you try to resolve an instance or metatype in a "real world" app? Maybe to make sure there's only a copy of the same object in some very specific scenario? i'm pretty sure Sets work like that under the hood aswell
You know your stuff, but those mistakes are quite annoying, my ADHD brain focuses on the same prints, or the body in the protocol function, and cannot comprehend the important stuff. Type slower, verify your code, and try to make less mistakes.
I may be missing something or maybe you and I use different terms; but I know the "dependency injection" to be something like this: let myService = Service(provider: APIProvider.shared) More specifically it would be a subset of dependency injection called "constructor injection." That is possible because your APIProvider class conforms to your protocol. The Service class depends on any object that conforms to the Providing protocol; so, you inject it via the constructor. I am unclear why you need the resolver. The Resolver's behavior looks more akin to a hash map as a class instance. It's a container for key-value pairs that happen to be objects (of the Providing protocol).
You can look at Swinject - it works basically the same as on the video but has some more convenience APIs to easier resolve and register the dependencies. It is no magic. You always need to ask yourself if it is worth to link against another dependency to just do simple cases. Depends on the project I guess
There are different forms of dependency injection. The resolver in the video is one pattern, passing it via init is another. Doing both is what i do (passing the dependency via init, and in the initializer parameter i call the resolvers resolve method and let swift handle all the right type requirements. that way i can test this class isolated with a mock. but still inject dependencies from a higher level to all classes that use it.
Lets connect: linkedin.com/in/afrazsiddiqui
Hi Afraz, first, I thank you for the great content. I've already watched some videos and I've learned a lot.
My question is: isn't this Resolver DI kind of anti-pattern? I mean, you only know whether the resolvers "resolves" into a valid / existing class at run time, so you kind of sacrifice the safety of the compiler warnings.
What do you address this? Or what are your thoughts about it?
Thanks in advance!
Thanks a lot for explaining DI container concept in swift such an easy way. Many Thanks !!
Always had trouble trying to understand dependency injection, but this video gives me a really good picture, thanks! Definitely looking forward to more on this topic if you ever decide to make them!
Thanks
Great video! You make the best content on iOS on RUclips. It would be great to see this di container used in an app with full architecture maybe with a similar implementation to dotnet , I would love to see you convert one of the apps you built on here to use dependency injection instead of singletons
Thanks
Super cool!
Thanks
Man you mistaked the second id uses the first object afraz again.
And the Ids in the console are the same...
Yep, I realized this afterwards. Copy and paste got me haha
@@iOSAcademy haha, we all do this man, but be more careful next time 😂😀
Exfluding that little bug great video!
CopyAndPastecidis C is a real disease :)
Hi! I'm a big fan of your channel Could you please do a video about how to save images to Realm next time? Thank you for your effort all the time and please keep your channel active :)
Sure thing!
Why would you try to resolve an instance or metatype in a "real world" app? Maybe to make sure there's only a copy of the same object in some very specific scenario? i'm pretty sure Sets work like that under the hood aswell
To avoid explicit dependencies
wow! thx
Youre welcome
🔥🔥🔥🧨🧨🧨
Thanks
Thanks, bro. I'm struggling to display monthly user data on the chart using the Uikit framework
Youre welcome
Hah, brain sees what it want to see. You forgot to update instance of a joe for second string, and the addresses were the same.
Yeah at 2:32 into the video, line 15 should take the ObjectIdentifier(joe) instead of afraz
I would use a simple example that vividly demonstrate the utility of Object Identifiers. All these pieces and code gymnastic just lose the point.
Thanks for the feedback
You know your stuff, but those mistakes are quite annoying, my ADHD brain focuses on the same prints, or the body in the protocol function, and cannot comprehend the important stuff. Type slower, verify your code, and try to make less mistakes.
He danced too much around the main point. We're all human and make mistake.
Thanks for the feedback
Bro the example you gave is too complex. You lost me here
Thanks for the feedback
I may be missing something or maybe you and I use different terms; but I know the "dependency injection" to be something like this:
let myService = Service(provider: APIProvider.shared)
More specifically it would be a subset of dependency injection called "constructor injection." That is possible because your APIProvider class conforms to your protocol. The Service class depends on any object that conforms to the Providing protocol; so, you inject it via the constructor.
I am unclear why you need the resolver. The Resolver's behavior looks more akin to a hash map as a class instance. It's a container for key-value pairs that happen to be objects (of the Providing protocol).
Correct. Reaolvers aee used in larger apps to pass deps. multiple levels
You can look at Swinject - it works basically the same as on the video but has some more convenience APIs to easier resolve and register the dependencies. It is no magic. You always need to ask yourself if it is worth to link against another dependency to just do simple cases. Depends on the project I guess
There are different forms of dependency injection. The resolver in the video is one pattern, passing it via init is another.
Doing both is what i do (passing the dependency via init, and in the initializer parameter i call the resolvers resolve method and let swift handle all the right type requirements.
that way i can test this class isolated with a mock. but still inject dependencies from a higher level to all classes that use it.