Router and Data Passing Architecture Clean Swift

Hello, reader!



In the previous article, I talked about the VIP cycle of the Clean Swift architecture. Now we will touch on one of the most important topics - the transfer and transfer of data between scenes.

Theory

For the logic of navigation and data transfer is the component Router , which is part of the scene (optional of course). It is initialized in ViewController , along with Interactor and Presenter .

')

Router implements two protocols - RoutingLogic and DataPassing , which we will fill with our functionality. RoutingLogic should contain methods that are responsible for the transition to a specific scene. DataPassing contains a dataStore variable that refers to the DataStore protocol. Scene Interactor implements the DataStore protocol and works with variables stored in it. The Router itself contains a link to its scene's ViewController .



Using a link to ViewController , Router transitions between scenes. To do this, you can use Segue or create a scene to which you need to make the transition, programmatically. What method is used is not important, the main thing for us is to have a link to an instance of the ViewController class, to which we make the transition.



Using a link to the DataStore we will transfer data from the Interactor of one scene to the Interactor of the scene we are switching to. And, as mentioned earlier, Router should know how to do this.

Practice

For an example, we will transfer the text from TextField to Label of another scene. Consider two ways to switch between scenes - by Segue and programmatically.



The Router class contains 3 semantic groups of methods:

1. Methods from the implementation of RoutingLogic (routeTo)
2. Methods responsible for navigation (navigateTo, transition without segue)
3. Methods for data transfer (passDataTo, if there is data to transfer)

If we make a transition using Segue , for example, when we press a button, then in ViewController we must override the prepare (for: sender :) method. This extension will allow you to automatically call methods from Router by the name of Segue .



The override prepare (for: sender :) is not required when working with Segue. You can exclude it from the code and call performSegue (withIdentifier: sender :) in the Router method. Prepare is only needed if you need to use Segue along with data transfer.







Now we finally come to the most interesting - to the code Router'a . The example contains comments, so we consider only the key points.



In this Router, we work with two scenes - Home and Detail . The transition from the Home scene is processed in two ways - by Segue and programmatically . Data is transferred from the Home scene to the Detail scene.



All methods in the RoutingLogic protocol should be named on the principle routeToNAME , where NAME is the name of the Segue (Identifier) ​​that we specify when working with Storyboard . This is necessary not only for convenience and beauty of use, but also for our selector of methods in prepare (for: sender :) ViewController'a , which we redefined earlier.



Also in the HomeRouter class there are methods starting with navigateTo and passDataTo . The first are responsible for the logic of the transition, and the second for the transfer of data. The navigateTo methods are created only if the transition is carried out programmatically.



In the example, we have the routeToDetail (segue :) method. The segue parameter is optional, since The method contains an implementation that allows you to call it without using Segue . In both transitions, we get the non-optional values ​​of our HomeViewController and HomeDataStore of the Home scene, as well as links to the ViewController and DataStore of the Detail scene. Here it is worth paying attention to the fact that detailDS is a variable and is passed to the passDataToDetail method using the pass -through parameter (inout). This is important because without inout, we will have to mark all the DataStore protocols as “possible to implement only by classes” (protocol DetailDataStore: class), and this implies a lot of difficulties, including the capture of strong links.







That's all. Thank you for reading to the end! Below I will leave a link to the project if you want to try out the article in the case.

Article series

1. Clean Swift architecture overview
2. Router and Data Passing in Clean Swift architecture (you are here)
3. Workers in Clean Swift architecture
4. Testing the application on the Clean Swift architecture
5. An example of a simple online store on Clean Swift architecture

Link to the project

Help with writing an article: Bastien