感谢您阅读本文。
这是我在iPhone Ipad应用程序编程中的第一步。 为了从头学习（因为我知道我的应用程序需要动态视图），我决定不使用Interface Builder。
我的问题是（关于我不使用IB的事实）：如何使用视图和控制器？
我认为我理解MVC概念，因为它在我遵循的教程中一遍又一遍地重复，但在“MVC解释”部分之后，没有做任何事情来明确“在场上”并且更接近真实世界（地球在这里是Xcode）。 更糟糕的是，有时似乎有些教程将这两个概念混合在一起并用一个词来说另一个。
我在这里读了很多基于此事的问题（当然还有答案），但我仍然没有得到它。有时它太通用了，有时它太具体了（至少对我来说）。
对于我认为我理解的内容，当视图控制器是将视图链接到数据并且必须分离这3个概念的逻辑时，UIView是静态视图。 这种分离，虽然使用Interface Builder稍微清楚一点，但当你编写所有内容时它会变得非常模糊，因为它变成了虚拟汤。
从技术上讲，我应该为每个关联的控制器为每个视图和ALSO创建一个特定的“.h”和“.m”文件吗？ 如果我理解MVC模式，似乎我应该但是当我遵循教程（没有IB）时，情况永远不会发生，视图和控制器在同一个实现文件中被创建和操作。
任何高级别（我是一个菜鸟，不要忘记）但仍然适用于使用和最佳实践的解释？
假设我想创建一个带有绿色视图的简单应用程序，我可以滑动以获得红色视图。 我确信我至少需要一个：
还有什么？
1）我应该把第二个视图（以及第一个视图放在“xxxView”中，还是应该创建另一个类h和m文件？）？
2）对于那种应用，控制器会做什么？他们将在哪些文件中创建文件以及调用哪些文件以及如何“控制”相关视图？
3）主要是关于MVC模式以及没有IB的事实，你会如何组织该应用程序？如果你进入细节和代码，我知道这很多，但这不是重点。
谢谢。这一点 - 看似简单 - 会有很大的帮助，而且在教程中并不像你想象的那么容易。 我理解我读过的教程，但它们非常特别。一旦我尝试自己创建一个不是“Hello World”屏幕的东西，我就会发现缺少某些东西，逻辑明智。
非常感谢你的帮助。
答案 0 :(得分：3)
抱歉，但我无法通过您的第一段。如果您不使用Interface Builder，那么您将不会成为一名成功的iOS程序员。就这么简单。我曾经读过的最好的建议是this Aaron Hillegass interview：
经验丰富的Cocoa程序员将他们应用程序的许多智能放在NIB文件中。结果，他们的项目代码少得多。在Visual Studio工作了几年的程序员被吓坏了。他们问我这样的问题：“我可以在不使用Interface Builder的情况下编写Cocoa应用程序吗？我喜欢看代码。也许我可以明确地创建我的窗口以及它上面的视图？”
很难解释NIB文件（以及其他一些可怕的想法）如何创造杠杆作用。正是这种杠杆使得地下室的一个人能够与微软或Adobe的工程师团队竞争。就像我向美国早期殖民者展示了一把链锯，他说：“我可以在不启动发动机的情况下砍伐树木吗？我不喜欢噪音。也许我可以把它撞到树上？” / p>
是的，在阅读特定教程后很难概括，但您将学习。我认为学习曲线在我刚开始时是不可克服的，但如果我能成为一名编写Cocoa软件的程序员，你也可以。继续阅读和练习。不要打击工具 - 使用它们。
答案 1 :(得分：0)
如果你真的坚持不使用IB（并且我同意100％使用SSteve），那么除了你列出的文件之外，你还需要使用UIViewController。现在，重要的是要知道在添加或更改默认行为时只需要创建头文件和实现文件。
在你的情况下，视图可能只是一个通用的UIView，所以你不需要这些文件。你要做的是UIViewController的子类，并将滑动逻辑放在那里。在滑动逻辑代码中，您可能只需更改视图的背景颜色。
您将在委托中实例化视图控制器（在这种情况下无论如何）并在视图控制器的loadView方法中创建视图。这是必需的，因为您不会使用IB。
就个人而言，我认为IB在鼓励正确的MVC模式方面做得很好，如果你刚开始那么你应该选择IB。
答案 2 :(得分：0)
早期：
为了从头学习（因为我知道我的应用程序需要 动态视图），我决定不使用Interface Builder。
随后：
一旦我尝试自己创造一些不是“你好”的东西 世界“屏幕，我意识到缺少某些东西，逻辑明智。
我认为缺少逻辑的是你已经接受了你的假设，即Interface Builder是一个拐杖而且要从头开始学习你必须避免使用它。您正在尝试学习MVC设计模式，但您不愿意使用旨在支持它的工具。
在Apple's own documentation中，他们讨论了这样一个事实：有时候组合角色 - 模型控制器和视图控制器 - 是值得阅读的，因为它可以解释你正在审查的一些代码示例。但我的主要建议是：在假设您比构建工具的人更了解之前，尝试按照他们推荐的方式使用它们。这可能会令人大开眼界。
后来增加： 好的，所以试着回答你的问题......
1）我应该在哪里放置第二个视图（以及第一个视图） “xxxView”或者我应该创建另一个类h和m文件？）？
如果我理解正确并且您在这里想到的两个视图是用户的红色和蓝色显示，您将没有第二个视图 - 无论是在IB还是在代码中，您将做什么？在视图中有一个元素，您在其中更改了颜色属性...无论您是在IB中还是在代码中设置父视图，都可以通过编程方式完成。
2）对于那种应用，控制器会做什么？在 将创建哪些文件以及它们将在哪些文件中 被调用以及他们将如何“控制”相关视图？
会有一个视图控制器可以实现手势支持，并且会提供一种方法，用于在成功接收到该滑动手势时更改蓝色和红色之间视图中项目的颜色。我有一个ViewController.h和ViewController.m。我认为如果你完全在代码中实现View，它将在ViewController.m中实现，而不是单独的View.m. （如果您使用的是IB，则会有一个ViewController.h，ViewController.m和ViewController.xib，后者提供视图元素和图层的基本设置。）
您将在AppDelegate中创建一个ViewController实例。
3）主要是关于MVC模式和将存在的事实 没有IB，你会如何组织这个应用程序？
如上所述。
答案 3 :(得分：0)
在实践中，除非他们需要进行自定义绘图或显示，否则大多数情况下不会为视图创建类。
对于视图的轻量级配置，通常在viewController的viewDidLoad（或者我猜你的情况下是loadView）方法中完成。
是的，保持模型和视图分离是一个好主意，但这也与减少存在的代码量同样好的想法相平衡。编写的代码越少，您拥有的错误就越少。
由于你刚刚开始这一点，我绝对会首先使用ARC，然后使用IB - 即使我确定你已经厌倦了听到所有人的意见，我会给你一个替代的选择。更少的代码意味着更少的错误。而这么多经验丰富的开发人员告诉你使用它的事实应该是一个关于前进道路的巨大线索。我的意思是，你这样做是为了构建应用程序还是学习UIView类的每个角落？
要说明您的代码示例，您不需要UIView自定义类。只需创建使用UIViewController的主视图作为容器视图，将UIView置于内部，背景设置为红色。在滑动（使用附加到容器视图的手势识别器）时，调用UIVew方法为现有红色视图交换新的绿色背景UIView，您甚至可以定义过渡样式。
或者在容器视图中创建滚动视图，在滚动视图中设置红色和绿色视图，设置内容大小并在滚动视图上启用分页。
或者像你一样创建一个自定义UIView类，听取触摸事件并慢慢调整两个子视图位置以跟随拖动动作。
或者使用OpenGL支持的视图，并基于手势识别器平移您正在观察的场景，其中两个三角形用于绿色矩形，两个三角形用于红色矩形。