UIVIew 或 UIViewController 中的复杂视图设置? (设计决策)

发布于 2024-10-10 13:57:32 字数 355 浏览 2 评论 0原文

目前,我以编程方式设置了大部分 UI。有两种方法可以排列属于屏幕的视图(除了使用笔尖):

  • 在视图控制器中,管理所有视图(它是一个视图控制器!)
  • 创建一个自定义 UIView 子类,然后将其连接到 我知道

两者都可以工作,但是在什么情况下您会选择哪种解决方案?

另外,对于第一个变体,可以选择在 viewDidLoad 中进行设置并将视图添加到 self.view,或者构建一个容器视图并将所有视图添加到 loadView 中。任何好的建议也将不胜感激。

当您将完整视图设置为控制器的视图时,第二种变体接近于使用笔尖。

无意在这里发起一场宗教战争,而是为这两种方法寻找论据。

At the moment I setup most of my UI programmatically. There are two ways of arranging the views that belong to a screen (additionally to using nibs):

  • In the view controller, manage all the views (it's a view controller!)
  • Make a custom UIView subclass, and just wire that one up in the controller

I know both will work, but in which situations would you chose which solution?

Also, for the first variant, one has the option to do the setup in viewDidLoad and add the views to self.view, or build a container view and add all the views in loadView. Any good advice here would also be appreciated.

The second variant comes close to using a nib, when you would set a complete view as a controller's view.

Not intended to start a religious war here, but looking for arguments for both approaches.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

ぽ尐不点ル 2024-10-17 13:57:32

我可以想出几个标准来选择一个选项或另一个选项。

如果视图集是或可能是在许多屏幕上显示的可重用组件,我会倾向于创建 UIView 子类。

如果视图控制器需要直接访问多个视图,我会在控制器中构造它们。我尝试使自定义 UIView 类不透明容器,以便它们的控制器只需要与父视图交互,而不是通过其子视图进行挖掘。

如果视图集不能提供处理单个概念的 API,例如,如果视图层次结构的存在只是为了正确设置视图的 z-index,并且这些视图处理显示不相关的数据,那么我将再次在控制器。 UIView 子类应该负责仅显示一组连贯的数据,或者以一致的方式管理一组子视图。

如果视图需要相对于其层次结构之外的视图进行定位,我会再次赞成在控制器中定义它们。

I can think of a couple of criteria which I would use to choose one option or the other.

If the set of views is, or could be, a reusable component shown on many screens I would favor creating a UIView subclass.

If the view controller needs to access a number of the views directly I would construct them in the controller. I try to make custom UIView classes opaque containers so their controller only needs to interact with the parent view, not dig around through its child views.

If the set of views cannot present an API dealing with a single concept, for example if the view hierarchy exists only to set the z-index of the views correctly and those views deal with displaying unrelated data, then I would again create them in the controller. A UIView subclass should be responsible for displaying only a single coherent set of data, or managing a set of sub views in a consistent way.

If views need to be positioned relative to views outside their hierarchy I would again favor defining them in the controller.

眼泪淡了忧伤 2024-10-17 13:57:32

在这种情况下,请考虑 MVC(模态、视图、控制器)。

一个好的选择是创建一个单独的 UIView 类并将 UIViewController 的视图设置为此(或将其作为子视图添加到控制器的视图),然后使用委托方法进行从 UIView 子类到控制器的任何用户交互。

但是,如果您只计划在控制器视图中拥有一个视图(因此无需交换视图、翻转等),则基本上可以将控制器视图用于所有 UI。

Think MVC (Modal, View, Controller) in this case.

A good choice is to create a separate UIView class and set the UIViewController's view to this (or add it as a subview to the controller's view), then use delegate methods for any user interaction from your UIView subclass to the controller.

However, if you're only planning to have one view in your controller's view (so no exchanging views, flipping, etc.) you could essentially just use the controller's view for all UI.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文