为什么我写家庭框架
在Apple平台上构建应用程序时，开箱即用的是模型视图控制器模式。
尽管多年来引起了很多争议，但这种体系结构本身并没有什么坏处。 主要的抱怨是可怕的“ Massive View Controller”，这些年来，它还获得了许多其他同义词，例如哥斯拉控制器，View ConTROLLer，我可以继续说下去。 我分享了很长时间的观点，在其他几个模式中寻找一个穿着闪亮盔甲的骑士。 但是，他们全都走同一条路。 与系统作斗争，直到我迷路了，发现自己回到了Apple为您提供的服务。 看起来一切希望都已荡然无存，Dave DeLong发表了自己的四部分文章系列“更好的MVC”。
更好的MVC，第1部分：问题
“修复”模型视图控制器系列文章的第1部分：修复封装问题修复大规模视图控制器…
davedelong.com
使灯泡发光的是第3部分。
我是一个常见的误解的受害者，因为误解是视图控制器需要负责整个屏幕。 一旦我学会了这种“反模式”，生活就变得像一千个太阳的火焰一样明亮。 我开始以不同的方式考虑控制器，并且我接受了子视图控制器。 作为iOS开发人员的生活开始重新变得有意义。
在继续之前，我只想弄清楚本文的目的。 这与流量控制器模式无关。 使用该模式仅暴露了我认为需要修复的情况。 我不认为流量控制器模式是最终的答案。 这是构建模块化，可扩展且可测试的控制器的一种好方法，甚至是一种很好的模式，对于我和我的同事来说，这都是很好的选择。 如果您想更多地了解该模式，则不是本文。 我建议您阅读戴夫的文章。 他解释得比以往任何时候都好。
继续前进，在使用了子视图控制器一段时间之后，我开始看到我的时间花在了哪里，主要是在必须快速适应变化的时候。 更精确地说，构建流量控制器比将多个控制器粘合在一起要麻烦得多。 我想使用Apple提供的所有可用的UI元素来构成我的用户界面，但是当任何需要出队的问题出现时，我很快就感到失望。 必须有更好的方法。 一种不涉及链式约束并且适应变化的方法。
就像过去的爆炸一样，我想到了Spots框架的核心实现，即SpotsScrollView 。 在该类中，我们使用了基于OLEContainerScrollView的Ole Begemanns实现的布局算法。 该算法开放用于在滚动视图内部使用滚动视图，从而为用户创建一致的滚动体验。 我以Spots算法为基础，重新审视了代码，并逐渐对其进行了改进，直到它可以与您喜欢的任何UI元素按预期方式工作，而无需配置单个约束。
在为框架破解公共API时，我希望它尽可能精简。 我的目标是成为一个嵌入式解决方案，使设置子视图控制器变得像馅饼一样容易。
“公共API简洁明了，应该节省很多您想花在其他地方的时间……”
我想出了三种方法，一种用于添加常规子视图控制器，该子视图控制器处理内部调用所有适当的子视图控制器相关方法。
对于需要将控制器（或更确切地说，其视图）限制为特定高度的情况，我又添加了一个。
最后但并非最不重要的一点是，我添加了一个带有闭包的方法来选择与标准UIViewController的视图不同的视图。
这些是当今存在的公共API方法，以与添加视图时相同的线性垂直顺序排列视图，而子视图控制器由框架内部掩盖和处理。
如果视图在任何时间点都应更改，则算法将相应地对视图进行布局。 另外，我实现了对动画的支持，如果通过使用动画将视图的高度设置为零来删除视图，则框架将确定动画的持续时间，并在布置视图的新位置时采用动画。 这样，它尊重用户的意愿，而无需他们做任何额外的工作。
那么关于出队的事情呢，因为该实现植根于Spots框架，该算法已经考虑到了这一点，这意味着您可以自由地混合和匹配集合视图，表视图，堆栈视图，分段控件和常规UIView ‘ s。
Family框架仍处于起步阶段，但是我看到它的前途光明，因为它的责任很轻，公共API简洁明了，应该可以节省很多您想花在其他地方的时间，最好是与人类家庭在一起。
因此，事不宜迟，我给你一个家庭友好的儿童视图控制器框架：家庭。 希望您能像我一样喜欢它！