2

当我连接我的第一个相当复杂的 Cocoa-Touch 视图时，我觉得我无意中滑回了旧的程序模式并且发现很难摆脱它们......尽管我完全了解许多 Cocoa (OO) 设计模式恐怕我会颠覆他们。

因此，这种有问题的观点很快变得难以管理，我想知道我是否可能以错误的方式接近它？！？视图由UIViewController的子类管理。视图本身包含 ±10 个子视图。其中一些子视图“滑入”和滑出并包含与它们一起滑动的自己的子视图（控件、图像视图等）。

没有过多的细节，我发现我在根视图控制器的 touchesBegan/Moved/Ended 方法中执行了大部分（如果不是全部，包括动画）管理代码。管理、设置和检查布尔属性变得一团糟。 if (editingMode & panelAVIsible) .... if (editingMode & panelBVisible) ... 或 *if (viewFlipped) { for (MyCustomView view in someArrayOfSubviews)}等等...授予此应用程序的 UI 需要其中的大部分视图（或其内容）被用户触摸并移动到屏幕的不同部分。

我试图解决的主要问题似乎是这样的：如果 viewA 存在，那么你 3 个视图会隐藏（动画）......或者，如果 viewB 被触摸，那么 viewC 中包含的所有对象都是负数......等等

任何聪明的（或基本的）OO方法来处理这个？也许让包含视图的子视图充当它们自己的迷你视图控制器？不过，我还没有找到太多（任何？）的例子......

4

2 回答 2

1

正如您在问题末尾所建议的那样，我建议您在需要特定子视图的逻辑时使用子控制器。控制器对象的目的是跟踪视图的状态并封装您描述的所有视图逻辑。界面动作，例如用户是否可以移动到不同的屏幕，可以调用保存逻辑，可以创建一个新文档，应该在该特定视图的控制器中。这将有助于保持各种控制器之间的关注点分离，并在顶层减少复杂的逻辑。

虽然它并不专门针对 iPhone 编程，但Mac OS X 的 Cocoa Programming一书包含了在应用程序中使用子控制器和子视图的好示例（尤其是关于如何创建首选项窗口的章节）。

于 2009-07-08T21:21:49.123 回答
0

我认为你应该遵循你的最后一个建议，让包含视图的子视图充当它们自己的迷你视图控制器。呈现“充满内容的屏幕”的每个（子）视图可以/应该由其自己的视图控制器管理。

这些视图之间的动画可以通过内置导航控制器完成（您实际上可以隐藏导航控制器的顶部栏），以便您拥有默认的幻灯片动画。否则，您确实可以在仍然使用该导航控制器的同时创建自己的动画。

'视图本身包含 ±10 个子视图'。其中一些子视图“滑入”和滑出[..]'。您正在谈论的这些子视图是从您的一个整体 UIView 中提取的完美候选者。

使用的基本 OO 原则是导航控制器如何通过在堆栈上和堆栈上推送和弹出视图来完成它。推送和弹出的每个视图都由其自己的视图控制器处理。

高温高压

编辑：我现在看到您并没有专门谈论 iPhone 开发。不过，看看它是如何在那里完成的（尤其是 UINavigationController）。你仍然可以得到基本的设计理念

于 2009-07-08T21:05:34.210 回答