Part 2 is out! kzread.info/dash/bejne/rK2Aptuxdsfdl6g.htmlsi=yKs4ty26RmWhwT8q

Super stuff ❤

It's great! I can't wait for Part 2.

@emrepun

3 ай бұрын

Thank you! Its coming soon :)

Waiting for part 2

@emrepun

3 ай бұрын

Its coming soon! :)

@JunaidKhan-ny8tu

3 ай бұрын

@@emrepun yaaayyy ❤️❤️

To begin with, I am quite passionate about the topic and it is pleasant to see such content, I am quite interested to see a continuation with actual Swift code :) But I have some questions to ask: 1 1:50 you describe a flow of highly coupled pages. What about separating concerns? Navigation is a separate concern, so isn`t it better for Page 1 to not know anything about further pages? What if we have to build 10-20 of them instead of 4? Another separate concern is objects instantiation, so why do we have to make Page 1 provide dependencies for Page 4 when it is a containers job? 2 What arrows at 4:38 represent? If that is direction of dependency, seems that arrows between Interface B and Page A must be reversed.

@emrepun

3 ай бұрын

Hey, thanks for your comment :) 1: I agree that navigation is a separate concern, and in a properly architectured application, any page should be easily plugged in for presentation or pushing onto navigation stack easily. But, without a dependency container, even if the navigation is a separate concern, we often need to provide some dependencies or some data to a page. So even if the page 1 doesn't know much about the details of the page 2, if it needs to be able to open it, and page 2 requires some dependencies or data to be injected into it on initialisation, it must provide them somehow, without the use of a dependency container. But as you said, if there is a container, page 2 can directly talk to the container to get the dependency needed. However, if this dependency/data only becomes available from a request at page 1, and if page 1 must register this into the container, then indirectly, page 1 will have to know that some of other pages in the flow need some sort of data from it. So to some degree, it will know a little bit about the needs of other pages. Additionally, I don't usually like the idea of registering everything on dependency containers. If there is a dependency that is only needed from page 2, and it requires some data from whatever page that needs to open it, the page that needs to open it should be able to construct that dependency and inject it. But of course, for bigger dependencies, such as, networking, analytics, data storage and etc, registering them in a container is a good approach so we don't have use singletons and we don't have to worry about injecting them from outside. 2: The module with the head of the arrow is touching, is meant to import the module from the beginning of the arrow. So, Page A imports Page B Interface, I hope this clarifies it :)

Didn't really understand your example with circular dependencies. If those 2 pages depend on each other, you will end up infinitely recursively resolving them. Am I missing smth?

@emrepun

3 ай бұрын

Hey, maybe it wasn't clear enough as I briefly explained it. Without using a dependency container, and implementing 2 packages for each module, yes the circular dependency will persist, and as you said, we will end up with the recursive resolving problem. But with the help of Dependency Containers, we can do the following. For each module, lets say Module A and Module B, we implement 2 different packages; Module A Interface, Module A Implementation - Module B Interface, Module B Implementation. So now we have 4 packages at hand. The interface packages will describe to the outside world, what is needed to be able to interact with the implementation, without outsiders knowing the implementation package. Then the implementation packages will also import their own interface packages and implement the required code to be able to provide the needed functionality at runtime. So "Module A Implementation" will depend on "Module B Interface", which is a protocol with some methods to be able to interact with "Module B", similarly "Module B Implementation" will depend on "Module A Interface". After this set up, we will register 2 dependencies in the container. We will register "Module A Implementation" for "Module A Interface", and "Module B Implementation" for "Module B Interface". Then in runtime, when "Module B Implementation" resolves "Module A Interface" from the dependency container. The container will give the actual implementation of Module A, without Module B knowing about it, and it will be able to present the page that resides in the Module A Implementation. To sum up, by creating 2 packages for each module, and making implementation packages to depend on other module's interface package only, we get rid of the circular dependency problem, and at run time we get the desired implementations from the container. Does this help? :)