In most of our projects here in IBM’s Mobile Innovation Lab, we have adopted the Model View Controller (MVC) pattern for iOS development. MVC is probably the most recognizable design pattern in iOS and is still very widely used. With our apps becoming more commonly open sourced, we wanted to make a greater effort in writing clean, readable, and well-structured code.
We realized we needed to make this effort after we had to create a Massive View Controller, the state when your view controllers become very long because they are doing too many things. So, we knew we needed to change our architecture a good bit and set out to research what we should do. Many design patterns were thrown around, but we eventually landed on Model-View-ViewModel (MVVM). Now, MVVM is not a complete departure from MVC, but rather an extension — an improvement, many would say.
As with any new idea there was a learning curve, but we committed to using MVVM for our next application, IBM Ready App for Venue . The basic idea of MVVM is to move most of the logic and data handling out of your ViewController and into your ViewModel. For a more thorough explanation, see this introduction to MVVM .
Now, about the results: throughout the project we noticed our ViewControllers were not going past 200 lines of code, and if they started to, we re-evaluated their contents. With the exception of three, all of our ViewControllers are less than 200 lines of code, with some less than 100. This is a huge improvement over previous projects, where most ViewControllers were sitting at around 400 lines of code each. The benefits go beyond reduced lines of code; our code overall became more modular, especially with the use of RBStoryboardLink, storyboard reference library, and ReactiveCocoa (another useful library that’s beyond the scope of this post).
There were many benefits, but I’d like to mention a few challenges in using MVVM. First, we wanted to initialize the view models for a view controller, outside of that view controller. We found this wasn’t always possible, or just seemed messy when we had view controllers coming off navigation controllers coming off a tab bar controller. Another issue we ran into was that some of our view controllers were not substantial enough to justify having a view model. So we either had to go overboard and add a view model or slightly break the consistency and exclude a view model. These challenges did not deter us from using MVVM, but we did have to work through them.
Back to the benefits: with greater modularity comes the ability to write better tests. We no longer have to create instances of ViewControllers just to test a few methods within them. We can just instantiate ViewModels, which are subclasses of NSObject, and test away. One other benefit I’ll mention is that we gained more reactive programming knowledge, since reactive programming complements the MVVM design pattern.
All these benefits show that the effort we put into making a cleaner application in IBM Ready App for Venue were worth it. While MVVM did take a while to get used to, and we may not have used it to its full potential, the benefits outweighed the cost. I think it’s a good idea for every development team to iterate on their methods and processes — it’s definitely helped us become a better team.
We took a risk with IBM Ready App for Venue by changing our architecture to MVVM from MVC, and it worked. I encourage you and your team to give MVVM a try!