![]() This means that our app will need two view controllers, which will need to share state. The app is going to show your favorite quote on one screen, and allow you to edit the quote on a second screen. We're going to write a simple app to see a concrete example of how this works. Propagating State Across View Controllers Using Dependency Injection Let’s see our solution in practice with an example. We have solved the singleton anti-pattern. This model controller can then be passed to view controllers as they come on the screen through dependency injection. This state keeping usually ends inside view controllers, but now we have a new and better place to put it: a model controller. The app’s state should not be its concern. The model should represent only the data of your app. The perfect example of when a model controller is useful is for keeping the app’s state. This is actually how the above scheme should look: Model controllers deal with the model of the app, fulfilling the roles that the model itself should not fulfil. This is what brings developers to use singletons when they need to propagate state: it seems like the only possible solution.įrom the lines quoted above, it is clear that we can add a new entity to our understanding of the MVC pattern: the model controller. For this reason, a lot of code ends up being written inside them for lack of a better place. Many developers think that view controllers are the only controllers that exist in an iOS app. In the same way, you can also have model-controller objects.” This “secret” hides in plain sight in a couple of lines in Apple’s documentation: “One can merge the MVC roles played by an object, making an object, for example, fulfill both the controller and view roles-in which case, it would be called a view controller. ![]() The problem is that this diagram is wrong. The usual representation of the MVC pattern is something like this: The controller layer acts as glue between the other two layers, moving data between them.The view layer shows information on the screen and allows interaction.The model layer represents the data of an app.The MVC pattern, in a nutshell, states that there are three layers in the architecture of an iOS app: To see how to use dependency injection in iOS apps and how it can enable state sharing, we first need to revisit one of the fundamental architectural patterns of iOS apps: the Model-View-Controller pattern. Dependency injection means that a class does not retrieve or create its own dependencies, but it receives them from the outside. The solution to this problem is dependency injection. delegateīut the shared instance of UIApplication is itself a singleton. You just have to add a static variable to a class to keep a shared instance of the class itself, and you are done. The singleton pattern is very quick to implement, especially in Swift, and it works well. As your users navigate through the screens of your app and interact with it, you need to keep a global state that tracks all the changes the user makes to the data.Īnd this is where most iOS developers reach for the obvious, but incorrect, solution: the singleton pattern. State propagation across view controllers is vital in any iOS app. I myself have fallen into this trap in the past. One of the most common iOS development bad practices arises when passing state between the view controllers of an app. I realized that, like many iOS developers, I had succumbed to some classic pitfalls of bad coding practices. From then on, the problems in my code started to stick out like a sore thumb. Not much later, I started reading about some best practices. I had the typical developer hubris: we often think that what we do is great and others don’t get it. I dismissed their judgement, thinking that my code was great and there was no way it could be improved. Although they said the quality of the code was not bad, they pointed to the fact that the code was hard to maintain and to test (unit testing was not very popular in iOS development back then). When their response came back, the verdict was different than I thought. That didn’t bother me, because I thought my code was impeccable and that the review company would say the same. Part of this process involved sending the code of the app I wrote to a third party for review. Big companies, especially banks, usually have processes in place to ensure that their software is secure, robust, and maintainable. A few years ago, when I was still an employee in a mobile consultancy, I worked on an app for a big investment bank. ![]()
0 Comments
Leave a Reply. |