2011-03-27 57 views
7

我已經看到自定義子視圖實現爲UIViewController子類,但可能已經實現爲UIView子類。何時爲自定義子視圖子類UIViewController?

什麼時候應該子類UIViewController而不是UIView子視圖?子類化UIViewController有什麼缺點嗎?

+0

也許當你有複雜子視圖需要實現其他子視圖。取決於情況:-) – Vinzius 2011-03-27 15:27:37

回答

6

就我個人而言,當我需要一些重要的邏輯繼續時,我會用UIViewController的子類來做。另外,如果我正在尋找一些你從UIViewController(例如以模態方式或在導航控制器中呈現。

如果你正在做一些相當簡單或輕量級的事情,一個UIView子類通常就足夠了。我似乎在製作自定義按鈕和表格視圖單元格時經常使用它們。

在我的經驗,我發現自己使用更多的UIViewController子比UIView子類,但是這可能不是最好的,它只是恰巧,我覺得有點更舒適的使用視圖控制器,而不是直線上升的觀點。

2

如果你打算在你的「視圖」中使用AdBannerView,你也可以繼承UIViewController。 AdBannerView需要一個UIViewController才能工作。

+0

+1不知道。 – hpique 2011-03-27 17:37:01

4

看看蘋果公司不得不說的Controller Objectsthe MVC design pattern

在iOS系統中控制器一般都有望填補至少一個下列角色:

  1. 協調控制器提供專用的邏輯。他們響應委託消息,通知和IBActions。協調控制器還在其他對象之間建立連接,並經常管理這些對象的創建和銷燬。

  2. 視圖控制器,特別是UIViewControllers,管理一個「屏幕」內容的顯示並觸發到下一個「屏幕」的轉換。他們迴應記憶警告和旋轉事件。

  3. 中介控制器存在於OS X中,但其角色通常由iOS中的視圖控制器填充。他們充當意見和模型之間的中介;視圖接收輸入時更新模型,模型更改時更新視圖。

如果您正在實施的行爲符合這些類別之一,那麼您可能需要創建一個控制器對象。如果你的邏輯只關心數據的顯示(並可能響應用戶輸入),那麼它可能屬於視圖層。如果你的邏輯是關於數據本身,那麼它可能屬於模型。 如果您無法在任何這些圖層中找到適合您的邏輯的圖形,那麼您可能應該對它們進行不同的建模,作爲屬於不同圖層中不同對象的不同職責的組合。即請求數據從中介視圖控制器顯示的視圖。

1

我遵循的拇指規則是,如果您正在做自定義繪圖,子類UIView。否則,繼承UIViewController。

相關問題