Use case
iOS MVC ("Massive view controller") is a widely known problem in the industry. Our FlutterViewController is getting massive with almost 3000 LOC.
Why it's a problem?
- hard to read & maintain. It's pretty intimidating to navigate into this massive file.
- testability: It's hard to write focused unit tests. Looking at
FlutterViewControllerTests.mm, we had to write lots of boilerplates to setup the whole VC, which isn't necessarily related to the feature being tested.
- reusability: some non-UIKit components could be reused across platforms. In fact, even for UIKit-related features, we could split out the non-UI logic part (e.g. data packet logic in gesture handlers)
- single responsibility principle: changing one part of the FlutterVC may have unintended and unforeseen consequences.
Proposal
Consider refactoring and breaking up FlutterVC into smaller components.
An example of good practice is the keyboardManager (which handles key press events) - it has a pretty small API used by FlutterVC, and it's also much easier to unit test.
Non-goal: we probably shouldn't adopt other architectures such as MVVM. I don't see much value for our use case.
Use case
iOS MVC ("Massive view controller") is a widely known problem in the industry. Our FlutterViewController is getting massive with almost 3000 LOC.
Why it's a problem?
FlutterViewControllerTests.mm, we had to write lots of boilerplates to setup the whole VC, which isn't necessarily related to the feature being tested.Proposal
Consider refactoring and breaking up FlutterVC into smaller components.
An example of good practice is the
keyboardManager(which handles key press events) - it has a pretty small API used by FlutterVC, and it's also much easier to unit test.Non-goal: we probably shouldn't adopt other architectures such as MVVM. I don't see much value for our use case.