Here are the steps I am going to execute in decoupling the Massive View Controllers I have in hand. To provide some backgrounds, this is my current scenario:
- Several View Controllers
- Displaying content from the same Model type
- Logic on each View Controller is slightly different
Here are the steps I am going to refactor the code:
- Group shared code into Protocol Extensions
- Separate Out Data Source and Other Protocols
- Use Generics to control code path in each listing mode
- Creating View Models
- Apply Reactive Functional Programming
The workflow is based on a bunch of studies, levels of complexity, and potential impacts to our production application. Each of these has some reference readings.
Share code base
The top-most priority of the refactor is to share code base used in multiple View Controllers. In the era of Swift, protocol-oriented programming (POP) is highly advocated. In fact, we can organize code as protocol extensions. When each View Controller implements the protocol, they automatically get the methods from protocol extension and make it available within View Controller. This is pretty nice.
"How can I use protocol-oriented programming in my everyday coding?" Natasha tackles this question and focuses on the…
Reduce Source Code in View Controllers
After moving the code to custom protocols, some protocols are provided by system frameworks, such as Data Source and Delegate of Collection View. Depending on the situation, I can either extend them into another protocol and provide the protocol extension implementations. Or, I could implement that as a class, where I can use Generics as well.
Lighter View Controllers · objc.io
objc.io publishes books on advanced techniques and practices for iOS and OS X development
Use Generics to Control Code Path
As I have slightly different logic in each View Controller, I need a way to differentiate between each one. Choosing Generics allow me to start the definition right at the intialization point. Also, compiler will help to check the type inference. This means I just need to set once at the View Controller initialization point, and all the related classes can run based on the Generics type provided.
Update 1/09/2015: Code tested on Xcode 7.0 beta 5 (7A176x) Note: Kudos to Robert for lending me his brain in some of…
Separating code into View Model
This part is more a design pattern switch from MVC to MVVM. This will help me to pull out data model related code into its own class View Model. View Controller will remain as view-related only. Yet, this is just half of the story. It is best to work with a data observing mechanism, so the View Controller is noticed when the underlying data changes.
MVVM in Swift - Artsy Engineering
Model View ViewModel has become the default way I write apps on iOS - it makes writing iOS apps a joy. I've written…
A practical MVVM example in Swift - Part 1
The good ol' MVC pattern has been around for a while. The acronym usually stands for Model-View-Controller, but in iOS…
Apply Reactive Functional Programming
No matter it’s KVO, Notification or RFP libraries like ReactiveCocoa, RxSwift or Intersteller. This provides a mechanism to trigger view updates from View Model. This is an even bigger topic that deserves its own set of articles. Also, this is something we are not familiar enough. Thus, this is kept as the very last part of the refactor.
Implementing MVVM in iOS with RxSwift (Updated for Swift 2)
There are countless articles on MVVM in iOS, but few focus on what MVVM looks like in practice and how to actually do…
I am taking a challenge to write a post every day for 180 days. The content will be related to my life as a father, entrepreneur, developer and trainer.