Xcode 4 组织、视图和控制器
感谢您阅读本文。
这是我在 iPhone Ipad 应用程序编程中的第一步。 为了从头开始学习（并且因为我知道我的应用程序需要动态视图），我决定不使用 Interface Builder。
我的问题是（关于我不使用 IB 的事实）：如何使用视图和控制器？
我想我理解 MVC 概念，因为它在我遵循的教程中一遍又一遍地重复，但是在“MVC 解释”部分之后，没有任何内容可以使“现场”变得清晰并更接近现实世界（地球）这里是 Xcode）。 更糟糕的是，有时有些教程似乎混淆了这两个概念，并用一个词来表达另一个词。
我在这里阅读了很多基于此事的问题（当然还有答案），但我仍然不明白。有时它太笼统，有时又太具体（至少对我来说）。
据我认为我所理解的，当视图控制器是将视图链接到数据的逻辑时，UIView 是静态视图，并且这三个概念必须分开。 这种分离虽然通过使用 Interface Builder 变得更加清晰，但当您对所有内容进行编码时，它似乎变得相当模糊，因为它变成了虚拟汤。
从技术上讲，我应该为每个视图以及每个关联的控制器创建一个特定的“.h”和“.m”文件吗？ 如果我理解 MVC 模式，似乎我应该理解，但是当我遵循教程（没有 IB）时，情况绝不会如此，视图和控制器是在同一实现文件中创建和操作的。
有任何高级别的（我是菜鸟，别忘了）但仍然适用的使用和最佳实践的解释吗？
假设我想创建一个具有绿色视图的简单应用程序，我可以滑动以获取红色视图。 我确信我至少需要一个：
- xxxappDelegate.h
- xxxappDelegate.m
- xxxView.h
- xxxView.m
还有什么？
1）我应该把第二个视图放在哪里（与“xxxView”中的第一个视图一起，或者我应该创建另一个类 h 和 m 文件？）？
2) 对于这种应用，控制器会做什么？它们将在哪些文件中创建、它们将在哪些文件中被调用以及它们将如何“控制”相关视图？
3）主要是，关于MVC模式以及没有IB的事实，您将如何组织该应用程序？
我知道如果您深入了解细节和代码，就会有很多内容，但这不是重点。
谢谢。这看起来很简单，但会很有帮助，并且不像您想象的那样容易在教程中找到。 我理解我读过的教程，但它们非常特殊。当我尝试自己创建一些不是“Hello World”屏幕的东西时，我意识到逻辑上缺少了一些东西。
非常感谢您的帮助。
Thank you for reading this.
These are my first steps in the iPhone Ipad app programming.
In order to learn from scratch (and because I know my app would need dynamic views), I decided not to use Interface Builder.
My question is(regarding the fact that I don't use IB): how would one use Views and Controllers?
I think I understand the MVC concept as it is repeated over and over again in the tutorials I follow, but after the "MVC explanation" part, nothing is made to make it clear "on the field" and closer to the real world (Earth being Xcode here).
Worse, sometimes it seems that some tutorials mix these two concepts up and use one word to say the other.
I read around here a lot of questions (and answers of course) based on the matter but I still don't get it. Sometimes it's too generic, sometimes it's too specific (for me at least).
For what I think I understood, the UIView is the static View when the View Controller is the logic which links the View to the data and those 3 concepts must be separated.
This separation, while a bit clearer with the use of Interface Builder seems to get quite blurry when you code everything as it becomes a virtual soup.
Technically, should I create a specific ".h" and ".m" file for each View AND ALSO for each associated Controller?
If I understand the MVC pattern, it's seems that I should but when I follow tutorials (without IB) it is never the case, view and controllers are created and manipulated within the same implementation files.
Any high level (I'm a noob, don't forget) but still applicable explanation of the use and best practices?
Let's say I want to create a simple app with a green view I can swipe to get to a red view.
I know for sure that I would need at least an:
- xxxappDelegate.h
- xxxappDelegate.m
- xxxView.h
- xxxView.m
What else?
1)Where should I put the the second view (along with the first one in "xxxView" or should I create another class h and m file?)?
2) What would the controller(s) do, for that kind of application? In which files would they be created and in which files would they be invoked and how would they "control" the related view?
3) Mainly, regarding to MVC pattern and the fact that there would be no IB, how would you organize that app?
I know it's a lot if you go into the details and code but that's not the point here.
Thank you. This - as simple as it seems - would be of a great help and is not as easily found in tutorials as you might think.
I understand the tutorials I read but they are so particular. As soon as I try to create something on my own which is not a "Hello World" screen, I realize that something is missing, logic wise.
Thank you very much for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
抱歉，我无法跳过你的第一段。如果您不使用 Interface Builder，您就不会成为一名成功的 iOS 程序员。就是这么简单。我读过的关于这方面的最佳建议是Aaron Hillegass 采访：
是的，阅读具体教程后很难一概而论，但你会学到的。当我刚开始的时候，我认为学习曲线是难以克服的，但如果我能成为一名编写 Cocoa 软件并获得报酬的程序员，那么你也可以。只要继续阅读和练习即可。不要对抗工具——使用它们。
Sorry, but I can't get past your first paragraph. If you don't use Interface Builder, you are not going to be a successful iOS programmer. It's that simple. The best advice I've ever read about this is in this Aaron Hillegass interview:
Yes, it's hard to generalize after reading specific tutorials, but you will learn. I thought the learning curve was insurmountable when I first started, but if I can become a programmer that gets paid to write Cocoa software, you can too. Just keep reading and practicing. Don't fight the tools--use them.
早期的：
之后：
我认为逻辑上缺少的东西是你已经接受了你的假设，即 Interface Builder 是一个拐杖，并且要“从头开始”学习，你必须避免使用它。你正在尝试学习 MVC 设计模式，但您不愿意使用
Apple 自己的文档 他们讨论了这样一个事实：有时组合角色（模型控制器和视图）是有价值的控制器——这值得一读，因为它可以解释您正在查看的一些代码示例，但我的主要建议是：在假设您比构建工具的人更了解之前，尝试按照他们推荐的方式使用它们。 可能会大开眼界
以后 ：
好的，所以尝试实际回答您的问题......
如果我理解正确，并且您在这里想到的两个视图是向用户显示的红色和蓝色，那么您将不会有第二个视图 - 无论是在 IB 中还是在代码中，您都会做的是有一个视图中更改颜色属性的元素...无论您是在 IB 中还是在代码中设置父视图，这都可以通过编程方式完成。
将有一个视图控制器来实现手势支持，并提供一种方法，用于在成功接收到滑动手势时将视图中项目的颜色在蓝色和红色之间更改。我会有一个 ViewController.h 和 ViewController.m。我认为如果您完全在代码中实现 View，它将在 ViewController.m 中实现，而不是有一个单独的 View.m。 （如果您使用 IB，您将拥有 ViewController.h、ViewController.m 和 ViewController.xib，后者提供视图元素和层的基本设置。）
您将在 AppDelegate 中创建一个 ViewController 实例。
如上所述。
Early:
Later:
I think what is missing logic wise is that you have accepted your assumption that Interface Builder was a crutch and that to learn "from scratch" you had to avoid using it. You are trying to learn the MVC design pattern but you are not willing to use the tools that have been designed to support it.
In Apple's own documentation they discuss the fact that sometimes there is value in having combined roles—Model Controllers and View Controllers—and that is worth reading, as it may explain some of the code examples you're reviewing. But my primary advice would be: before assuming you know better than the people who built the tools, trying using them the way they recommend. It might be an eye-opener.
Additions later:
OK, so to try and actually answer your questions...
If I am understanding correctly and the two views you are thinking of here are the red and the blue displays to the user, you wouldn't have a second view—what you would do, whether in IB or in code—is to have an element in your view on which you changed a colour property... This would be done programmatically whether you were setting up the parent view in IB or in code.
There would be a view controller that would implement the gesture support, and would provide a method for changing the colour of the item in the view between blue and red when that swipe gesture was successfully received. I would have a ViewController.h and and ViewController.m. I think if you were implementing the View entirely in code, it would be implemented in the ViewController.m rather than having a separate View.m. (If you were using IB, you would have a ViewController.h, ViewController.m and ViewController.xib, with the latter providing the basic setup of the view elements and layers.)
You would create a ViewController instance in your AppDelegate.
As above.
如果你真的坚持不使用 IB（我 100% 同意 SSteve），那么除了你列出的文件之外，你还需要使用 UIViewController。现在，重要的是要知道，当您添加或更改默认行为时，只需要创建头文件和实现文件。
在您的情况下，视图可能只是一个通用的 UIView，因此您不需要这些文件。您要做的就是子类化 UIViewController，并将滑动逻辑放在那里。在滑动逻辑代码中，您可能只需要更改视图的背景颜色。
您将在委托中实例化视图控制器（无论如何在本例中）并在视图控制器的 loadView 方法中创建视图。这是必需的，因为您不会使用 IB。
但就我个人而言，我认为 IB 在鼓励正确的 MVC 模式方面做得很好，如果您刚刚开始，那么您应该选择 IB。
If you really insist on going without IB (and I agree 100% with SSteve) then in addition to the files you list you will also want to use a UIViewController. Now, it is important to know that you only need to create header and implementation files when you are adding or changing default behavior.
In you case, the view can probably just be a generic UIView, so you wouldn't need the files. What you would do is subclass UIViewController, and put the swipe logic there. In the swipe logic code you would probably just change the background color of the view.
You would instantiate the view controller in the delegate (in this case anyway) and create the view in the view controller's loadView method. That is required since you won't be using IB.
Personally though, I think that IB does a great job of encouraging proper MVC patterns, and if you are just starting then you should go with IB.
在实践中，您通常不会为视图创建类，除非它们需要进行自定义绘图或显示。
对于视图的轻量级配置，这通常是在 viewController 的 viewDidLoad （或者我猜在你的情况下是 loadView）方法中完成的。
是的，将模型和视图分开是一个好主意，但这也与减少现有代码量的同样好主意相平衡。编写的代码越少，出现的错误就越少。
既然你现在才刚刚开始，我绝对会从使用 ARC 开始，然后使用 IB - 尽管我确信你已经厌倦了从每个人那里听到这些，但我会给你一个替代方案。更少的代码意味着更少的错误。事实上，这么多经验丰富的开发人员告诉您使用它应该是一个关于什么是有效的前进道路的巨大线索。我的意思是，您这样做是为了构建应用程序还是为了学习 UIView 类的每个角落？
要说明您的代码示例，您不需要 UIView 自定义类。只需创建使用 UIViewController 的主视图作为容器视图，将 UIView 放入其中，并将背景设置为红色。在滑动时（使用附加到容器视图的手势识别器）调用 UIVew 方法将新的绿色背景 UIView 替换为现有的红色视图，您甚至可以定义过渡样式。
或者在容器视图中创建一个滚动视图，在滚动视图内设置红色和绿色视图，设置内容大小并在滚动视图上启用分页。
或者像您一样创建一个自定义 UIView 类，侦听触摸事件并慢慢调整两个子视图位置以跟随拖动操作。
或者使用 OpenGL 支持的视图，并基于手势识别器平移您正在观察的场景，其中两个三角形表示绿色矩形，两个三角形表示红色矩形。
In practice you mostly do not make classes for views, unless they need to do custom drawing or display.
For lightweight configuration of views, that is often done in the viewController's viewDidLoad (or I guess in your case loadView) method.
Yes it's a good idea to keep model and view separated, but that's also balanced with the equally good idea to reduce the amount of code that exists. The less code that is written, the fewer bugs you will have.
Since you are just starting out at this point I would absolutely start by using ARC, and using IB - even though I'm sure you're tired of hearing that from everyone, I'll give you an alternate take. Less code means fewer bugs. And the fact that so many experienced developers are telling you to use it should be a giant clue about what a productive path forward is. I mean, are you doing this to build applications or learn every corner of the UIView class?
To speak to your code example, you do not need the UIView custom class. Just create use a UIViewController's main view as a container view, place a UIView inside with the background set to red. On swipe (using a gesture recognizer attached to the container view) call the UIVew method to swap in a new green-background UIView for the existing red view, you can even define the transition style.
Or create a scroll view in the container view, set up the red and green view inside the scroll view, set the content size and enable paging on the scrollview.
Or create a custom UIView class as you had, listen for touch events and slowly adjust two subview positions to follow the drag action.
Or use an OpenGL backed view, and based on the gesture recognizer pan the scene you are observing with two triangles for a green rectangle and two triangles for a red rectangle.