Why I wrote the Family framework
When building applications on Apple’s platform, what you get out of the box is a model view controller pattern.
There is nothing inherently bad about this architecture even though it has sparked a lot of controversy over the years. The main complaint being the dreaded “Massive View Controller,” it has gained a lot of other synonyms over the years, such as Godzilla controller, View ConTROLLer, I could go on and on. I shared this view for a very long time, looking for a knight in shining armor among a couple of other patterns. However, they all led down the same road; fighting the system until I lost and found myself going back to what Apple provides you. Just as it seemed all hope was lost, Dave DeLong published his four-part article series “A Better MVC.”
The thing that made the light-bulb shine came in part 3.
I was a victim of the common misconception that a view controller needs to be in-charge of the entire screen. Once I unlearned this “anti-pattern,” life became as bright as the fire of a thousand suns. I started to think about controllers differently, and I embraced child view controllers. Life as an iOS developer started to make sense again.
Before we continue, I just want to make the intention of this article clear; this is not about the flow controller pattern. Using that pattern merely exposed a scenario that I thought needed fixing. I don’t see the flow controller pattern as the final answer; it is a good, or rather a great pattern for building modular, scalable and testable controllers which have turned out great for my co-workers and me. If you wish to know more about the pattern, this article is not it. I suggest you read Dave’s articles; he explains it much better than I ever could.
Moving on, after using child view controllers for a while, I started to see where I spent my time, mostly when having to adapt to changes quickly. To be more precise, it was more hassle than it should be to build flow controllers, which meant to glue multiple controllers together. I wanted to compose my user interfaces using all available UI elements that Apple provides but I quickly fell short when anything that needed dequeuing came into question. There had to be a better way. A way that did not involve chained constraints and be adaptive to change.
Like a blast from the past, I came to think of a core implementation of the Spots framework, namely the SpotsScrollView. Inside that class, we used a layout algorithm that was based on Ole Begemanns implementation of OLEContainerScrollView. This algorithm opened up for using scroll views inside of scroll views creating a consistent scrolling experience for the user. I used Spots algorithm as the base, revisited the code and gradually improved it until it worked like intended with any UI element that you fancy, without the need to configure a single constraint.
When it came to cracking out a public API for the framework, I wanted it to be as lean as possible. I aimed for it to be a drop-in solution that would make setting up child view controllers as easy as pie.
“the public API is concise and should save a lot of time that you’d want to spend elsewhere …”
I came up with three methods, one for adding a regular child view controller that handles calling all the appropriate child view controller related methods internally.
I added one more for the case where you need to constrain a controller, or rather its view, to a specific height.
And last but not least, I added one method with a closure to select a different view than the standard UIViewController’s view.
Those are the public API methods that exist today, laying out the views in the same linear vertical order as they were added a child view controllers is masked and handled internally by the framework.
If a view should change at any point and time, the algorithm would lay out the views accordingly. As a bonus, I implemented support for animations, if a view is being removed by setting its height to zero using animations, the framework will figure out the duration of the animation and adopt it when laying out the new positions of the views. That way it respects the user’s wishes without them having to do any extra work.
So what about dequeuing, well because the implementation has its roots in the Spots framework, the algorithm already takes this into account, which means that you are free to mix and match collection views, table views, stack views, segmented controls and regular UIView’s.
The Family framework is still a toddler, but I see it having a bright future as its responsibility is lean, the public API is concise and should save a lot of time that you’d want to spend elsewhere, preferably with your human family.
So without further ado, I give you the family friendly child view controller framework: Family. Hope you enjoy it as much as I did building it!
