Hi guys, around 32:30 you say the Payment Flow class is easily testable. Can you provide a hint on how to do it? Thanks a lot for these contents. You guy are doing great.
Excellent coverage of a topic that's at the back of every iOS developers mind! I have tried different approaches to this problem, but this is the cleanest I have found! A small request - would you be so kind as to publish the source code that you white boarded to illustrate the proposed solution during this Q and A session? Thanks so much!
Great content. I am wondering about how to handle inter-dependencies between feature modules. let's say all features require an OAuth authorisation service or some features process on the same data layer/Objects?
Hi Souhail, it depends on what you're trying to achieve. If you want to maintain the modules decoupled from authorization, you can invert the dependency with an abstraction and implement it with a Decorator or an Adapter, for example. This way, you can inject authorization into the modules without modifying them. But it depends on what you want to achieve.
Whats the best way to go through the legacy code and understand the flow when there is no documentation present for the same? How can we start with documentation as we go through the code... Please share the link if u have already covered this topic.... Once again thanks a lot for your time and great way of spreading knowledge
Here are 3 short videos about it 👇 ruclips.net/video/wGpsH40seGQ/видео.html ruclips.net/video/4g0NOmDp8X0/видео.html ruclips.net/video/0mFL0nsOaUQ/видео.html
Not sure to 100% get what's the difference between the Flow class and a Coordinator? You said the flow doesn't have a child or parent, but then you need to keep a reference to the Flow class somewhere too right? So it's retained?
Hello! There are many other ways to keep it in memory without a child/parent model. For example, the view controller can hold it indirectly - so the flow is retained just as long as the view controller.
@@EssentialDeveloper What does it mean to hold indirectly? Keeping a delegate reference as strong? Seems confusing and unintuitive to me, as most of iOS developers expect the delegate to have a weak reference. Actually, I would argue that the whole point of a delegate pattern is maintaining parent- child relationship without creating a retain cycle, using an interface as a strategy. So I don’t get the reasoning behind this demo. You try to solve a problem by creating a new ‘hidden’ problem. A better solution seems to be a closure, which then the client can determine the type of reference, seems more understandable to me. But then, many closures can be very much unreadable and hard to reason about.
Hi Niko! Indirectly means through any kind of indirect reference, such as a protocol, closure, or object association. So, no, you don't need to make the delegate strong. We do it with closures instead of delegates. But if you want to do it through weak delegates, you could use `objc_setAssociatedObject` to indirectly connect both objects. Moreover, there's nothing wrong with strong delegates. You can even find them in the Foundation framework. For example, the URLSession delegate is a strong reference. You can also combine them directly if you want to - we just mentioned that you *don't* need to - it's a choice. (Although maintaining parent/child relationships within Coordinators creates a much bigger problem: a lot of complexity to manually keep them in sync to avoid memory issues. You end up replicating the UIViewController parent/child relationship everywhere - which is unnecessary in most cases). Again, it's a choice - there's no absolute answer - and we want to share different ways of doing things so you can choose the best option depending on the current requirements.
Returning a view controller is a great way. As you said client can handle how to show the payment. Thank you.
thanks for great video!
Glad you liked it!
You guys are really doing great.
Thank you, Madhur!
Hi guys, around 32:30 you say the Payment Flow class is easily testable. Can you provide a hint on how to do it? Thanks a lot for these contents. You guy are doing great.
Hi Stefano! We show how to test-drive many kinds of components in this playlist: www.essentialdeveloper.com/professional-ios-engineering-series
Excellent coverage of a topic that's at the back of every iOS developers mind! I have tried different approaches to this problem, but this is the cleanest I have found! A small request - would you be so kind as to publish the source code that you white boarded to illustrate the proposed solution during this Q and A session? Thanks so much!
Thanks, Raman! Glad it was helpful. The source code is not publicly available, but it should be easy to replicate it ✅
Great content. I am wondering about how to handle inter-dependencies between feature modules. let's say all features require an OAuth authorisation service or some features process on the same data layer/Objects?
Hi Souhail, it depends on what you're trying to achieve. If you want to maintain the modules decoupled from authorization, you can invert the dependency with an abstraction and implement it with a Decorator or an Adapter, for example. This way, you can inject authorization into the modules without modifying them. But it depends on what you want to achieve.
Whats the best way to go through the legacy code and understand the flow when there is no documentation present for the same?
How can we start with documentation as we go through the code...
Please share the link if u have already covered this topic.... Once again thanks a lot for your time and great way of spreading knowledge
Here are 3 short videos about it 👇
ruclips.net/video/wGpsH40seGQ/видео.html
ruclips.net/video/4g0NOmDp8X0/видео.html
ruclips.net/video/0mFL0nsOaUQ/видео.html
You have to return your container controller to the client. That way internally you use your container.
Not sure to 100% get what's the difference between the Flow class and a Coordinator? You said the flow doesn't have a child or parent, but then you need to keep a reference to the Flow class somewhere too right? So it's retained?
Hello! There are many other ways to keep it in memory without a child/parent model. For example, the view controller can hold it indirectly - so the flow is retained just as long as the view controller.
@@EssentialDeveloper What does it mean to hold indirectly?
Keeping a delegate reference as strong? Seems confusing and unintuitive to me, as most of iOS developers expect the delegate to have a weak reference. Actually, I would argue that the whole point of a delegate pattern is maintaining parent- child relationship without creating a retain cycle, using an interface as a strategy. So I don’t get the reasoning behind this demo. You try to solve a problem by creating a new ‘hidden’ problem. A better solution seems to be a closure, which then the client can determine the type of reference, seems more understandable to me.
But then, many closures can be very much unreadable and hard to reason about.
Hi Niko! Indirectly means through any kind of indirect reference, such as a protocol, closure, or object association. So, no, you don't need to make the delegate strong. We do it with closures instead of delegates. But if you want to do it through weak delegates, you could use `objc_setAssociatedObject` to indirectly connect both objects. Moreover, there's nothing wrong with strong delegates. You can even find them in the Foundation framework. For example, the URLSession delegate is a strong reference. You can also combine them directly if you want to - we just mentioned that you *don't* need to - it's a choice. (Although maintaining parent/child relationships within Coordinators creates a much bigger problem: a lot of complexity to manually keep them in sync to avoid memory issues. You end up replicating the UIViewController parent/child relationship everywhere - which is unnecessary in most cases). Again, it's a choice - there's no absolute answer - and we want to share different ways of doing things so you can choose the best option depending on the current requirements.
@@EssentialDeveloper I agree. Thank you for your enlightenment
😊
There was an obvious knowledge gap between the guest and host, that initially made the show boring. But i guess that's how we all learn.