iPhone에서 UIView 대 UIViewController를 언제 사용합니까?
나는 항상 iPhone에서 UIView 대 UIViewController를 언제 사용할지 궁금해했습니다.
전체 화면보기가 아닌 이상 UIViewController를 사용해서는 안된다는 것을 이해하지만 다른 지침이 있습니까?
예를 들어 모달 오버레이를 만들고 싶습니다. 현재 화면에서 제자리로 미끄러지는 화면입니다. 이 모달 오버레이가 전체 화면 인 경우 UIViewController 여야합니까? 마지막으로 이와 같은 것을 만들었을 때 UIViewController를 서브 클래 싱했지만 지금은 그것이 맞는지 궁금합니다.
iOS 용 Apple의 View Controller 프로그래밍 가이드에서 :
"뷰 컨트롤러의 가장 중요한 역할은 뷰의 계층을 관리하는 것입니다. 모든 뷰 컨트롤러에는 뷰 컨트롤러의 모든 콘텐츠를 포함하는 단일 루트 뷰가 있습니다. 해당 루트 뷰에 콘텐츠를 표시하는 데 필요한 뷰를 추가합니다. "
또한:
"보기 컨트롤러에는 두 가지 유형이 있습니다.
- 콘텐츠보기 컨트롤러는 앱 콘텐츠의 개별 부분을 관리하며 사용자가 만드는 기본보기 컨트롤러 유형입니다.
- 컨테이너보기 컨트롤러는 다른보기 컨트롤러 (하위보기 컨트롤러라고 함)에서 정보를 수집하고 탐색을 용이하게하거나 해당보기 컨트롤러의 콘텐츠를 다르게 표시하는 방식으로 제공합니다.
대부분의 앱은 두 가지 유형의 뷰 컨트롤러가 혼합되어 있습니다. "
이것은 좋은 질문입니다.
나의 기본 경험 법칙. 응용 프로그램의 모든 주요 '페이지'는 자체 뷰 컨트롤러를 갖습니다. 이것이 의미하는 바는 애플리케이션 설계의 와이어 프레이밍 단계에서 자체 엔티티로 존재하는 모든 것이 결국 자체 뷰 컨트롤러에 의해 관리된다는 것입니다. 기존 화면 위로 미끄러지는 모달 화면이있는 경우이를 별도의 '페이지'로 간주하고 자체 뷰 컨트롤러를 제공합니다. 오버레이와 기존 페이지 (예 : 로딩 화면 또는 도움말 팝업)가있는 뷰가있는 경우이를 다르게 취급하고 UIView 하위 클래스로 구현하고 해당 '페이지'뷰 컨트롤러에 논리를 유지합니다. 팝업에는 델리게이트 패턴을 사용하여 해당 페이지 뷰 컨트롤러와 다시 통신하는 동작이 있습니다.
이게 도움이 되길 바란다. 그것은 매우 철학적이고 건축적인 질문이며 그것에 대해 많은 것을 쓸 수 있습니다.
뷰가 전체 화면이고 콘센트 / 액션 및 / 또는 하위 뷰가있을 때마다 UIViewController를 사용합니다.
약간 다른 접근 방식이 있습니다.
drawRect에서 사용자 정의 그리기를 계획하는 경우 UIView를 재정의하십시오. 그렇지 않으면 UIViewController를 하위 클래스로 만들고 [self.view addSubview : blah]를 사용하여 페이지의 구성 요소를 추가합니다.
몇 가지 다른 특수한 경우가 있지만 이는 상황의 약 95 %를 처리합니다.
(사용자 정의 UIView가있는 UIViewController가 필요한 경우가 많습니다.하지만 해당 사용자 정의 UIView가없는 사용자 정의 UIViewController가있는 것이 일반적입니다.)
뷰 컨트롤러가 너무 많은 코드를 가질 때까지 화면의 모든 것을 UIViewController에 넣은 다음 하나의 마스터 뷰 컨트롤러에 포함 된 여러 UIViewController로 화면을 나눕니다.
답변의 컨텍스트에 넣으려면 해당 모달 오버레이에 대한 뷰 컨트롤러를 만드십시오. nav 컨트롤러를 사용하여 표시하는 경우 어쨌든 하나가있을 것입니다.
자체 포함 된 화면에서 슬라이드하는 것이 있습니까? 내 말은, 그것이 부모와 직접적으로 상호 작용 하는가? 그렇다면 UIView, 그렇지 않은 경우 UIViewController.
UIView는 UIViewController의 일부입니다. 이에 대한 UIViewController의 뷰 속성을 참조하십시오. 올바르게 지적했듯이 UIViewController는 전체 화면을 관리하며 한 번에 하나의 보이는 UIViewController 만 있어야합니다. 그러나 대부분의 경우 화면에 더 많은 UIView 또는 UIView의 하위 클래스가 표시됩니다.
귀하가 제공 한 예는 대부분의 경우 올바른 사용입니다. 아시다시피 UIViewController를 서브 클래 싱 할 때 많은 기능을 얻을 수 있습니다. UIViewController의 모양과 해제를 애니메이션하는 것도 그중 하나입니다.
marcc가 지적했듯이 슬라이드하려는 것이 자체 포함 화면이 아닌 경우 UIView를 사용하는 것이 좋습니다.
결론적으로 UIViewController 서브 클래 싱과 함께 제공되는 기능을 사용하려는 경우 UIViewController로 만드는 것보다 더 많이 사용합니다. 그렇지 않으면 UIView가 더 좋을 수 있습니다.
아이튠즈 U Standford 클래스는 일반적으로 UIViewControllers에 관한 많은 정보를 가지고 있기 때문에 내가 시청하는 것이 좋습니다.
MVC 패턴에 익숙하다면 UIVIew와 UIViewController의 차이점을 이해할 수있을 것입니다. 간단한 문장을 만들기 위해 UIView는 화면에 UI 요소를 렌더링하기위한 것입니다. UIView는 거의 모든 Cocoa Touch UI 요소의 수퍼 클래스입니다. 이러한 요소는 표시해야하는 정보, 사용자가 버튼을 클릭 할 때 수행해야하는 작업, 비동기 네트워크 요청이 완료되면 어떤 일이 발생하는지 등을 모릅니다. UIViewController는 그 이상을위한 것입니다. 뷰 컨트롤러는 UI 요소를 화면의 올바른 위치에 배치하고, UI 요소의 내용을 설정하고, 버튼 누름 및 기타 사용자 입력을 처리하고, 필요할 때 모델을 업데이트하는 등의 작업을 담당합니다.
개념적으로 단일 UIViewController는 iPhone 앱에서 전체 화면의 콘텐츠를 제어하므로 뷰 컨트롤러 측면에서 생각하기가 쉽습니다. 사용자가 음식 레시피의 재료를 선택할 수있는 뷰가 필요한 경우이를위한 UIViewController가 필요합니다. Java 배경에서 왔기 때문에 MVC를 적용하는 프레임 워크에 익숙하지 않았기 때문에이 구분을 만들었습니다. UIViews 측면에서 생각하고 그런 식으로 구현하기 시작하면 모든 종류의 문제가 발생합니다. 앱에 대해 UIKit을 고수하려는 경우 Apple이 만든 워크 플로는 앱의 각 개별 뷰에 대해 UIViewController 하위 클래스를 만든 다음 인터페이스 빌더를 사용하여 UI 요소를 배치하고 버튼에 대한 연결을 만드는 것입니다. 등등. 그것은 경이로움을 작동합니다,
전체 화면에서보기를 표시하기 위해 UIViewController를 사용합니다.
사용자 지정보기에 대한 더 나은 제어를 위해 UIView 대신 UIViewController의 하위 클래스를 선호합니다. 이전에는 사용자 지정 하위 클래스를 만들기 위해 UIView를 사용했습니다.
참조 URL : https://stackoverflow.com/questions/1690852/when-to-use-a-uiview-vs-a-uiviewcontroller-on-the-iphone
'Development Tip' 카테고리의 다른 글
| Firebase 저장소 비디오 스트리밍 (0) | 2021.01.08 |
|---|---|
| nvidia-smi 휘발성 GPU 활용 설명? (0) | 2021.01.08 |
| 자바 스크립트로 콘솔 입력을 받으려면 어떻게해야합니까? (0) | 2021.01.08 |
| LL (1), LR (1), LR (0), LALR (1) 문법의 예? (0) | 2021.01.08 |
| 사용자 지정 컨테이너보기 컨트롤러에 포함 된 콘텐츠는 탐색 모음 아래에 있습니다. (0) | 2021.01.08 |