如何将通用(NSObject)控制器与 UIViewController 的子视图一起使用?
我有一个 UIViewController,它根据用户交互在不同时间加载多个子视图。我最初在代码中构建了所有这些子视图,没有 nib 文件。现在我正在转向带有自定义 UIView 子类的 nib 文件。
其中一些子视图显示静态数据,我使用 loadNibNamed:owner:options: 将它们加载到视图控制器中。其他包含我需要访问的控件。
我(某种程度上)理解苹果说每个内容屏幕使用一个视图控制器的原因,使用通用控制器对象(NSObjects)来管理屏幕的各个部分。
所以我需要一个视图控制器、一个通用控制器、一个视图类和一个笔尖。我如何将这一切放在一起?
我的工作假设和后续问题:
- 我将把视图类与 “阶级身份”掉落中的笔尖 位于IB下方。
- 视图控制器将协调 整体画面交互。什么时候 必要时,它将创建一个实例 的通用控制器。
- 通用控制器是否加载 笔尖?如何?
- 我是否定义了渠道和行动 在那个视图类中,或者它们应该是 在通用控制器中?
- 如何在两者之间传递消息 视图控制器和通用 控制器?
如果有人可以向我指出一些以这种方式使用控制器的示例代码,这将有助于我理解。我读过的所有书籍或 stackoverflow 帖子都还没有完全切中要害。
I have a UIViewController that is loading several subviews at different times based on user interaction. I originally built all of these subviews in code, with no nib files. Now I am moving to nib files with custom UIView subclasses.
Some of these subviews display static data, and I am using loadNibNamed:owner:options: to load them into the view controller. Others contain controls that I need to access.
I (sort of) understand the reasons Apple says to use one view controller per screen of content, using generic controller objects (NSObjects) to manage subsections of a screen.
So I need a view controller, a generic controller, a view class and a nib. How do I put this all together?
My working assumptions and subsequent questions:
- I will associate the view class with
the nib in the 'class identity' drop
down in IB. - The view controller will coordinate
overall screen interactions. When
necessary, it will create an instance
of the generic controller. - Does the generic controller load the
nib? How? - Do I define the outlets and actions
in that view class, or should they be
in the generic controller? - How do I pass messages between the
view controller and the generic
controller?
If anyone can point me to some sample code using a controller in this way, it will go a long way to helping me understand. None of the books or stackoverflow posts I've read have quite hit the spot yet.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
好吧,我想我已经弄清楚了:
新的基于 NSObject 的控制器将非常类似于视图控制器。
Okay, I think I figured it out:
The new NSObject based controller will work very much like a view controller.
听起来你想要的就是我创造的“可重用的 UIView 小部件”——可重用的小部件,可以执行某些操作/呈现一个显示,您可以将其合并到应用程序屏幕中,无论何时何地,只要您想要多少次——您可以创建它们纯粹在代码中或通过将其框架放入另一个 xib 文件中来实例化它们(但您无法更改 xib 文件中小部件的内部参数,这需要 IB 插件)。
这是一个我从未在任何地方讨论过的组织。我早期对 iOS 编程感到沮丧的部分原因是想要这样的东西,但在任何示例中都看不到任何表达它的方法。
请参阅我在这个问题中的答案,了解它的结构:
UIView 和 initWithFrame 以及 NIB 文件。我如何加载 NIB 文件?
我建议将直接/低级事件的所有小部件内部处理放在 uiview 小部件子类中,并实现委托协议以与小部件客户端进行更高级别的交互(即,“loginRequested:userName:passWord”,而不是手动访问小部件内部的按钮和文本字段)。
小部件的(可选但推荐的)xib 文件具有小部件的所有者,并且小部件中的初始化代码拥有加载 xib 文件的职责。小部件的客户只需实例化小部件并实现对其有意义的小部件委托函数即可。
It sounds like what you want is what I've coined "reusable UIView widgets" -- reusable widgets that do something / present a display that you can incorporate in your app screens wherever and how many times as you want -- you can create them purely in code or instantiate them by placing their frame in another xib file (but you don't get to change the widgets' internal parameters in the xib file, that would require an IB plugin).
This is an organization that I've never seen discussed anywhere. Part of my frustration early on with iOS programming is wanting something like this but not seeing any way to express it in any example.
See my answer in this question to see how it can be structured:
UIView and initWithFrame and a NIB file. How can i get the NIB file loaded?
I recommend placing all widget-internal handling of direct/low-level events in the uiview widget subclass, and implememnt a delegate protocol for a highler level interaction with the widget client (i.e., "loginRequested:userName:passWord" instead of manually accessing button and textfields internal to the widget).
The (optional but recommended) xib file for the widget has an owner of the widget, and the init code in the widget owns the duty of loading the xib file. The customer of the widget simply instantiates the widget and implements whicever widget delegate functions makes sense for it.