Router and Data Passing Clean Swift Architecture

  • Tutorial
Hello reader!

In a 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 transition and transfer of data between scenes.



Theory


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

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

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

Using the link to the DataStore we will transfer data from the Interactor of one scene to Interactorthe scene we are moving to. And, as mentioned earlier, it is Router that needs to know how to do this.

Practice


For an example, we will transfer the text from TextField to Label of other scene. Let's consider two ways of transition between scenes - according to Segue and programmatically.

The Router class contains 3 semantic groups of methods:

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



If we make a transition through Segue , for example, when a button is clicked, 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 .

Overriding prepare (for: sender :) is optional 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 thing - the Router code . The example contains comments, so we will only consider key points.

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

All methods in the RoutingLogic protocol must be named according to the routeToNAME principle , where NAME is the name of Segue(Identifier), which we set when working with the Storyboard . This is necessary not only for convenience and beauty of use, but also for our method selector in prepare (for: sender :) ViewController , which we redefined earlier.

Also in the HomeRouter class there are methods starting with navigateTo and passDataTo . The former are responsible for the transition logic, while the latter are responsible for data transfer. The navigateTo methods are only created if the transition is done programmatically.

In the example, we have a routeToDetail (segue :) method . The segue parameter is optional since the method contains an implementation that allows you to call it without usingSegue . In both cases of transition, we get non-optional values ​​of our HomeViewController'a and HomeDataStore'a Home scene , as well as links to ViewController and DataStore 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 with classes” (protocol DetailDataStore: class), and this entails many difficulties, including capturing strong links.



Conclusion


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 action.

Series of articles


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

Link to the project
Help in writing an article: Bastien

Also popular now: