iOS体系结构:MVVM-C,场景(2/6)

场景可以被认为是应用程序内部的sectionfeature用例 。 一个很小但是内部完整的包含整个应用程序的一部分。 您要制作场景的大小取决于您。

我通常会发现将场景定义为功能非常有效。 它通常是1到4个屏幕的集合,旨在实现一个单一的目的。 例如登录流程,图片上传过程或购买渠道。


首先,我在Xcode项目中创建一个名为Scenes的文件夹,其中将包含所有场景的子文件夹。 在一个特定场景内(如您在下面的“ 搜索”示例中可以看到的),我拥有与该场景有关的所有部分。 从协调员到视图。 这些文件夹结构将针对每个场景重复。

我认为这有助于将应用程序的每个场景划分为更大的整个应用程序中的完整的独立设备。 我可以将这个场景的文件夹拖到另一个应用程序,它应该可以正常工作。

从上面的屏幕快照中可以看到,每个场景都应该有自己的故事板 ,并且与场景名称相同。

在iOS社区中,故事板仍然是一个有争议的话题。 有些人无法想象不使用情节提要来创建iOS应用程序,而社区中的其他一些人不会因为使用情节提要而陷入困境。 他们要么以编程方式创建视图,要么仅在每个屏幕上使用XIB。

对情节提要板的抱怨之一是,有时开发人员会将其应用程序的所有屏幕都塞进一个大型情节提要板中,这变得一团糟,尤其是当有多个人在同一个情节提要板上工作时。 一定喜欢那些无法理解的GIT合并冲突,在这些冲突中,您必须解析XML文本以了解正在发生的事情。

但是使用情节提要板仍然有很多好处。 它们使尺寸分类和自动布局变得轻而易举,它们允许静态表视图,它们使您可视化应用程序的流程等。

我不会在这里介绍使用情节提要的所有优点和缺点,但是我想我已经找到了中间立场。 每个场景都应该有一个情节提要,其中仅包含该场景中包含的ViewController。 这对于防止合并冲突大有帮助,因为通常只有一个开发人员正在开发应用程序中的特定功能或部分。

最重要的是 ,尽管我确实使用情节提要的面板来包含每个场景的ViewController,但我并未在情节提要上设置任何顺序或关系。 它仅用于为特定场景中包含的每个ViewController配置视图。

这一点很重要。 我们可以使用情节提要,但不能使用segues或可以使用界面生成器创建的任何其他类型的关系。 原因是协调器将负责处理导航和ViewController之间的关系。

许多人认为协调器和情节提要不能并存。 实际上,如果您不使用搜寻或关系,它们可以很好地协同工作。


有关协调员的更多信息,请继续阅读本系列的下一篇文章:

iOS架构:MVVM-C,协调器(3/6)