UI 커스터마이징
UI 커스터마이징
커스터마이징 작업이란 주어진 라이브러리나 프레임워크를 수정하여 사용한다는 의미 뿐만 아니라 요구사항을 만족시키기 위해 수정하는 것 을 말한다.
일반적으로 iOS 의 커스터마이징 작업은 화면 표현 구조와 밀접한 관련이 있다.
iOS의 화면 표현 구조
iOS는 유저 인터세이스 표현 구조가 기존의 데스크톱과 다소 다르다. 하나의 스크린에 여러개의 창을 띄울 수 있는 데스트콥과 달리 항상 디바이스 스크린에 하나의 화면만 표시할 수 있다. 다른 프로그램이 실행되면 기존의 화면은 내려가고 그자리를 새로운 화면이 대신 채우는 방식이다. 이런 특성을 구현하는 데에 window 와 view 객체가 사용된다.
window는 iOS에서 디바이스의 스크린을 빈틈없이 채우기 위한 객체로 항상 유저 인터페이스 표현 계층의 최상위에 위치한다. view의 일종이지만 직접 콘텐츠를 가지지 않으며 콘텐츠를 가진 뷰를 내부에 배치하여 화면에 출력하는 역할만 한다. 화면 전환시 단지 윈도우 내부에 배치된 뷰 콘텐츠만 변경될 뿐, 윈도우 객체 자체는 전환되지 않는다.
view는 콘텐츠를 담아 이를 스크린 상에 표시하고, 사용자의 입력에 반응하는 객체이다. 윈도우의 일부를 자신의 영역으로 정ㅇ의하고, 여기에 필요한 콘텐츠를 채워넣어 스크린에 나타내는 동시에, 윈도우로부터 전달된 사용자의 입력에 반응하여 그에 맞는 결과를 처리하여 보여준다.
- 여러개의 중첩된 view와 window (출처: 애플 공식 사이트)
- Root View Controller 식별
루트 뷰를 설정하는 것에 제약은 없다. 다만 루트 뷰 컨트롤러로 지정되지 못한 나머지 뷰 컨트롤러들은 루트 뷰 컨트롤러의 제어 대상으로 연결되거나 혹은 다른 방식으로 이어지기도 하지만, 이들은 윈도우 객체의 직접적인 관리 대상이 아니다. 윈도우 객체는 항상 루트 뷰 컨트롤러만 참조하고 관리한다.
</br>
스토리보드를 통해 편집하는 대부분의 뷰 컨트롤러들은 각자가 하나씩의 화면을 담당하여 콘텐츠를 표현하고 뷰를 관리한다.
이를 씬(Scene) 이라고한다. 보통 씬 하나당 뷰 컨트롤러 하나가 사용된다. 이렇게 씬을 담당하여 콘텐츠를 표시하는 뷰 컨트롤러를 콘텐츠 뷰 컨트롤러Contents View Controller)라고 한다.
</br>
컨테이너 뷰 컨트롤러(Container View Contoller) 는 내부에 뷰로 이루어진 콘텐츠를 배치하는 것이 아니라 뷰 컨트롤러를 배치하고, 이들을 서로 유기적인 관계로 엮이도록 만들어 준다. 내비게이션 컨트롤러나 탭 바 컨트롤러, 페이지 컨트롤러 등이 대표적인 예이다.
</br>
Cocoa Touch Framework와 사용자 인터페이스
코코아 프레임워크의 경우 기존의 Foundation 프레임워크기반에 AppKit 프레임워크로 인해 사용자 인터페이스를 담당하는 방식에서 AppKit 대신에 UIKit 프레임워크를 대신 추가하여 만든 것이 iOS 의 Cocoa Touch 프레임워크이다.
Foundation 프레임워크는 애플리케이션의 중심이자 기능적인 면을 담당하는 프레임워크로, 기본 자료형을 포함한 자료구조, 객체 지향 처리와 연산, 그리고 각종 구조체나 타이머, 네트워크 통신 등 모바일 애플리케이션으로서의 특징적 기능에 직접 연관되지 않은 대부분의 기본적인 애플리케이션 기능을 처리한다.
Foundation 프레임워크에 속한 객체들은 모두 NS라는 키워드로 시작하지만 최근 Swift용으로 사용되는 일부 객체는 NS 키워드가 빠지고 있다. eg) TableView의 NSIndexPath -> IndexPath
UIKit는 화면이나 유저 인터페이스, 앱의 동작 등 모바일 애플리케이션으서의 기능 구현을 주로 담당하는 프레임워크이다. 화면에 표현되는 각종 콘텐츠나 컨트롤 객체를 보유하고 있고, 화면의 구조를 만들고 관리, 사용자의 상호반응, 모바일 디바이스의 화면 변경에 따른 이슈까지 다양하게 처리한다.
ViewController(뷰 컨트롤러)
모바일 앱의 화면을 구성하는 요소인 뷰를 관리하는 것과 화면과 데이터 사이의 상호작용을 관리하는 역할까지 담당한다. 윈도우 객체로부터 전달된 이벤트를 받아 내부적으로 구현된 비즈니스 로직을 실행하고, 그 결과로 얻어진 데이터를 콘텐츠로 만들어 화면에 표현하는 등(기존의 MVC 모델 방식과 유사) 일련의 작업을 처리한다. 이 뷰 컨트롤러는 크게 콘텐츤 뷰 컨트롤러와 컨테이너 뷰 컨트롤러로 나뉘게된다.
뷰 컨트롤러는 뷰와 데이터 간의 중재자 역할을 한다. UIViewController를 상속하고 데이터를 관리하는 변수를 설정하는 것으로 데이터를 관리한다.
뷰 컨트롤러와 데이터 객체 사이는 항살 분명항 책임의 나눔이 있어야한다. 자료 구조의 무결성을 확인하는 대부분의 로직은 데이터 객체 자체에 속해야한다. 뷰 컨트롤러는 뷰로부터 오는 입력 값의 유효성을 검사하고 데이터 객체에서 요구하는 포맷으로 포장하는 역할을 한다. 그러나 뷰 컨트롤러가 실제 데이터를 관리하는 역할은 최소화 해야한다. (ArchitecturePattern 등으로 데이터와 ViewController의 역할을 분리 하는 등)
</br>
UIDocument 객체
UIDocument 객체는 뷰 컨트롤러와 데이터를 분리하여 관리하는 한 방법이 된다. 도큐먼트 객체는 저장소의 데이터를 읽고 쓰는 방법을 제공하는 컨트롤러 객체이다.
앱의 데이터를 관리하는 추상 클래스로 도큐먼트를 사용하면 얻는 이점은 아래와 같다.
- 백그라운드 큐에서 비동기적으로 데이터를 읽거나 쓰기가 가능, 반응성이 좋아진다.
- 도큐먼트 파일의 읽기나 쓰기가 클라우드 서비스에 자동으로 결합된다.
- 다른 버전의 도큐먼트의 충돌 감지를 지원한다.
- 임시 파일에 먼저 저장하고 이후 실제 파일을 대체함으로써 안전한 저장이 가능하다.
- 자동 저장 기능이 제공된다.
</br>
User Interactions
뷰 컨트롤러는 리스폰더 객체기 때문에 리스폰더 체인을 따라 내려오는 이벤트를 처리할 수 있다. 하지만 대부분 뷰가 터치 이벤트를 처리한다. 뷰는 터치를 받고 일반적으로 뷰 컨트롤러가 맡는 타겟 객체나 Delegate에게 이 결과를 전달한다.
</br>
Target-Action Pattern
타겟-액션 패턴은 객체가 이벤트가 일어날 시에 다른 객체에게 보내는 데 필요한 정보를 보유하는 패턴으로 다음과 같은 정보를 가지고 있다.
- Action selector : 실행될 메서드를 식별(callback method의 일종)
- Target: 메시지를 받을 객체(IBOutlet)
myButton.addTarget(self, action: #selector(doSomething), for: .touchUpInside)
...
@objc func doSomething() {...}
@IBAction func doSomething() {...}
Contents ViewController(콘텐츠 뷰 컨트롤러)
콘텐츠 뷰 컨트롤러는 이미지나 텍스트, 또는 HTML 페이지 등 애플리케이션의 화면에 표현할 콘텐츠를 관리하는 컨트롤러이다. 이를 위해 콘텐츠 뷰 컨트롤러는 화면 전체 사이즈의 루트 뷰를 내장하고 있으며, 이 뷰 위에 각종 콘텐츠를 얹어 화면에 출력한다.
기본적으로 뷰 컨트롤러를 정의하는 기본 클래스는 UIViewContoller이다.
그 외에도 우리는 앱을 설계할때 해당 뷰 컨트롤러가 어떤 클래스를 상속받아 구조를 구축할 지를 생각해야한다.
- 테이블 뷰 컨트롤러(UITableViewController)
- 컬렉션 뷰 컨트롤러(UICollection ViewController)
- 스크롤 뷰 컨트롤러(UIScrollViewController)
- 기본 뷰 컨트롤러(UIViewController)
Container ViewController(컨테이너 뷰 컨트롤러)
컨테이너 뷰 컨트롤러는 뷰 컨트롤러와 뷰 컨트롤러의 연결 관계를 관리하는 컨트롤러이다. 기본적으로 iOS는 한 화면에 하나의 뷰 컨트롤러만 표시할 수 있기 때문에 나머지 뷰 컨트롤러에 접근하는 수단을 이 컨테이너 뷰 컨트롤러가 제공한다.
