OSXDEV

--Cjddjeorkfl 2009년 6월 23일 (수) 17:01 (KST)= Contents = 똑바루

[편집] Figures, Tables, and Listings

[편집] Introduction

[편집] The Core Application

모든 아이폰 애플리케이션은 UIKit 프레임워크를 사용하여 만들어지기 때문에, 모두 동일한 코아 아키텍처를 가지게 된다. UIKit가 제공하는 주요 객체들을 통해, 애플리케이션을 돌리거나, 사용자 입력을 처리하고, 스크린에 내용을 디스플레이 하는 것들을 상호 조율하게 된다. Where applications deviate from one another is in how they configure these default objects and also where they incorporate custom objects to augment their application’s user interface and behavior.

여러분의 애플리케이션의 사용자 인터페이스와 기본적인 동작은 애플리케이션의 커스텀 코드에서 커스터마이징하지만, 애플리케이션의 가장 상위 수준에서 해야할 커스터마이징들도 많다. 이러한 애플리케이션 수준에서의 커스터마이징이 여러분의 애플리케이션의 시스템과 디바이스에 설치된 타 애플리케이션과 상호작용하는 방식에 영향을 주기 때문에, 언제 여러분이 행동하고, 언제 기본 동작 정도만으로도 충분한지를 제대로 이해하고 있는 것이 중요하다. 이 장은 코어 애플리케이션 아키텍처에 대한 개괄과 고수준 커스터마이징 포인트를 제공하여 여러분이 커스터마이징을 해야할 때와, 디폴트 동작을 사용해야할 때를 판단할 수 있도록 도와준다.

[편집] Core Application Architecture

사용자가 여러분의 애플리케이션을 기동할 때부터, 종료할 때까지, UIKit 프레임워크는 애플리케이션의 주요 인프라스트럭처의 대부분을 관리한다. 아이폰 애플리케이션은 시스템으로부터 지속적으로 이벤트를 받으면, 반드시 그 이벤트들에 대해서 응답을 해줘야 한다. 이벤트를 받는 일은 UIApplication 객체의 몫이지만, 이벤트에 응답하는 것은 여러분의 커스텀 코드가 할일이다. 이벤트를 어디서 반응해야하는지를 이해하려면, 아이폰 애플리케이션의 전체적인 라이프 사이클과 이벤트 사이클에 이해해두는 것이 좋다. 다음의 절들은 이러한 사이클을 설명하고, 또한 아이폰 애플리케이션의 개발 전반에 걸쳐 사용되는 주요 디자인 패턴들 중 몇가지를 요약해줄 것이다.

[편집] 애플리케이션 라이프 사이클

애플리케이션 라이프 사이클은 여러분의 애플리케이션이 시작하고나서부터 종료할 때까지 발생하는 일련의 이벤트들로 이뤄진다. 아이폰 OS에서는 사용자가 여러분의 애플리케이션을 기동하려할 때, 홈 스크린에서 아이콘을 클릭한다. 클릭하고나면, 시스템은 곧이어서 넘기기 그래픽을 보여주고, 여러분의 애플리케이션을 기동하게 되는데, 이때 애플리케이션의 main 함수가 호출된다. 바로 이때부터, 초기화 작업이 몽창 UIKit으로 넘어가게 되고, UIKit에서는 애플리케이션의 사용자 인터페이스를 로딩하고, 이벤트 루프를 준비한다. 이벤트 루프동안에 UIKit은 이벤트를 여러분의 커스텀 객체로 넘기는 작업과 애플리케이션이 내뱉는 커맨드에 반응하는 작업을 서로 조율하게 된다. 사용자가 애플리케이션을 종료하게하는 액션을 취하면, UIKit은 이를 애플리케이션에 알리고, 종료를 처리하기 시작한다.

그림 1-1은 아이폰 애플리케이션의 라이프 사이클을 간단하게 표현한 것이다. 이 다이어그램은 애플리케이션의 시작 시점부터 종료 시점까지 발생하는 일련의 이벤트들을 보여주고 있다. 초기화 시점과 종료 시점에 UIKit은 특정 메시지를 애플리케이션 델리깃 객체에 보내서, 지금 무슨 일이 벌어지고 있는지를 알려주게 된다. 이벤트 루프동안에는 UIKit이 이벤트를 애플리케이션의 커스텀 이벤트 핸들러로 디스패치한다. 초기화 이벤트와 종료 이벤트 처리에 관해서는 '초기화와 종료'에서 나중에 살펴보게 될 것이고, 이벤트 핸들링 프로세스는 '이벤트 핸들링 사이클'에서 잠시 소개하고, 좀 더 자세한 것은 나머지 장에서 다룰 것이다.

그림 1-1 애플리케이션 라이프 사이클

[편집] Main 함수

아이폰 애플리케이션에서는 main 함수가 아주 최소한으로 사용된다. 애플리케이션 수행에 필요한 실제 작업의 대부분은 UIApplication 함수가 대신 처리한다. 결과적으로, Xcode에서 애플리케이션 프로젝트를 새로 시작할 때, 모든 프로젝트 템플릿에는 "중요 애플리케이션 태스크 처리하기"에서처럼 표준 main 함수의 구현이 담겨있다. main 루틴에서 하는 일은 딱 세가지다. autorelease pool을 생성하고, UIApplicationMain을 호출하고, autorelease pool을 릴리즈한다. 아주 드문 예외를 제외하곤, 여러분이 main 함수의 구현을 수정할 일은 거의 없다.

리스팅 1-1 아이폰 애플리케이션의 main 함수

#import <UIKit/UIKit.h>
 
int main(int argc, char *argv[])
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, nil);
    [pool release];
    return retVal;
}

[편집] 애플리케이션 델리깃

[편집] Main NIB 파일

[편집] 이벤트 핸들링 사이클

UIApplicationMain 함수가 응용프로그램을 초기화한 다음에, 응용프로그램의 이벤트와 그리기 사이클을 관리하는데 필요한 제반사항들을 시작시킨다.(Figure 1-2) 사용자가 기기와 상호작용 할 때, 아이폰 OS는 터치 이벤트를 감지하고 이 이벤트를 응용프로그램 이벤트 큐에 적재한다. UIApplication객체의 이벤트 관리 기반은 이 큐의 가장 상단부터 이벤트를 가져다가 이 이벤트를 적당히 손볼 객체로 배달한다. 예를 들어, 버튼에서 터치 이벤트가 발생하면, 대응되는 버튼 객체로 이 이벤트가 전달된다. 이벤트들은 컨트롤러 객체나 응용프로그램의 터치 이벤트를 담당하는 다른 객체로 전달될 수도 있다.

Figure 1-2 The event and drawing cycle

아이폰 OS 멀티 터치 이벤트 모델에서, 터치 데이터는 하나의 이벤트 객체(UIEvent)로 캡슐화되어 있다. 각각의 터치들을 따라가기 위해, 이벤트 객체는 터치 객체(UITouch)를 포함한다(스크린에 터치한 하나의 손가락에 하나의 객체). 사용자가 스크린에 손가락을 위치하고, 이동하고, 마지막에는 스크린에서 뗄때, 시스템은 각 손가락의 모든 변화를 대응되는 터치 객체로 리포팅한다.

응용프로그램이 실행되면, 시스템은 응용프로그램을 위한 프로세스와 단일 스레드를 둘다 생성한다. 이 초기 스레드는 응용프로그램의 메인 스레드가 되고, 이는 UIApplication 객체가 생성, 설정하는 메인 실행 루프와 응용프로그램 이벤트 핸들링 코드에 위치한다.

Figure 1-3은 메인 실행 루프와 이벤트 핸들링 코드와의 관계를 보여준다. 터치 이벤트는 시스템에 의해 보내지고 메인 실행 루프에 의해 실행될때까지 큐에 적재된다.

Figure 1-3 Processing events in the main run loop

UIApplication 객체는 적당한 응답 객체로 전송되는 터치 이벤트가 처리되는 입력원과 함께 메인 실행 루프를 설정한다. 응답 객체는 UIResponder 클래스를 상속받고 터치 이벤트의 다른상태에 대한 처리를 위한 메소드를 한개 이상 갖는다. 응용프로그램의 응답 객체는 UIApplication, UIWindow, UIView 와 모든 UIView 의 서브클래스의 인스턴스를 포함한다. 응용프로그램은 기본적으로 이벤트들을 응용프로그램의 기본 윈도우인 UIWindow 객체로 전달한다. 이를 윈도우 객체는 그것의 first responder 에게 전달하는데 이는 일반적으로 터치가 발생하는 view 객체(UIView) 이다.

또한 이벤트를 처리하는 함수를 정의하는것 뿐 아니라, UIResponder 클래스 또한 responder chain 의 프로그램의 구조를 정의한다. (이벤트 처리에 관한 코코아 메커니즘에 따라) responder chain 은 first responder 로 시작하는 응답 객체의 일련의 연결로 되어 있다. 만약 first responder 객체가 이벤트를 처리할 수 없다면, 체인상의 다음 responder 에게 이를 넘긴다. 메시지는 처리될 때 까지 체인을 계속해서 돈다(고 레벨 응답객체로 향해서 이동한다 예, window, 응용프로그램, 응용프로그램 대리자).

이벤트를 처리하는 응답 객체는 유서 인터페이스의 부분 또는 전체의 다시그리기를 유발하는 프로그램 동작의 일련을 설정하는것을 의도한다.(). 예를들어, 컨트롤 객체(UIControl의 서브클래스)는 다른 객체(일반적으로 활성화된 현재의 뷰의 집합들) 에서 전달되는 액션 메시지를 처리한다. 액션 메시지를 처리하는동안, 컨트롤러는 유저 인터페이스를 변경하거나, 재실행될 필요가 있는 뷰의 위치를 확인한다. 이 일이 일어나는 동안, 뷰와 그래픽의 기반은 가능한 효율적으로 요청된 다시그리기 이벤트를 가져다가 처리한다.

이벤트, 응답자, 어떻게 이벤트를 처리하는지 등에 대한 더 많은 정보를 알기 위해서는 "Event Handling"를 보고, 이벤트 핸들링 목적에 맞는 윈도우와 뷰의 정보를 확인하기 위해서는 "The View Interaction Model". 그래픽 기반과 어떻게 그들을 업데이트 하는지에 대한내용은 "The View Drawing Cycle"에서 확인 할 수 있다.

[편집] Fundamental Design Patterns

[편집] The Application Runtime Environment

[편집] The Application Bundle

[편집] Handling Critical Application Tasks

[편집] 초기화와 종료

[편집] Responding to Interruptions

[편집] Observing Low-Memory Warnings

[편집] Customizing Your Application's Behavior

[편집] Internationalizing Your Application

[편집] 성능과 응답속도 향상을 위한 튜닝

[편집] 메모리 효율적으로 사용하기

[편집] 애플리케이션의 메모리 사용량 줄이기

[편집] 메모리 똑똑하게 할당하기

아이폰 애플리케이션은 관리 메모리 모델을 사용하는데, 이렇게 되면 여러분이 직접 객체를 리테인하고 릴리즈해야 한다. 표 1-7은 여러분의 프로그램에서 메모리를 할당할 때의 팁을 나열하고 있다.

For detailed information on how to allocate memory in iPhone applications, and for more information on autorelease pools, see Cocoa Objects in Cocoa Fundamentals Guide.

[편집] Window and Views

[편집] What are Windows and Views

Mac OS X 처럼, iPhone OS도 스크린상에 이미지를 제공하기 위해 윈도우(Windows)와 뷰(Views)를 사용한다. 두 플랫폼 상에서 윈도우와 뷰는 많은 유사성을 가지고 있지만, 각 플랫폼 상에서 약간 다르게 동작한다.

The Role of UIWindow

Mac OS X 어플리케이션과 달리, iPhone 어플리케이션은 오직 하나의 윈도우를 가지며, UIWindow class의 객체로 나타내어진다. 당신의 어플리케이션은 launch time(또는 nib파일로 부터 로딩)에 이 윈도우를 만들고, 하나 또는 그 이상의 뷰들을 윈도우에 추가하며, 이것을 화면에 나타낸다. 그 이후에는 윈도우 객체를 참조할 일은 거의 없을 것이다.

iPhone OS에서는 윈도우가 close box or title bar와 같은 시각 도구들을 가지고 있지 않으며, 유저에 의해 바로 닫히거나 수정될 수 없다. Window에 대한 모든 수정은 programmatic 인터페이스에 의해서 수행된다. 또한 해당 어플리케이션에 이벤트를 전달하는데에도 Window를 사용하게 된다. 예를 들면, Window 객체는 자신의 첫번째 응답 객체를 유지하고 UIApplication 객체에 의한 이벤트 전달 요청을 해당 객체로 처리하게 된다.

Mac OS X를 경험한 개발자는 UIWindow에서 상속에 대한 이상한 부분을 볼 수 있다. Mac OS X에서는 NSWindow가 NSResponder의 부모 클래스이다. iPhone OS에서는 UIWindow의 부모는 UIView이다. 그래서, iPhone OS에서는 window도 하나의 view객체이다. 자신의 태생에도 불구하고, iPhone OS상의 window를 Mac OS X상에서의 그것과 동일하게 다룰 것이다. 그것은 UIWindow 객체의 view 관련된 속성을 일반적으로는 수정하지 않기 때문이다.

어플리케이션 window를 생성할 때에는 항상 화면의 전체 사이즈를 채울 정도로 프레임 사이즈를 설정해야 한다. nib로 부터 window를 로드할 때에는, IB(인터페이스 빌더)에 의해 화면 보다 작은 크기의 window를 생성할 수 없게 된다. Programmatically하게 window를 생성하더라도 필요한 크기를 반드시 명시하여야 하며, 화면과 다른 사이즈의 크기를 설정할 이유가 전혀 없으므로 아래와 같이 세팅하게 된다.

UIWindow* aWindow = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];

iPhone OS가 layer window를 지원하더라도, 당신의 어플리케이션은 하나 이상의 window를 만들면 안된다. 시스템 자체적으로 시스템 상태바, 중요한 알림, 다른 메시지들을 나타내기 위해 추가적인 window를 사용하게 된다. 화면 가장 위로 알림(alert)을 보여주고 싶으면, 추가적인 window를 만들기 보다는 UIKit에 의해 제공되는 알림뷰(alert views)를 사용하면 된다.

The Role of UIView A view, an instance of the UIView class, defines a rectangular area on the screen. In iPhone applications, views play a key role in both presenting your interface and responding to interactions with that interface. Each view object has the responsibility of rendering content within its rectangular area and for responding to touch events in that area. This dual behavior means that views are the primary mechanism for interacting with the user in your application. In a Model-View-Controller application, view objects obviously are the View portion of the application.

In addition to displaying its own contents and handling events, a view may also manage one or more subviews. A subview is simply a view object embedded inside the frame of the original view object, which is referred to as the parent view or superview. Views arranged in this manner form what is known as a view hierarchy and may contain any number of views. Views can also be nested at arbitrarily deep levels by adding subviews to subviews. The organization of views inside the view hierarchy controls what appears on screen, as each subview is displayed on top of its parent view. The organization also controls how the views react to events and changes. Each parent view is responsible for managing its direct subviews, by adjusting their position and size as needed and even responding to events that its subviews do not handle.

Because view objects are the main way your application interacts with the user, they have a number of responsibilities. Here are just a few:

Drawing and animation Views draw content in their rectangular area. Some view properties can be animated to new values. Layout and subview management Views manage a list of subviews. Views define their own resizing behaviors in relation to their parent view. Views can manually change the size and position of their subviews as needed. Views can convert points in their coordinate system to the coordinate systems of other views or the window. Event handling Views receive touch events. Views participate in the responder chain. In iPhone applications, views work closely with view controllers to manage several aspects of the views behavior. View controllers handle the loading and unloading of views, interface rotations caused by the user physically rotating the device, and interactions with the high-level navigation objects used to construct complex user interfaces. For more information, see “The Role of View Controllers.”

Most of this chapter is dedicated to explaining these responsibilities and showing you how to tie your own custom code into the existing UIView behaviors.

UIKit View Classes The UIView class defines the basic properties of a view but not its visual representation. Instead, UIKit uses subclasses to define the specific appearance and behavior for standard system elements such as text fields, buttons, and toolbars. Figure 2-1 shows the class hierarchy diagram for all of the views in UIKit. With the exception of the UIView and UIControl classes, most of the views in this hierarchy are designed to be used as-is or in conjunction with a delegate object.

Figure 2-1 View class hierarchy

This view hierarchy can be broken down into the following broad categories:

Containers Container views enhance the function of other views or provide additional visual separation of the content. For example, the UIScrollView class is used to display views whose contents are too large to fit onscreen all at once. The UITableView class is a subclass of UIScrollView that manages lists of data. Because table rows are selectable, tables are commonly used for hierarchical navigation too—for example, to drill down into a hierarchy of objects.

A UIToolbar object is a special type of container that visually groups one or more button-like items. A toolbar typically appears along the bottom of the screen. The Safari, Mail, and Photos applications all use toolbars to display buttons representing frequently used commands. Toolbars can be shown all the time or only as needed by the application.

Controls Controls are used to create most of a typical application’s user interface. A control is a special type of view that inherits from the UIControl superclass. Controls typically display a specific value and handle all of the user interactions required to modify that value. Controls also use standard system paradigms, such as target-action and delegation, to notify your application when user interactions occur. Controls include buttons, text fields, sliders, and switches.

Display views Although controls and many other types of views provide interactive behavior, some views simply display information. The UIKit classes that exhibit this behavior include UIImageView, UILabel, UIProgressView, and UIActivityIndicatorView.

Text and web views Text and web views provide a more sophisticated way to display multiline text content in your application. The UITextView class supports the display and editing of multiple lines of text in a scrollable area. The UIWebView class provides a way to display HTML content, which lets you incorporate graphics and advanced text-formatting options and lay out your content in custom ways.

Alert views and action sheets Alert views and action sheets are used to get the user’s attention immediately. They present a message to the user, along with one or more optional buttons that the user can use to respond to the message. Alert views and action sheets are similar in function but look and behave differently. For example, the UIAlertView class displays a blue alert box that pops up on the screen and the UIActionSheet class displays a box that slides in from the bottom of the screen.

Navigation views Tab bars and navigation bars work in conjunction with view controllers to provide tools for navigating from one screen of your user interface to another. You typically do not create UITabBar and UINavigationBar items directly but configure them through the appropriate controller interface or using Interface Builder instead.

The window A window provides a surface for drawing content and is the root container for all other views. There is typically only one window per application. For more information, see “The Role of UIWindow.”

In addition to views, UIKit provides view controllers to manage those objects. For more information, see “The Role of View Controllers.”

The Role of View Controllers Applications running in iPhone OS have many options for organizing their content and presenting it to the user. An application that contains a lot of content might divide that content up into multiple screens’ worth of information. At runtime, each screen would then be backed by a set of view objects responsible for displaying the data for that particular screen. The views for a single screen would themselves be backed by a view controller object, whose job is to manage the data displayed by those views and coordinate updates with the rest of the application.

The UIViewController class is responsible for creating the set of views it manages and for flushing them from memory during low-memory situations. View controllers also provide automatic responses for some standard system behaviors. For example, in response to a change in the device's orientation, the view controller can resize its managed views to fit the new orientation, if that orientation is supported. You can also use view controllers to display new views modally on top of the current view.

In addition to the base UIViewController class, UIKit includes more advanced subclasses for handling some of the sophisticated interface behaviors common to the platform. In particular, navigation controllers manage the display of multiple hierarchical screens worth of content. Tab bar controllers let the user switch between different sets of screens, each of which represents a different operating mode for the application.

For information on how to use view controllers to manage the views in your user interface, see View Controller Programming Guide for iPhone OS.

[편집] View Architecture and Geometry

[편집] Creating and Managing the View Hierarchy

[편집] Modifying Views at Runtime

[편집] Creating a Custom View

[편집] Event Handling

iPhone OS 의 이벤트는 멀티터치 모델을 기반으로 한다. 사용자들은 마우스나 키보드 대신에 기기 화면을 터치함으로서 객체들을 움직이고, 데이터를 입력하고, 의도하고자 하는 바를 적용한다. iPhone OS 는 멀티터치 시퀀스의 일환으로 하나 또는 두개의 손가락 터치를 인지한다. 이 시퀀스는 처음 손가락이 스크린에 눌릴때 부터 마지막 손가락이 스크린으로부터 떼어질때까지 이루어진다. iPhone OS는 터치가 발생하는 시간과 스크린상의 위치를 포함한 특성들을 기록하거나 멀티터치 시퀀스를 통해서 터치하는 손가락들을 추적한다. 응용프로그램은 주로 제스처로서의 터치들의 일련의 묶음들을 인지하고, 사용자에게 직관적인방법으로 이들에 응답한다. 예를들어, 핀칭 제스쳐를 이용한 컨텐츠의 확대나 플리킹 제스쳐를 이용한 스크롤 같은것들이다.

UIKit 의 많은 클래스들은 클래스의 객체를 통해 특색있게 멀티 터치 이벤트를 관리한다. 이는 정확히 UIButton과 UISlider 같은 UIControl 의 서브클래스들이다. 컨트롤 객체로 알려진 이 서브클래스들의 객체는 탭이나 드래그 같은 특정 형식의 제스쳐를 수용할 수 있다. 적절하게 설정되었다면, 제스쳐가 발생했을때 액션 메시지들을 대상 객체로 보낸다. 다른 UIKit 클래스들은 다른 컨텍스트의 제스쳐들을 관리한다. 예를들어, UIScrollView 는 테이블 뷰, 텍스트 뷰 또는 많은 량의 컨텐츠를 위한 뷰 를 위한 스크롤 동작들을 제공한다.

몇몇의 응용프로그램은 이벤트들을 직접적으로 제어할 필요가 없다. 대신에, UIKit 의 클래스들에 의존적일 수 있다. 다만 여러분들이 UIView 의 커스텀 서브클래스를 생성하고자 하거나 특정 터치 이벤트에 응답하길 원한다면, 여러분은 이들 이벤트를 처리하는 코드를 구현해야 할 것이다. 게다가 여러분들이 이벤트에 다르게 반응하는 UIKit 객체를 원한다면, 프레임워크 클래스의 서브클래스를 생성하거나 적절한 이벤트-처리 메소드를 오버라이드 해야 한다.

[편집] Events and Touches

iPhone OS 에서, 터치는 유일한 멀티터치 시퀀스의 부분인 스크린상 손가락의 이동 또는 닿음 이다. 예를 들어 두 손가락 모으기 동작은 두 터치로 이루어진다(스크린상에 두 손가락의 서로 반대 방향 움직임). 여기에 탭이나 두번 탭 또는 플릭(스크린을 빠르게 쓸어내리기)같은 간단한 한손가락 동작이 있다. 응용프로그램은 더 복잡한 동작들을 인지해야 할것이다. 예를 들어 응용프로그램이 여러 손가락을 이용한 "턴" 류의 다이얼 모양 동작을 필요로 하는 커스텀 컨트롤을 가질 수 있다.

이벤트는 손가락이 스크린을 터치 하거나 그 표면을 이동할때 시스템이 지속적으로 응용프로그램으로 보내는 객체이다. 이벤트는 가장 중요한것으로 멀티 터치 시퀀스중의 새롭거나 변화된 모든 터치에 대해 스냅샷을 제공한다.

An event is an object that the system continually sends to an application as fingers touch the screen and move across its surface. The event provides a snapshot of all touches during a multi-touch sequence, most importantly the touches that are new or have changed for a particular view. A multi-touch sequence begins when a finger first touches the screen. Other fingers may subsequently touch the screen, and all fingers may move across the screen. The sequence ends when the last of these fingers is lifted from the screen. An application receives event objects during each phase of any touch.

Touches have both temporal and spatial aspects. The temporal aspect, called a phase, indicates when a touch has just begun, whether it is moving or stationary, and when it ends—that is, when the finger is lifted from the screen (see Figure 3-1). A touch also has the current location in a view or window and the previous location (if any). When a finger touches the screen, the touch is associated with a window and a view and maintains that association throughout the life of the event. If multiple touches arrive at once, they are treated together only if they are associated with the same view. Likewise, if two touches arrive in quick succession, they are treated as a multiple tap only if they are associated with the same view.

Figure 3-1 A multi-touch sequence and touch phases

In iPhone OS, a UITouch object represents a touch, and a UIEvent object represents an event. An event object contains all touch objects for the current multi-touch sequence and can provide touch objects specific to a view or window (see Figure 3-2). A touch object is persistent for a given finger during a sequence, and UIKit mutates it as it tracks the finger throughout it. The touch attributes that change are the phase of the touch, its location in a view, its previous location, and its timestamp. Event-handling code evaluates these attributes to determine how to respond to the event.

Figure 3-2 Relationship of a UIEvent object and its UITouch objects

The system can cancel a multi-touch sequence at any time and an event-handling application must be prepared to respond appropriately. Cancellations can occur as a result of overriding system events, such as an incoming phone call.

[편집] Event Delivery

[편집] Handling Multi-Touch Events

[편집] Graphics and Drawing

[편집] The UIKit Graphics System

[편집] The View Drawing Cycle

UIView 객체의 기본적인 그리기 모델은 요청이 있을 때 내용을 업데이트 하는 것이다. UIView 클래스는 이 업데이트 과정 (만든 업데이트 요청을 얻거나 그 요청들을 그리기 코드에 전달 하는것)을 가장 적절한 시간에 하도록 하여 쉽고 효과적으로 해 준다.

뷰의 일부가 다시 그리기가 필요한 경우는 언제든지, UIView 객체가 자동으로 drawRect: 메소드를 호출한다. 이 메소드에 다시 그리기가 필요한 영역을 전달한다. 이 메소드를 커스텀 뷰 서브클래스에 맞게 오버라이드 하여 새로운 뷰에 맞게 그리는데 써야 한다. 뷰가 처음 그려지면, 보이는 영역 전체가 drawRect: 메소드로 전달된다. 그러나 이후 부터는, 오직 다시 그려질 필요가 있는 영역만 전달된다. 아래는 업데이트를 유발하는 인자들이다.

• 뷰의 일부이상을 가리고 있는 다른 뷰가 이동되어졌을때.
• 숨겨져 있던 뷰가 다시 보여졌을때
• 스크롤 되어 사라졌다가 다시 나타났을때
• setNeedsDisplay 또는 setNeedsDisplayInRect 함수가 명시적으로 호출되었을때

drawRect: 메소드가 호출 되고 난 후, UIView 객체는 스스로 업데이트 되었음과 새로운 액션 이나 업데이트 인자들을 기다린다는 표식을 한다. 만약 출력내용이 정적이라면 기껏해야 스크롤이나 다른 뷰에 의해서만 다시 그리기 요인들이 발생하지만, 정기적으로 변경되는 내용이라면 시간에 따라 업데이트를 해야 할 것이다. 또한 뷰의 내용에 따라 유동적으로 뷰를 업데이트 할 수도 있다.

[편집] 좌표 및 좌표변환

// 추가 필요

윈도우나 뷰의 원점은 왼쪽 상단이다. 이로부터 우측 아래로 갈 수록 좌표는 증가하게 된다. 이 좌표를 이용하여 원하는 위치에 그리기를 실행 할 수 있다.

이런 기본적인 좌표 시스템을 변경 할 필요가 있을 때, 현재 변형 매트릭스를 수정하면 된다. Current Transformation Matrix(CTM)은 뷰 좌표 시스템을 기기의 스크린과 매핑해놓은 수학적인 매트릭스이다. 뷰의 drawRect: 메소드가 처음 호출되면 CTM은 좌표 시스템의 원점과 뷰의 원점을 매치 시키고 양의 축으로 아래, 우측을 향해 확장될 수 있도록 매칭 시킨다. 그러나 이 CTM은 scale, rotation 그리고 translation 인자에 의해 변경될 수 있다.

CTM의 수정은 뷰에 내용을 그리는데 쓰인 표준 기술이다. 만약 10x10 사각형을 20,20 위치에 그리길 원한다면 path를 20,20 으로 옮기고 해당 라인들을 그리기 시작해야 할 것이다. 만약 이를 후에 10,10 으로 옮기고자 한다면 이를 다시 생성한 하웨 새로운 포인터에서 그려야 할 것이다. 사실 매번 이 작업을 반복해야 하는데 이것은 매우 연산이 무겁다. 그러나 CTM을 변경하는것은 매우 가벼운 연산으로 이를 이용할 수 있다.

Core Graphics 프레임워크에서 CTM을 변경하는 두가지 방법이 있다. CGContext 레퍼런스로 CTM을 직접적으로 변경하거나, CGAffineTrasform 구조체를 사용하여 생성할 수 있다. 더 자세한 정보는 Quartz 2D Programming Guide 를 참고한다.

[편집] Graphics Contexts

커스텀 drawRect(메소드) 호출 전 : view 객체는 자동으로 그리기 환경을 설정하여 코드가 즉각적으로 그리기를 시작할 수 있도록 한다. 이 환경설정을 통해, UIView객체는 현재 그리기 환경을 위한 그래픽 컨텍스트( CGContextRef opaque type)를 조성한다. 이 그래픽 컨텍스트는 그리기 시스템이 다음 그리기 명령을 수행하기 위해 필요한 정보를 포함한다. 이는 그릴 때 사용되는 색상, 오려내기 영역, 라인의 너비와 스타일 정보, 글씨 정보, 구성옵션 등 기본 그리기 속성을 정의한다.

뷰의 한 영역에 그리기를 원할 때, 그래픽 컨텍스트 객체를 생성할 수 있다. Quartz에서, 주로 일련의 그리기 명령을 캡처하여 이미지나 PDF 파일을 생성하기를 원할 수 있다. 컨텍스트를 생성해내기 위해, CGBitmapContextCreate 또는 CGPDFContextCreate 함수를 사용한다. 일단 컨텍스트가 생성되면, 컨텐츠를 표현하는데 필요한 그리기 함수로 그것을 전달할 수 있다.

커스텀 컨텍스트를 생성할 때, 이를 위한 좌표 시스템은 아이폰 os에 의해 사용되는 기본 좌표 시스템과는 다르다. 그리기 면의 좌측상단에 표현되었던 원점 대신에, 좌측하단에서 축 값이 증가되어 오른쪽에 표시된다. 그리기 명령으로 명시한 좌표는 표현 중에 이미지나 PDF파일을 잘못 나타내어 질 수도 있다는 생각으로 이를 받아드려야만 한다.

Important : bitmap으로 그리거나 PDF로 꾸밀 때 좌측하단 원점을 사용하기 때문에, view에 결과 내용을 표현할 때, 반드시 좌표시스템을 보완해 주어야만 한다. 다시 말해, 만약 당신이 이미지를 생성하여 그것을 CGContextDreawImage 함수로 그렸다면, 그 이미지는 거꾸로 뒤집혀서 표현될 것이다. 이를 바로잡기 위해, CTM의 축을 뒤집어줘야 하며, view의 원점을 좌측하단에서 좌측상단으로 이동시켜주어야 한다.

만약 당신이 생성한 CGImageRef 를 포함한 UIImage객체를 사용했다면, CTM을 수정할 필요가 없다. UIImage 객체는 CGImageRef타입의 뒤집힌 좌표시스템을 자동으로 보완해준다.

그래픽 컨텍스트, 그래픽 상태정보 수정과 커스텀 컨텐츠 생성을 위한 그래픽 컨텍스트에 대한 더 많은 정보를 원한다면, Quartz 2D programming Guide를 참고하시오. 그래픽 컨텍스트와 관련하여 사용되는 일련의 함수들은 CGContext Reference, CGBitmapContext Referce, CGPDFContext Reference를 참고하시오.

[편집] Points Versus Pixels

Quartz 그리기 시스템은 벡터기반의 그리기 모델을 사용한다. 래스터기반의 그리기 모델과 비교하면, 그리기 명령은 각각의 픽셀위에서 동작한다. Quartz의 그리기 명령은 고정 스케일 그리기 공간을 사용하는데, user coordinate space 로 알려져 있다. 그것을 아이폰 OS 기기의 실제 픽셀상에 맵핑한다. 이 모델의 장점은 벡터로 그려진 그래픽들은 스케일이 변경되더라도 그 모양이 좋게 유지된다.

벡터기반의 그리기 시스템에서 본래의 속성을 유지하기 위해서, 그리기 좌표는 정수형이 아닌 부동소수점 값으로 사용된다. 좌표를 위해 부동소수점 값을 사용하는 것은 정보를 매우 정확한 위치에 표시할 수 있도록 해준다. 가장 중요한것은, 이것이 어떻게 기기의 스크린과 매핑되는지 걱정할 필요가 없다는것이다. user coordinate space 는 그리기 명령을 위해 사용되는 환경이다. 이 space의 기본 유닛으로서 포인트를 사용한다. device coordinate space 는 픽셀을 기반으로 쓰인다. 일반적으로 user coordinate space 의 1포인트는 device coordinate space의 1픽셀과 같다. 그러나 이것을 항상 염두할 필요는 없다.

[편집] Color and Color Spaces

아이폰 OS는 Quartz에서 사용가능한 색 공간 모두를 지원한다. 그러나, 대부분의 응용프로그램은 오직 RGB 색공간만을 필요로 한다. 아이폰 OS가 임베디드 하드웨어와 그래픽을 위하여 디자인되었기 때문에, RGB 색공간은 가장 사용하기 적당한 색공간이다.

UIColor 객체는 RGB, HSB, grayscale 값 을 이용하는데 매우 편리한 메소드 들을 지원해 준다. 이방법으로 색을 생성할때 색공간을 특별히 지정해줄 필요는 없다. UIColor객체가 자동으로 지정해준다.

또한 색을 생성하고 설정하기 위해서 CGContextSetRGBStrokeColor 와 CGContextSetRGBFillColor 함수를 이용할 수 있다. 이는 Core Graphics 프레임웍 에 포함되어 있다. 비록 Core Graphics 프레임웍은 다른 색공간에서 색을 생성, 커스텀 색공간 생성등을 위한것도 지원하지만, 이것들의 사용은 추천하지 않는다. 그리기 코드는 항상 RGB를 이용해야 한다.

[편집] 지원되는 이미지 형식

Table 4-1 에는 아이폰 OS에서 직접적으로 지원하는 이미지 형식에 대한 리스트를 나타낸다. PNG 형식은 그 사용이 가장 강력하게 추천되는 형식이다.

[편집] Drawing Tips

다음 섹션에서는 최종사용자에게 어떻게 당신의 어플리케이션이 보일지를 코드로 나타내는 것에 대해 설명한다.

[편집] Deciding When to Use Custom Drawing Code

[편집] Improving Drawing Performance

[편집] Maintaining Image Quality

[편집] Drawing with Quartz and UIKit

[편집] Drawing with OpenGL ES

Open Graphics Library (OpenGL) 은 데스크탑 시스템 상에서 2D 와 3D 를 표현하기 위한 C 기반의 크로스플랫폼이다. 이것은 일반적으로 게임 개발자나 고수준의 프렘임율의 드로잉이 필요할 경우에 사용된다. OpenGL 함수는 점,선,면 같은 원론적인 구조를 나타낼때와 텍스쳐, 특수 효과를 위해 사용한다. 함수 콜을 하면 렌더링을 위한 중요한 하드웨어에게 명령을 내린다. 렌더링이 하드웨어를 이용하기 때문에 OpenGL 드로잉은 매우 빠르다.

임베디드 시스템을 위한 OpenGL 은 모바일기기나 현대 그래픽 하드웨어의 이점에 맞도록 성능을 낮춘 버전이다. 만약 iPhone OS 기기에 맞는 OpenGL 컨텐트를 개발하려 한다면 OpenGL ES 를 사용하여야 한다. iPhoneOS 의 OpenGL ES 프레임워크(OpenGLES.framework)는 OpenGL ES v1.1 과 OpenGL ES v2.0 을 지원한다.

더 많은 OpenGL ES 에 대한 정보를 얻고자 한다면, OpenGL ES Programming Guide for iPhone 문서를 참고하기 바란다.

[편집] Applying Core Animation Effects

[편집] Text and Web

[편집] About Text and Web Support

[편집] 키보드와 입력 방식

사용자가 텍스트 입력이 허용되는 객체를 탭핑 할때는 언제든지, 객체가 시스템에게 적당한 키보드를 출력할지를 물어본다. 사용자가 선호하는 언어나 프로그램의 요구에 따라, 시스템은 여러 다른 키보드중 하나를 출력할 것이다. 비록 응용프로그램이 사용자가 선호하는 언어를 컨트롤 할 수 없을지라도, 사용하길 원하는 키보드의 속성은 컨트롤 할 수 있다. 예를들어, 어떤 특수 키의 설정이나 그 동작들이 그것이다.

비록 UIWebView 가 UITextInputTraits 프로토콜을 직접적으로 지원하지는 않더라도
텍스트 입력을 위한 몇몇 키보드 속성을 설정할 수 있다. 
부분적으로, 다음과 같은 코드를 이용해서 키보드의 동작을 설정하는 입력 인자의 
정의에 autocorrect 속성과 autocapitalization 속성을 넣을 수 있다.
<input type="text" size="30" autocorrect="off" autocapitalization="on">
입력 인자로 키보드 타입은 지정할 수 없다. 
webView는 기본 키보드를 기반으로한 커스텀 키보드를 출력한다. 
다만 form 인자간을 오고가는 추가적인 컨트롤들을 포함한다.

기본 키보드 설정은 일반적인 텍스트 입력을위해 디자인되었다. Figure 5-3 은 여러 다른 키보드 설정을 보여준다. 기본 키보드는 알파벳을 기본적으로 출력하지만 사용자는 숫자 출력이나 특수기호 출력으로 바꿀 수 있다. 대부분의 다른 키보드들도 비슷한 속성을 띠고 있다. 몇몇 추가기능을 위한 버튼 또한 지원한다. 그러나 폰과 숫자 키보드는 완전히 다른 레이아웃을 제공한다. 이는 요구조건에 맞게 레이아웃되어 있기 때문이다.

다른 사용자에게 언어 설정을 쉽게 하기 위해서, 아이폰 OS는 다른 언어에 따른 다른 입력 방법과 레이아웃을 제공한다. 이들은 Figure 5-4 에서 보인다. 사용자의 언어 설정에 따라 키보드의 입력방식과 레이아웃이 바뀐다.

[편집] Managing the Keyboard

비록 많은 UIKit 객체가 사용자와 자동으로 반응하여 키보드를 출력하지만, 응용프로그램은 여전히 키보드에 대한 관라와 설정에 책임을 가지고 있다. 다음 섹션에서는 그 책임들에 대한 언급을 한다.

[편집] 키보드 통지 받기

키보드가 나타나거나 사라질때, 아이폰OS는 아래와 같은 알림을 등록된 옵저버로 보낸다

• UIKeyboardWillShowNotification
• UIKeyboardDidShowNotification
• UIKeyboardWillHideNotification
• UIKeyboardDidHideNotification

시스템은 키보드 알림을 처음 키보드가 보였을 때, 사라졌을 때, 키보드의 소유자가 변경되었을 때, 프로그램의 방위가 변경되었을 때 보낸다. 각각의 경우에, 시스템은 그에 맞는 적당한 메시지만을 보낸다. 예를 들어 키보드의 소유자가 변경되었다면 시스템은 현 소유자에게 UIKeyboardWillHideNotification 메시지를 보내지만 UIKeyboardDidHideNotification 메시지는 보내지 않는다. 왜냐하면 그 변화는 키보드가 사라지는것을 유발하지는 않기 때문이다. UIKeyboardWillHideNotification의 전달은 간단하게 현재 소유자에게 키보드의 포커스를 잃었다는것을 통지하는 방법이다. 방위의 변경은 will 과 did hide 통지를 모두 보낸다. 그러나 각 방위에 대한 키보드가 다르기 때문에 새로운 키보드를 출력하기 전에 기존의 키보드는 숨겨야 한다.

각 키보드 통지는 키보드의 크기와 위치에 관한 정보를 포함하고 있다. 키보드가 특정 크기와 특정 위치에 있는지등을 확인하지 않기 위해서 항상 이 통지에 있는 정보를 이용해야 한다. 키보드의 크기는 아이폰OS버전이 변경되거나, 다른 입력방식을 사용하는것에 따라 같아야 된다는 보장이 되지 않는다. 덧붙여 말하면 한 언어와 시스템을 위하더라도, 키보드의 dimension은 응용프로그램과 매우 밀접하게 관련되어 있다. 예를 들어 Figure 5-5 에서 가로 세로 모드에 따른 키보드의 상대 크기를 보여준다. 키보드 통지에 있는 정보를 이용해서 항상 정확한 현재 크기와 위치 정보를 가지고 있는지 확인해야 한다.

키보드 통지를 사용하는 한 이유는 키보드가 보여졌을때 정보의 위치를 재설정하기 위함이다. 이 시나리오의 처리를 어떻게 하는지 알고 싶다면 "Moving Content That is Located Under the Keyboard" 를 확인하라

[편집] 키보드의 출력

사용자가 뷰를 가볍게 두드리면, 시스템이 자동으로 최초 응답자로서의 뷰를 디자인한다. 이것이 수정할 수 있는 문맥을 포함한 뷰에서 일어났을 경우, 뷰는 그 문맥을 위해 편집세션을 초기화한다. 편집세션을 초기화할 때, 뷰는 시스템에 키보드를 보이도록 요청한다. 이미 보이고 있는게 아니라면…

만약 키보드가 이미 보이는 상태라면, 최초 응답상태로의 변화가 새롭게 선택된 뷰에서 재선택 되도록 키보드로부터 문자를 입력 받을 수도 있다.

뷰가 초기 응답상태를 취했을 때, 키보드가 자동으로 보여지기 때문에, 때때로 그것이 보여지도록 요구할 필요가 없다. 그러나 프로그래밍을 통해 뷰의 becomeFirstResponder 메소드를 호출하여 편집 가능한 텍스트 뷰로 키보드를 보일 수 있다. 이 메소드 호출은 목적 뷰를 최초 응답상태로 만들고, 마치 사용자가 뷰를 선택했었던 것처럼 바로 편집 과정을 시작한다.

만일 어플리케이션이 단일 스크린에서 여러 개의 텍스트 기반 뷰를 관리한다면, 뷰가 현재 최초 응답상태인가 추적하는 것이 용이하며 나중에 키보드를 선택해제 할 수 있게 한다.

[편집] 키보드 해제

자동으로 키보드를 보이는 것이 일반적이라 할지라도, 시스템은 자동으로 키보드를 선택해제 하지 않는다. 대신, 어플리케이션 응답을 통해 일정 시간 내에 키보드를 선택해제 한다.

대체로, 사용자 반응에 응답으로 이렇게 할 지 모른다. 예를 들어, 사용자가 키보드의 리턴 또는 완료 버튼을 누르거나, 어플리케이션 인터페이스에서 어떤 다른 버튼을 눌렀을 경우, 키보드를 선택해제 할지도 모른다.

키보드 선택해제를 위해, 현재 최초 응답상태인 텍스트기반 뷰의 resignFirstResponder 메소드를 호출한다. 텍스트 뷰는 최초 응답자 상태에서 해제되었을 때, 편집 세션을 종료한다. 그리고 그 사건에 대한 위임을 인지하고, 키보드를 선택해제 한다. 다시 말해, 만약 당신이 다양하게 호출된 myTextField(현재 최초 응답자로서의 UITextField 객체를 가리키는)를 가지고 있다면, 키보드 선택해제가 다음과 같이 간단하게 수행될 것이다.

[myTextField resignFirstResponder];

저 부분으로부터 모든 것이 텍스트 객체에 의해 자동적으로 조작되어진다.

[편집] 키보드로 인해 가려진 내용 이동

키보드 출력을 요청하면 시스템은 키보드를 화면 아래서부터 위치대로 사용자의 내용을 덮어서 슬라이드 시킨다. 왜냐하면 내용의 최 상단에 위치하여, 텍스트 객체를 수정하고자 하면 가장 위에 존재해야 가능하기 때문이다. 이런일이 생기면, 컨텐츠를 보이는 화면에 맞게 적응시켜야 한다.

컨텐츠를 적응시키는 것은 일반적으로 임시로 볼 수 있는 뷰의 크기를 리사이징 하는 것을 포함한다. 가장 간단한 방법으로는 텍스트 객체를 UIScrollView 객체에 포함시켜서 관리하는 방법이다. 키보드가 출력이 되면, 해야 할 전부는 단지 스크롤 뷰을 리사이즈 하는것일뿐이다. 게다가, UIKeyboardDidShowNotification에 응답하기 위해서 핸들러 메소드는 다음을 따라야 한다.

• 키보드의 사이즈를 얻는다
• 스크롤뷰의 높이에서 키보드의 높이를 뺀다
• 뷰 안의 텍스트필드를 스크롤한다.

Figure 5-6은 이와 같은 UIScrollView 객체안에서 text fields 들을 보여준다. 키보드가 나타나면 통지 핸들러 메소드에 의해 스크롤 뷰가 리사이징되고 사용자는 UIScrollView 내의 scrollRectTovisible:animated: 메소드를 이용해서 탭으로 스크롤이 가능하다.

Listing 5-1 은 받은 통지를 등록하는 코드와 핸들러 메소드를 보여준다. 이 코드는 스크롤 뷰를 관리하는 뷰 컨트롤러에 구현되어 있다. 또한 scrollView 변수는 스크롤 뷰 객체의 포인터이다. 각각의 핸들러 메소드는 키보드 크기를 받아 스크롤 뷰의 높이를 저장한다. 또한 keyboardWasShown: 메소드를 통해activeField에 저장되고 textFieldDidBeginEditing: 대리자에 의해 설정된 활성화된 텍스트필드의 사각형을 스크롤한다.

기 재시된 코드의 keyboardShown 변수는 키보드가 이미 보여지는지 아닌지에 대한 불린타입니다. 만약 인터페이스가 여러 텍스트 필드를 가지고 있다면 사용자는 그 사이를 간단하게 두르려 선택 할 수 있디. 그러나, 무슨일이 일어나는가 하면, 키보드는 사라지지 않고 시스템은 계속 UIKeyboardDidShowNotification 통지를 매 수정 할 때마다 보낸다. 이 키보드가 실제로 숨겨져 있는지 따라감으로서 이 코드는 한번이상 크기가 줄어드는것이 방지된다.

[편집] Drawing Text

추가적으로 텍스트 출력 및 수정을 위한 UIKit 클래스에 덧붙이면, iPhone OS에는 스크린상에 텍스트를 직접 그리는 여러가지 방법이 있다. 가장 쉽고 효율적인 방법은 UIKit 에 NSString을 추가로 사용하여 단순 문자열을 그리는 것이다. 이들에는 스크린상에 원하는곳에 여러 속성들을 이용하여 문자열을 그릴수 있는 메소드들이 포함된다. 또한 여기에는 실제 문자열을 그리기 전 그 내용을 명확하게 배치하거나 보여줄 수 있도록 도와주는 문자열 크기를 계산하는 메소드들도 역시 포함된다.

커스텀 문자열을 출력하길 원할 때는, NSString 을 이용한다. UIKit은 뷰에 문자열을 그리게끔 하는 기본 NSString 클래스의 확장이 포함되어 있다. These methods allow you to adjust the position of the rendered text precisely and blend it with the rest of your view’s content. The methods of this class also let you compute the bounding rectangle for your text in advance based on the desired font and style attributes. For information, see NSString UIKit Additions Reference.

그리기를 사용할때 폰트에 대해 더 제어하길 원한다면 Core Graphics 프레임워크의 함수들을 사용하면 된다. Core Graphics 프레임워크는 도형과 텍스트의 정확한 배치 및 그리기에 대한 메소드들을 제공한다. 이들에 대해 더 알고 싶으면 Quartz 2D Programming Guide 와 Core Graphics Framework Reference 를 참고하라

[편집] Files and Networking

[편집] File and Data Management

[편집] Networking

[편집] Multimedia Support

[편집] Using Sound in iPhone OS

[편집] Playing Video Files

[편집] Device Support

[편집] Accessing Accelerometer Events

[편집] Taking Pictures with the Camera

[편집] Picking a Photo from the Photo Library

[편집] Application Prefernces