本節書摘來自異步社群《ios創意程式設計家》一書中的第6章，第6.1節界面的管理，作者 林柏全，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視
6.1 界面的管理
ios創意程式設計家
uiviewcontroller提供了對于ios應用程式的基本界面管理模式，包括界面的呈現、modal視窗界面的管理以及ios裝置旋轉後界面旋轉的支援等。
每個uiviewcontroller都會對應到一個唯一的uiview，這表示這個界面由相對應的uiviewcon-
troller所控制。如同我們在前一章所提到的，在uiviewcontroller類中，有一個view的屬性，而uiviewcontroller正是通過這個屬性才得以與其管理的界面關聯起來。在iphone與ipod touch中，這個關聯的底層界面通常占有整個螢幕的大小；然而在ipad中，這個底層界面可能隻占一小部分而已。
除了對界面的管理外，其實uiviewcontroller跟uiview一樣，都是uiresponder這個類的子類。因為uiviewcontroller也會負責事件的處理，事實上，在大部分時候，我們也都會用uiviewcontroller來處理這些事件。
ios sdk為不同的界面需求提供了相對應的界面控制器。例如，為了在界面上顯示表格控件uitable-
view，就必須使用相對應的界面控制器uitableviewcontroller；為了做出導航欄的應用程式，就必須使用uinavigationcontroller等。此外，在ios應用程式中，界面的切換通常也伴随着界面控制器的切換，在本章後續的内容裡面，我們會提到如何做到這一點。
6.1.1 界面方向的管理
界面控制器也同時控制着界面方向的改變。例如，當我們在使用safari來浏覽網頁的時候，界面會随着手機方向而改變，這就是界面控制器在起作用。如果要讓手機可以支援方向的改變，那麼應該去改寫uiviewcontroller裡面的shouldautorotatetointerfaceorientation:這個方法。如果希望手機可以支援“home”鍵在左邊的風景模式以及“home”鍵在右邊的風景模式，那麼可以将這個方法改寫如下。
6.1.2 記憶體使用的管理
由于界面控制器控制着它所使用的界面，在記憶體不足的時候，界面控制器的didreceivememorywarning方法就會被調用，這時候您可以在這個方法内釋放不需要使用的資源，這其中包括界面控件。對于ios 3.0之後的版本，您應該在viewdidunload方法中釋放掉不需要使用的界面控件。如果在界面控制器中包括了一些outlet的使用，那麼您也應該在這個方法中将這些outlet設定為nil以便釋放它們。
6.1.3 界面的加載流程
在設計界面上，所有的界面都是以view controller為機關的。也就是說，不管使用故事闆或是xib來産生界面，每一個手機的界面背後都有一個view controller來控制着界面。是以，當系統加載了這些.xib或.storyboard的檔案後，其實也一并加載了界面控制器。這個加載的過程跟我們日後編寫程式的時候有很大的關聯性，是以一定得知道這一過程中發生了哪些事情。
從uiviewcontroller類的定義裡面，我們可以得知它遵循着nscoding這個協定。而這個協定就是在xib加載後，可以把xib檔案裡面的東西轉化為對象的關鍵所在。當每一個xib檔案載入後，就會開始解析檔案裡面的每個對象，并且對表示這個xib檔案的file's owner（對故事闆來說，就是每個界面的view controller類）發送nscoding協定裡面的initwithcoder:資訊，以通知file's owner“現在我正要開始解析這個檔案了”。是以，如果您的file's owner是一個uiviewcontroller，那麼請不要在這個方法通路outlet，因為在這個時候，這些outlet還沒有與類連接配接起來，也就是說您通路到的outlet隻是個nil。
接下來，xib的加載器會準備将outlet以及action與類連接配接起來，并對xib裡面的對象發送awake-fromnib的資訊。如果xib裡面包含了uiview，那麼當uiview接收到awakefromnib的資訊之後，就會産生uiview的執行個體，并調用uiviewcontroller的viewdidload方法。隻有在這個方法調用之後，才可以通路界面控制器的outlet。這就是為什麼在前面幾章的例子中，我們會盡量将通路outlet的程式代碼放在viewdidload裡面。在viewdidload之後則依次發生viewwillappear以及viewdidappear事件。
現在問題來了，如果我們是通過程式代碼的方式來産生界面控制器與界面的，那麼uiview又是如何與uiviewcontroller産生關聯的呢？下面解答這個問題，我們可以看到在控制器裡面有個view的屬性，可以通過這個屬性來設定這個控制器所管理的界面。如果是通過xib的方式加載的，那麼，xib的加載器會把上面的流程所産生uiview的執行個體自動設定為uiviewcontroller的view屬性。但如果不是通過xib的方式來加載控制器，那麼您應該自己重載控制器的–(void) loadview方法，然後在這個方法中産生一個uiview的對象，并将其設定為這個控制器的view屬性；否則，您在界面上将看不到任何東西。
6.1.4 常見接口模式
仔細觀察一下在app store上的應用程式，您應該會發現它們外觀的布局似乎都有點雷同。其實這是因為apple已經幫助開發人員預先定義好了幾種界面呈現模式，且它們也可以一起搭配使用。這些模式包括。
導航欄接口模式的出現是為了應對界面間有上下頁關系，上一頁的标題會變成下一頁的傳回鍵（當然這點我們可以修改），如圖6.1所示。例如，在設定界面上點選“通知”的話，界面會切換到通知的設定界面，同時在左上角也會出現一個“設定”的傳回鍵。這個模式經常和表格控件一起使用，這是因為表格控件本身就具備了master-detail的特性。當然，這并不表示這兩者必須一起使用，您仍然可以根據應用程式的情況來選擇自己的界面呈現模式。
這個模式會在界面下方安排一列工具欄（uitoolbar），點選上面的按鈕後，這些按鈕會以高亮度來顯示正在執行的功能。如圖6.2所示，這裡同時采用了導航欄模式與工具欄模式來呈現界面。
這個接口模式會在界面下方顯示數個tab，每個tab都有其專用的界面（通常使用不同的界面控制器），使用者可以很快地在這些界面中切換，就像切換頻道一樣友善，如圖6.3所示。這個模式也常與導航欄接口模式一起使用。
模态接口模式會把要出現的界面由下方慢慢地拉到上方，并且遮蓋住其他的界面；等到使用者在界面上點選了某些按鈕後，界面會被慢慢地拉到螢幕下方，如圖6.4所示。
表格接口模式是最常見的一種資料呈現方式，用來表示master-detail的界面，也經常與其他模式合并使用，例如，聯絡人資訊就是采用這種模式顯示。我們會在後面以專門的一章來說明這個模式。