More concrete plan in Decoupling Massive View Controllers

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:

1. Group shared code into Protocol Extensions
2. Separate Out Data Source and Other Protocols
3. Use Generics to control code path in each listing mode
4. Creating View Models
5. Apply Reactive Functional Programming

Reference Articles

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.

Practical Protocol-Oriented-Programming

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

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.

Generic UIViewControllers

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

A practical MVVM example in Swift - Part 1

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)

Animating table row changes using changesets with MVVM

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.

Recent Articles:

Refactoring Massive View Controllers

4 Lessons Learned in Handling User Notification in macOS