iOS 응용프로그람작성지도서

Apple Inc.

©2011 Apple Inc.

All rights reserved.

이 발행물의 어떠한 부분도 검색체계에 복사, 저장할수 없으며 Apple Inc.의 사전허가없이 어떠한 형식이나 수단으로 기계적, 전자적, 복사, 녹음, 또는 기타에 의하여 전송할수 없다. 그러나 개별적 사용만을 위하여 개인콤퓨터에 문서를 저장할수 있으며 Apple 의 저작권정보가 포함되여 있는 개별적사용의 문서를 인쇄할수 있다.

Apple 로고는 Apple 의 등록상표이다.

이 문서에 서술된 기술에 대하여서는 아무런 면허나 명시 혹은 암시가 부여되지 않는다.

Apple 은 이 문서에 서술된 기술과 관련된 모든 지적재산권을 가진다. 이 문서는 Apple계렬의 콤퓨터들만을 위한 응용프로그람을 개발하는 응용프로그람개발자들을 지원하기 위한것이다.

Apple Inc.

1 Infinite Loop

Cupertino, CA 95014

408-996-1010

앱 스토는 Apple 의 서비스상표이다.

Apple 과 the Apple logo, AirPlay, Bonjour, Cocoa, Instruments, iPhone, iPod, iPod touch, iTunes, Keychain, Mac, Mac OS, Macintosh, Numbers, Objective-C, Sand, Xcode 는 미국과 다른 나라들에 등록된 Apple Inc.의 상표이다.

iPad 와 Retina 는 Apple Inc.의 상표이다.

iOS 는 미국과 다른 나라들에서 Cisco 의 상표,등록상표이며 허가하에 사용된다.

Intel 과 Intel Core 는 미국과 다른 나라들에 있는 Intel 본회사와 혹은 그 자회사의 등록상표이다.

OpenGL 은 Silicon Graphics Inc.의 등록상표이다.

Times 는 Linotype Library GmbH 에서 제공하는 Heidelberger Druckmaschinen AG 의 등록상표이다.

UNIX 는 The Open Group 의 등록상표이다.

Apple 이 이 문서를 검사하였지만 본 문서와 관련하여 그 어떠한 경우에도 품질, 정확성, 상품성, 상업성을명시적으로나 암시적으로 보증 또는 진술할수 없다.

따라서 이 문서는 있는 그대로 제공되며 독자는 품질과 정확성에 대한 위험부담을 가질수 있다.

Apple 은 어떠한 경우에도 이 문서의 결함 혹은 부정확으로 인한 직접, 간접, 특별, 부수적, 결과적 혹은 그에 대하여 알고 있다고 하여도 그 손해에 대한 책임을 지지 않는다.

우에서 명시된 보증과 교정은 독점적이며 다른 나라, 구두 또는 서면, 명시적 혹은 암시적을 대신한다.

Apple 판매자, 대리인, 직원은 이 보증과 관련하여 어떠한 수정, 확정, 추가를 할수 있는 권한이 없다.

여러 국가에서는 제외과 암시적보증의 제한, 파생적 혹은 부수적손해에 대한 책임에 대하여 허용하지 않으므로 우의 제한과 제외가 당신에게 적용되지 않을수도 있다.

이 보증은 당신에게 특정한 법적권리를 부여하고 국가마다 다른 권리를 가질수 있다.

차례

개론 iOS 응용프로그람개발에 대하여 9

At a glance 10

당신의 기초설계를 실현계획으로 번역 10

UIKit 가 응용프로그람의 핵심을 제공한다 10

응용프로그람은 전경과 배경이 다르게 동작하여야 한다 10

iCloud 는 당신의 자료모델과 UI 층의 설계에 작용한다 11

응용프로그람에는 특정한 몇개의 자원이 필요하다 11

많은 응용프로그람의 상태를 사용자정의할수 있다 11

응용프로그람은 성능을 위해 조정되여야 한다 11

iOS 환경이 많은 응용프로그람상태에 영향을 미친다 12

이 문서의 사용법 12

필요한것 12

참고 12

1 장 응용프로그람설계 기초 15

기초설계의 작성 15

기초적인 iOS 설계패턴과 기술에 대하여 배우기 15

기초설계를 실현계획으로 번역 16

응용프로그람의 창조처리를 시작 17

2 장 핵심응용프로그람의 객체들 21

응용프로그람의 핵심객체들 21

자료모델 24

사용자자료모델의 정의 24

핵심자료를 리용한 구조화자료모델의 정의 26

문서기초의 자료모델의 정의 27

사용자대면부 28

UIKit 보기를 리용한 대면부 설계 28

보기와 OpenGL ES 를 리용한 대면부 설계 29

응용프로그람 묶음 30

3 장 응용프로그람상태와 다중과제처리 35

응용프로그람의 상태변화에 대한 관리 35

응용프로그람 실행주기 37

새치기에 대한 응답 42

배경에로의 이동 43

전경에로 돌아가기 46

응용프로그람 중단 48

기본실행주기 49

배경실행과 다중과제처리 51

다중과제처리가 가능한가를 결정 51

배경에서 유한기간 작업을 실행 52

국부알림의 진행에 대한 일정짜기 53

장기실행배경과제의 실현 54

든든한 배경응용프로그람 58

배경실행의 중단 59

동시 및 보조 스레드 60

4 장 iCloud 저장창고

iCloud 응용프로그람의 설계고려사항 61

당신의 응용프로그람의 iCloud entitlement 를 설정 63

iCloud 문서저장창고의 리용 64

iCloud 문서저장창고를 사용할수 있는지를 검사 66

작업흐름에 파일제출기를 통합 66

iCloud 에서 파일과 등록부 조작 66

버젼충동에 대응하는 전락을 선택 67

하부구조에 검색엔진을 통합 68

파일이나 등록부의 전송상태를 결정 69

아직 다운되지 않은 파일에 대한 작업 70

iCloud 를 위한 사용자대면부의 갱신 70

자료기지련결과 관련한 iCloud 의 리용 71

iCloud 열쇠-값 자료창고의 리용 74

든든한 iCloud 응용프로그람 75

5 장 응용프로그람과 관련된 자원들 77

앱 스토 필수자원 77

정보속성목록파일 77

필요한 장치에 대한 성능을 결정 78

응용프로그람의 지원가능한 문서형식을 결정 80

응용프로그람 아이콘 81

응용프로그람 실행(표준)그림 83

서로 다른 방향의 실행그림 제공 84

장치특정의 실행그림 제공 85

사용자정의 url 구조에 대한 실행그림 제공 85

설정묶음 86

국부화된 자원파일 87

6 장 고급 응용프로그람 작성묘리 89

보편적인 응용프로그람의 창조 89

Info.plist 설정의 갱신 89

보기조종자와 보기의 실현 90

최신기호에 대한 실행시간검사를 추가 91

조건부코드경로의 창조를 위한 실행시간 검사의 리용 91

자원파일의 갱신 92

응용프로그람 사용자대면부의 상태를 보존 92

가로보기 방식으로 실행 93

첫 실행에서 응용프로그람특정의 자료파일을 설치 94

On-disk 암호화를 리용한 자료의 보호 94

VoIP 응용프로그람작성을 위한 기교 95

VoIP 사용을 위한 소케트의 설정 96

Keep-alive 처리기의 설치 97

응용프로그람의 음성쎄션의 설정 97

사용자환경을 개선하기 위한 Reachability 대면부의 리용 98

다른 응용프로그람과의 통화 98

사용자정의 URL 구조 실현 99

사용자정의 URL 구조의 등록 99

URL 요청에 대한 처리 100

건반의 보이기와 숨기기 104

화면잠금의 해제 104

7 장 성능조정 105

응용프로그람 백업을 보다 효률적으로 만들기 105

무엇이 백업되는가? 105

응용프로그람갱신시 저장된 파일 106

효률적인 기억기의 리용 106

적은 기억기에 대한 경고를 관찰 107

응용프로그람의 기억기사용량을 감소 107

알맞는 기억기 할당 108

작업을 주스레드로 이동 109

류동소수점수학에 대한 고려사항 109

전력소비를 감소 109

코드조정 111

파일접속시간을 개선 111

망코드에 대한 조정 112

효률적인 망리용을 위한 도움말 112

Wi-fi 의 리용 112

비행기모드에 대한 경고 113

부록 A iOS 환경 115

전용체계동작 115

가상기억기체계 115

자동수면시간측정기 115

다중과체처리 지원 116

보안 116

응용프로그람 쎈드박스 116

열쇠고리 자료 116

문서수정내역 19

그림, 표, 목록

2 장 핵심응용프로그람객체 21

그림 2-1 iOS 응용프로그람의 기본객체 22

그림 2-2 문서를 리용한 파일내용 관리 27

그림 2-3 보기객체를 리용한 대면부작성 29

그림 2-4 OpenGL ES 를 리용한 대면부작성 30

표 2-1 iOS 응용프로그람에서 객체들의 역할 22

표 2-2 기초구성체계에서의 자료클라스 24

표 2-3 표준응용프로그람 묶음 31

목록 2-1 사용자자료객체의 정의 25

3 장 응용프로그람 상태와 다중과제처리 35

그림 3-1 iOS 응용프로그람에서 상태변화 36

그림 3-2 전경에서 응용프로그람의 실행 38

그림 3-3 배경에서 응용프로그람의 실행 39

그림 3-4 경보에 기초한 새치기의 처리 42

그림 3-5 전경에서 배경에로의 이동 44

그림 3-6 배경에서 전경에로의 변환 46

그림 3-7 기본실행주기에서 사건처리 50

표 3-1 응용프로그람 상태 36

표 3-2 깨여있는 응용프로그람에 전달되는 알림 47

표 3-3 iOS 응용프로그람에서 사건의 기본형태 50

목록 3-1 iOS 응용프로그람에서 main 함수 40

목록 3-2 iOS 의 기존버젼들에서 배경지원에 대한 검사 52

목록 3-3 중단시간에서 배경작업의 시작 52

목록 3-4 경보알림의 시간표 53

4 장 iCloud 창고 61

그림 4-1 문서에 대한 변화를 iCloud 에로 전달 65

표 4-1 문서와 키-열쇠자료창고의 차이점 62

5 장 응용프로그람과 관련된 자원 77

그림 5-1 설정응용프로그람에 의하여 현시되는 사용자정의환경설정 86

표 5-1 UIRequiredDeviceCapabilities 열쇠를 위한 사전키 79

표 5-2 CFBundleIconFiles 열쇠에서 그림크기 82

표 5-3 표준실행그림치수 83

표 5-4 실행그림방향변환기 84

6 장 고급응용프로그람 작성묘리 89

그림 6-1 Info.plist 파일에서 사용자 URL 구조 정의 100

그림 6-2 URL 열기를 통한 응용프로그람 실행 101

그림 6-3 URL 열기를 통한 배경응용프로그람 깨우기 102

표 6-1 VoIP 사용을 위한 스트림대면부 환경설정 96

표 6-2 CFBundleURLTypes 속성의 열쇠와 자료값 99

목록 6-1 사용자구성에 기초한 URL 요청 처리 103

7 장 성능조정 105

표 7-1 기억기흔적을 줄이기 위한 묘리 107

표 7-2 기억기할당을 위한 묘리 108

부록 A iOS 환경 115

그림 A-1 iOS 에서 SandBox 등록부

소개

iOS 응용프로그람작성에 대하여

이 문서는 iOS 응용프로그람들을 만들기 위한 시작입니다. 여기서는 iOS 에 의해 제공되는 코드에 맞게 어떻게 코드를 작성하는가를 비릇하여 iOS 응용프로그람들의 기초적인 구성에 대하여 서술하여줍니다. 이 문서는 또한 실질적인 안내로 하여 설계 및 계획을 할때 더 좋은 선택을 하도록 하여주고 특성한 과제를 어떻게 취급하는가에 대한 더 구체적인 지식을 포함하는 iOS 개발도서에서의 다른 문서들에로 이끌어준다.

이 문서의 내용은 iPad, iPhone 과 iPod touch 를 비릇한 모든 종류의 iOS 장치들에서 실행되는 모든 iOS 응용프로그람들에 다 적용된다.

소개

iOS 응용프로그람작성에 대하여

At a Glance

임의의 새 응용프로그람의 첫 시작점은 만들어야 할 설계의 선택이나 어떻게 그 선택한것들을 적당한 실현에로 옮기겠는가에 대한 리해를 감정한다.

당신의 초기 생각을 실철 단계에로 옮기기

훌륭한 iOS 응용프로그람들은 좋은 생각으로부터 출반하지만 그 생각을 실천에로 옮기는것은 계획이 필요하다. 매 iOS 응용프로그람들은 설계형식에 크게 관련되며 그 설계형식들은 당신이 써야할 코드에 많이 영향을 미친다. 그러므로 코드를 하기전에 그 코드를 쓰는에 쓰이는 가능한 기교 및 기술들을 연구해봐야 한다. 그렇게 함으로서 많은 시간을 절약하고 실패를 줄인다.

UlKit 는 당신의 응용프로그람의 핵심을 제공한다.

iOS 응용프로그람 핵심 내부구조는 UlKit 프레임워크안에 있는 객체들로부터 만들어졌다. 프레임워크안에 있는 객체들은 사건들을 처리하고, 화면에 내용을 현시하며 그 밖의 체계들과 호상작용하는에 필요한 모든것을 제공한다. 그러므로 이 객체가 노는 역할과 기정 응용프로그람의 움직임을 어떻게 고치가를 리해하는것은 코드를 빨리 그리고 정확히 쓰는데 있어서 매우 중요하다.

응용프로그람들은 전경색 및 배경식에서 서로 다르게 작용해야 한다.

알림: iOS 응용프로그람 개발은 iOS SDK 가 설치된 Intel 기반용 마킨토시 콤퓨터를 필요로 한다.

관련 장: “응용프람 설계 기초”(15페지)

관련 장: “핵심 응용프로그람 객체들”(21페지)

iOS 장치는 여러 앱들을 동시에 실행시키지만 임의의 주어진 시간에 사용자가 주목하는 전경앱은 하나만 실행시킨다. 현재 전경앱은 사용자대면부를 현지하고 타치사건들에 응답하도록 되여있는 앱이다. 다른 앱들은 배경에 남으며 잠자기상태에 들어가지만 하지만 때때로 추가적인 코드를 실행시킨다. 전경으로부터 배경상태에로의 이행은 당신의 앱들의 움직임에 여러 측면을 변화시킨다.

소개

iOS 응용프로그람작성에 대하여

iCloud 는 당신의 자료모델 및 UI 층들의 설계에 영향을준다.

iCloud 는 서로다른 iOS 및 Mac OS X 장치들에서 실행되는 당신의 앱들의 여러 객체들속에서의 사용자자료교환을 하도록 하여준다. 당신의 앱들에로의 iCloud 지원의 결합은 당신이 어떻게 파일들을 관리하는가에 대한 많은 측면을 변경하는데 관계된다. 이것은 iCloud 에 있는 파일들이 당신의 앱들보다 더 많은데 접급가능하며 모든 파일 조작들은 자료의 파괴를 막기위해 동기화되여야 한다. 당신의 앱에 관계되고 어떻게 그의 자료를 현시하는가에 관계되므로 iCloud 는 또한 당신의 사용자 대면부 부분들의 변화를 필요로 한다.

앱들은 일부 특정 자원을 필요로 한다.

모든 iOS 앱들에 존재해야 되는 일부 자료들이 있다. 대부분 앱들은 앱의 내용을 현시하기위해 그림들과 음성들 그리고 다른 종류의 자원을 포함하지만 App 저장고는 또한 현시에 필요한 일부 특정 자원을 필요로 한다. 기것은 iOS 는 당신의 앱을 사용자들에게 현시하고 다른 부분 체계와 작용할때 여러가지 특정 자원들을 사용하기때문이다. 그러므로 이 자원들은 전만적 사용자 경험을 향상시키기 위해 존재하게 된다.

관련 장: “응용프로그람 상태 및 다중과제”(35페지)

관련 장: “iCloud 저장”(61 페지)

관련 장: “앱 관련 자원들”(77 페지)

많은 앱들의 행동들은 사용자의 요구에 따라 변경될수 있다.

모든 앱들의 핵심구성은 다 같을것이지만 높은 수준의 설계에 이른 당신의 앱을 만들방법은 얼마든지 있다. 이 방법들중 일부는 당신이 자료보호나 URL 처리와 같은 특정한 높은 수준의 기능들을 어떻게 추가하는가 하는것이다. 다른것들은 VolP응용프로그람들과 같은 특수한 형태의 앱들의 설계에 영향을 미친다.

응용프로그람들은 리행을 위해 반드시 조정되여야 한다.

훌륭한 응용프로그람들은 가장 적절한 리행을 위해 항상 조정된다. iOS응용프로그람들을 위해 리행이라는것은 그저 빠른 코드의 쓰기보다 더 많은 의미를 가진다. 그것은 때때로 더 좋은 코드의 쓰기도 의미하며 따라서 당신의 사용자 대면부가 사용자의 입력에 응답적이며, 당신의 앱이 의미있게 배터리수명을 낮추지는 않으며 당신의 앱이 다른 체계 자원들에 영향을 미치지 않게된다. 당신이 코드를 조정하기전에 최대한의 리윤을 제공하여주는 변경형태들에 대해 배워두어야 한다.

iOS 환경은 많은 앱들의 행동에 영향을 미친다.

iOS 환경에는 당신이 어떻게 설계하고 응용프로그람을 작성하는가에 대한 측면들이 있다. 왜냐면 iOS 는 모바일장치들을 위해 만들어졌으며 그것은 앱들의 보안을 제공하는데 더 적극적인 역할을 하기때문이다. 다른 체계행동들은 메모리가 어떻게 조정되는가로부터 하드웨어입력으로부터 어떻게 체계가 응답하는가에 이르기까지 모든것에 대해 영향을 미친다. 이 모든 체계행동들은 당신이 앱들을 설계하는 방식에 영향을 준다.

이 문서를 어떻게 사용하는가

관련 장: “더 앞선 응용프로그람의 기교들”(89 페지)

관련 장: “실행조정” (105 페지)

관련 장: “iOS 환경” (115 페지)

이 문서에서 당신의 앱의 핵심 객체들과 어떻게 그들이 같이 동작하는가에 대한 가장 중요한것에 대해 배우게 된다. 이 문서는 임의의 iOS 의 특정한 형태의 앱의 만들기에 대해 설명하여주지 않는다. 대신에 모든 iOS 앱들에 공동으로 제공하여주고 당신이 변경할수 있는 당신의 조건을 만족에 따라 구성에 대해 기본 부분들을 부각시켜주는 구성에 대해 제공하여준다. 가능한껏 이 문서는 또한 핵심 앱구성관련 특성들을 실현시키는 기교 방법을 대준다.

필요조건들

이 문서는 iOS 앱의 설계를 위한 매단계 중요한 지도서이다. 이 문서는 또한 당신의 앱을 실현시키는것과 관련한 많은 실천적인 측면들을 포함하고 있다. 그러나 이 책은 당신이 이미 iOS SDK 를 이미 설치했으며 개발환견을 이미 가동한것을 가정한다. 당신은 iOS응용프로그람을 작성할수 있기전에 그 단계들을 먼저 거쳐야 한다.

iOS 응용프로그람에 대해 처음이고 개발환견을 어떻게 구성하는가를 비릇하여 iOS개발공정에 대해 학습하고 싶다면 “App Development Overview”를 학습하시오.

함께 보기

앱설계와 관련하여 추가적으로 다음을 보시오

- 당신이 어떻게 iOS 앱을 설계하는가에 대해 배우기 위해 “iOS Human Interface Guidelines”를 읽어보시오. 이 책은 어떻게 당신의 앱의 사용자들을 위한 좋은 경험을 만드는가에 대한 요령 및 지도를 보장한다. 또한 그것은 iOS 앱들을 둘러싸는 기초 설계 원리를 알려준다.

- 당신이 iOS 앱들에서 무엇이 가능한가에 대해 확신하지 못한다면 “iOS Technology Overview”를 읽어보시오. 이 책은 당신이 그것들을 어디서 사영하는가에 대한 iOS 기술및 경우에 대해 배워준다. 이 책은 읽는것을 필요로 하지 않으며 당신의 과제단계마다 집체토의할때 좋은 참고서로 된다.

iOS 앱들을 만드는가에 대한 더 많은 지도서에 관심있다면 “Your First iOS App”에 대해 읽어보시오. 이 참고서는 간단한 앱을 어떻게 만들고 실행시키는가를 보여주는것을 비릇하여 처음부터 끝까지 앱 창조에 대해 배워준다.

응용프로그람설계기초

당신이 iOS 응용프로그람개발에 처음이라면 당신은 어디서부터 개발을 시작해야할지 걱정할것이다.

앱을 위해 초기생각을 궁리해낸후에 당신은 당신의 앱을 실현시키기 위한 실천계획에로 넘어가야 할것이다. 설계측면으로부터 당신은 당신의 생각을 실현시키기 위한 가장 좋은 행동을 위한 높은 수준의 결심들을 해야할것이다. 당신은 또한 개발을 쉽게 하기위해 초기 Xcode 과제를 설정하여야 한다.

당신이 앱들을 다 같이 개발하는데 처음이라면 기초개념들부터 잘 알아두어야 한다. 당신이 코드작성을 하고싶다면 그에 맞는 참고서들이 있으나 iOS 는 기초설계방식으로부터 만들어지는 체계이다. 그 방식들을 배우는데 시간을 투자하면 후에 대단히 도움이 될것이다

기초설계하기

응용프로그람을 설계하기위한 방법들은 많지만 많은 좋은 방법들은 하나도 코드를 쓰지 않는것이다.

좋은 응용프로그람은 좋은 생각으로부터 출발하며 그다음 기증이 더 많은 제품으로 확장하면 된다. 이미 설계단계에서 그것은 당신의 앱이 단지 무엇을 하는가를 리해하는데 도움을 준다. 당신의 생각을 실현하는데 필요한 높은 수준의 특징들을 적어나가시오. 사용자들이 필요한것이 무엇인가에 대한 생각에 기초하여 그 특징들에 권한을 부여하시오. iOS 그것에 대해 약간의 조사를 하여 그의 능력들을 리해하고 당신의 목적을 달성하기위해 그것들을 어떻게 리해할것인가에 대해 리해한다. 그리고 당신의 대면부설계를 태충 종이에 적어놓아 당신의 앱이 어떻게 보이는가를 시각화하시오

초기설계의 목적은 당신의 앱에 대한 일부 배우 중요한 질문들을 하는것이다. 특징들이나 당신의 대변부에 대한 개략적인 설계는 당신이 코드를 작성할때 후에라두 무엇이 필요할가에 대해 생각하여준다. 일부 문제에서 앱에서 현시되는 정보들을 자료객체들로 변환하여야 할 필요도 제기된다. 류사하게 당신의 앱의 보임면은 당신이 사용자대면부적인 코드를 실현시킬때 당힌이 반드시 만들어야 할 선택들에서 압도적인 영향을 준다. 종이에 초기 설계를 하는것은(콤퓨터에 하는것처럼) 무엇이 하기 쉬운가에 의하여 끝이 없는 질문들에 대처에 자유를 준다.

물론 당신의 초기설계를 하기전에 할수 있는거중 가장 중요한것은 “iOS Human Interface Guidelines”를 읽는것이다. 그 책은 당신의 초기설계를 하는데서 여러가지 전략들을 서술하여준다. 그것은 또한 iOS 에서 잘동작하게 앱들을 어떻게 만드는가에

대한 요령 및 지침를 포함한다. 당신은 또한 iOS Technology Overview 를 읽어 iOS 의 능력이 어떠하며 당신이 목적을 달성하기 위해 그능력들을 어떻게 리용할것인가를 리해하여야 한다.

기초 iOS 설계형식 및 기술에 대해 배우기

어떤 형태의 앱을 만들든 코드를 쓰기전에 반드시 알아야 할 일부 기초적인 설계형식과 기술들이 있다. iOS 에서체계프레임워크는 당신의 앱을 위한 없어서는 안될 내부구조를 제공하여주며 대부분의 경우들에서는기초를 이루는 하드웨어에로의 접근방법들을 제공한다. 교대로 프레임워크는 많은 특수한 설계형식을 사용하며 당신이 이미 그들과 친숙해졌다고 가정한다. 이 설계 형식들을 리해하는것은 그러므로 체계가 당신의 앱을 개발하는데 어떻게 도움울 줄수 있는가를 리해하기 위한 첫단계로 된다.

당신이 반드시 알아야 할 가장 중요한 설계 형식들:

- 모델보기 조종자: 이 설계형식은 당신의 앱의 전반적인 구조를 지배한다.- 대표단: 이 설계형식은 한 객체로부터 다른객체에로 자료를 전송하는것을 쉽게

하여준다- 목표행동: 이 설계형식은 단추들이나 조종체들과의 사용자 호상작용을 당신의

앱이 실행시킬수 있는 코드에로 전환하여준다- 블로크객체들: 당신은 콜백이나 비동기적인 코드를 리용할때 블로크들을

리용한다- 모래함: 모든 iOS 응용프로그람들은 체계 및 다른 앱들을 보호하기위해

모래함들에 위치하고 있다. 모래함의 구조는 당신의 앱파일들의 위치에 영향을 주며 자료복귀나 일부 앱관련 특징들을 위한 밀접한관계를 가진다.

정확하고 효과적인 기억기관리는 iOS 앱들을 위해 중요하다. iOS 앱들은 일반적으로 비교적인 탁상용콤퓨터에 비해 더 적은 사용가능한 기억기를 사용하기때문에 앱들은 필요없는 객체들을 지우고 객체들을 첫 위치에 창조하는것에 대해 적극적이여야 한다. 콥파일러의 “자동참고계수기”( ARC)특징을 을 사용하는 앱들은 많은 실행처벌들이 없이 이미 ‘쓰레기모으기’와 류사한 효과적인 메모리관리방법을 가지고 있다. ARC 를 사용하고 있지 않는다면 당신은 묭백히 객체를 얻기 및 석방하는데 대체 자체로 기억기 관리를 해야 한다.

때때로 혹은 당신의 코드에서 자체로 리용되는 다른 설계형식들도 있다. 설계 형식 및 기술들에 대한 완전한 보기를 위해 당신은 iOS 앱들을 창조하여 사용할것이며 “Cocoa Fundamentals Guide”를 보시오

초기 설계를 실천단계에로 넘기기

iOS 는 모든 앱들이 모델보기조종자설계형식을 리용하여 만들어졌다고 가정한다. 그러므로 이 목적을 달성하기 위한 첫 단계느 당신의 앱의 자료 및 보기부분들의 방법을 선택하는것이다.

자료 모델을 위한 기초적인 방법을 선택하기- 존재하는 자료모델코드: 당신이 이미 C언어로 작성된 자료모델코드를 가지고

있다면 그것을 직접 iOS 앱들에로 실현시킬수 있다. iOS 앱들은 Object-C 객체로 씌여졌기때문에 그들은 다른 C 기반 언어로 씌여진 코드들과두 맞는다. 물론 임의의 Object-C 코드가 아닌것을 위해 object-C 표지를 작성하는데서도 리득이다.

- 일반 객체 자료모델: 일반객체는 일반적으로 일부 간단한 자료(문자렬, 수자들, 날자, URL 들 등)를 그 자료를 관리하고 그의 지속성을 보장하는데 필요한 기업론리와 결합시킨다. 일반 객체들은 스칼라값들과 다른 객체들에로의 지적자들의 결합들을 보관할수 있다. 실례로 기초프레임워크는 많은 간단한 자료형들과 다른객체들의 집합들을 보관하기 위한 클라스들을 정의한다. 이 클라스들은 당신의 그 자체 일반 객체들에서 훨씬 더 쉽게 정의할수 있게 하여준다.

- 구조화된 자료모델: 당신의 자료가 고도로 구조화되였다면 그것은자료기지에로 그것들을 보관하도록 하여준다. 그것은 Core Data(또는 SQLite)를 리용하여 자료를 보관한다. Core Data 는 당신의 구조화된 자료를 위해 간단한 객체지향모델을 보장한다. 그것은 ‘본래되로 해놓기’나 iCloud 와 같은 일부 앞선 특징들을 위한 이미 만들어진 기증을 보장한다. (SQLite 파일들은 iCloud 에로의 련결에 쓸수 없다)

문서들을 위해 도움이 필요한가를 결정하기

문서는 응용프로그람의 내부기억기자료모델객체를 관리하며 디스크에서 해당한 자료파일이 보관된 기억공간을 조정한다. 일반적으로 문서는 사용자가 창조한 파일을 의미하지만 응용프로그람은 사용자가 만들지 않은 파일을 조작하기 위해 문서를 리용하기도 한다. 문서를 리용하는 큰 우점중의 하나는 UIDocument 클라스를 리용하여 iCloud 와 내부파일체계간의 련계를 쉽게 보장할수 있는것이다. UIDocument

클라스는 Core Data 를 리용하여 자료를 보관하는 응용프로그람들에 대해서도 이러한 기능을 제공한다.

두가지 사용자대면부설계방법이 있다.

블로크단위설계방식 – 사용자대면부를 설계하는데서 가장 쉬운 방법은 이미 있는 객체들을 조합하는 방식이다. 여기서 객체란 table, 단추, 입력창등과 같은 시각적인 요소들이다. 객체는 있는 그대로 리용할수도 있고 요구에 따라 바꿀수도 있다. 기정의 객체들과 사용자가 작성한 객체들을 조합하여 새로운 대면부를 구성할수 있다. 이러한 방식의 설계는 사용자들이 익숙한 대면부이며 빨리 만들수 있다는 우점이 있다.

OpenGL ES 에 기초한 방식 – 화면이 자주 바뀌거나 화면상에서 정교한 조작이 필요한 응용프로그람에서는 이 방식을 리용한다. 이 방식은 주로 오락프로그람이나 정교한 대면부조작이 필요한 프로그람들에서 리용된다.

응용프로그람작성 시작

계획작성이 끝나면 코드작성을 시작한다. iOS 프로그람개발경험이 없는 사람이라면 우선 개발을 위해 제공되는 Xcode틀거리에 대해 먼저 알아야 한다. 이 틀거리를 리용하면 응용프로그람작성을 훨씬 쉽고 빠르게 할수 있다.

Xcode 프로젝트를 작성할때에는 다음과 같은 질문들에 대해 견해가 있어야 한다.

프로그람의 기본 대면부형식은 무엇인가? 프로그람대면부에 따르는 여러가지 기초틀거리대면부들이 제공된다. 작성하려는 프로그람의 대면부형식에 따라 알맞는 틀거리를 선택하면 프로그람작성을 쉽게 할수 있다.

작성하려는 프로그람이 일반적인 응용프로그람인가 혹은 iPad 나 iPhone 만을 위한 프로그람인가? 일반적인 프로그람을 작성하기 위해서는 실행시에 iPad 나 iPhone 에 맞는 객체와 조종체들을 동적으로 선택할수 있어야 한다. 모든 iOS장치들에서 리용되게 하려면 일반적인 프로그람을 작성해야 하며 그러자면 모든 가동환경에 맞게 코드를 작성해야 한다. 이에 대해서는 “일반적인 응용프로그람작성”(89페지)에서 더 보기로 하겠다.

응용프로그람이 storyboards 를 리용하는가? Storyboards 는 대면부내의 객체들과 조종체들, 그들의 변화를 보여줌으로써 설계를 보다 쉽게 할수 있게 해준다. Storyboards 는 iOS 5 이상부터 지원되였으며 프로젝트를 새로

창조하면 기정으로 제공된다. 프로그람이 iOS 5 보다 낮은 판본에서 실행되여야 한다면 Storyboards 를 리용할수 없으며 nib 파일들을 리용해야 한다.

자료모델로 Core Data 를 사용하는가? 일부 응용프로그람들은 구조화된 자료모델에 제공되면서 Core Data 를 리용할수 있게 한다. Core Data 와 그의 우점에 대해서는 Core Data Programming Guide 에 서술되여 있다.

이제는 Xcode 를 리용하여 프로젝트파일들을 창조하고 코드를 작성한다.

1. 먼저 Xcode 를 태우고 iOS 개발팀을 구성한다. App Development Overview에는 개발팀을 구성하고 Xcode 환경을 설정하는데 대해 구체적으로 서술되여있다.

2. Xcode 프로젝트를 창조한다.3. 코드를 작성하기 전에 Xcode 프로젝트를 실행시켜본다. 프로그람을 iOS

모의장치에서 실행시킨다.모든 새로운 Xcode 프로젝트는 모든 기능이 갖춰진 프로그람을 제공한다. 응용프로그람은 storyboards 나 nib 파일들에 있는 기정의 객체들을 실행시켜 현시한다. 응용프로그람이 실행될수 있는것은 UIKit 에 의하여 제공되는 하부구조때문이다. 이 하부구조는 응용프로그람을 초기화하고 초기대면부파일을 적재하며 체계련결을 통해 사건처리를 진행한다.

4. 기초적인 코드작성새로운 프로그람을 작성할 때에는 우선 프로그람의 자료모델을 표현하는 클라스를 창조하는것으로부터 시작한다. 이 클라스들은 응용프로그람의 다른 부분들에 의존되는것이 아니며 프로그람작성에서 가장 처음으로 해야 할 일이다.다음으로 해야 할것은 사용자대면부설계이다. 대면부에 배치된 객체들을 통하여 대면부와 관련된 사건처리코드를 작성한다.응용프로그람이 iCloud 를 지원한다면 그를 위한 코드도 작성해야 한다.

5. 응용프로그람 상태변화를 위한 지원iOS 에서 프로그람의 상태는 언제 무엇을 할수 있는가를 결정한다. 응용프로그람의 상태는 높은 준위의 객체들에 의하여 관리되지만 그 결과는 다른 많은 개체들에 영향을 끼친다. 따라서 응용프로그람의 상태가 자료모델과 객체들에 어떤 영향을 끼치는가를 고려하여 코드를 작성해야 한다.

6. 프로그람에 사용되는 자원창조응용프로그람들에는 익숙한 사용자대면부를 만들기 위해 사용된 아이콘이나 화상들이 있을수 있다. 또한 훌륭한 응용프로그람들에서는 코드와 자료를

분리시키기 위해 자원파일들을 많이 사용한다. 이러한 방법으로 프로그람을 작성하면 대면부수정과 같은 같은 작업을 코드를 고치지 않고 쉽게 할수 있다.

7. 응용프로그람고유의 기능들을 추가한다.iOS 는 다매체, 화면현시, 게임내용, 지도, 위치추적등 다양한 기능을 관리하기 위한 많은 틀거리들을 제공한다.

8. 응용프로그람에 알맞는 여러가지 기초적인 조작들을 진행한다.모든 iOS 응용프로그람들은 최고의 성능을 위한 조정이 필요하다. 조정된 응용프로그람들은 기억기나 battery 수명과 같은 체계자원들을 효과적으로 리용함으로써 최고의 성능을 내게 된다.

9. 반복응용프로그람개발은 반복적인 작업이다. 새로운 기능을 추가할 때마다 앞의 단계들을 모두 혹은 부분적으로 반복해야 한다.

주요 응용프로그람객체들

UIKit 는 모든 응용프로그람의 하부구조를 지원하지만 프로그람고유의 기능을 제공하는것은 작성자가 만든 객체이다. 응용프로그람은 사건고리를 및 iOS 와의 기본적인 호상작용을 관리하는 UIKit 객체들로 이루어져있다. 응용프로그람을 작성하기 위해서는 클라스계승, delegation 을 비롯한 여러가지 기술들을 조합하여 UIKit 가 제공하는 기정의 기능들을 고쳐서 리용하여야 한다.

UIKit 객체를 고치는것과 함께 자체로 다른 객체들도 정의하여 리용하여야 한다. 또한 사용자대면부객체를 제공해야 하며 UIKit 객체가 제공하는 클라스들을 리용하여 대면부를 쉽게 구성할수 있다. 코드와 함께 프로그람에 리용되는 자원과 자료파일들도 제공해야 한다.

응용프로그람의 주요객체들

사용자가 프로그람을 실행시킬 때부터 프로그람실행이 끝날 때까지 UIKit틀거리는 프로그람의 중요한 처리들을 관리한다. 프로그람의 기본부분은 체계로부터 사건을 받아 처리부로 보내는 UIApplication 객체이다. 다른 UIKit클라스들도 프로그람실행을 관리하며 해당한 코드를 실행시켜 사건을 처리한다.

UIKit 객체들이 어떻게 동작하는가를 보기 위해서는 iOS 프로그람을 구성하는 객체들에 대해 먼저 리해해야 한다. 그림 2-1 은 iOS 응용프로그람들에서 공통적으로 리용되는 객체들을 보여주며 표 2-1 에서는 매 객체의 역할에 대한 설명을 주었다. 도표에서 보는바와 같이 iOS 응용프로그람은 MVC(model-view-controller)설계방식으로 구성되여 있다. 자료의 처리와 현시를 분리하여 처리한다. 이러한 분리처리방식은 현시내용을 요구에 따라 임의로 바꿀수 있게 하며 특히 일반적인 프로그람을 작성할때 매우 효과적이다.

그림 2-1 iOS 응용프로그람의 주요 객체들

표 2-1 iOS 응용프로그람에서 객체들의 기능

객체 설명UIApplication UIApplication클라스는 파생을 하지 않고 그대로 리용한다. 이

조종객체는 프로그람의 사건고리를 관리하며 프로그람의 다른 높은 준위의 처리들을 조정한다.

App delegate 객체

아 객체는 프로그람실행시에 UIApplicationMain 함수에 의하여 창조되는 객체이다. 이 객체의 주요기능은 프로그람의 상태전환을 조종하는것이다. 례를 들어 실행시 초기화와 배경으로의 전환등을 조종한다.iOS 5 이상부터는 다른 사건처리들에도 이 객체를 리용한다. Xcode 프로젝트틀거리에는 이 객체가 UIResponder클라스의 파생클라스로 선언되여 있다. UIApplication 객체가 사건을

처리하지 않는다면 app delegate 로 그 사건을 넘겨서 처리한다.문서와 자료모델객체

자료모델객체는 응용프로그람의 내용을 보관하며 이 내용은 프로그람에 따라 고유하다. 실례로 은행프로그람은 재정거래내용을 포함하는 자료기지를 보관하며 그림그리기 프로그람은 그림객체들과 그리기순서등의 자료를 보관한다.문서객체는 자료모델객체를 관리하기 위해 리용된다. 문서객체는 꼭 필요하지는 않지만 이를 리용하면 쉬운 방법으로 파일이나 패캐지에 있는 자료들을 묶어서 처리할수 있다.

현시조종객체 현시조종객체는 화면에 현시되는 내용을 관리하는 객체이다. 현시할 때에는 현시조종객체는 프로그람창문에 객체를 설치하는 방법으로 내용을 현시한다.UIViewController클라스는 모든 현시조종객체들의 기초클라스이다. 이 클라스는 내용을 적재, 현시, 회전시키기 위한 여러가지 기초적인 기능들을 제공한다.UIKit 와 다른 틀거리들에서는 표준체계대면부를 실현하기 위한 추가적인 기능들을 제공한다.

UIWindow객체

UIWindow 객체는 화면상의 현시내용을 조정한다. 대부분의 응용프로그람들은 한개의 창문을 가지고 있지만 필요에 따라 여러개의 창문을 가질수도 있다.프로그람의 내용을 변경시키기 위해서는 현시조종객체를 리용하여 해당한 창문의 현시내용을 변경시킨다. 창문자체를 전환할 필요는 없다.UIApplication 객체를 리용하여 사건들을 해당한 조종체들에 전달한다.

현시, 조종체와 층객체

보기와 조종체들은 응용프로그람의 현시내용들이다. 보기는 지정된 4각형 구역에 현시되며 그 구역안에서 일어나는 사건들을 처리한다. 조종체는 단추, 입력창등과 같이 사용자들에게 익숙한 대면부를 제공하기 위한 특수한 보기이다.UIKit틀거리는 여러가지 내용을 현시하기 위한 표준보기들을 제공한다. 이외에도 UIView클라스를 파생하여 새로운 보기를 창조할수도 있다.보기들과 조종체들을 리용하는것과 함께 Core Animation 층을 리용하여 여기에 등급을 줄수도 있다. 층객체들은 시각적인 내용을 가지고 있는 실제적인 자료객체들이다. 프로그람작성자는 요구에 따라 층객체를 새로 창조하여 복잡한 동화상이나 다른 정교한 시각적효과들을 실현시킬수 있다.

iOS 응용프로그람이 다른 프로그람들과 차이나는것은 다루는 자료내용(그에 따르는 론리)과 그를 현시하는 방법이다. UIKit 객체가 작성자가 원하는 기능을 그대로

제공하지는 않지만 이를 리용하면 프로그람을 보다 세련되게 작성할수 있다. 실례로 프로그람의 메쏘드들은 상태가 변할 때마다 그에 대해 통보를 하여 해당한 처리를 진행할수 있게 한다.

자료모델

자료모델은 자료구조와 실무론리로 구성되여 있다. 자료모델을 설계하는데서 사용자대면부를 무시할수는 없지만 자료모델객체가 특정한 보기나 현시조종체의 현시에 의존하도록 설계되여서는 안된다. 자료를 대면부현시와 관계없이 별도로 보관해야 프로그람작성을 표준적으로 할수 있다.

iOS틀거리는 자료모델을 정의하기 위한 기능들을 제공한다. 아래의 내용들은 특정한 형식의 자료모델을 정의할 때 리용되는 기술들에 대해 서술한것이다.

자용자정의 자료모델 정의

자료모델을 정의할 때 최대한 높은 준위의 자료를 표현할수 있는(그러나 체계가 제공하는 간단한 자료형들의 우점을 최대한 살려야 한다) 사용자정의객체를 창조한다. 틀거리는 문자렬, 수자, 그리고 여러가지 간단한 자료형들을 객체지향적으로 관리할수 있는 표준적인 객체들(표 2-2)을 제공한다. 이 객체들을 리용하면 새롭게 객체를 만드는데 비해 시간을 절약할수 있으며 많은 체계루틴들은 이러한 객체들을 리용하는것을 념두에 두고 있다.

표 2-2틀거리가 제공하는 자료크라스들

자료 클라스 설명문자렬형 NSString(NSMutableStrin

g)NSAttributedString (NSMutableAttributed String)

iOS 에서 문자렬은 유니코드에 기초하고 있다. 문자렬클라스들은 여러가지 방법으로 문자렬을 관리하기 위한 함수들을 제공한다. 두번째 클라스는 Core Text 와 함께 쓰이는 형식화된 문자렬에 대한 처리기능을 제공한다.

수자형 NSNumberNSDecimalNum berNSIndexPath

NSNumber클라스는 옹근수, 실수, 론리형과 문자형의 자료를 표현할수 있다.NSIndexPath클라스는 수자렬을 표현할수 있으며 리용되며 등급목록에서 다층선택을 표현하는데 많이 리용된다.

바이트형 NSData(NSMutableData)NSValue

바이트형식으로 자료를 표현하는데

리용된다. NSValue클라스는 점이나 4각형과 같은 공통적인 자료형들을 보관하는데 리용된다.

자료 클라스 설명자료와 시간

NSDateNSDateComponets

시간도장과 달력자료, 그래고 다른 시간과 관련된 정보를 보관하는데 자료객체를 리용한다

URL 들 NSURL 전통적으로 망자원을 참조하는데 리용되던것외에 iOS 에서 URL 들은 파일경로를 보관하는 좋은 방법이다. NSURL클라스는 파일관련속성들을 설정하거나 얻는데도 리용한다.

집합들 NSArray(NSMutableArray)NSDictionary(NSMutableDictionary)NSIndexSet(NSMutableIndexSet)NSOrderedSet(NSMutableOrderedSet)NSSet(NSMutableSet)

집합들은 그룹과 관련된 객체들을 하나로 묶는데 리용한다. 기초 프레임웍크는 여러가지 종류의 집합클라스들을 제공한다.

자료관련객체들외에 류사한 자료를 관리하기위해 iOS framework 가 리용하는 다른 종류의 자료들이 있다. 류사한 자료를 표현하기 위한 당신의 개별적인 객체에서 이러한 자료형식들을 리용면 좋다.

NSInteger/NSUInteger – 구조에 기초하여 옹근수의 크기를 결정하는 부호있는 옹근수와 부호없는 옹근수의 추출

NSRange – 일련의 부수적인 부분을 정의하는데 리용한다. 실례로 문자렬에서 일부 선택된 문자들을 정의하는데 리용할수 있다.

NSTimeInterval – 주어진 시간간격에서 (전체 혹은 부문) 초수 CGPoint – 위치를 정의하는 x 와 y 자리표 CGSize – 수직 , 수평구역을 정의하는 자리표값 CGRect – 직사각형구역을 정의하는 자리표값

물론 개별화된 객체를 정의할때 클라스수행에 스칼라값들을 직접 대입할수도 있다. 실제로 개별화된 자료객체들은 그의 성원변수로서 스칼라와 객체형식들은 포함할수

있다. 목록 2-1 은 그림의 집합을 위한 표본 클라스정의를 보여준다. 이 객체의 클라스는 그림의 정렬과 그 정렬에서 선택된 항목을 표현하기 위한 색인값목록을 포함한다. 클라스는 또한 집합의 제목을 위한 문자렬과 집합이 현재 편집가능한가를 표현하는 스칼라 Boolean 값을 포함하고 있다.

목록 2-1 개별화된 자료객체의 정의

@interface PictureCollection : NSObject {NSMutableOrderedSet* pictures;NSMutableIndexSet* selection;NSString* title;BOOL editable;

}@property (nonatomic, strong) NSString * title;@property (nonatomic, readonly) NSOrderedSet* pictures;// Method definitions...

@end

Note: 자료객체들을 정의할때 객체의 의뢰자들에게 로출되는 성원변수들을 위한 속성들을 정의할것을 권거한다. 당신의 클리스실현에 이러한 속성들을 정의함으로서 당신이 필요한 속성들에 대한 접근방법들을 창조한다. 하여 객체관계가 정확히 유지되며 이러한 객체들을 공개되지 않는다.

당신의 개별화된 객체에서 어떻게 취소조작들이 어떻게 취급되겠는지 고려하여야 한다. 취소를 지원한다는것은 당신의 객체에 한 변경들을 깨끗하게 되돌려놓는다는것이다. 만약 당신의 객체가 복잡한 사업 론리를 구현하고 있다면 이러한 론리가 쉽게 취소될수 있도록 하여야 한다. 여기에 개별회된 객체에서 취소조작을 실현하기 위한 여러 비결들이 있다.

객체에 대한 변경이 대칭되도록 할수 있는 Method 들을 정의하라. 실례로 항목을 추가하기 위한 Method 를 정의한다면 류사한 방법으로 항목을 삭제하기 위한 Method 를 정의해야 한다.

성원변수값들을 변경시키기 위해 리용하는 Code 에서 기업론리를 추출하라. 다단계 행동들에 대해서는 단계들을 묶기 위해서 현재 NSUndoManager

객체를 리용하라.

당신의 app 에서 undo 조작을 어떻게 실현하는지 더 알기 위해서는 Undo Architecture 를 보라. 기초적인 framework 의 클라스들에 대한 정보는 Funndation Framework Reference 에서 볼수 있다.

핵심 자료를 리용한 구조화된 자료 모델 정의

핵심자료는 schema-driven 객체 크라프 관리와 완고한 framework 다. 근본적으로 핵심자료들은 모델객체(model-view-controller 설계 pattern)를 파일에 보관하고 또 파일에서 불러내는데 리용한다. 이것은 Archiving 과 비슷한 개념이나 핵심자료는 그보다 많은것들을 제공한다.

핵심자료는 당신의 모델객체에 대한 보든 변경을 관리할수 있는 하부구조를 제공한다. 이것은 당신에게 undo, redo 와 객체들사이 호상관계를 관리할수 있는 자동적인 지원을 제공한다.

또한 임의의 주어진 시간안에 Memory 에서 모델객체의 부분을 유지하도록 하며 이러한 기능은 iOS app 들에서 아주 중요하다.

또한 모델객체를 설명하기 위한 schema 를 리용한다. GUI 기반의 편집기에서 그들간의 관계를 포함하여 모델클라스들의 중요한 기능들을 정의한다. 기정값괴 속성값 유효화를 포함하여 많은 기초기능을 무상으로 제공한다.

객체들에 대한 서로 다른 종류의 편집들을 관리하도록 한다. 이러한 기능은 실례로 당신이 한 사용자가 다른 사용자에게 영향을 주지 않게 편집하도록 한다.

자료저장 versioning 과 migration 을 위한 하부구조를 제공한다. 하여 사용자의 파일을 쉽게 새 판본으로 개량할수 있다.

자료를 iCloud 에 저장하고 여러 장치에서 호출할수 있다.

핵심자료에 대한 자료를 Core Data Programming Guide 에서 찾을수 있다.

문서기반자료모델 정의

문서기반의 자료모델은 앱들에 의하여 디스크에 씌여지는 파일들을 관리하는데 효과적이다. 이러한 자료모델형식들에서 디스크에서 하나의 파일을 나타내는 문서객체를 리용한다. 이러한 문서객 체는 파일 내용 읽기/

쓰기, 그리고 화면에 문서의 내용을 현시하기 위한 app 보기 조종자를 관리한다. 실례로 본문파일을 창조하고 관리하는 app 는 개별적인 파일에 대해서 개별적인 문서객체를 리용한다. 하지만 파일에 의해서 지원되는 개개의 app 자료를 위해서 문서를 리용할수 있다.

그림 2-2 는 문서, 파일, 그리고 app 자료모델에서 객체들사이 호상 관계를 보여준다. 일부 례외들을 제외하고는 매개 문서들은 self-contained 되였으며 다른 문서들과 직접 연관되지 않는다. 문서는 하나의 파일을 관리하며 파일에서 찾은 자료에 대한 기억기상태의 표현을 창조한다. 매개 파일의 내용이 유일하기 때문에 매개 문서와 련결된 자료구조들도 유일하다.

그림 2-2 파일의 내용을 관리하기 위한 문서 리용

iOS app 에서 문서객체를 실현하기 위해서는 UIDocument클라스를 리용해야 한다. 이 클라스는 문서에서 파일관리축면을 다루기 위한 하부구조를 제공한다. UIDocument 클라스의 다른 우점은

일정한 시간내에 문서의 내용을 자동보관한다. iCloud 에서 문서를 위한 필요한 파일자리표를 조종한다. 판본충돌을 막기위한 hook 를 제공한다.

undo 행동을 제공한다.

App 문서에 필요한 특정한 행동을 실현하기 위해서는 UIDocument 의 subclass 를 만들어야 한다. UIDocument 를 리용한 문서기초의 app 실현을 위한 정보는 Document-Based Application Programming Guide for iOS에서 찾을수 있다.

사용자 대면부

매개의 iOS app 는 그 내용을 표현하기 위한 적어도 하나의 창문과 하나의 보기를 가지고 있다. 창문을 내용을 현시하기 위한 구역을 제공하며 UIWindow클라스객체이다. 보기는 내용의 현시를 관리하기위해 리용되며 UIView클라스의 객체이다. 보기객체들을 리용하여 만드는 대면부들에 대해서는 app 의 창문이 자연히 다중보기객체들을 포함하고 있다. OpenGL ES 를 리용하여 만들어진 대면부들에 대해서는 특별히 하나의 보기를 가지고 있으며 내용을 표현하기 위해서 그 보기를 리용한다.

보기조종자들은 app 사용자대면부에서 아주 중요한 역할을 수행한다. 보기조종자는 UIViewController클라스 객체이며 한묶음의 보기들과 그 보기들사이의 호상관계를 관리한다. iOS app 들은 내용을 현시하기위한 제한된 량의 공간을 가지고 있기 때문에 보기조종자들을 하나의 보기조종자 보기를 다른 보기조종자의 보기로 바꾸기 위한 하부구조를 제공한다. 그러므로 보기조종자들은 한 형식의 내용을 다른 형식으로 바꾸기 위한 방법을 제공한다.

당신은 항상 보기조종자를 self-contained 객체로 생각하여야 한다. 보기의 창조과 해체를 조종하며 화면에서 보기들의 표현, app 에서 보기와 다른 객체의 호상련관을 조종한다.

UIKit 보기들을 리용한 대면부 만들기

현시하기 위해서 UIKit 보기를 리용하는 app 을 만들기 쉽다. 왜냐하면 기초 대면부를 빨리 조립할수 있기 때문이다. UIKit framework 는 자료를 표현하고 관리하기 위한 많은 서로다른 형식들을 제공한다. 보기의 특별한 형태인 조종체들은 사용자가 어떤 행동을 취할때 개별화된 코드를 실행하기

위한 내장된 방법론을 제공한다. 실례로 단추를 누르면 그에 해당한 method가 호출된다.

대면부에 기초한 UIKit 의 우점은 XCode 에 있는 시각적인 대면부 편집기인 대면부 Builder 로 도식적으로 조립할수 있다는 것이다. 대면부 Builder 는 대면부를 만드는데 필요한 표준 보기, 조종체 드리고 다른 객체들의 서고를 제공한다. 서고에서 이러한 객체들을 끌어다 작업구역에 놓고 당신이 원하는 대로 배치하면 된다. 그리고 storyboard 나 nib 파일에 보관하기 전에 inspector 를 리용하여 객체들을 형성하면 된다. 도식적으로 대면부를 만드는과정은 그즉시 결과를 볼수 있는 동등한 코드보다 훨씬 빠르며 app 를 구성하고 실행하지 않아도 된다.

Note: 또한 개별화된 보기들을 UIKit 보기계층도에 포함할수도 있다. 개별화된 보기는 UIView클라스의 부분클라스로서 모든 그리기와 사건처리과제를 자체로 조종할수 있다. 개별화된 보기를 창조하고 그것을 UIKit 보기계층도에 포함시키는 방법에 대한 정보는 View Programming Guide for iOS 에서 볼수 있다.

그림 2-3 은 보기 객체를 리용하여 대면부가 구성된 app 의 기초구조를 보여준다. 이 실례에서 기본 보기는 창문의 보기구역을 나타내며 하나의 하얀 바탕화면을 제공한다. 기본보기는 또한 세개의 부분보기를 가지고 있다. 그림보기, 문서보기 그리고 단추. 이러한 부분보기들은 사용자에게 내용을 보여주고 호상작용에 응답하기 위해서 리용된다. 이 계층도에 있는 모든 보기들은 하나의 보기조종자에 의해서 조종된다.

그림 2-3 보기객체를 리용한 대면부구성

이 전통적인 보기기반의 app 에서 보기조종자를 리용하여 onscreen 보기를 조종한다. App 는 언제나 화면에 내용을 현시하도록 조종하는 하나의 보기조종자를 가지고 있다. 그 보기조종자는 내용보기를 가지고 있는데 이 내용보기는 다른 보기들을 포함할수 있다. 일부 보기조종자들은 다른 보기조종자에 의해 제공된 내용을 위한 용기로서 동작할수도 있다. 실례로 split 보기조종자는 두개의 보기조종자로부터 받은 자료를 하나하나(side by side)씩 현시한다. 보기조종자들이 보기관리에서 중요한 역할을 하기 때문에 View Controller Programming Guide for iOS 를 보면서 어떻게 그것들이 동작하며 어떤 우점이 있는지 리해하여야 한다. app 에서 보기들과 그들의 역할을 알기 위해서는 View Programming Guide for iOS 를 보라

보기들과 OpenGL ES 를 리용한 대면부 구성

높은 frame rate 와 정교한 그리기 능력을 필요로 하는 게임이나 다른 app들은 OpenGL ES 를 위해 틀별히 제작된 view 를 자기의 보기계층도에 추가할수 있다. 간단한 종류의 OpenGL ES app 는 OpenGL ES 그리기를 위한창문객체와 하나의 보기를 포함하며 그 내용의 현시와 회전을 위한 하나의 보기조종자를 가지고 있다. 보다 정교한 app 들은 OpenGL ES 와 UIKIt 보기를 둘다 대면부에 실현할수 있다.

그림 2-4 는 대면부를 그리기 위해서 하나의 OpenGL ES 를 리용하는 app 구조를 보여준다. UIKit 보기와 달리 OpenGL ES 보기는 보기기반으 app에서 리용되던 표준층대신에 서로다른 종류의 층객체(CAEAGLLayer 객체)에 의하여 구성되였다. CAEAGLLayer 객체는 OpenGL ES 가 표현할수 있는 그리기구역을 제공한다. 그리기 환경을 관리하기 위해서 app 는 또한 EAGLContext 객체를 창조하여 보기에 그 객체를 보관하여 찾아보기 쉽게 하였다.

그림 2-4 OpenGL ES 를 리용한 대면부작성

app 에서 어떻게 OpenGL ES 를 리용하겠는지에 대해서는 OpenGL ES Programming Guide for iOS 를 참고하라.

App 묶음

iOS app 를 만들때 XCode 는 그것을 묶음으로 포장한다. 여기서 묶음이란 서로 련관된 자료들을 하나로 묶어놓은 파일체계에서 등록부이다. iOS App묶음은 실행파일과 아이콘, 그림 파일, 지역화된 내용들을 비릇한 보조자원파일들을 포함한다. 표 2-3 은 전통적인 iOS app 묶음내용을 표현하며 표명하기 위한 목적으로 MyApp 라고 부른다. 이 실례는 설명적인 목적밖에는 없다. 이 표에 있는 일부 파일들은 app 묶음에 없을수도 있다.

파일 실례 설명App실행가능한 파일

MyApp 실행파일은 app 의 번역된 코드를 포함하고 있다. App 의 실행파일은 .app 확장자를 제외하고는 이름이 같다.꼭 필요한 파일이다.

정보속성목록파일

Info.plist Info.plist 파일은 app 에 대한 조작자료를 포함한다. 체계는 이 파일을 리용하여 어떻게 app 와 호상작용하겠는지 결정한다.꼭 필요한 파일이며 Info.plist 로 되여야 한다. 구체적인 정보는 그림 6-1 에서 참고하시오

App 아이콘 Icon.pngIcon@2x.pngIcon – Small.pngIcon – Small@2x.png

App 의 아이콘은 Home 창에서 app의 표현을 위하여 리용된다. 다른 아이콘들은 체계내에서 적당한 목적에 리용된다. @2x 가 붙은 아이콘들은 Retina 화면이 있는 장치들을 위해서이다.app 아이콘은 꼭 필요하며 구체적인 정보는 App Icons(81페지)를 참고하라.

Launch Images

Default.pngDefault – Portrait.pngDefault – Landscape.png

체계는 이 파일들을 app 가 실행될때 일시적인 바탕화면으로 사용한다. 이 그림은 app 가 사용자대면부를 현시할수 있을때 지워진다.적어도 하나의 실행그림이 필요하다. 실행그림을 어떻게 지적하는가에 대해서는 App Launch(Default) Images”(83페지)를 참고하라.

StoryBoard files(or

MainBoard.storyboard

Storyboard 는 app 가 화면에 현시하는 보기와 보기조종자를

nib files) 가지고 있다. storyboard 에서 보기는 그것을 표현하는 보기조종자에 의하여 조직된다. Storyboard 는 또한 어떤 보기로 부터 다른 보기로의 변화(또는 segues)를 나타낸다.기본 storyboard 의 이름은 프로젝트를 창조할때 XCode 에 의하여 설정된다. 이 이름은 Info.plist 의 NSMainStoryboardFile 열쇠를 다른 값을 대응하여 바꿀수 있다. storyboard 대신에 nib 를 리용하는 app 들은 NSMainStoryboardFile 열쇠를 NSMainNibFile 열쇠로 변경하고 그것을 리용하여 이름을 바꾼다.Storyboard(혹은 nib)를 리용하는것은 필요하지는 않지만 좋다.

특변한 분포 아이콘

iTunesArtWork 특별히 App 를 분포할때는 512*512화소판본의 app 아이콘을 포함해야 한다. 이 아이콘은 일반적으로 app store 에서 iTune 련결에 제공한것으로부터 제공된다. 하지만 특별히 분포되는 app 들은 app store 를 거치지 않기 때문에 이 아이콘은 app 묶음에 있어야 한다. iTunes 는 이 아이콘은 리용하여 당신의 app 을 표현한다. (만약 당신이 이러한 방법을 쓴다면 지정한 파일은 app sotre 에 출시한 것과 같아야 한다. )이 파일의 이름은 iTunesArtwork여야 하며 파일확장자를 포함하지 말아야 한다. 이 파일은 특별히 분포되는 app 에 필요하며 다른경우에는 중요치 않다.

설정묶음 Settings.bundle 만약 당신이 설정 app 를 리용하여

선호하는 개별화된 app 를 출시한다면 설정묶음을 포함해야 한다.이 묶음은 속성목록자료와 app의 preference 를 정의하는 자원파일들을 포함한다. 설정 app 는 app 에 필요한 대면부성원들을 조립하기 위해서 이 묶음에 있는 정보를 리용한다.이 묶음은 꼭 필요하지 않다. 보다 구체적인 정보는 Preference and settings Programming Guide 를 참고하라.

비극부화된 자원파일들

sun.pngmydata.plist

비극부화된 자원들은 app 가 리용하는 그림, 음성파일, 도영상과 개별화된 자료 파일을 포함한다. 이 파일들은 app 묶음의 꼭대기에 배치되여야 한다.

극부화된 자원을 위한 보조등록부

en.lprojfr.lprojes.lproj

극부화된 자원들은 language-specific 프로젝트등록부에 배치되여야 하며 ISO 639-1 언어략자를 포함하는 이름들은 .lproj뒷붙이를 가진다.(실례로 en.lproj, fr.lproj, es.lproj 등록부들은 영어, 프랑스어, 에스빠냐어에 대한 극부화된 자원을 포함한다.)iOS app 는 국제화되여야 하며 지원하는 언어들에 대하여 .lproj등록부를 포함해야 한다. 또한 극부화된 판본을 제공하기 위해서는 app 아이콘, 실행그림, 설정아이콘을 language-specific 프로젝트 등록부에 배치하여야 한다.구체적인 정보는 Localized Resource Files(87페지)를 참조하라.

코드에서 NSBundle 객체를 리용하여 app 자원에 접근한다.

1. NSBundle 의 mainBundle 함수를 리용하여 app 의 기본묶음을 얻는다.

2. 묶음객체의 함수를 리용하여 원하는 자원파일의 위치를 얻는다.3. 파일을 열고(접근) 리용한다.

pathForResource:ofType:함수는 NSBundles 함수들중의 하나로서 자원파일의 위치를 검색하는데 리용할수 있다. 아래의 실례는 어떻게 sun.png 파일을 찾으며 화상객체를 창조하는가를 보여준다. 첫행은 bundle 에서 화상파일의 위치를 얻는다. 두번째행은 그 경로에 있는 파일의 내용을 리용하여 UIImage 객체를 창조한다.

NSString* imagePath = [[NSBundle mainBundle] pathForResource:@"sun" ofType:@"png"];

UIImage* sunImage = [[UIImage alloc] initWithContentsOfFile:imagePath];

요점: Core Foundation 는 또한 bundle 에 접근하기 위한 루틴을 제공한다. 응용프로그람의 기본 bundle 의 CFBundleRef opaque 형을얻으려면CFBundleGetMainBundle 함수를 사용한다. 그리고 다른 bundle 관련 Core Foundation 함수들을 리용하여자원파일을 찾을수 있다.

응용프로그람에서 자원에 어떻게 접근하고 리용하는가에 대하여 더 자세한 정보를 얻으려면 Resource Programming Guide 를 참고할것.

IOS 응용프로그람의 구조에 대하여 더 자세한 정보를 얻으려면 Bundle Programming Guide 를 참고할것.

응용프로그람의 상태와 다중과제처리iOS 응용프로그람에 있어서 그것이 전경에서 실행되는가 아니면 배경으로 실행되는가를 아는것이 아주 중요하다. iOS 장치들에서 자원이 더욱 제한되여 있기 때문에 배경과 전경에서 서로 다르게 동작하여야 한다. 조작체계는 또한 바테리수명을 향상시키며 전경응용프로그람에서의 사용자의 경험을 증가시키기 위하여 배경에서 응요프로그람이 할수 있는 기능을 제한한다. 조작체계는 전경과 배경으로 응용프로그람이 절환할 때 그 상태를 통지하여 준다. 이 통보들을 처리하여 응용프로그람의 상태를 변경시킬수 있다.

응용프로그람이 전경에 있는 동안 체계는 touch 사건을 보내 처리하게 한다. UIKit하부구조는 사용자정의된 객체에 거의 모든 사건을 전달하는 일을 한다. 개발자가 해야할 일은 적합한 객체들의 메쏘드들을 재정의하여 이 사건들을 처리하도록 하는것이다. 조종체들을 위하여 UIKit 는 touch 사건들을 자체로 처리하며 본문칸의 값이 변경되는것과 같은 흥미있는 사건이 일어날 때만 사용자가 추가한 코드를 처리하게 하여 개발자가 할일을 단순하게 한다.

응용프로그람을 개발할 때 아래의 지표를 따를것.

(필요) 일어나는 상태절환에 적합하게 응답하여야 한다. 이 절환을 적합하게 처리하지 않는것은 자료손실 및 잘못된 사용자 경험을 초래할수 있다. 상태절환에 어떻게 응답하겠는가에 대한 요약을 참고하려면 "응용프로그람상태변경관리"(35페지)를 참고할것.

(필요)배경으로 이동할 때 응용프로그람이 정확히 상태를 설정하도록 하여야 한다. 응용프로그람이 배경으로 이동할때 어떻게 할것인가에 대하여 참고하려면 "책임적인 배경 응용프로그람 작성"(58페지)를 참고 할것.

(권고) 보고체계가 응용프로그람이 필요로 하는것들을 변경시키는 통보들을 등록하여야 한다. 응용프로그람이 정지되면 체계는 중요한 통보들을 대기렬에 넣고 응용프로그람이 재개된다음에 전달한다. 응용프로그람들은 이 통보들을 사용하여 원활한 실행에로의 상태이행을 할수 있도록 하여야 한다. 구체적인 정보는 "Wakeup 시간에 대기렬의 통보를 처리하기"(47페지)에서 참고할것.

(생략가능) 만일 응용프로그람이 배경에서 실지로 해야 할 일이 있다면 체계에 문의하여 적합한 허용을 받아 계속 실행하여야 한다. 리용할수 있는 배경처리 형식과 그것을 허용받기 위한 요청을 어떻게 할것인가에 대한 구체적인 정보는 "배경에서 실행 및 다중과제처리"(51페지)를 참고할것.

응용프로그람 상태변경관리주어진 임의의 순간에 응용프로그람은 표 3-1 에 라렬된 상태들중 하나를 가지게 된다. 체계는 발생하는 사건들에 호응하여 응요프로그람을 어느 한상태에서 다른 상태로 이동한다. 실례로 사용자가 home 단추를 누르면 전화가 들어오거나 다른 여러 새치기가 발생할수 있으며 이에 따라 현재 실행중인 응용프로그람의 상태가 변경된다. 그림 3-1 은 응용프로그람이 상태이행경로를 보여준다.

표 3-1 응용프로그람의 상태

Not running 응요프로그람이 실행되여 있지 않거나 실행되다가 체계에 의해 종결된 상태.

Inactive 응용프로그람이 전경에서 실행되거 있지만 사건을 받지 못하는 상태(다른 코드를 실행할수는 있다.)응용프로그람은 일반적으로 다른 상태로 이행하는 과정에 잠시 이상태에 있게 된다. Inactive 에 있게 되는 시간은 사용자가 화면을 잠그거나 들어오는 전화나 SMS 문자와 같이 체계가 사용자가 어떤 사건에 응답하도록 재촉할 때 이다.

Active 응용프로그람이 전경에서 실행되며 사건은 접수하는 상태이다. 전경에 있는 프로그람이 가지는 표준방식이다.

Background 응용프로그람이 배경에서 코드를 실행하는 상태이다. 거의 모든 응용프로그람들이 정지상태로 되는 과정에 잠시 이 상태에 있게 된다. 또한 추가로 실행시간을 요구하는 응용프로그람이 한동안 이 상태에 있기도 한다. 이밖에 Inactive 대신에 배경으로 직접 들어가는 응용프로그람이 이 상태에 있기도 한다. 배경에서 어떻게 코드를 실행하는가에 대한 구체적인 정보는 "배경에서 실행 및 다중과제처리" (51페지)를 참고할것

Suspended 배경에 있으면서 코드를 실행하지 않는상태이다. 체계는 자동적으로 응용프로그람들을 이 상태에로 이동하며 사전에 통보는 하지 않는다. 정지상태에 있게 되면 기억기에 응용프로그람이 남아 있지만 코드는 실행하지 않는다. 기억기부족상태가 오면 체계는 정지상태에 있는 응용프로그람들을 통보없이 소제하여 전경에 있는 응용프로그람에 필요한 기억기를 보장한다.

요점: iOS 3.2 와 그 이전 판본들에서 동작하는 응용프로그람들은 background 나 suspended 상태에 들어가지 않는다. 그리고 일부 장치들은 iOS 4 에서 실행되여도 다중과제처리나 배경실행을 전혀 지원하지 않는다. 이런 장치들에서 실행되는 응용프로그람들 역시 background 나 suspended 상태에 들어가지 않는다. 대신에 전경에서 떠나면 프로그람은 완료된다.

거의 모든 상태이행은 응용프로그람의 해당한 위탁객체의 메쏘드호출을 통하여 일어난다.

이 메쏘드들을 정확한 방식으로 상태변경에 응답할수 있도록 기회를 제공한다. 아래에 이 메쏘드들과 함께 사용방법요점을 서술하였다.

application:didFinishLaunchingWithOptions: 이 메쏘드에는 실행시 처음으로 실행할 코드를 추가한다.

applicationDidBecomeActive:이 메쏘드에는 전경응용프로그람으로 실행준비를 하기 위한 코드를 추가한다.

applicationWillResignActive: 이 메쏘드는 응용프로그람이 전경상태에서 다른 상태로 이행하고 있다는것을 알려준다. 이 메쏘드를 리용하여 응용프로그람을 정지상태에 놓는다.

applicationDidEnterBackground: 응용프로그람이 배경에 들어 왔으며 임의의 시간에 정지상태에 들어갈수 있다는것을 알려준다.

applicationWillEnterForeground:응용프로그람이 배경에서 나와 전경으로 들어오려고 한다는것을 통지한다. 그러나 아직 능동(active)상태는 아니다.

applicationWillTerminate:응용프로그람이 완료된다는것을 통지한다. 이 메쏘드는 응용프로그람이 정지상태에 있을 때에는 호출되지 않는다.

응용프로그람 실행주기응용프로그람이 실행될 때 비능동(inactive)상태를 잠시 거쳐서 비실행상테에서 능동상태 또는 배경으로 이행한다. 응용프로그람의 실행주기의 한 부분으로서 체계는 응용프로그람을 위한 프로세스와 기본 스레드를 창조하고 응용프로그람의 기본 main함수를 호출한다. Xcode 프로젝트와 함께 오는 기정 main 함수는 즉시 조종권을 UIKit 기틀에로 넘기며 이것은 거의 모든 초기화과정을 거치고 실행을 준비한다. 그림 3-2 는 호출되는 위탁메쏘드를 포함하여 응용프로그람이 전경에로 실행될 때 일어나는 사건순서들을 렬거하였다.

만일 응용프로그람들이 배경상태에로 실행되여 배경상태의 사건들을 처리하려 한다면 그림 3-3 에서 보여준것처럼 실행주기는 조금 달라지게 된다. 기본 차이점은 응용프로그람이 능동상태로 되는 대신에 배경상태에로 들어가 사건을 처리하고 인차 정지상태로 된다는것이다.

배경에로 실행될 때까지도 체계는 응용프로그람의 사용자대면부파일들을 적재하게 되지만 응용프로그람의 창문에는 현시하지 않는다.

Figure 3-3 Launching an app into the background

응용프로그람이 전경에로 실행되는지 아니면 배경에로 실행되는지를 결정하자면 application:didFinishLaunchingWithOptions메쏘드안에서 공유객체인 UIApplication 의 applicationState 속성을 검사하면 된다. 응용프로그람이 전경에서 실행된다면 이 속성은 UIApplicationStateInactive 값을 가지게 된다. 배경에로 실행된다면 UIApplicationStateBackground 값을 가지게 된다. 이 값에 따라 application:didFinishLaunchingWithOptions 에서 실행시 처리를 진행하면 된다.

요점: 응용프로그람이 실행되여 URL 을 열수 있게 되면 기동순서는 그림 3-2 와 3-3에서 보여준것과는 조금 다르게 된다. URL 을 열때 기동순서를 참고하려면 "URL요청처리"(100페지)를 참고할것.

main 함수에 대하여

C 기반의 응용프로그람들과 마찬가지로 iOS 응용프로그람의 시작점은 main 함수이다. iOS 의 응용프로그람에서 main 함수는 극소로 사용된다. main 함수가 하는 일은 조종권을 UIKit 기틀에로 넘기는것이다. 그러므로 Xcode 에서 창조하는 새 프로젝트는 목록 3-1 에서 보여준것과 같이 기정 main 함수와 함께 창조된다. 특별한 례외를 제외하고는 이 함수는 절대로 변경하지 말아야 한다.

목록 3-1. iOS 응용프로그람의 main 함수

#import <UIKit/UIKit.h>

int main(int argc, char *argv[])

{

@autoreleasepool {

return UIApplicationMain(argc, argv, nil, NSStringFromClass([MyAppDelegate class]));

}

}

요점: autorelease pool 은 기억기 관리에서 리용된다. 그것은 코드의 함수블로크에서 창조된 객체의 해체를 지연하는데 리용되는 Cocoa 방법이다. autorelease pools 에 대한 구체적인 정보는 개선된 기억기관리프로그람 지도서(Advanced Memory Management Programming Guide)를 참고한다.

UIApplicationMain 함수는 4 개의 파라메터를 가지고 응용프로그람을 초기화한다. 이 함수에로 넘겨지는 기정값들을 변경시키지 말아야 한다. 중요한것은 그 목적과 함께 어떻게 응용프로그람을 시작하는가를 리해하는것이다.

argc 와 argv 파라메터는 실행시 체계에서 응용프로그람으로 넘어온 인수들이다. 이 인수들은 UIKit 하부구조에서 해석되거나 무효화된다.

세번째 파라메터는 응용프로그람의 주되는 class 의 이름을 식별한다. 이 클라스는 응용프로그람을 실행하는 책임을 지게 된다. 이 파라메터에 nil 값을 지정할것을 권고하며 그러면 UIKit 는 UIApplication클라스를 리용하게 한다.

네번째 파라메터는 사용자응용프로그람의 위탁클라스를 식별한다. 응용프로그람의 위탁은 체계와 프로그람코드사이에서 고수준의 호상작용을 관리하기 위한 책임을 지게 된다. Xcode 형타프로젝트는 이 파라메터에 자동적으로 적합한 값을 설정한다.

UIApplicationMain 함수가 하는 또 다른 일은 응용프로그람의 사용자대면부파일을 적제하는것이다. 기본대면부파일은 응용프로그람의 대면부에서 현시할 초기보기관련객체들을 포함한다. storyboards 를 리용하는 응용프로그람들에서 이 함수는 storyboard 에서 초기방식조종기를 적재하여 응용프로그람의 위탁객체에 의해 제공된 창문에 설치한다. nib 파일을 리용하는 응용프로그람들에 대하여 이 함수는 nib파일내용을 기억기에 적재하지만 응용프로그람의 창문에는 적제하지 않는다. 개발자가 자체로 응용프로그람 위탁객체의 application:didFinishLaunchingWithOptions메쏘드에서 설치하여야 한다.

응용 프로그람은 기본 장면화판 파일이나 기본 끝파일 중 하나를 가질 수 있지만 모두를 가질 수 없다.

응용프로그람의 대면부를표시하기에 정합한 방법일 장면화판방법은 모든 IOS 기정에서 지원되지 않는다. 응용프로그람의 Info.plist 파일의 UIMainStoryboardFile 에 당신의 기본 장면화판 이름을 쓰시오. (Nib 기반 응용프로그람에서는 NSMainNibFile 을 대신에 사용한다.) 대체로 Xcode 가 프로젝트를 창조할 당시 이 값을 성절하지만 필요시 바꿀수 있다.

Info.plist 파일이나 이것을 어떻게 당신의 응용프로그람에 접합시킬것인가에 대해 더 많인 정보가 필요하면 6-1 을 참조하시오.(100페지)

시작하기에 앞서 해야할 것들

당신 응용프로그람이 실행되면(표면에서 아니면 배경에서든) 다음의 것을 하기 위해 응용프로그람에 할당된 application:didFinishLaunchingWithOptions: 메쏘드를 사용하시오.

.왜 응용프로그람이 실행되고 정확히 응답하였는가하는 정보에대한 설정사전을 실행하는 내용을 검사한다.

.응용프로그람의 중요한 자료구조들을 초기화한다.

. 응용프로그람의 대면부를 준비하고 화면상에서 보기.

OpenGL ES 를 사용하는응용프로그람들은 개발환경을 준비하기 위한 이과정을 거치지 않아도 된다.대신에 applicationDidBecomeActive: method 로 OpenGL ES 개발호출을 연기해야 한다.

. 이전 실행단계로 이동하기위해 보관된 상태정보나 우선권들을 이용한다.

만일 대면부관리에 nib 파일들을 사용하는 경우 현시되는 대면부를 구성하는데 application:didFinishLaunchingWithOptions: 메쏘드를 사용해야 한다.

nib 기반으로하는 응용프로그람인 경우 대면부창을 창조하고 초기화면조종기를 리용하여 대면부를 설치하고 현시한다.

Portrait 와 landscape 을 지원하는 응용프로그람들은 항상 orientation 을 기본으로 화면을 설치한다.

만일 장치가 다른 형태로 실행시 체계는 화면을 현시하기 전에 적당한 형태로 창을 회전시킨다.

Your application:didFinishLaunchingWithOptions: 메쏘드는 응용프로그람실행 시간을 줄이기위해 가능한 간단하게 해야 한다.

응용프로그람들은 실행한다음 자체로 초기화해야하며 대체로 5 분마다 사건을 처리해야 한다.

만일 응용프로그람이 실행주기를 제시간에 끝내지 못할경우 체계가 응답이 없는것으로 과제를 끝낸다.

이와같이 실행속도를 늦추는 과제들은 (망을 접근하는것과 같은) 두번째 처리로 비동기적으로 실행되여야 한다.

실행주기를 제시간에 끝내지 못할경우 체계가 응답이 없는것으로 과제를 끝낸다.

이와같이 실행속도를 늦추는 과제들은 (망을 접근하는것과 같은) 두번째 처리로 비동기적으로 실행되여야 한다.

전경에서 실행될때 체계는 전경에로의 전송을 마감짓기 위해 applicationDidBecomeActive: 메쏘드를 호출해야 한다.

이 메쏘드가 실행시 량쪽에서 실행되기때문에 전경에서 실행될때 체계는 전경에로의 전송을 마감짓기 위해 applicationDidBecomeActive: 메쏘드를 호출해야 한다.

이 메쏘드가 실행시 량쪽에서 실행되기때문에 내부로부터의 전송시 공통으로 실행되는 과제들을 처리하기위해 사용한다.

내부에로의 전송시 응용프로그람에 어떤 사건이 발생할때 처리할수없는 례외가 많어서는 안된다.

새치기에 응답하기

전화가 온다거나 알림과같은 새치기가 발생할경우 체계가 사용자에게 어떻게 처리하는지를 알려줄수 있도록 응용프로그람은 일시적으로 비활성상태로 넘어가게 된다. 응용프로그람은 이 상태로 사용자가 알림을 볼때가지 남게 된다. 여기서 이 응용프로그람은 활성상태라든가 또는 내부처리에 있는 다른 응용프로그람의 빠른 실행을 위해 정보를 돌려주게 될다. 아래의 3-4 그림은 알림새치기가 발생할경우 응용프로그람을 통해 발생할 사건들의 흐름을 보요주고 있다.

IOS5 에서 banner 로 보여주는 알림은 응용프로그람을 우와 같은방법으로 비활성화 하지 않는다. 대신에 banner 는 프로그람화면의 웃쪽에 놓이며 전과같이 touch사건을 계속 받는다. 또한 사용자가 알림창을 보기 위해 banner 를 내리면 응용프로그람은 전과같이 비활성상태로 되거나 다른 응용프로그람을 실행한다. 여기서 응용프로그람은 대체로 활성상태나 내부실행상태로 간다. 사용자는 어느것이 banner와 알림을 현시할것인가를 설정프로그람을 리용해 할수 있다.

Sleep 단추나 Wake 단추는 프로그람을 비활성상태로 만드는 또 하나의 새치기이다. 사용자가 이 단추를 누를때 체계는 touch 사건을 정지시키고 프로그람을 비활성화 시키며 화면을 lock 상태로 만든다.

화면이 lock 상태로 되면 파일을 보관하기 위한 자료보호프로그람들이 실행된다.

이 프로그람들에 대해서는 새치기 발생시 해야하는것(42페지) 에 서술되요 있다.

새치기 발생시 해야하는것

알림새치기결과는 응용프로그람에의해 일시적 조종이 불가능하다. 프로그람은 내부실행상태로 계속 실행되지만 체계로부터 touch 사건을 받지 않는다.

applicationWillResignActive 메쏘드로 다음과 같이 해야 한다.

.시계및 기타 정기적인 작업을 중지한다.

. 실행중인 metadata 실행명령문들을 중지한다.

. 새 과제들에 초기화를 하지 않는다.

. 동영상 재생 일시 정지(AirPlay 를 통해 재생시 제외).

. 게임들은 일시 정지 상태로 된다.

. OpenGL ES 창들의 속도를 낮춘다.

. 중요하지 않는 시행 지령들과 그 밖의 다른 지령대기렬을 정지한다.

(비활성화 되있는동안 망요청이나 다른 시간에 관한 과제들을 계속 수행할수 있다.)

프로그람이 활성화상태로될때 applicationgDidBecomeActive: 메쏘드는 applicaionWillResignActive: 메쏘드에서 실행되는 단계를 거꾸로 해야 한다. 그러나 재활성화 할때에는 timer 를 다시시작해야 하며 신속한 처리들을 재생하고 OpenGL ES fame 속도를 높여야 한다. 그러나 게임들은 자동적으로 재생되여서는 안된다. 사용자가 재생할지를 경절할때까지 정지상태로 남아있어야 한다.

만일 사용자가 Sleep/Wake 단추를 누르면 NSFileProtactionComplete 보호설정에 의해 보호된 파일들이 있는 프로그람은 그 파일들에 괄련된것을 취소해야 한다.

고유한 암호를 가진 장치들은 Sleep/Wake 단추를 누르면 화면을 lock 상태로 하고 파일들을 완전한 보호상태로 하기 위해 암호풀이 열쇠를 없앤다.

화면이 lock 상태일때 복잡한 파일들에 대한 접근시도는 실패한다. 그래서 그런 파일들을 사용하는경우 applicationWillResignActive: 메쏘드에서 그파일들에게 참조된것들을 취소하고

applicationDidBecomeActive: 메쏘드에서 새로은 참조를 켠다.

전화통화동안 사용자대면부 조절하기

 사용자가 전화를 받고 그 상태로 프로그람으로 돌아갈때 사용자가 전화중이라는것을 보여주기 위해 상태띠 높이를 높여준다. 그리고 전화가 끝날때 상태띠 높이는 원래 크기로 돌아간다.

상태띠높이 변화를 조종하는데서 가장 좋은 방법은 화면과리에 view controller 를 사용하는것이다. 대면부에 설치됬을때 상태띠 창크기가 변하는데 따라 view controller는 자동적으로 화면의 높이를 조절한다.

프로그람이 어떤 리유로 view controller 를 사용하지 않을 경우 상태띠창 변화에 UIApplicationDidChangeStatusBarFrameNotification 알림을 등록하는것으로서 수동적으로 응답해야 한다.

이 알림에 대한 조종부분은 상태띠 높이를 받아야 하며 프로그람 화면의 높이를 정확히 조절하는데 사용한다.

Background 로 가기

사용자가 Home 단추를 누르거나 체계가 다른 프로그람을 실행할경우 전경프로그람은 비활성상태로 되고 그다음을 background 상태로 될다. applicationWillResignActive: 와 applicationDidEnterBackground: 메쏘드 호출시 이변화결과를 그림 3-5 에서 보여준다.

applicationDidEnterBackground: 메쏘드에서 돌아온다음 대부분 프로그람들은 그후 잠시동안 정지상태로 되게된다. 특별히 내부실행과제들을 요구하는 (음악듣기 등) 프로그람들이나 체계로부터 조금다른 실행을 요구하는 프로그람들은 조금더 오래동안 실행된다.

*

프로그람은 다증처리를 지원하는 장치에서나 그리고 그 장치들이 IOS 4.0 이후의 판본에서 동작할 경우 background 상태로 옮겨진다. 다른 경우들에서는 background 상태 대신에 프로그람을 종결시킨다.( 또한 기억기에서 깨끗이 지워진다.)

Background 상태로 넘어갈때 해야하는것들

프로그람들은 Background 상태로 넘어가기 위한 준비로 applicationDidEnterBackground: 메쏘드를 사용할수 있다. Background 상태로 넘어갈때 다음과 같이 하여야 한다.

- 현시될 그림 준비. applicationDidEnterBackground: 메쏘드가 되돌려줄때 체계는 사용자대면부 그림을 동화변화에 사용한다. 만일 대면부어떤부분이 섬세한 정보를 가지고 있는경우 applicationDidEnterBackground: 메쏘드에서 돌아오기 전에 그 부분화면을 숨기거가 변화시켜야 한다.

- 사용자 자료와 프로그람 상태정보 보관하기. 보관되지 않은 모든 변화들은 background 상태로 들어가기전에 디스크에 씌여져야 한다. 이 단계는 background 상태에 있는동안 어떠한 여러가지 리유로 하여 쉽게 프로그람이 없어질수 있기 때문이다. 필요하면 이 과정을 background thread 에서 진행할수 있다.

- 가능한 많은 기억기 공간을 비워든다. 이것을 어떻게 해야하며 왜 중요한가에 대해 더 많은 정보가 필요하면 “background 상태 프로그람들을 위한 기억기사용”(45페지) 를 보시오.

applicationDidEnterBackground: 메쏘드는 어떤 과제를 끝내고 돌려주는데 대략 5초정도 걸린다. 실지로는 이 메쏘드가 가능한 빨리 돌려줘야 한다.이 메쏘드가 시간초과 할때까지 제때에 돌려주지 않으면 프로그람은 사라지고 기억기에서 삭제된다. 그래도 과제를 수행하는데 더 많은 시간이 필요하면 background 상태 실행시간을 요구하기 위해 beginBackgroundTaskWithExpirationHandler: 메쏘드를 호출하고 두번째 thread 에서 오래 실행디는 과제들을 시작한다. 어떤 background 과제를

실행하든상관없이 applicationDidEnterBackground: 메쏘드는 5 초내에 취소되야 한다.

***

UIApplicationDidEnterBackgroundNotification 알림은 또한 background 상태로 되고 있음을 프로그람의 중요한 부분들에 알려준다. 객체들은 이 알림을 등록하기위해 기정 알림쎈터를 리용할수 있다.

프로그람의 기능에 따라 background 상태로 넘어갈때 해야할 여려가지 일들이 있다. 실례로 모든 활성화된 Bonjour service 들은 정지되여야 하며 프로그람은 OpenGL ES함수 호출을 정지해야 한다. background 상태로 갈때 프로그람이 해야할 목록을 보려면 “중요한 background 상태 프로그람 되기”(58페지) 를 참조하시오.

Background 상태 프로그람들을 위한 기억기 사용법

모든 프로그람들은 background 상태로 넘어가면서 사용되는 가능한 많은 기억기를 비워놓아야 한다. 체계는 가능한 많은 프로그람을 동시에 기억기에 보관하려고 하지만 기억기가 실행이 느리면 정지된 프로그람들의 기억기를 재활용하기 위해 그 프로그람들을 끝낸다.

실천에서 보면 프로그람은 더 이상 필요없는 객체들에 련결된 참조들을 없애야 한다.

참조를 없애면 자동적으로 참조계산체계가 련결된 객체를 없애고 이 객체가 사용하던 기억기를 즉시 재리용하게 한다. 그리고 프로그람이 성능을 높이기 위해 고속완충기를 리용하는경우 background 상태로 변환동안 고속완층기에 보관된 내용들을 기다리다 지을수 있다.

기억기 재리용할수 있게 할당해주어야 할 갤체들의 실례는 다음과 같다.

- 고속완층기에 보관될 그림객체- 디스크로부터 다시 꺼낼수 있는 큰 매체 나 자료파일들- 프로그람이 필요없고 후에 쉽게 다시 창조할수 있는 객체들

프로그람의 기억기차지를 줄이기 위해서 체계는 뒤에서 지원하는 많은 객체들을 자동적으로 없앤다.

실례로:

- 모든 중요한 동화층에대해서 화면에 층들의 내용이 보여지는것을 막는 backing store 기억기를 해방시킨다. 이것은 층객체자체를 놓아주지는 않는다.

- 고속완층기에 보관된 그림들에 련결된 참조들을 삭제한다.(만일 그림들에 련결된 비교적 많이 쓰는 참조가 없으면 기억기에서 그이후에것을 삭제한다.)

- 체계가 관리하는 자료들을 보관하는 다른 고속완층기억기를 해방시킨다.

전경으로 돌아가기

전경으로 돌아가는것은 background 상태로 넘어가면서 멈췄던 프로그람과제들을 다시 시작할수 있는 기회이다. 전경으로 움직일때 일어나는 단계들을 그림 3-6 에서 보여주고 있다. applicationWillEnterForeground:메쏘드는 applicationDidEnterBackground: 메쏘드에서 했던 모든 것들을 다시 해야 하며 applicationDidBecomeActive: 메쏘드는 실행할때 하는 똑같은 활성과제들을 계속 실행하게 하여야 한다. (그림 3-6 background 상태에서 전경으로 이동)

알아두기: UIApplicatonWillEnterForegroundNotification 알림은 프로그람이 다시 전경상태로 들어설때 추적하는데도 가능하다. 당신 프로그람에 있는 객체들은 이 알림을 기록하는데 기정알림쎈터를 리용할수 있다.

깨여나는 시간에 대기렬에 있는 Notification 들을 실행하기

정지된 상태에 있는 프로그람들은 전경이나 background 실행상태로 되돌아 올때 대기렬된 notification 들을 처리할수 있게 준비되 있어야 한다. 정지된 프로그람들은 그 어떤 코드도 실행시하지 않으며 또한 방향, 시간, 선택창변화와 같이 프로그람 외부나 상태에 영향을 줄수 있는 많은 다른것들에 괄련된 notification 들을 실행할수 없다. 이 변화들이 없어지지 않았다는것을 확인 하기 위해서 체계는 관련된 notification 들을 대기렬에 넣고 될수록 빨리 실행코드들이 다시 시작할수 있게 프로그람에 날라다준다(background 나 foreground 상태에서든). 재생될때 프로그람에 notification 들이 겹치는 것을 막기 위해서는 체계가 사건들을 합쳐서 프로그람이 정지된 때부터 망변화를 반영하는 하나의 notification 으로 (서로 련관된 형태의) 전달하는 것이다.

표 3-2 는 합쳐져서 프로그람으로 전달될수 있는 notification 들의 목록을 보여준다. 대부분 notification 들은 등록된 감시자에게 직접 전달된다. 장치에 관련된 변화에 관한 것들은 대체로 체계 framework 에 의해 새치기되며 다른 방법으로 프로그람에 전달된다.

표 3-2 깨여나는 프로그람에 전달되는 notifications

사건 Notification부속품이 련결됬는가 안됬는가 EAAccessoryDidConnectNotification

EAAccessoryDidDisconnectNotification장치적 변화 UIDeviceOrientationDidChangeNotification

이 notification 에 추가로 view controllers 는 대면부적인것들을 자동적으로 갱신한다.

중요한 시간변화가 있다. UIApplicationSignificantTimeChangeNotification배터리 급이나 상태 변화 UIDeviceBatteryLevelDidChangeNotification

UIDeviceBatteryStateDidChangeNotification근접상태 변화 UIDeviceProximityStateDidChangeNotification보호된 파일변화 상태 UIApplicationProtectedDataWillBecomeUnavaila

bleUIApplicationProtectedDataDidBecomeAvailable

외부화면이 련결됬는가 안됬는가

UIScreenDidConnectNotificationUIScreenDidDisconnectNotification

화면막 상태 변화 UIScreenModeDidChangeNotification설정을 통해 프로그람에 영향을 주는 선택들이 변했을떄

NSUserDefaultsDidChangeNotification

현재언어나 장소설정이 변했을때

NSCurrentLocaleDidChangeNotification

대기렬된 notification 들은 프로그람의 기본실행순환에 전달되며 대체로 어떤 touch사건이나 다른 사용자입력전에 전달된다. 대부분 프로그람들은 재생할때 두드러지게 알리는 일이 일어나지않게 하기 위해서 이 사건들을 빨리 처리해야 한다. 만일 프로그람이 background 상태에서 돌아올때 떠지게 보이면 notification 처리하는 코드가 연기시키는가 아닌가를 결정짓지위해 도구를 사용하시오.

foreground 상태로 돌아가는 프로그람은 또한 마지막 갱신부터 어둡게 표시된 일견들에 대한 notification 을 받는다. background 상태에서 실행하는 프로그람은

화면갱신을 요구하기 위해 setNeedsDIsplay 아니면 setNeedDisplayInRect: 메쏘드를 호출할수 있다. 어쨋든 화면이 보이지 않기 때문에 체계는 foreground 상태로 돌아온 다음에만 화면에 대한 갱신와 요구를 합칠수 있다.

아름다운 장면변화 처리하기

프로그람이 정지된상태에서 사용자가 현재언어를 바꾸면 시간,날자 그리고 foreground상태로 돌아갈때 돌려주는 수자들과 같은 장면에 민감한 정보들을 포함하여 화면에 변화를 주도록 하는 NSCurrentLocaleDidChangeNotification 알림을 리용할수 있다. 물론 언어와 관련된 문제점들을 피하는 제일 좋은 방법은 화면 변화를 쉽게 코드를 작성하는것이다.

실례로

- NSLocale 객체를 복구할때 autoupdatingCurrentLocale클라스 메쏘드를 리용하시오. 이 메쏘드는 변화에 따라 자동적으로 갱신하는 장면객체를 돌려주며 그래서 재창조를 하지 않아도 된다. 어쨋든 장면이 바뀔때 현재 장면으로부터 나오는 내용을 표함하는 화면을 새롭게 하는것이 필요하다.

- 언제든 현재 장면정보가 변하면 고속완층기 자료와 여려 형식객체들을 재창조해야 한다.

장소변경을 처리하기 위해 코드를 국제화하기 위한 더 많은 정보가 필요하면 프로그람국제화사기를 보시오.

프로그람설정에서 변화에 응답하기

만일 프로그람이 설정프로그람에 의해 관리되는 설정을 가지고 있으면 NSUserDefaultsDidChangeNotification 을 주시해야 한다. 사용자는 프로그람이 중지되거나 background 상태에 있을때에 설정을 수정할수 있기때문에 중요한 설정변경에 응답하는데 이 notification 을 사용할수 있다. 어떤 경우 이 notification에 응답하는것으로 가능한 안전보호구멍을 없앨수 있다. 실례로 메일프로그람은 사용자구좌정보변화에 응답해야 한다. 이변화들감시에 실패하는것은 사생화 이나

안전문제에 문제를 일으킬수 있다. 특히 현재 사용자는 원래 구좌가 더는 자기것이 아닌데도 오래된 구좌정보로 메일을 보낼수 있다.

NSUserDefaultDidChangeNotification notification 을 받을때 프로그람은 적절한 설정을 적재해야 하며 필요하면 사용자대면부를 적절히 재배치해야 한다. 암호 또는 다른 안전과 관련된 정보가 변한곳인 경우 그 전에 현시됬던 정보를 숨기고 사용자에게 새로운 암호를 입력하게해야 한다.

프로그람 종료

프로그람이 일반적으로 background 상태로가서 정지됬다고 해도 다음의 경우들이 옳으면 프로그람은 종료되고 대신에 기억기에서 깨끗이 없어진다.

-앱은 ios4.0 이전의 버젼과 호환 된다.

-앱은 또 한 ios4.0 이전의 체계가 장착되있는 장치에서 동작한다.

-현존하는 장치는 다중과제처리를 제공하지 않는다.

-앱은 UIApplicationExitsOnSuspend key 를 Info.plist file 에 보관하고 있다.

만약 앱이(배경혹은 전면에서 실행중)이던 앱이 꺼질때 체계는 해당앱의applicationWillTerminate메쏘드를 실행시켜 필요한 정리를 진행한다.

이 method 는 또한 순차적인 실행으로부터 현보존 상태로 앱을 원상복귀시키기 위한 사용자 자료 혹은 앱유지정보를 보관 하는데 쓴다.

이 method 는 어떤 기능을 수행하고 복귀하는데 5 초정도 시간이 걸린다.

또 한 그 시간안에 복귀하지 않으면 앱은 메모리에서 삭제된다.

Important: applicationWillTerminate method 는 앱이 정지되면 실행되지 않는다.

비록 ios sdk4.0 이나 그 이후의 버젼으로 앱을 개발한다 하더라도 반드시 앱이 알림없이 종료될수 있도록 해야 한다.

사용자는 다중과제처리 대면부를 리용하여 앱을 명백히 종료시킬수 있다.

더하여 메모리가 부족하면 체계는 메모리로부터 앱을 삭제하여 용량을 확보할수 있다.

정지된 앱은 종료될때 알림이 나타나지않지만 현재 실행중인(정지되지 않은)앱에 관해서는 체계가 앱의 applicationWillTerminate메소드를 실행시킨다.

앱은 이 메소드로 부터 추가적인 실행시간을 요청할수 없다.

기본순환실행

앱의 기본순환실행은 사용자관련 사건들을 처리하기 위한것이다.

UIApplication 객체는 앱실행시에 기본순환실행을 동작시키며 사건이나 대면부기반의 손잡이를 갱신하기위해 쓴다.

이름이 보여주는것과 같이 기본순환실행은 앱의 기본 스레드를 실행시킨다.

이러한 과정은 사용자관련 사건들이 접수받은 차례로 순차적으로 처리되게 하여 준다.

Figure3-7 은 이러한 기본순환실행의 구조와 해당앱을 통한 사용자관련 사건들이 어떻게 결과를 내는가하는가를 보여준다.

사용자들이 장치와 호환하는데 상응하여 그 호환과 관련된 사건들은 체계에 의해 발생하며 UIKit 에 의하여 형성된 특수한 port 를 통하여 앱에 전달된다.

사건들은 앱에 의하여 내부적으로 대기렬로 정렬되고 하나씩 실행을 위하여 기본순환실행부분으로 전송된다.

UIApplication 객체는 사건을 가장 처음으로 받아들이고 다음동작을 결정하는 첫번째 객체이다.

touch 사건은 누름사건이 발생한 부분에 대한 표시를 진행하는 main window 객체에 발송된다.

다른사건들은 여러 객체를 통하여 조금 다른 경로를 리용할수 있다.

여러종류의 사건들은 ios app 으로전송된다.

아래의 표에 있는 내용은 가장흔한 사건들이다.대부분의 이렇한 사건들은 기본순환실행을 통하여 전송되지만 일부는 아니다.

실례로 accelerometer같은 사건은 당신이 지정한 accelerometer deligate 객체로 직접 전송된다.

가장기본적인 touch,remote control,motion,accelerometer,gyroscopic 과같은 사건들에 대한 처리방법은 ios 사건처리지도서를 보면 알수 있다.

사건종류 전송목적지 내용Touch 사건이 발생한

표시객체표시객체는 응답객체이다.보기객체를 통하여 처리되지 않은 누름사건은 응답사슬로 전송되여 처리된다.

Remote control

첫응답객체 원격조종사건은 메디아 재생 혹은 headphone 과 같은 accesorry 들을 통해서 발생한다,

motion 첫응답객체 motion 사건은 장치를 흔드는것과 같은 특정한 사건에 반응하며 서로다른accelerometer-based events 를 통하여

처리된다.Accelerometer core motion

지적된 객체 Accelerometer 와 gyroscope 장치와 관련된 사건들은 당신이 제시한 객체로 전송된다.

Redraw 갱신이 필요한 표시객체

Redraw 사건은 사건객체를 포함하지 않지만자체로 재그리기를 진행하기 위해 view 를 호출한다.Ios 의 drawing architecture 는Drawing and Printing Guide for iOS 에 서술되 있다.

location 지적된 객체 CoreLocation framework 를 리용해서 location 사건을 얻기위해 등록한다. CoreLocation framework 에관한 더 구체적인 정보는 Location Awareness Programming Guide 에 서술되여 있다.

누름사건이다 원격조종사건과 같은 사건들은 앱의 응답객체에 의해 처리된다.

응답객체는 앱의 어디에나 있다.(UIApplication 객체,View 객체,View control 객체들은 다 응답객체의 실례들이다.)대부분 사건들은 특정한 응답객체를 목표로 잡지만 처리를 위해서는 (응답 사슬)을 통하여 다른 응답객체로도 전송될수 있다.

실례로 사건을 처리하지 않는 view 는 사건을 자신의 superview 혹은 view controller로 전송한다.

누름 사건은 (단추)와 같은 조종체에 의해 발생하며 그 사건이 어떤 종류의 view 에서 발생했는가에 따라 서로 다르게 처리된다.

보통 한조종체에 관해서 제한된 개수의 가능한 동작이 있으며 그것들은 action message 에 다시 pack 되여 해당 객체로 전송된다.

target-action design 방식은 앱에 있는 특정코드실행을 위한 방아쇠를 조종하기 쉽게 하여 준다.

배경프로그램실행과 다중과제 처리

Ios4 와 그 이후 버젼에서 다중과제처리는 앱으로 하여금 사용자가 다른 앱으로 절환해도 이전 앱을 배터리가 다 할때까지 배경상태에서 실행되도록 하여 준다.

대부분 앱들은 배경상태에 들어서자마자 곧장 suspended state 로 전송된다.

사용자에게 중요한 정보를 주는 앱만이 일정한 시간동안 실행되도록 허용된다.

가능한껏 앱이 배경상태에서 동작하고 suspend state 상태이지 않도록 노력해야 한다.

당신이 배경상태의 앱을 실행해야 한다면 해당 방법은 아래와 같다.

-적어도 하나이상의 사용자 서비스를 실행해야 한다.

- single finite-length task 를 실행해야 한다.

-앱이 실행되지 않을때 나타나는 정보를 사용자에게 알려주는 알림을 리용해야 한다.

체계는 suspend 상태의 앱들을 가능한껏 오래 보관하며 만약 메모리가 부족해지면 지운다.

메모리에 보관하고 있다는것은 순차적인 앱의 실행이 빨리 진행될수 있다는것이다.

또한 그것은 배터리의 사용량을 줄여준다는것이다.

Multitasking 이 가능한지 아닌지 측정하기

앱은 multitasking 이 가능하지 않는 정황에 준비되어야 한다.

앱이 ios4.0 이나 그이후의 버젼을 위해 만들어 졌다고 해도 ios4.0 이 태워져 있는 어떤 장치들은 multitasking 을 제공하지 않는다.

만약 앱이 ios 이전 버젼용이라면 multitasking 이 없이 실행되도록 준비되어야 한다.

만약 multitasking 이 존재하는가 존재하지않는가가 app 의 행동을 변화시킨다면 해당 과제를 처리하기전에 multitaking 이 존재하는가 안하는가를 검사하기 위해 UIDevice클라스ㅇ의 multitaskingSupported 속성을 검사한다.

Listing 3-2 ios 이전버젼에서 background 기능 검사하기

UIDevice* device = [UIDevice currentDevice];BOOL backgroundSupported = NO;if ([device respondsToSelector:@selector(isMultitaskingSupported)])backgroundSupported = device.multitaskingSupported;

Background 에서 Finite-Length Task 실행하기

Background 상태로 되고 있는 앱은 중요한 마지막 처리를 위해 추가 시간을 요구할수 있다.

background 실행시간을 요청하기 위해서는 UIApplication클라스의beginBackgroundTaskWithExpirationHandler 메소드를 실행한다.

만약 앱이 실행도중 background 상태로 넘어가거나 이미 넘어가 있는 상태라면 이 메소드는 앱의 suspension 을 지연시킨다.이것은 만약 앱이 사용자 자료를 디스크에 쓰고 있거나 네트워크 서버에서 자료를 다운하고 있다면 매우 중요한것이다.

beginBackgroundTaskWithExpirationHandler:메소드를 쓰는 방법은 당신이 보호하려는 동작이 실행되기 전에 그 메소드를 실행시키는것이다.

이 메소드를 실행시키는 명령문은 항상 이 실행의 끝을 알리는 endBackgroundTask:와 균형이 맞춰 있어야 한다.

왜 냐면 앱은 배경상태의 실행을 끝내기 위해 제한된 시간을 할당받기 때문에 시간이 끝나기전에 이 메쏘드를 실행해야 하며 그렇지 않으면 체계는 앱을 강제적으로 종료시킨다.

그렇한 강제적인 종료를 막기위해 실행을 시작했을때 완료손잡이를 사용할수 있으며 그때 endBackgroundTask메소드를 실행시킬수 있다.(앱객체의backgroundTimeRemaining 속성을 시간이 얼마나 남았는가를 측정하는데 쓸수 있다.)

Important:하나의 앱은 같은시간에 여러개의 과제를 실행시킬수 있다.

매 과제를 시작할때마다 beginBackgroundTaskWithExpirationHandler메소드는 유일한 id 를 해당 과제를 식별하기 위해 돌려준다.

따라서 그 과제를 끝낼때에는 endBackgroundTask메소드에 같은 id 를 전송해주면 된다.

Listing3-3 은 앱이 background 상태로 넘어갈때 long-running task 를 어떻게 시작할지 보여주고 있다.

이 실례에서는 과제가 오래걸릴때 리용되는 완료 손잡이를 포함하는 배경 task 에 관한 요청이다.

과제는 비동기적인 실행을 위해 처리 대기렬로 들어가며 따라서applicationDidEnterBackground메소드는 정상적으로 돌려준다.

이 코드블록의 리용은 background task 식별자와 같은 중요자료에 대한 참조 를 유지하기위한 코드를 간단하게 하여준다.

bgTask 변수는 현 background task 식별자로의 지시자를 보관하는 클라스의 속성변수이다.

Listing 3-3 Starting a background task at quit time- (void)applicationDidEnterBackground:(UIApplication *)application{UIApplication* app = [UIApplication sharedApplication];bgTask = [app beginBackgroundTaskWithExpirationHandler:^{// Clean up any unfinished task business by marking where you.// stopped or ending the task outright.[app endBackgroundTask:bgTask];bgTask = UIBackgroundTaskInvalid;

}];// Start the long-running task and return immediately.dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{// Do the work associated with the task, preferably in chunks.[app endBackgroundTask:bgTask];bgTask = UIBackgroundTaskInvalid;});}

Note:task 가 실행할때 항상 expiration handler 가 제공되지만 앱실행시간이 얼마나 남았는지를 알기 위해서는 UI Application클라스의 backgroundTimeRemaining속성값을 얻으면 된다.

expiration handlers 에서 task 에 접근하기 위한 추가코드를 포함할수 있다.

하지만 그렇한 코드들은 실행시간이 길지말아야 하며 그것은 expiration handler 가 호출되고 앱이 이미 제한시간에 접근하고 있기 때문이다.

그러므로 최소한 자료에 대한 정리만을 진행하고 task 를 끝내야 한다.

내부 알림 전송의 순서화

알림은 배경상태나 혹은 실행되어 있지 않은 상태의 앱이 사용자들의 시선을 끌기위한 하나의 방도이다.

앱은 내부 경고를 경고,소리재생 ,앱아이콘 표시를 위해 리용 하며 또 는 앞의 3 가지 경우의 조합을 위해 리용한다.

실례료 시계앱은 경고음과 경고를 비동기화시키기 위한 경고를 나타내기 위한데 내부알림을 쓴다.

사용자가 알림을 봤을때 그 알림내용이 앱을 foreground 상태로 되돌리려는것이라면 사용자는 무엇인가를 해야 한다.

(이미 앱이 foreground 상태로 실행중이라면 알림은 사용자에게로 아니라 앱으로 전송된다.)

내부 알림 전송의 순서화를 진행하려면 UILOcalNotification 객체를 만들고 알림파라메터들을 정리한다음 UIApplication클라스의 함수들을 리용하여 순서화 한다.

내부알림객체는 음,경고,표시아이콘과 같은 전송되는 알림 형태정보를 가지고 있으며 전송되는곳으로의 적당한 시간을 알려준다.

UIApplication클라스의 메소드들은 알림들을 즉시 혹은 순서화된대로 전송할것인가같은 방식을 가지고 있다.

Listing3-4 은 사용자가 정한 날짜와 시간을 리용하여 단순경고 알림을 순서화 하는것을 버요주고 있다.

이 실례는 한번에 하나의 경고소리를 실행시키며 새로운것을 실행하기전에 낡은것을 취소시킨다.

(사용하는 앱에서는 한번에 128 개 이상의 알림을 활성화 시킬수 없으며 설정한 수만큼 같은 알림을 반복시킬수 는 있다.)

Alarm 은 앱이 실행되어있지 않거나 배경상태일때 시간이 되면 실행되는 경고함과 음파일이 포함되있다.

앱이 활성화되있고 또 실행되어 있는 상태이라면 앱의application:didReceiveLocalNotification메소드가 대실 실행된다.

Listing3-4

- (void)scheduleAlarmForDate:(NSDate*)theDate{UIApplication* app = [UIApplication sharedApplication];NSArray* oldNotifications = [app scheduledLocalNotifications];// Clear out the old notification before scheduling a new one.if ([oldNotifications count] > 0)

[app cancelAllLocalNotifications];// Create a new notification.UILocalNotification* alarm = [[[UILocalNotification alloc] init] autorelease];if (alarm){alarm.fireDate = theDate;alarm.timeZone = [NSTimeZone defaultTimeZone];alarm.repeatInterval = 0;alarm.soundName = @"alarmsound.caf";alarm.alertBody = @"Time to wake up!";[app scheduleLocalNotification:alarm];}}

음성파일은 경고를 내보내는것과 같은 기능을 수행하는 내부알림고 같이 리용된다.

전문적인 음성파일은 앱의 기본 묶음에 포함되 있으며 다음과 같은 PCM, MA4, μ-Law, or a-Law 파일 형식을 지원한다.

또한 음성파일의 이름을 장치를 위한 기정음성경고로 리용하기 위해 기정으로 설정할수 있다.

알림이 전송되면 음성파일이 재생되며 체계는 그를 위한 진동을 동작시킨다.

또한 알림순서를 변경시키며 알림목록을 얻기위해 UIApplication 클라스를 리용할수 있다.

이에관한 더 구체적인 정보는 UIApplicationClass Reference 에서 볼수 있다.

내부알림정리에 관한 추가적정보는 Local and Push Notification Programming Guide 를 보면 알수 있다.

Long-Running Background Tasks 실현하기

더많은 실행시간이 요구되는 task 에관에서는 background 상에서 suspend 없이 더 실행시키기위한 특수한 허가가 필요하다.

iOS 에서는 특수한 종류의 앱만이 background 에서 실행가능하다.

-Music App 과 같이 background 상에서 음악재생과 같은 기능을 수행하는 app

-사용자들에게 그들의 위치정보와 같은 정보를 알려주는 navigation app

-인터넷프로토컬을 리용하요 음성통화를 진행하는 app

-외부장치로 부터 주기적인 update 를 제공받는 app

이렇한 기능을 수행하는 앱들은 그 수행을 위해 조건을 보장받아야 하며 system framework 를 리용하여 해당 기능을 수행하여야 한다.

이렇게 app 들의 service 를 보장하는것은 system 으로 하여금 사용자가 어떤 기능을 리용하는가를 알게 하지만 특수한 경우에는 앱이 suspend 되는것을 system framework 를 리용하여 방지하여 준다.

앱의 background task 기능 보장하기

여러종류의 background 기능을 보장하기 위해서는 그것을 수행하는 앱들에서 우선 정의 되여야 한다.

앱들은 Info.plist 파일을 통하여 그렇한 기능들을 정의한다.

Info.plist 파일에 UIBackgroundModes키를 추가하며 그것을 하나혹은 여러개의 문자렬을 포함하고 있는 배렬로 정의해야 한다.

-audio-background 상태일동안 음성재생과 같은 기능을 수행한다.(이 기능은 AirPlay를 리용한 음성이나 비디오재생이다.)

-location-background 상태에서 동작중일지라도 사용자에게 현 위치를 알려준다.

-voip-사용자로하여금 인터넷련결을 리용하여 음성통화 기능을 리용하게 하여준다.

-newsstand-content-background 상태에서 magazine 혹은 신문을 다운하여 처리하여준다.

-external-accessory-주기적인 update 를 발송하는 하드웨어 장치와 작업할수있게 하여준다.

앞에서 말한 내용은 체계로 하여금 앱들이 해당사건에 응답하기 위해 적당한시간에 동작하리라는것을 알려준다.

실례로 음악을 재생하기시작하면서 background 상태로 넘어간 앱도 음성재생버퍼링을 위한 시간이 필요하다.

audio키를 포함하는것은 system framework 로 하여금 계속 재생하는것과 필요한 수만큼 다시재생하겠다는것을알려 주는것이다.

만약 이키를 포함하지 않는다면 재생이 시작된 음성은 앱이 background 상태로 넘어감에 따라 꺼진다.

사용자 위치추적

background 상에서 사용자의 위치를 추적하는 방법에는 여러가지가 있으며 대부분 background 상태에서 동작을 계속하려고 하지 않는다.

- significant-change 위치 서비스

- Foreground-only 위치 서비스

-Background 위치 서비스

significant-change 위치 서비스 는 많은량의 위치정보를 요구하지않는 앱을 위한 서비스이다.

이 서비스는 사용자의 위치가 크게 변하였을때 update 가 되며 그렇기 때문에 이 서비스는 social app 이나 사용자의 위치정보에 의존하는 앱에 사용된다.

앱이 update 가 일어날때 suspend 상태로 넘어가면 system 은 그것이 background상태에서 update 를 계속할수있게 해준다.

앱이 이 서비스를 시작하고 바로 꺼진다면 system 은 새로운 위치정보가 들어오면 바로 다시 실행시킨다.

이 서비스는 ios4.0 과 그 이후 버젼에서 가능하며 라디오 기능이 장착된 장치에서 동작가능하다.

oreground-only 와 background location 서비스는 둘다 위치정보를 얻기 위하여standard location Core Location service 를 리용한다.

단하나의 차이점이 있다면 foreground-only location 서비스는 앱이 suspend 상태로 됬을때 update 를 멈추지만 background location 서비스는 그런것이 없다.

foreground-only location 은 오직 그것이 foreground 상태로 동작할때만 app 에 서비스를 제공한다.

사용자에게 계속해서 위치정보를 제공해주는 앱은(background 상태일지라도) UIBackgroundModes key 를(값은 location 으로) 그 앱의 Info.plist 파일에 추가하여background location 서비스를 동작시킬수 있다.

location 값을 UIBackgroundModes 키에 포함시키는것은 suspend 상태의 앱으로부터 system 을 배제시키는것이 아니지만 체계로 하여금 새로운 위치정보가 가능할때마다 앱을 동작시키도록 하여 준다.

따라서 이 키는 새로운 위치정보가 나타날때마다 그것을 배경상태에서 효과적으로 처리할수 있도록 하여 준다.

중요사항: 표준봉사기능을 리용하거나(드물게) 위치변경봉사기능을 대신 리용하는것이 좋다. 위치봉사기능을 리용하려면 iOS 장치의 주기판에 설치된 라지오장치가 활성화되여야 한다. 이 라지오장치를 지속적으로 리용하는 경우 상당한 량의 전력을 소비하게 된다. 작성하려는 앱이 매우 정확하고 실시간적인 위치정보를 사용자에게 제공하지 않아도 되는 경우에는 위치봉사기능의 리용을 최소화하는것이 좋다.

iOS 앱에서 위치봉사기능을 리용하는 서로 다른 방법들에 대한 구체적인 정보에 관해서는 위치인식프로그람작성안내를 참고할것.

배경음악재생

음성을 지속적으로 재생해야 하는 앱들은 (앱이 배경에서 실행중인 동안에도) Info.plist파일안에 UIBackgroundModes 속성값을 audio 로 설정함으로써 배경음악앱으로 등록하여야 한다. 이 속성값을 포함한 앱들은 배경에서 실행하는동안 사용자에게 음성자료를 재생할수 있다.

배경음악앱들의 대표적인 실례들로는 Music 앱, AirPlay 를 리용하는 음성 및 영상 재생앱들, VoIP 앱들을 들수 있다.

UIBackgroundModes 속성값이 audio 로 설정된 경우에는 조작체계의 매체프레임워크가 해당 앱이 배경실행상태로 넘어갈 때 실행중지되는 현상을 자동적으로 방지해준다. 음성이나 동영상을 재생하는 동안 그 앱은 배경에서 계속 실행된다. 앱이 음성 혹은 동영상재생을 중지하면 조작체계는 앱의 실행을 중지시킨다.

배경음악재생에 관해서는 조작체계의 음성프레임워크중 임의의것을 리용할수 있으며 이러한 프레임워크를 리용한는 공정은 변하지 않았다. (AirPlay 를 통한 동영상재생을 하려면 Media Player Framework 를 리용하여야 한다.) 다매체를 재생하는동안 앱의 실행이 중지되지 않으므로 귀환함수기능들은 앱이 배경에서 실행되는 동안 정상동작한다. 그렇다고 해도 이 귀환함수들안에서 진행하는 작업들은 음성재생에 필요한 자료처리와 관련된 작업들이여야 한다. 실례로 실시간음성재생을 하는 앱들은 봉사기로부터 실시간음성자료를 받은 다음 받은 음성자료를 재생시킬수 있다. 재생과 관련이 없는 작업들은 진행해서는 안된다.

배경음악재생앱들이 여러개 존재할수 있으므로 조작체계는 특정한 순간에 음성을 재생할수 있는 앱들의 수를 제한한다. 전경작업앱들은 항상 음성재생에서 우선권을 가진다. 이외에 배경에서 실행하는 앱들은 매 앱의 음성쎄션객체설정에 따라 우선권이 결정된다. 앱의 음성쎄션객체는 항상 적절하게 설정하여야 하며 새채기처리나 다른 음성관련통보처리를 하는데서 조작체계의 프레임워크를 신중하게 리용하여야 한다.

배경실행중인 앱들의 음성쎄션객체를 설정하는 방법에 관한 정보에 대해서는 음성쎄션프로그람작성안내를 참고할것.

VoIP 앱의 실현

VoIP(Voice over Internet Protocol)앱은 휴대형장치의 이동통신봉사기능을 쓰지 않고 인터네트를 리용하여 전화할수 있는 기능을 제공한다. 이러한 앱은 해당 봉사기에 대한 안정된 인터네트련결상태가 필요하며 그래야 들어오는 호출 및 기타 관련자료를 받을수 있다. 조작체계는 VoIP 앱들을 항상 실행하게 하지 않고 실행을 중지할수 있는 기능과 앱들이 리용하는 소케트들을 감시하는 기능도 제공한다. 들어오는 통신자료가 검출되는 즉시 조작체계는 해당 VoIP 앱을 실행상태로 만든 다음 해당 소케트의 조종권을 앱에 넘긴다.

VoIP 앱의 설정항목(Configuration)들은 다음과 같다.

1. 앱의 Info.plist 파일에 UIBackgroundModes 마당을 추가하고 값을 voip 값이 포함된 배렬로 준다.

2. 앱의 소케트마당들중에서 VoIP 리용에 필요한 한개 소케트마당을 설정한다.3. 앱이 배경실행상태로 들어가기전 시점에서 setKeepAliveTimeout:handler: 메쏘드를 호출한다. 이 메쏘드안에는 주기적으로 실행할 코드를 써넣는다. 앱은 이 메쏘드를 리용하여 해당 봉사기와 련결을 지속적으로 유지할수 있다.

4. 음성쎄션을 설정하여 능동상태절환을 처리한다.

UIBackgroundModes 마당값에 voip 값을 포함시키면 조작체계는 앱이 배경실행상태에서 망련결을 유지할수 있도록 허용한다. 이러한 앱들은 또한 조작체계가 재기동한다음에도 다시 재실행되여 배경실행상태로 들어감으로써 언제든지 VoIP봉사기능리용을 리용할수 있도록 한다.

대부분의 VoIP 앱들은 망련결뿐아니라 배경음악재생을 위하여 배경음악앱으로도 설정을 한다. 그러므로 이러한 경우에는 UIBackgroundModes 마당값에 audio 와 voip값 두개를 다 포함시켜야 한다. 그렇지 않으면 그 앱은 배경실행상태에서 음성을 재생하지 못한다. UIBackgroundModes 마당에 대한 구체적인 정보에 관해서는 정보속성목록마당참고를 참고할것.

VoIP 앱을 실현하는데서 제기되는 특수한 정보들에 관해서는 VoIP 앱개발팁을 참고할것.

배경실행상태에서 Newsstand 자료의 내리적재

새로운 잡지나 신문기사들을 내리적재하는 Newsstand 앱들이 배경실행상태에서도 내리적재를 계속하려면 등록을 하여야 한다. 봉사기가 새로운 기사나 잡지가 적재되였다는것을 알리는 통보문을 보내여 띄우면 조작체계는 앱의 UIBackgroundModes 마당값이 newsstand-content 값을 포함하는가를 검사하고 포함하면 앱이 켜지지 않은 경우에는 앱을 새로 실행시킨다. 그러면 앱은 새로운 기사의 내리적재를 시작한다.

Newsstand Kit 프레임워크를 리용한 내리적재를 시작하면 조작체계가 내리적재과정을 맡아서 처리한다. 조작체계는 앱의 실행이 중지되거나 완전히 꺼진 상태에서도 내리적재를 계속한다. 내리적재가 다 되면 조작체계는 내리적재된 파일을 앱의 샌드복스에 전송한 다음 앱에 통보문을 날린다. 앱이 실행되고 있지 않은 경우에는 이 통보문을 리용하여 앱을 실행한 다음 해당 파일을 처리할수 있다. 내리적재도중 오유가 발생하는 경우에도 우와 류사하게 오유처리를 할수 있다.

Newsstand Kit 프레임워크를 리용한 자료내리적재에 대한 구체적인 정보에 관해서는 Newsstand Kit 프레임워크참고를 참고할것.

외부부품과의 통신

외부부품들과 작업하는 앱들은 앱의 실행이 중지된 경우에도 해당 부품에 관한 정보가 갱신될 때마다 실행을 재개할수 있다. 이러한 기능제공은 심장박동수를 재는 부품들과 같이 일정한 주기를 두고 자료전송을 진행하는 부품들에게 매우 중요한것으로 된다. 앱의 Info.plist 파일에서 UIBackgroundModes 마당값이 external-accessory 값을 포함하면 외부부품관련프레임워크는 해당 부품의 모든 능동쎄션들을 닫지 않고 열어놓는다. (iOS 4 와 그 이전 판본들에서는 앱의 실행이 중지되면 이 쎄션들도 함께 자동적으로 닫긴다.) 또한 부품으로부터 새로운 자료가 도착할 때마다 조작체계는 해당 앱을 실행 혹은 실행재개시켜 들어온 자료들을 처리하도록 한다. 또한 부품이 iOS장치에 련결되거나 련결이 끊길 때마다 해당 앱을 실행시켜 통보문을 보낸다.

배경실행상태에서 부품관련정보를 처리하려는 앱들은 다음의 기초적인 절차를 따라야 한다.

1. 부품관련사건통보를 시작 혹은 정지시킬수 있는 대면부를 사용자에게 제공하여야 한다. 대면부에서 사용자가 선택한것에 따라 부품쎄션을 열거나 닫아야 한다.

2. 어떤 사건에 의하여 앱의 실행이 재개되면 10 초안에 해당 자료의 처리를 끝내야 한다. 자료를 가능한껏 빨리 처리하고 자체로 실행중지상태에 들어가도록 하는것이 리상적이다. 하지만 10 초이상의 시간이 요구되는 경우에는 beginBackgroundTaskWithExpirationHandler: 메쏘드를 리용하여 추가시간을 요구할수 있다. 이러한 요구도 반드시 절대적으로 필요한 경우에만 하여야 한다.

응답가능한 배경앱

조작체계자원이나 하드웨어를 리용하는데서 전경앱은 배경앱들보다 항상 우선권을 가진다. 배경에서 실행되는 앱들은 이러한 우선권차이에 대응할수 있어야 하며 배경에서 실행하는동안에 진행할 행동들을 조절할수 있어야 한다. 특별히 전경에서 배경으로 실행상태가 이전되는 앱들은 이러한 절차를 따라야 한다.

1. 코드에서 OpenGL ES 를 호출하는 부분을 쓰지 말아야 한다. 배경실행상태에 있는 동안에는 EAGLContext 객체를 창조하거나 OpenGL ES 그리기명령을 쓰지 말아야 한다. 그렇지 않으면 앱은 그 즉시 완전히 꺼지게 된다. 또한 배경실행상태로 이전하기전에 이미 실행을 시작한 명령들을 다 끝내야 한다. 배경실행상태로 이전 혹은 복귀시 OpenGL ES 를 처리하는 방법에 대한 정보에 관해서는 iOS 용 OpenGL ES 프로그람작성법 에 있는 “다중과제처리용 OpenGL ES 의 실현”을 참고할것.

2. 실행을 중지하기전에 봉쥬르(Bonjour)와 관련된 모든 봉사기능들을 취소하여야 한다. 앱이 배경앱으로 되면서 실행이 중지되기전에 Bonjour 에 등록한 내용을 취소하고 열려있는 모든 망봉사관련소케트들을 닫아야 한다. 어쨌든간에 실행중지된 앱은 들어오는 봉사요청에 응답하지 못한다. 단지 이러한 소케트들을 닫음으로써 해당 봉사기능의 리용이 가능하지 못할때 가능한것처럼 보이는 현상을 방지한다. Bonjour봉사기능을 앱자체로 닫지 않으면 조작체계가 자동적으로 앱의 실행이 중지될 때 이 봉사기능들을 닫아준다.

3. 망기반소케트리용에서 망련결오유에 대한 처리를 해주어야 한다. 조작체계는 앱의 실행이 중지된 동안 앱과 관련된 소케트련결시도들을 차단할수도 있다. 소케트기반의 코드에서 신호분실 혹은 망의 변이현상과 같은 각종

망관련오유들을 처리하여준것만큼 이러한 오유가 발생할 때 별다른 문제를 유발시키는것과 같은 현상을 방지할수 있다. 앱의 실행이 재개될 때 소케트리용에서 어떤 오유가 발생하면 그냥 련결을 재설정하면 된다.

4. 배경상태로 들어가기전 앱의 현재실행상태정보들을 보관하여야 한다. 배경상태에 있는동안 조작체계가 관리하는 남은 기억기용량이 작은 경우 일부 앱들을 배경상태에서 없애버림으로써 기억공간을 마련하는 경우가 있다. 이러한 경우 실행정지상태에 있는 앱들부터 먼저 처리되며 이러한 앱들을 끄기전에 앱에 통보문같은것도 보내지 않는다. 그러므로 앱이 배경상태로 들어가기전에 반드시 상태정보를 충분히 저장하였다가 후에 필요하면 다시 이전 상태로 복귀할수 있도록 하여야 한다. 사용자대면부의 상태정보보관에 대한 정보에 관해서는 앱의 사용자대면부의 상태정보보관을 참고할것.

5. 배경상태로 이동할 때 불필요하게 쓰이는 기억공간들을 해제하여야 한다. 앱이 용량이 큰 기억기내부캐쉬객체를 리용하는 경우 (특히 화상, 그림객체들) 배경상태로 들어가기전에 그 캐쉬객체들에 대한 참조지적자들을 없애야 한다. 이와 관련한 구체적인 정보에 관해서는 배경앱의 기억기관리를 참고할것.

6. 실행을 중지하기전에 체계공유자원들에 대한 리용을 중지하여야 한다. 주소책이나 달력자료기지와 같은 공유된 체계자원들을 리용하는 앱들은 실행중지전에 이 자원들에 대한 리용을 중지하여야 한다. 이 자원들을 리용하는 우선권은 항상 전경앱이 높다. 실행중지된 앱이 공유된 체계자원을 리용한다는것을 알아차리는 즉시 조작체계는 그 앱을 완전히 꺼버린다.

7. 창문이나 보임구역을 갱신하는것을 피하여야 한다. 배경상태에 있는 앱들의 창문이나 보임구역들은 사용자에게 보이지 않으므로 배경상태에 있는동안에는 창문이나 보임구역을 갱신하는 일이 없어야 한다. 비록 창문이나 보임구역객체들에 대한 창조 및 조작이 앱을 완전히 꺼지게 하지는 않지만 전경상태로 돌아올 때까지 이러한 갱신은 하지 않는것이 좋다.

8. 외부부품과 관련한 접속/단절 통보문에 대한 응답처리를 진행하여야 한다. 외부부품들과 작업하는 앱들에 관하여 조작체계는 앱이 배경상태로 들어가는 경우 자동적으로 앱에 외부부품통신단절통보문을 보낸다. 해당 앱은 반드시 이 통보문을 등록하고 응답처리하는 코드안에서 현재 열려진 외부부품쎄션을 닫아야 한다. 앱이 전경상태로 돌아오면 마찬가지로 외부부품접속통보문을 앱에 보내여 앱이 외부부품과의 쎄션을 재개할수 있도록 한다. 이와 관련한 구체적인 정보에 관해서는 외부부품프로그람작성법을 참고할것.

9. 배경상태로 들어가기전에 active alert 에 쓰이는 자원들을 처분하여야 한다. 앱사이에 절환을 진행할 때 문맥(Context)을 보존하기 위하여 앱이 배경상태로

될 때 조작체계는 자동적으로 액션표(UIActionSheet)나 통보창(UIAlertView)을 무시하지 않는다. 배경실행상태로 되기전에 적당한 자원처분처리를 진행하는것은 개발자의 몫이다. 실례로 액션표나 통보창을 프로그람적으로 취소할수도 있고 혹은 앱상태를 후에 복귀(앱이 프로쎄스목록에서 없어진 경우)할수 있을만큼 충분한 문맥정보를 저장할수 있다. iOS 4.0 혹은 그 이전 판본의 iOS 에서 동작하도록 개발된 앱들에 관해서는 액션표와 통보창이 앱종료시에 무시되는데 이렇게 함으로써 앱의 취소처리함수가 실행될수 있는 기회를 제공한다.

10. 배경상태로 들어가기전에 민감한 정보들은 보임창에서 제거하여야 한다. 앱이 배경상태로 넘어갈 때 조작체계는 앱의 기본창화면을 그림으로 복사하였다가 앱이 다시 전경상태로 넘어올 때 화면에 현시해준다. applicationDidEnterBackground 메쏘드에서 되돌림명령을 실행하기전에 이 메쏘드안에서 사진으로 찍힐수 있는 암호나 기타 민감한 정보들을 숨기거나 희미한 효과처리를 해주어야 한다.

11. 앱이 배경상태에서 실행하는동안 될수록 적은 량의 작업을 진행하여야 한다. 배경앱에게 주어진 실행시간할당량은 전경앱보다 제한되여있다. 배경앱이 배경음악을 재생하거나 위치변경감시를 하여야 한다면 그 작업에만 열중하고 다른 필수적이 아닌 작업들은 후에 하도록 하여야 한다. 배경상태에서 너무 많은 실행시간을 소비하는 앱들은 조작체계에 의하여 실행이 저지되거나 경우에 따라서는 완전히 종료될수도 있다.

배경음악앱이나 기타 다른 배경에서 실행할만한 작업을 수행하는 배경앱들은 들어오는 통보문들에 대하여 보통처럼 응답한다. 다시 말하여 조작체계는 기억기공간부족 등에 대하여 그러한 현상이 일어나면 배경앱에게 통보문을 날린다. 또한 조작체계가 부족한 기억기공간을 마련하기 위하여 앱을 종료하여야 할 필요가 있는 상황에서도 조작체계는 앱의 delegate메쏘드인 applicationWillTerminate메쏘드를 호출하여 종료되기전에 필요한 처분작업들을 진행할수 있도록 한다.

배경실행상태에서 물러나기

만일 앱이 배경상태에서 실행되는 배경앱으로 되지 않도록 하려면 앱의 Info.plist파일안에 UIApplicationExitsOnSuspend 마당값을 YES 로 설정하면 된다. 이렇게 되면 앱은 not-running, inactive, active 상태들을 주기적으로 반복하면서 배경상태나

참고: 명시적으로 배경실행상태를 금지시키는것은 앱이 iOS SDK 4 나 그 이상의 판본의 iOS 들에 관해서만 필요하다. 그 이전판본의 iOS SDK 들에서는 배경실행상태를 제공하지 않는것을 원칙으로 하고있으므로 필요가 없다.

실행연기상태에 전혀 들어가지 않는다. 사용자가 Home 단추를 눌러 앱을 끄면 앱의 delegate메쏘드인 applicationWillTerminate메쏘드가 호출되고 이 안에서 5 초안에 필요한 처리를 진행한 다음 종료되여 not-running 상태로 넘어간다.

배경상태실행금지는 될수록 하지 않는것이 좋지만 일부 상황에서는 유용하게 쓰일수도 있다. 특히 배경실행에 필요한 코드작업이 매우 복잡한 경우 앱을 그냥 종료시키는것이 간단한 해결책으로 된다. 또한 배경상태에 있는 동안 앱이 많은 기억기공간을 차지하고 쉽게 기억기공간을 해제할수 없는 경우 조작체계가 앱을 다른 앱들이 실행할 기억기공간을 마련하기 위하여 그 앱을 꺼버리게 된다. 그러므로 이러한 앱들에 대해서는 배경상태로 이동하는것 대신 그냥 종료시키는것이 배경상태로 만들 때와 같은 결과를 낳게 되며 개발시간과 노력을 줄일수 있도록 한다.

앱의 Info.plist 파일에 추가할수 있는 마당과 관련한 구체적인 정보에 관해서는 정보속성목록마당참고를 참고할것.

동시성과 보조스레드 (Concurrency and Secondary Threads)

조작체계는 매 앱에 대하여 앱의 기본스레드를 자동적으로 창조한다. 이외에도 앱은 다른 작업수행에 필요한 보조스레드들을 더 창조할수 있다. 스레드창조를 위한 일반적인 방법은 조작체계에 의뢰하여 dispatch 대기렬과 operation 대기렬을 리용하는것이다. 대기렬은 비동기실행모델을 제공한다. 대기렬에 과제를 제출하면 조작체계가 스레드들을 돌면서 해당 작업을 수행한다. 스레드관리를 조작체계에 맡기면 코드를 간단하게 할수 있으며 조작체계는 스레드관리를 가장 효률적으로 진행한다.

앱의 기본스레드밖에서 해야 할 일들에 대해서는 가능한껏 대기렬을 리용해야 한다. 기본스레드는 손입력(touch)이나 그리기사건들에 대한 처리를 진행하므로 기본스레드안에서는 지나치게 실행시간이 긴 작업을 수행하지 말아야 한다. 실례로 앱의 기본스레드안에서 망통신응답신호를 기다리는것과 같은 작업을 하지 말아야 한다. 이러한 작업들은 대기렬을 리용하여 비동기요구를 보낸 다음 응답이 도착하면 결과를 처리하는 방법이 훨씬 낫다.

중요사항: iCloud 에 대한 접근은 권한(entitlement)을 리용하여 조종되며 이 권한은 앱이 Xcode 를 통하여 설정한다. 이러한 권한이 설정되여 있지 않으면 그 앱은 iCloud 에 있는 파일들과 기타 자료에 접근할수 없게 된다. 앱의 iCloud 권한설정에 대한 구체적인 정보에 관해서는 앱의 iCloud 권한설정을 참고할것.

작업들을 보조스레드화 하는데서 중요한것은 또한 스레드의 실행시작시간량이다. 모든 앱들은 실행후 제한된 시간내에 (약 5 초) 초기설정을 진행한 다음 사건처리를 시작해야 한다. 앱의 기본스레드에서 실행시간보장에 지장을 주거나 보조스레드에서 처리할수 있는 작업들은 그 즉시로 보조스레드로 옮겨 수행해야 한다. 이러한 경우 기본스레드는 사용자대면부현시와 사건처리에만 쓰인다.

dispatch 와 operation 대기렬을 리용한 과제처리에 관한 구체적인 정보에 대해서는 동시성프로그람작성법을 참고할것.

iCloud 저장매체

iCloud 저장매체(iCloud Storage)는 서로 다른 장치들에서 실행되는 앱들사이에 자료를 공유하는데 쓰이는 대면부와 봉사기능의 모임이다. iCloud 에 대한 착상은 여러 앱들이 자료를 한곳에 저장할수 있도록 하자는것에서 제기되였다. 어떤 앱이 자료를 변경시키면 사용자의 다른 장치들에 그 자료가 원활하게 전송되여 그 장치들에서 실행되는 앱들도 변경된 자료를 볼수 있도록 한다. 이렇게 하면 장치들사이에 자료를 동기화하거나 콤퓨터를 하브처럼 리용하여 사용자의 파일과 자료들을 저장하는것과 같은 필요를 없앰으로써 일관된 사용자경험을 만들게 된다.

iCloud Storage 를 앱에 적용시키는데는 두가지 방법이 있다.

1. iCloud 문서저장매체 – 사용자의 iCloud 계좌에 사용자의 문서나 사용자앱의 자료들을 보관한다.

2. iCloud 마당-값자료저장매체 – 사용자앱의 위태롭지 않은 설정자료들을 보관한다.

iCloud 대면부들은 대부분 사용자대면부가 아니라 사용자의 파일자료들을 관리하는데 목적을 두고있다. iCloud Storage 를 앱에 적용하려면 앱의 자료모델과 파일들을 추적하고 관리하는 방법을 변경시켜야 한다. 또한 앱에 따라 앱의 사용자대면부나 전체적인 앱설정을 변경하여야 할 필요가 제기될수도 있다. 또한 iOS 와 Mac OS X장치들사이에 파일들을 공유하기 위하여서는 파일형식들도 재창조할 필요가 있다.

iCloud 앱의 설계에 관한 고려사항

iCloud 적용시 처음으로 결정해야 할 사항은 문서저장방식과 마당-값자료저장방식 두가지중 어느것을 선택하는가 하는것이다. 문서저장방식은 앱이 내부적으로 창조 및 관리하는 자료들과 사용자가 창조한 파일들, 그리고 기타 다른 수단에 의해서 접근가능한 자료들을 저장하는데 쓰인다. 문서저장방식은 문서처리앱과 같이 사용자에 의해 창조 및 관리되는 자료들이 기본을 이루는 앱을 위한 방식이다. 그러나 앱이 자체로 내부적으로 필요해서 창조하는 자료파일들에 대한 관리에도 쓰일수 있다. 마당-값자료저장방식은 여러 앱들사이에 공유할수 있는 위태롭지 않은 설정자료를 저장하는데 기본적으로 쓰인다. 실례로 앱의 사용자설정이나 앱의 실행에 보조적으로 영향을 주는 기타 다른 비트자료들을 보관하는데 마당-값자료저장방식을 쓸수 있다. 사용자에 의해 창조 및 관리되는 자료들에 관해서는 마당-값자료저장방식을 쓰는것을 피하여야 한다.

다음의 표 4-1 에서는 iCloud Storage 를 둘러싼 주요 리용방식에 대해서와 그리고 문서저장방식과 마당-값자료저장방식이 리용방식에서 어떻게 차이나는가에 대한것을 지적하고있다.

표 4-1 문서저장방식과 마당-값자료저장방식의 차이점

속성 문서저장방식 마당-값자료저장방식관리하는 자료종류

파일 및 등록부 속성목록자료형

언제 리용하는가

앱에 절실하게 필요되는 자료를 관리할 때 리용할수 있다. 앱의 기본자료모델과 직접적으로 관련된 파일 및 자료들을 관리하는데 문서저장방식을 쓴다. 즉 사용자문서나 앱의 내부자료파일들, 앱 혹은 사용자에 의해 생성된 자료파일들을 관리하는데 이 방식을 쓴다.

파일존재지적자와 파일조정지적자가 필요한가

예 아니

자료탐색방법 NSMetadataQuery 객체를 리용하여 파일을 탐색한다.

기정의 NSUbiquitousKeyValue 를 리용하여 마당에 해당한 값을 검출해낸다.

자료관리방법 NSFileManager클라스를 리용. 표준파일체계루틴을 리용하여 파일의 열기, 닫기, 읽기, 쓰기조작 진행

NSUbiquitousKeyValueStore 객체를 리용하여 마당/값을 설정하거나 얻는다.

저장할수 있는 자료크기

사용자의 iCloud 계좌에 설정된 크기로 제한된다.

64KB 로 제한된다.

충돌처리방법 앱의 파일존재지적자를 리용하여 충돌현상을 수동으로 풀어야 한다.

리용하기 위한 권한

com.apple.developer.ubiquity-container-identifiers

com.apple.developer.ubiquity

자료의 동기화 시간

iCloud 는 자료에 변경이 생기는 즉시로 파일의 메타자료와 기본자료를 해당 장치로부터 꺼낸다. 장치들은 파일의 메타자료는 항상 꺼내지만 대체로 변경된 자료는 그 자료를 리용할 때가 오기전까지는 꺼내지 않는다.

실행시 iCloud봉사에 접속가능한가

registered container 등록부들중 하나에 대하여URLForUbiquityContainerIdentifier메쏘드를 호출한다. 메쏘드가 nil 값을

검사하는 방법

돌려주면 문서저장방식은 리용가능하지 못한 상태에 있음을 나타낸다.

제공되는 사용자대면부

없음. iCloud 는 대체로 자료저장이 목적이므로 iCloud 자료를 원활하게 전송받고 사용자대면부에는 될수록 변경을 가하지 말아야 한다.

없음.

iCloud 앱설계에서 고려해야 할 다른 사항은 앱의 사용자대면부에 iCloud봉사기능을 어떻게 포함시킬것인가이다. 특히 문서자료들에 대해서 볼 때 사용자에게 문서의 상태 즉 문서의 내리적재가 다 되였는가 혹은 풀어야 할 판본충돌이 있는가 등에 대하여 알려주어야 할 때가 있을수 있다. 이러한 상황에서는 사용자에게 적당한 정보를 전달하기 위한 객체요소를 사용자대면부에 추가해주는것이 좋다. 사용자대면부갱신에 대한 구체적인 정보에 관해서는 iCloud 사용자대면부갱신을 참고할것.

앱의 iCloud 권한설정

iCloud 를 리용하는 앱들은 반드시 iCloud 용 권한을 할당받아야 한다. 이러한 권한은 자료를 창조한 앱들만이 그 자료에 접근할수 있도록 함으로써 앱에 일정한 수준의 보안을 보장하여준다. 또한 조작체계는 이 권한을 사용자의 iCloud 저장공간에 있는 여러 자료들을 앱별로 구분하는데 리용한다.

iOS 앱의 iCloud 권한을 Xcode 에서 능동시키려면

1. Xcode 에서 앱의 목표(target)를 선택한다.2. 요약(Summary)표쪽(tab)을 선택한다.3. 권한(Entitlements)부분에서 Enable Entitlements 검사칸을 능동시킨다.

제 4 장

iCloud 저장

당신에 App 의 이름을 붙일수 있을때 Xcode 는 자동적으로 응용프로그람의 문서저장과 key-value 자료저장의 이름달기를 진행한다. 각각의 자격은 자격 구성되어 값이 하나 이상의 집합 식별자 문자렬입니다 .집합 식별자 문자렬이 다음 중 하나를 식별 iCloud 집합 등록부는 응용프로그램의 파일을 저장하는 데 사용합니다. Xcode 는 다음과 같이 이름달기를 한다:

- iCloud 용기 마당은 응용 프로그램이 사용자의 iCloud 저장소에 접근할 수있는용기 등록부의 목록을 식별합니다. (이 마당은 com.apple.developer.ubiquity - 용기 식별자에 해당합니다.) 문자렬은 당신이 추가한 이 목록은 당신의 팀에 의해 만들어진 응용프로그람에 대한 식별자와 일치해야합니다. Xcode 는 첫 번째 문자렬을 지정하기 위해 현재 응용프람의 식별자를 사용하며, 여러 개의 응용프로그람의 주요 자료 등록부를 공유하고 싶다면 당신은 다른 식별자 를 변경할 수 있습니다. 당신은 또한 당신의 팀의 다른 응용프로그람에 대한 추가 식별자를 추가할 수 있습니다. (첫 번째 문자렬은 어떤 Wild 카드 문자를 포함해서는 안되지만 별도로 모든 식별자를 지정하지 않으 수있다면 이후의 문자렬을 포함할수 있다.)

- iCloud Key-Value 저장 마당은 응용 프로그램에 대한 iCloud Key-Value자료저장에 대응하는 하나의 Container 식별자 문자렬을 포함하고 있습니다. (이 마당은 com.apple.developer.ubiquity-kvstore-식별자 에 해당합니다.)

당신이 Xcode 에서 지정한 식별자는파일에 기록되는 정규화된 Container 식별자 문자렬을 대신하지 않습니다.정규화된 Container 식별자 형식은 <TEAM_ID>입니다. <TEAM_ID>는 개발 팀과 <BUNDLE_IDENTIFIER>입니다 연관된 독특한 문자열 식별자입니다 <BUNDLE_IDENTIFIER>는 iCloud Container 에 식별자 중 하나입니다

코드에서 Container 등록부에 대한 URL 을 검색하면 URLForUbiquityContainerIdentifier 에 대한 정규화된 문자렬을 전달해야합니다. 그러나 여러분은 목록의 첫 번째 Container 등록부에 대한 URL 을 검색하는 방법으로 전달할 수 있습니다.

참고 : 애플 개발자 홈페지(http://developer.apple.com/membercenter)에서 사용자 관리에서 개발 팀의 고유한 <TEAM_ID> 값을 찾을 수 있습니다.

사용자관리 홈 페지에서 당신의 계정 항목을 선택한 다음 해당 항목의 왼쪽 목록에서 개인자료를 선택합니다.

당신 팀의 식별자는 회사 / 조직 ID 마당에 있습니다.

iCloud 문서 저장을 사용하는 응용프로그람들의 파일에 여러 개의 Container 식별자를 지정하여 다중 Container 등록부의 내용을 읽고 쓸 수 있습니다.iCloud Container 마당은 여러 문자렬을 지정할 수 있습니다. 이 마당의 첫 번째 문자렬은 항상 당신의 응용프로그람에 대한 기본 Container 식별자이여야합니다. 어떤

추가적인 문자렬은 다른 응용프로그람을위한 Container 식별자를 나타냅니다 검색이 가능한 Container 의 모든 등록부에서 파일의 병합된 집합을 반환합니다. IOS 응용 프로그람을 구성하는 방법에 대한 자세한 내용은 IOS 응용프로그람 개발 작업흐름 설명서의 "Configuration Applications"을 참고하십시오.

iCloud 문서 저장의 사용

iCloud 문서 저장소는 사용자의 iCloud 계정으로 파일과 등록부를이동하고 거기서 그들을 관리할 수 있습니다.

한 개의 장치에있는 파일이나 등록부에 대한 변경 사항이 아니라 그림 4-1 과 같이 지역의 데몬을 사용하여 iCloud 압력을 가한 후 로컬 저장됩니다. 파일 및 각 장치의 전송은 응용 프로그람에 투명합니다.

따라서, 응용프로그람은 단순히 파일에 동작합니다.

iCloud 저장

그림 4-1

iCloud 문서 저장을 활용하도록 응용 프로그람을 설계하는 것은 몇 가지 중요한 변화가 필요합니다.

필요한 주요 변경 내용은 다음과 같습니다

- 방법 iCloud 가 활성화되어 있는지 확인합니다 : 당신의 응용 프로그람의 실행시에 URLForUbiquityContainerIdentifier 호출하십시오. 이 메소드를 호출하면 또한 응용 프로그람의 요청된 Container 등록부 각각을 포함하도록 응용 프로그람을 확장할 필요가 있습니다, (66 페지) "iCloud 문서 저장소를 사용할 수 있는가를 결정"을 참고하십시오.

- 명시적으로 파일 발표자 (례 : UIDocument 클라스 등)의 자료 계층에를 통합, (66 페지) "당신의 작업흐름으로 통합하는 파일 발표자"를 참고하십시오.

- 명시적으로 iCloud 로 파일을 이동; "iCloud 의 조작 파일과 등록부"(66 페지)을 참고하십시오.

- 파일 버전 충돌을 처리하기 위해 준비를 참조 (페지 67) "버전 충돌에 대응하는 전략을 선택."

- iCloud 에서 파일을 찾으려면 검색을 유용하게 사용할; (페지 68) "당신의 내부 통합 검색"을 참고하십시오.

- 파일 iCloud 에 있지만 완전히 로컬 장치에 다운로드하지 않은 사건을 처리하기 위해 준비, 이것은 feedbacl 과 사용자를 제공 설치해야 할 수도 있습니다; 참조 "파일이나 등록부의 전송 상태 확인"(페지 69).

- 당신 iCloud 에서 live 자료기지를 저장하려는 경우 공동 자료를 사용하여, SQLite 는 사용하지 마십시오.

- 당신은 또한 응용 프로그람의 Mac OS X 버전이있는 경우, 두 응용프로그람을위한 일반적인 문서 형식을 사용합니다.

iCloud 을 지원하는 당신의 작업의 대부분은 당신의 응용프로그람의 자료 계층에서 발생합니다. iCloud 과 상호 작용하여 응용 프로그람 자료를 저장하는 데 사용하는 파일과 등록부를 통해 주로 발생합니다. 그러나 당신은 또한 기본 자료 변경 사항은 응용 프로그램의 사용자 대면부를 가지고 영향을 고려해야합니다.

가능하다면 사용자는 파일을 로컬로 또는 iCloud 에 저장되는지 여부를 상관하는 게 아니다 사용자경험이 낮아지는 경우에는 례외이다

iCloud 문서 저장이 가능한가를 결정

Apple 식별자를 가진 모든 사용자는 무료 iCloud 계정을 받고 있지만, 일부 사용자들은 특정 장치 iCloud 사용하지 않도록 선택할 수도 있습니다.

iCloud 가 활성화되어 있는지 확인 방법 : 당신이 다른 iCloud 대면부를 사용하려고하기 전에 URLForUbiquityContainerIdentifier 를 호출해야합니다.

iCloud 가 활성화 (그리고 지정된 Container 등록부를 사용할 수있는) 또는 iCloud가 능동이 안됐을때 이 메소드는 유효한 URL 을 반환합니다.

당신이 URLForUbiquityContainerIdentifier 처음 호출했을때 : 지정된 Container 등록부에 대한 방법은, IOS 는 Container 등록부를 포함하도록 응용 프로그람 틀거리를 확장합니다.

따라서, 당신이 iCloud 가 기본 Container 등록부에 접근할 수 있는지 활성되도록 적어도 한번의 메서드를 호출하는 것이 중요합니다.

응용 프로그람이 여러 Container 등록부를 접근하고있다면, 당신은 각 등록부에 대해 한번씩 메서드를 호출해야합니다.

당신의 작업흐르에서 파일현시자와의 통합

iCloud 에 저장된 모든 파일과 등록부는 파일 현시 객체에 의해 관리되어야하고, 이러한 파일과 등록부를 만드는 모든 변경이 파일 조종객체를 통해 발생합니다.

파일 현시자는 NSFilePresenter 규약을 채택한 객체입니다.파일 현시자의 임무는 주어진 파일이나 등록부에 대한 책임있는 대리인 역할을하는 것입니다.

외부 원천 파일을 변경하기 전에 해당 파일에 등록된 파일 현시자에게 통지하고 필요한 장부 정리 작업을 수행할 수있는 기회가 즈어진다. 당신의 응용 프로그람이 파일을 변경하자면, 그것은 본질적으로 NSFileCoordinator 객체를 통해 그 변화를 만들어 파일을 보호해야합니다.

파일 조종 동시에 파일을 수정하는 외부 원천을 방지하고 다른 파일 현시자에 해당한 알림을 전달합니다.

당신의 응용 프로그람으로 파일 현시자를 통합하는 가장 간단한 방법은 UIDocument 클라스를 사용하는 것입니다. 이 클라스는 NSFilePresenter규약의 메서드를 구현하고 당신을 위해 파일 관련 관리를 모두 처리합니다.

그렇게 되면 여러분의 응용 프로그람이 해야하는것은 모든 문서 데이터를 읽고 쓰는것이다

당신은 사용자 생성 내용을 포함하는 파일 (그래서 사용자에게 직접 표시되는)과 당신의 응용프로그람이 사용자를 대신 생성하고 사용자 개입없이 관리되는 파일에 대해 모두 UIDocument 클라스를 사용할 수 있습니다.

당신의 응용 프로그람의 자료 구조로 UIDocument 클라스를 포함하는 방법에 대한 자세한 내용은 IOS 를위한 문서 기반 응용 프로그람작성안내서를 참고하십시오.

파일 및 등록부를 관리하기 위해 사용자 정의 파일 현시자를 만드는 방법에 대한 자세한 내용은 파일 체계 프로그람작성 참고하십시오.

iCloud 에서 파일들과 등록부들을 조종하기

Apple 응용프로그람들은 local 파일과 등록부에 대해 수행하는 iCloud 에있는 파일과 등록부를 관리하는 동일한 기술을 사용합니다.

iCloud 에서 파일과 등록부는 여전히 파일과 등록부일뿐입니다.

당신은 그것들을 만들고 그것들을 이동, 그것들을 복사 읽고 그것들로부터 작성, 삭제하거나 당신이 원하는 모든 조작들을 할 수 있습니다

local 파일 및 등록부와 iCloud 파일과 등록부 사이의 유일한 차이점은 당신이 그들을 접근하는 데 사용하는 URL입니다. 대신 URL 에 해당 응용프로그람의 기틀에 상대되는 중에 iCloud 파일 및 등록부에 대한 URL 은 해당 iCloud Container 등록부에 상대적입니다.

다운 되지 않은 파일들과의 작업

(BOOL)downloadFileIfNotAvailable:(NSURL*)file {NSNumber* isIniCloud = nil;if ([file getResourceValue:&isIniCloud forKey:NSURLIsUbiquitousItemKeyerror:nil]) {// If the item is in iCloud, see if it is downloaded.if ([isIniCloud boolValue]) {NSNumber* isDownloaded = nil;if ([file getResourceValue:&isDownloadedforKey:NSURLUbiquitousItemIsDownloadedKey error:nil]) {if ([isDownloaded boolValue])return YES;// Download the file.NSFileManager* fm = [NSFileManager defaultManager];[fm startDownloadingUbiquitousItemAtURL:file error:nil];

return NO;}}}// Return YES as long as an explicit download was not started.return YES;

}

변경 iCloud 의 파일에 발생하면 IOS 장치는 자동으로 변화와 연관된 자료를 다운로드하지 않습니다. 그들은 변화가 있는지 알 수 있도록 대신, IOS 디바이스 파일에 대한 meta 자료를 다운로드하십시오.

다음 중 하나가 발생할 때까지 파일의 실제 자료가 다운로드되지 않습니다 :

-당신의 응용 프로그람이 파일을 열거나 접근하려고 시도합니다.

-오유 : 메서드를 명시적으로 변경 사항을 다운로드하도록 하는 응용 프로그람은 startDownloadingUbiquitousItemAtURL 를 호출합니다.

당신의 URL 에 사용할 수 iCloud 관련 속성에 대한 자세한 내용은 NSURL 클라스 참조를 참고하십시오.

iCloud 에서 당신의 사요자 대면부를 갱신

iCloud 관련된 당신이 만드는 모든 사용자 대면부 변경 사항은 사용자에게 최대한 눈에 보이지 말아야합니다.

당신 iCloud 에 저장할 문서는 iCloud 를 사용할 수없는 때 로컬로 저장할 같은 것들입니다.

유일한 차이점은 파일 체계에서의 위치입니다.

따라서 사용자 대면부의 대부분은 똑같이 보여야 한다.

가끔 당신은 iCloud 에 대한 사용자 대면부를 수정할 수도 있습니다. 당신의 대면부를 수정 :

-그것을 사용하기 전에 사용자가 만든 문서가 다운로드해야합니다. 응용 프로그람의 문서를 Browser 의 일종을 제시하는 경우 문서를 다운로드하는것을 통해 사용자 정의 조종 주는것이 필요합니다.

그들이 사용할 수없는 경우 응용 프로그람을 개인적으로 관리하는 파일의 경우 자동으로 다운로드합니다.

당신이 사용하는 모든 Point 는 문서를 다운로드하는 시작 선택을 사용자에게 제공해야합니다.

다운로드가 몇 초 이상 걸릴 경우에는 현재 다운로드 진행 상황을 표시할 수 있습니다.

-Version 충돌이있을 때 사용자가 해결합니다.

Version 충돌은 동일한 문서를 동시에 두 가지 장치에서 수정되었을 때 발생할 수 있습니다.

(변경 사항이 만들 어질 때 장치 중 하나가 망에 련결되어 있지 않은 경우에 발생할 수 있습니다.) 당신의 응용 프로그람이 충돌을 해결하기 위해 사용자의 도움을 필요로하는 경우,이 사건임을 알린다.경고 또는 충돌이 존재한다는 것을 사용자에게 통보하는 파괴적인 대면부의 여러 종류를 표시하지 마십시오.

(또한 클라스의 managedObjectModel 속성을 수정하여 파생클라스의 객체모델을 개별화할수 있다.) 대부분 자료들은 객체콘텍스트(object context) 에 의해 다뤄지기때문에 흔히 파생없이 UIManagedDocument 클라스를 리용할수 있다. 보관과 같은 동작들은 모든 문서들에 제공되는 자동보관기능에 의해 자동적으로 처리된다.

새 문서를 열때 아래와 같은 순서로 한다.

1. UIManagedDocument 클라스객체를 창조한다.

2. 'NSPersistentStoreUbiquitousContentNameKey' 키를 당신의 문서의 persistentStoreOptions 속성에 추가한다. 이 키의 값은 문서를 식별하는데 쓰이는 유일한 값이다.

3. 문서에 자료를 입력한다.

4. saveToURL:forSaveOperation:completionHandler 메쏘드를 리용하여 디스크에 문서를 보관한다.

이때 iCloud 에 직접 보관할수가 있도 내부등록부에 보관하고 후에 iCloud 에 옮길수도 있다. iCloud 에 직접 보관할때 URLForUbiquityContainerIdentifier 메쏘드에 의해 돌려지는 주소에 기초한 url 을 지정한다. 내부등록부에 보관할때는 setUbiquitous:itemAtURL:destinationURL:error메쏘드를 리용하여 후에 iCloud 에 옮길수 있다.

iCloud 에 보관된 문서를 열때는 아래와 같이 한다.

1. NSMetadataQuery 객체를 리용하여 iCloud 에 있는 문서를 찾을수(search) 있다.

2. DocumentMetadata.plist 파일을 열고 NSPersistentStoreUbiquitousContentNameKey 키값을 얻는다.

3. UIManagedDocument클라스객체를 창조한다.

4. NSPersistentStoreUbiquitousContentNameKey 값을 persistentStoreOptions 속성에 보관한다. 이때 이 값은 DocumentMetadata.plist 파일로부터 얻은 값이여야 한다.

5. openWithCompletionHandler 메쏘드를 리용하여 문서를 연다.

당신의 앱이 다른 장치에 창조된 Core Data 문서를 처음으로 열때 Core Data 는 자동적으로 SQLite Store 의 존재를 확인하고 국부적으로 창조한다. 다음으로 NSPersistentStoreUbiquitousContentNameKey 값을 리용하여 해당 transaction 로그를 얻고 자료기지의 내용을 다시 구성한다. 이 시점에서 당신은 문서의 내용을 변경하여 다시 iCloud 에 보관할수 있다. 당신이 만든 변경내용은 새로운 로그파일에 보관되여 다른 장치들의 SQLite Store 들에 통합된다.

iCloud 로부터 문서의 변경내용을 받으면 Core Data 는 자동적으로 문서의 SQLite Store 에 보관하여 당신의 앱에 NSPersistentStoreDidImportUbiquitousContentChangesNotification 을

발송한다. 앱들은 늘 이 알림문을 받을수 있어야 하며 변경이 있은 레코드들에 대한 재구성을 해야 한다. 만약 당신의 앱이 국부적으로 보관된 자료의 복사본을 갱신할수 없다면 iCloud 에 낡은 자료가 다시 복사되면서 자료의 불일치가 일어난다. 변경된 내용을 통합하는것으로 이 문제를 해결해야 한다.

문서를 지우려고 할때는 그 문서의 파일패키지와 transation 로그파일들을 보관하는 등록부를 같이 지워야 한다. DocumentMetadata.plist 파일이 NSPersistentStoreUbiquitousContentURLKey 값과 transaction 로그등록부의 URL을 보관한다. 파일 coordinator 의 리용에 대해서는 File System Programming Guide 를 보라.

당신 앱의 객체들을 관리하는데 Core Data store 들이 어떻게 리용되는가에 대해서는 Core Data Programming Guide 를 참조하시오.

Core Data 를 리용하여 Central Library 관리

앱의 자료를 관리하기 위하여 중앙적인 Core Data store 를 리용하는 앱은 data store를 앱 샌트복스 등록부에 보관하는것을 반복해야 한다. 중앙적 data store 를 리용하는 앱들은 전형적으로 단 하나의 persistent store coordinator 객체와 하나의 persistent store 객체를 가진다.

국부적으로 SQLite store 를 창조할때 다음과 같이 한다.

1. NSPersistentStoreUbiquitousContentNameKey 와 NSPersistentStoreUbiquitousContentURLKey 값들을 data store 를 창조할때 호출하는 addPersistentStoreWithType:configuration:URL:options:error 메쏘드에 같이 넘긴다.

2. NSPersistentStoreDidImportUbiquitousContentChangesNotification 을 등록하고 레코드변경들에 리용해야 한다.

단하나의 data store 를 리용하기때문에 NSPersistentStoreUbiquitousContentNameKey 에 임의의 값을 줄수 있다.

당신앱은 항상 iCloud 에 관련된 변경내용에 대응해야 한다. 이런 신호들은 당신앱이 늘 갱신된 값들을 리용할수 있도록 해준다. 만약 계속 낡은 자료를 리용한다면 새로운 자료를 덛쓰기할수도 있고 버젼 충돌도 있을수 있다.

Core Data Store 를 어떻게 창조하는가에 대해선 Core Data Programming Guide를 참고하시오.

Core Data Transaction 로그를 위한 경로지정

앱의 Core Data store 들의 갱신내용을 보관하는데 쓰이는 transaction 로그들은 해당 사용자의 iCloud 구좌에 있는 특수한 등록부에 보관된다. 앱의 모든 Core Data Stores를 위한 단 하나의 등록부가 있다. 기정으로 등록부이름은 앱의 식별자와 같으며 앱의 기정 iCloud 등록부의 맨 웃준위에 위치한다.

iCloud Key-Value Data Storage 의 리용

환경정보들이나 중요치 않은 설정자료 보관만 원하는 앱들은 iCloud 의 Key-Value data store 를 리용할수 있다. Key-Value data store 는 개념상으로 앱의 정보들을 보관하는데 리용하는 사용자기정의 국부자료기지와 류사하다. 차이점은 iCloud store의 키들이 다른 장치들에서 동작하는 모든 앱객체들에 의해 공유된다는것이다. 결과 한앱이 키값을 변경하면 다른앱들은 그 변화를 볼수 있고 저들의 설정을 갱신하는데 리용할수 있다.

NSUbiquitousKeyValueStore 클라스를 리용하는 앱들은 com.apple.developer.ubiquity-kvstore-identifier 를 요구한다. 이 하나의 같은 값으로 여러개의 앱들을 configure 하면 모든앱들이 같은 key-value 자료를 공유한다. 참고: "Configuring Your App's ICloud Entitlements" 63페지

key-value data store 에 자료를 입력하려면 NSUbiquitousKeyValueStore클라스를 리용한다. 이 클라스는 개념상으로 일반자료형들을 보관하고 얻는데 리용되는 NSUserDefaults클라스와 류사하다. 큰 차이는 NSUbiquitousKeyValueStore클라스는 자료를 국부가 아닌 iCloud 에 쓴다는것이다.

앱의 key-value store 의 가능한 용량은 64kb 이다. 따라서 사용자문서나 큰 자료보다는 작은 정보들을 보관하는데 리용해야 한다. 실례로 잡지앱은 최근소식이나 사용자가 읽고있는 페지번호같은것을 보관할것이다. 이렇게 사용자가 다른 장치에서 앱을 열때 이 앱은 그 사용자가 보던 페지를 열어줄것이다.

NSUbiquitousKeyValueStore클라스는 NSUserDefaults클라스의 대신 사용할수 없다.

앱은 NSUserDefaults클라스를 리용하여 디스크에 모든 configuration 정보를 보관한다. 또한 NSUbiquitousKeyValueStore클라스를 리용하여 key value data store 를 공유한다.

참고: Preferences and Settings Programming Guide.

Being Responsible Icloud App

Icolud 보관기능의 우점을 가진 앱은 자료를 보관할때 책임적으로 동작한다. 매 사용자계정에 가능한 용량은 제한되고 모든 앱들에 의해 공유된다. 사용자들은

얼마만큼의 용량이 앱에 의해 사용되였는지 볼수 있으며 앱과 관련된 문서들과 자료들을 지울수 있다. 아래에 문서들을 옳바로 관리할수 있는 몇가지 요령이 있다.

1. icolud 문서를 보관하는데 적당한 방법론을 가져야 한다. 가능하면 사용자에게 icolud 에 모든정보를 보관할수 있도록 해야 한다.

2. 어떠한 문서를 지운다는것은 사용자 icloud 계정에서와 그 사용자의 모든 콤퓨터와 장치들에서 지운다는것이다. 사용자들이 이점을 정확히 알고 지우는 동작을 확인할수 있게 하여야 한다.

3. icolud 에 문서를 보관할때 가능한껏 ,documents 등록부 에 보관해야 한다. Documents 등록부에 보관된 문서들은 용량을 위해 사용자들이 개별적으로 지울수 있다. 그러나 이 등록부밖의 문서들은 자료로 취급되므로 단 한번에 지울수 있다.

4. Icloud storage 에 앱의 캐쉬나 private 정보를 보관하지 말아야 한다. Icloud 사용자 계정은 반드시 사용자관련정보와 앱에 의해 재창조될수 없는 내용들만을 보관해야 한다.

5. Icloud 안의 파일들을 사용자의 앱샌드복스안의 다른 파일들처럼 다뤄야 한다,

앱관련 정보들

그림이나 매체파일들과 같이 앱은 화면에 현시된다. Ios 자체가 앱에 요구하는 특별한 자료들이 있다. 체계는 이러한 정보들을 리용하여 앱을 사용자의 화면에 어떻게 현시할것인지, 체계의 다른 부분들과 어떻게 호상련결할것인지를 결정한다

App Store Required Resources

App store 에 앱을 제출하기 전에 앱에 제공하여야 할 몇가지 문제가 있다.

1. 앱은 반드시 info.plist 파일을 가져야 한다. 이파일은 체계가 앱과 호상작용하는데 필요한 정보를 포함하고 있다. Xcode 는 자동적으로 이파일을 창조하지만 대부분의 앱들은 어떠한 방법으로 이 파일을 수정해야 한다. 참고자료: “The Information Property List File”(Page 77)

2. 앱의 info.plist 파일은 UIRequiredDeviceCapabilities 키를 포함해야 한다 App Store 는 이 키를 리용하여 사용자가 당신의 앱을 해당 장치에서 실행할것인지 말것인지를 결정한다. 참고자료 “Declaring the Required Device Capabilities”(page 78)

3. 앱은 앱을 현시하는데 리용되는 아이콘을 한개 혹은 그이상 요구한다. 이 아이콘은 ios 장치의 홈화면에 현시된다. 참고자료: app Icons (페지 81)

4. 앱은 앱이 실행하면서 현시할수있는 그림을 적어도 한개 가지고 있어야 한다. 체계는 앱의 기동이미지를 보여준다. 참고자료 “app Lanuch (default) Images(페지 83)”

The Information Property List File

앱의 속성정보리스트(info.plist)파일은 그 앱의 환경설정에 필요한 중요한 정보들을 포함하고 있으며 앱묶음에 반드시 포함되야 한다. Xcode 에서 창조되는 매 프로젝트들은 기정의 info .plist 파일은 가지고 있는데 그 프로젝트에 대한 가장 기초적인 정보들을 제공한다. Shipping 앱에 대해서는 몇가지 중요한 키들을 추가해야 한다.

앱의 info.plist 파일은 반드시 아래의 키들을 가지고 있어야 한다.1. UIRequiredDeviceCapabilities – App Store 는 이 키를 리용하여 앱의

능력을 결정하며 앱이 필요로 하는 기능들을 제공하지 못하는 일부 장치들에 대해서는 설치되지 않도록 막는다. 참고자료: Declaring the Required Device Capabilities 페지 78

2. CFBundleIcons – 앱의 아이코파일을 설정하는 기정키다. 지난 프로젝트들에는 CFBundleIconFiles키를 대신 가지고 있다. 이 두개의 키들은 기본적으로 같은 목적으로 사용되지만 CFBundleIcons키가 당신의 앱의 아이콘을 더 효률적으로 조직화하기 때문에 기정키로 된다.

3. UISupportedIntefaceOrientations – 이 키는 Xcode 에 의 해 포함되는데 초기에 적당한 값묶음으로 설정된다. 그러나 해당앱이 실질적으로 제공하는 방향에서 값들을 추가및 삭제해야 한다.

다음으로 앱의 Info.plist 피일에 앱의 동작에 기존하여 다음과 같은 키들을 포함시켜야 한다.

1. UIBackgroundModes – 앱이 기존의 방식들중 하나를 리용하여 배경화면을 설정할때 이키를 포함시킨다. 참고자료: Implementing Long Running Background Tasks(페지 54)

2. Key DescriptionMagnetometer 개발하려는 앺이 자력계를 리용해야 한다면 이

열쇠항목을 포함시킨다. 이 하드웨어를 리용하는 앺들은 Core Location 프레임워크로부터 관련사건들을 받을수 있다.

Microphone 당신의 앺이 내장 마이크나 주변장치의 마이크를 래용해야 한다면 이 열쇠항목을 포함시킨다.

Opengles-1 당신의 앺이 OpenGL ES 1.1 대면부를 래용해야 한다면 이 열쇠 항목을 포함 시킨다.

Opengles-2 당신의 앺이 OpenGL ES 2.0 대면부를 래용해야 한다면 이 열쇠 항목을 포함 시킨다.

Peer-peer 당신의 앺이 Bluetooth 망을 통한 말단 대 말단 통신이 필요하다면 이 열쇠항목을 포함시킨다.(ios 3.1 이상부터)

Sms 당신의 앺이 SMS(휴대전화의 본문전송기능)기능을 리용해야 한다면 이 열쇠항목을 포함시킨다. SMS 형식의 URL 을 열어야할 필요성이 있을때 이 기능이 유용하게 쓰일수 있다.

Still-camera 당신의 앺이 캐머러 기능을 리용해야 한다면 이 열쇠항목을 포함시킨다. UIImagePickerController 대면부를 통하여 전화기의 캐머러로부터 정지화상을 찍어 사용할수 있다.

Telephony 당신의 앺이 전화기의 전화기능을 리용해야 한다면 이 열쇠항목을 포함시킨다. 실례로 전화번호형식의 URL 을 열어야할 필요성이 있을때 사용할수 있다.

Video-camera 당신의 앺이 동영상을 촬영할 필요성이 있을때 리용할수 있다. UIImagePickerController 대면부를 래용하여 카메라로 부터 동영상을 촬영할수 있다.

Wifi 당신의 앺이 장치의 망기능을 리용해야 할때 이 기능을 리용할수 있다.

자세한 내용을 위해서는 Information Property List Key Preference 표를 참조하길 바란다.

앺의 파일지원형식 정의

만일 당신의 앺이 이미 존재하거나 앺특정의 파일혀식을 읽게 하려면 반드시 그 파일형식들을 정의해 주어야 한다. 사용자가 메일의 첨부파일을 열려고 하거나 다른 앺이 특정한 형식의 파일을 열려고 할때 조작체계는 정의된 파일형식들을 참조하여 당신의 앺이 그 파일을 열수 있는지 없는지 확인한다. 만일 열수 있다면 그 파일은 당신의 앺의 림시경로에 복사되고 그 위치가 앺으로 넘어간다. (림시경로는application:didFinishLaunchingWithOptions: 이나application:openURL:sourceApplication:annotation: 함수들을 래용하여 전달된다.) 그다음 당신의 앺이 그 파일을 열어 처리한다.

Xcode 에서 당신은 target 설정의 Info 태브에서 파일 형식을 정의할수 있다. 이 태브의 Document Type 부분에서 당신은 파일형식을 추가하거나 지우기 할수 있고 추가된 파일형식들에 대하여 추가적인 설정을 할수 있다.

Document Type 는 당신의 앺이 그 형식의 파일을 어떤 방법으로 어떻게 처리하는가를 정의해준다. Single Document Type 는 당힌의 앺이 한개 파일형식을 관리하는가 여러가지 파일형식을 관리하는가를 정의한다. 실례로 당신의 앺이 png, jpeg, gif 이미지형식중에서 png 파일만을 처리한다면 single document type 로 설정할수 있다. 만일 모든 파일들이 한가지 아이콘을 가지고 있고 한가지 코드로 실행된다면 single document type 로 설정한다. 여려 파일형식들이 다른 아이콘이나 서로 다른 코드로 실행된다면 개개에 따라서 서로다른 document type 를 정의해 주어야 한다.

Document type 에 따라서 다음의 정보를 최소한으로 제공해야 한다.

A name. 사용자에게 보여지는 이름

An Icon. 특정한 document type 를 가지고 있는 모든 파일들은 같은 아이콘을 가진다.

The file types. 파일형식을 정의하는 Uniform Type Identifier(UTI) 문자이다. 실례로 png 파일형식으로 정위하려면 public.png UTI 로 정의해야 한다. UTI 는 파일형식을 정의 하는 다른 방법에 비해 편리하고 안전하기때문에 자주 사용된다.

당신이 Xcode 를 통해서 설정한 document types 는 당신의 앺의 info.plist 파일에 열쇠항목들로 포함된다. Document types 는 여려값들의 배렬인 CFBundleDocumentTypes 열쇠항목으로 정의된다. 배렬의 매 항목들은 document type 의 이름,아이콘 등으로 이루어 진다. 이런 기본적인 항목들외에 document type

와 관련한 다른 항목들도 정의 할수 있다. 실례로 어떤 항목을 사용하여 document type 를 조작체계가 하나의 파일이라고 인식하고 처리하는 file package 로 정의할수 있다.

앺의 document type 정의에 관한 자세한 정보를 위해서는 information Property List Key Preference 표를 참조해 보기 바란다.

App Icons

모든 앺은 앺소토어와 홈스크린에 보여줄 아이콘을 제공하여야 한다. 아이콘은 여러가지 상황에 따라서 서로 다른것을 지정해 줄수 있다. 실례로 검색결과를 보여줄때는 작은 아이콘을 사용할수 있고 레티나 화면과 같이 고화질의 화면에 필요한 아이콘을 따로 제공할수 있다.

당신의 앺의 아이콘을 지정하기 위해서는 info.plist 파일에 CFBundleIconFiles 키를 추가하고 아이콘파일 이름을 관련배렬로 정의해줄수 있다. 체계가 일정한 크기의 아이콘을 요구하면 CFBundleIconFiles 배렬을 보고 필요한 아이콘크기와 비숫한 크기로 정하면 된다. (당신의 앺이 ios 3.1.3 이나 그 이하에서 동작하는 앺이라면 아이콘파일에 대해서 특정한 형식의 이름을 주어야 한다. 이에 대해서는 앞으로 구체적으로 설명하겠다.)

Table 5-2 는 CFBundleIconFiles 키와 관련한 아이콘크기들을 그 사용용도와 같이 설명해주고 있다. 레티나 화면을 위한 아이콘을 가지고 있는 앺은 두가지 아이콘을 다 제공해야 한다. 그 이름들은 레티나 화면을 의한 아이콘에 @2x 를 붙이는것외에는 같아야 한다. Drawing and Pringing Guide for Ios 를 보면 고화질 화상자료들을 어떻게 불러 들이고 가공하는지 알수 있다. 참고자료: ios Human Interface Guidelines.

Table 5-2

Icon Idiom Size UsageApp icon(required)

Iphone 57*57 pixels114*114pixels(@2x)

이 아이콘은 iphone 이나 ipod touch 에서 동작하는 앺을 위한 기본 아이콘이다. 이름에 @2x 가 붙은

아이콘은레티나 화면만을 위한 아이콘이다.

App Icon(required)

Ipad 72*72 pixels

이 아이콘은 ipad 에서 동작하는 앺을 위한 기본 아이콘이다.

Settings/Search results icon

Iphone/ipad

29*29 pixels58*58 pixels (@2x)

이 아이콘은 iphone 이나 ipod touch 의 검색결과에 나오는 아이콘이다. 또한 Settings 앺에서도 사용할수 있다.(@2x 아이콘은 레티나 화면에서만 사용된다.)

Search results icon

Ipad 50*50 pixels

Ipad 의 검색결과에 보여지는 아이콘이다.

CFBundleIconFiles 키로 아이콘을 정의할때 파일의 확장자는 주지 않는것이 좋다. 만일 파일 확장자를 주면 레티나 화면을 위한 아이콘이름과 같은 다른 아이콘들의 이름들도 명시적으로 정의해주어야 한다. 파일 확장자를 주지 않으면 배렬에 다른 아이콘들이 없어도자동적으로 조작체계가 아이콘들을 알아낸다.

Note: CFBundleIconFiles 키와 CFBundleIconFiles 키를 헛갈리지 않게 주의해야 한다. 이 항목들은 비숫한 기능을 수행하지만 CFBundleIconFiles 에서 아이콘 배렬을 사용할수 있기 때문에 복수형을 써야 한다. CFBundleIconFiles 는 ios 3.2 나 그 이상에서 사용할수 있다.

당신의 iphone 앺이 ios 3.1.3 이나 그 이하에서 동작한다면 조작체계는 CFBundleIconFiles 키를 참조하지 않는다. 대신에 특정한 이름을 가진 아이콘을 찾는다. CFBundleIconFiles 는 ios 3.2 에서 처음으로 나온 기능이며 그이하 판본에서는 제공되지 않는다. 아이콘의 크기는 표와 같지만 이름을 붙일때는 아래의 규칙을 리용해야 한다.

Icon.png. iphone 이나 ipod touch 의 기본아이콘이름

Icon-72.png ipad 의 기본아이콘 이름

Icon-small.png iphone 아니 ipod touch 에서 검색결과나 settings 앺에 사용될 아이콘이름

Icon-small-50.png ipad 에서 검색결과에 사용될 아이콘 이름.

Important: 앺의 아이콘에 제정된 이름을 주는것은 낡은 판본만 위한것이다.당신이 아이콘이름을 수정했다고 해도 ios 3.2 이상에서 동작하게 하려면 반드시 info.plist 의 CFBundleIconFiles 항목을 추가해 주어야 한다. 그렇지만 ios 3.2 이상에서도 우와같은 정해진 이름을 먼저 찾아본다. Ios 4 이상에서는 CFBundleIconFiles 항목을 먼저 참조한다.

개별적으로 앺을 만들어 배포하는 개발자들은 512*512 크기의 아이콘을 추가하고 iTunesArtWork 라는 파일이름을 주어야 한다. 아 아이콘은 itunes 에서 배포를 위한 앺을 보여줄때 사용된다.다른 아이콘들과 같이 이 아이콘도 앺의 기본등록부에 있어야 한다. 이 아이콘은 앺스토에 제공한 아이콘과 같은 아이콘이여야 한다.

참고자료: Information Property List Key Preference

App Launch (Default) Images

조작체계가 앺을 실행할때 화면에 실행화상을 일시적으로 보여준다. 앺 개발자는 이 화상을 여려 다른 정보와 같이 제공하여야 한다. 이 이미지의 목적은 사용자에게 앺에 대한 기본적인 정보를 제공하는 동시에 앺을 불러들이는데 필요한 시간을 주는것이다. 앺이 실행준비되였으면 조작체계는 이 이미지를 없애고 앺을 실행시킨다.

모든 앺은 적어도 하나의 실행이미지를 제공해야 한다. 이 이미지는 보통 default.png로 이름지어지며 화면의 portrait(전경보기)방식을 위한 이미지다. 하지만 당신은 여러 실행 상태에 따라서 여러가지 이미지를 제공할수 있다. 모든 실행 이미지는 png 파일 형식이여야 하며 앺의 기본 등록부에 있어야 한다. 모든 실행화상의 이름은 상황에 따라서 다르며 다음의 규칙으로 정의 된다.

<basename><usage_specific_modifier><scale_modifier><device_modifier>.png

<basename> 은 UILaunchImageFile 키에서 정의해준 문자로서 기정값은 Default 이다. <scale_modifier> 는 @2x 를 나타내며 레티나 화면을 위한 실행이미지에만 준다. 다른 항목들도 리용될수 있으며 그에 대해서는 앞으로 구체적으로 설명된다.

Table 5-3 은 ios 앺의 실행이미지의 크기를 정의한다. (모든 크기는 길이*높이 이다)

참고자료 : ios Human Interface Guidelines.

Info.plist 파일에 이름을 정의 하려면 UILaunchImageFile 항목의 MyLaunchimage 세부항목을 리용하여 정의할수 있다. 표준크기의 실행이미지 이름은 MyLaunchImage.png 로 주어야 하며 크기는 320*480 이다. 레티나 화면을 위한 이미지는 @2x 가 붙는다.

참고자료: Information Property List Key Reference

Providing Launch Images for Different Orientation (다른 방향에 따른 실행 화상 정의)

Ios 3.2 이상에서 ipad 앺은 landscape 방식과 portrait 방식의 실행이미지를 제공할수 있다. 각방향의 이미지는 파일 이름에 특정한 항목을 포함하여야 한다. 그 형식은 다음과 같다.

<basename><orientation_modifier><scale_modifier><device_modifier>.png

Table 5-4 는 <orientation_modifier> 에 대한 가능한 항목들에 대하여 정의한다. 모든 실행이미지의 확장자는 png 여야 한다. 이 항목들은 ipad 앺의 실행이미지에만 적용된다.

Table 5-4 Launch image orientation modifiers

Modifier Description-PortraitUpsideDown

실행이미지의 뒤짚힌 판본이다.

-LandscapeLeft 왼쪽방향의 landacape 방식의 이미지를 정의한다-LandscapeRight 오른쪽방향의 landscape 방식의 이미지를 정의한다.-Portrait 일반적인 portrait 방식의 이미지를 정의한다. 이 이미지는

바로선 portrait 방식의 이미지로 사용된다.-Landscape 일반적인 landscape 방식의 이미지를 정의한다.(none) 특정한 방향 항목을 정의 하지 않는다. Ios 3.2 아하 판본부터는

Default.png 를 리용한다.

실례로 UILaunchImageFile키를 MyLaunchImage 로 정의하였다면 landscape 방식에는 MyLaunchImage-Landscape.png 로 portrait 방식에는 MyLaunchImage-Portrait.png. 로 정의 한다. 만일 UILaunchImageFile 을 정의 하지 않았다면 Deafult-Landscape.png 와 Default-Portrait.png 로 정의할수 있다.

체계가 어떤 이미지를 보여주든 앺은 처음에 portrait 방식으로 실행되며 그다음 방향을 수정한다. 그러므로 application:didFinishedLaunchingWithOptions: 메소드는 앺을 실행할때 항상 portrait 방식으로 되여있다. 조금 있다가 조작체계는 앺에 정확한 방향변화 요청을 보낸다.

참고자료: View Controller Programming Guide for iOS

Providing Device-Specific Launch Images

일반족으로 앺은 iphone 와 ipad 를 위한 실행이미지를 같이 제공해야 한다. 그겉은 iphone 은 하나의 실행 이미지(default.png) 만 필요하지만 ipad 는 landscape 나 portrait 방식에 따라서 다른 이미지를 요구하기 때문이다.

만일 당신이 iphone 와 ipad 를 위한 다른 이미지를 만들었다면 파일에 장치식별자를 추가하면 된다.

다음의 장치 식별자는 ios 4.0 이나 그 이상에서 인식한다.

~ipad. Ipad 장치를 위한 실행 이미지.

~iphone. Iphone 이나 ipod touch 를 위한 실행 이미지.

Ios 3.2 에서 장치 식별자가 동작하지 않기 때문에 일반적인 앺에서는 기본 실행 이미지가 필요하다. 이 이미지는 default.png 나 default~iphone.png 로 이름

지어야 한다.그런 경우 default.png 는 ipad 를 위한 실행이미지이고 default-iphone.png 는 iphone 이나 ipod touch 를 위한 실행 이미지 이다.

레티나 화면을 위해서는 default@2x-iphone.png 로 정의 하여야 한다.

Note: 만일 info.plist 의 UILaunchImageFile 키를 리용 한다면 서로다른 장치의 실행이미지를 위한 device-specific version 을 정의 해 주는 것이 좋다. 실례로 ipad 실행이미지의 기본 이름으로 UILaunchImageFile-ipad 를 정의 해 주는것이다. 참고자료 : Information Property List Key Preference

Providing Launch Images for Custom URL Scheme

당신의 앺이 하나 이상의 사용자정의 URL 을 가지고 있다면 매 URL 마다 서로 다른 이미지를 제공할수 있따.

앺이 URL 을 실행할때 조작체계는 그 URL 에 따르는 실행 이미지를 보여준다. 실행이미지 형식은 다음과 같다.

<basename>-<url_scheme><scale_modifier><device_modifier>.png

The Settings Bundle

당신의 앺이 settings 앺에서 앺 설정을 진행할수 있게 하려면 settings bundle Resource 를 포함하여야 한다. Settings Bundle 은 앺묶음등록부의 맨 우에 있는 특수한 묶음으로서 당신의 앺의 설정정보들을 가지고 있다.

그림 5-1 은 어떤 앺의 설정창을 보여주고 있다.

Note: Settings 앺에서 설정을 변경하려면 앺을 종료해야 하기 때문에 settings Bundle 에 사용하는 설정들은 자주 변경시키지 않는것들로 하여야 한다. 자주 변경시키는 설정들은 앺안에 직접 가지고 있어야 한다.

Xcode 에서 settings Bundle resource 를 창조하고 당신의 앺에 추가하는 작업을 할수 있다. Settings Bundle 에서 여려가지 속성파일들과 그와 관련한 이미지들을 추가할수 있다. 속성파일들은 설정창의 여러 페이지들을 어떻게 표시할것인가를 나타내는 키와 값들로 이루어 진다.

설정을 변경시키면 그것은 사용자 기본 자료기지에 보관되며 NSUserDefaults object 를 래용하여 접근할수 있다.

참고자료: Preference and settings programming guide.

Localized Resource Files

ios 앺들은 여러 나라들에 배포돼기 때문에 여려 나라에 맡게 앺을 변화시키면 더많은 사용자들이 리용하게 할수 있다. 사용자들은 당신의 앺이 자기 국어로 되여 있으면 더 사용하기 좋아 할것이다. 이런 자료들을 하나의 자료파일로 묶어 놓으면 localize 하는것은 매우 간단해진다.

Localize 하기전에 당신의 앺을 세계적으로 사용할수 있게 해야 한다. 앺을 국제화 하는것은 앺의 지역별 파일을 만들고 각언어별 프로적트(.lproj) 등록부를 만들어야 한다.

완전히 국제화된 앺을 만들기 위해서 localization 단계에서 언어별 자료파일을 만들어 프로젝트에 추가 해야 한다. Ios 앺은 localization 을 위하여 다음의 자료 파일들이 필요 하다.

Storyboard files( or nib files) – Storyboard 파일은 지역화 되여야 하는 문자나 다른 콘텐츠을 포함하고 있다. 당신은 또한 언어별 문자 길이에 따라 사용자 대면부항목들을 다시 배치 할 필요가 있을수도 있다.

String files- strings 파일은 당신의 앺에 보여줄 문자들을 각 언어로 보관한다.

Image files- 이미지가 특수한 문화적인 요소를 포함하지 않는한 이미지를 localize 하는것은 피해야 한다. 그리고 문자를 그림에 직접쓰는것도 피해야 한다. 대신 문자를 strings 파일에 보관하고 실시간으로 읽어서 언어별로 표시할수 있다.

Video and audio files – 다매체파일들을 localize 하는것도 피해야 한다.

참고자료: International programming topics, resource programming guide

앱관련 자료들

발전된 앱 기교들

많은 앱관련 과제들은 당신이 창조하려는 앱형태에 의존한다.

일반적인 앱 창조하기

보편적인 앱은 iphone, ipod touch 와 ipad 장치용으로 최적화된 단일응용프로그람이다.

현재장치에 적응하는 단일 2 진법을 보장하여 최상의 사용자경험을 제공하지만 물론 당신의 부분에 대한 추가작업을 포함한다.장치들의 서로다른 화면크기, ipad 에서의 거의 대부분의 창문, 보기, 보기조종체코드의 차이로부터 iphone, ipod touch 코드도 다를 가능성이 높기 때문이다.추가로 앱의 각 장치 형태에 따라 옳바로 실행되도록 하기위해 당신이 해야할 일들이 있다.Xcode 는 일반앱들 구성을 위한 내장지원을 제공한다. 당신이 새로운 project 를 창조할때 당신이 장치의존 프로젝트인가, 일반프로젝트를 창조하려는가를 선택할수 있다.당신의 프로젝트를 창조한다음 요약패널을 사용하여 앱타겟을 위한 장치의 지원되는 집합을 변경할수 있다.단일장치프로젝트로부터 일반적은 프로젝트로 변환할때는 당신이 추가하려는 지원을 위한 장치형태에 대한 정보를 채워야 한다.다음절에서는 기존앱이 임의의 장치에서 원만히 실행되도록 하기 위해 주는 변화들을 강조표시한다.

Info.plist 설정 갱신하기

일반 앱들의 Info.plist 파일안에 있는 많은 기존 키들은 동일하게 유지되여야 한다.그러나 아이폰대 ipad 장치에서 다른 값을 필요로 하는 키들에 대해서는 당신이 키이름에 장치수정자를 추가할수 있다. Info.plist 파일에서 키를 읽을때 체계는 다음의 형식을 리용하여 개개의 키들을 해석한다.key_root-<platform>~<device>

이 형식에서는 key_root 부분이 키의 원래 이름을 나타낸다. <platform>과 <device> 부분은 둘다 가동환경이나 장치에 특정한 키들을 위해 리용할수 있는 추가적인 끝을 나타낸다.iOS 체계에서만 동작하는 앱들에 대해서는 가동환경문자렬을 생략할수 있다.특정한 장치에 키를 적용하기 위해서는 다음의 값들중 하나를 리용해야 한다.

● iphone—iphone 장치에 적용● ipod—ipod touch 에 적용● ipad—ipad 장치에 적용

실례로 당신의 앱이 이이폰과 아이포드에서 세로방향으로 실행되지만 ipad 에서는 가로 오른쪽으로 실행시키기 위해서는 다음의 키를 리용하여 Info.plist 를 구성하여야 한다.<key>UIInterfaceOrientation</key><string>UIInterfaceOrientationPortrait</string><key>UIInterfaceOrientation~ipad</key><string>UIInterfaceOrientationLandscapeRight</string>이전실례에서 아무런 장치수정자가 없이 ipad 특정의 고유키와 기본키가 있다는것을 알수 있다. 가장 일반적인(또는 기본)값을 지정하고 장치특정수정자로 특정한 판본을 추가하기 위해 그값을 변경할 경우 기정키를 계속하여 사용한다.이것은 시스템에 검사하기 위한 사용가능한 값이 항상 있다는것을 보장한다.실례로 당신이 UIInterfaceOrientation 의 iphone 과 ipad 특정판본으로 기정키를 갱신했다면 체계는 ipod 장치에 대한 기본시작방향을 모를것이다.Info.plist 파일에서 당신이 포함할수 있는 키에 대한 더많은 정보를 위해 Information Property List Key Reference 를 보시오.

보기조종체와 보기 실현

일반적인 앱을 창조하는데 들어가는 많은 노력은 사용자대면부를 설계하는것이다.서로다른 화면크기로 하여 앱들은 자주 각 장치관용구에 대한 그들의 대면부를 완전히 다른 판본으로 필요로 한다.이것은 새로운 보기구조를 만드는것뿐아니라 이런 보기들을 관리하는 완전히 다른 보기조종체객체를 만든다는것을 의미한다.보기에 관해서는 기본 수정이 보다큰 화면을 지원하기 위해 당신의 보기배치를 다시해야 한다는것이다.간단하게 기존보기확장은 동작할수도 있지만 좋은 결과를 가져오지 못한다. 당신의 새로운 대면부는 사용가능한 공간을 사용하고 새로운대면부 요소들을 적절하게 사용하여야 한다.그렇게 함으로서 iphone뿐아니라 더큰 화면에서 사용자에게 더 자연스러운 느낌을 줄수 있다.보기조종체에 관한 다음의 지도서가 있다.-iphone 과 ipad 장치에 대해 별도의 보기조종체 클라스정의를 생각해볼수 있다.별도의 보기조종체를 리용하는것이 2 개의 가동환경을 다 지원하는 하나의 보기조종체를 창조하는것보다 훨씬 쉽다.

공유코드가 많이 있다면 당신은 기초클라스에 공유코드를 항상 넣을수 있으며 그다음 장치특정의 문제들을 지정하기 위해 사용자정의부분클라스를 구현할수 있다.-당신이 두개의 가동환경을 위해 단일보기조종체클라스를 사용한다면 당신의 코드는 iphone 과 ipad 화면크기에 둘다맞게 지원하여야 한다. 비슷한 방법으로 보기조종체코드는 두개의 가동환경사이 차이를 처리할수 있어야 한다.view 들을 위한 지도서

-iphone 과 ipad 장치들을 위한 보기들의 개별적인 묶음으로 생각하면 사용자정의보기인 경우 이것은 매장치들을 위해 서로다른 판본의 클라스들을 정의한다는것이다.-만일 당신이 2 개의 장치에 대해 같은 사용자정의 보기를 사용하기로 선택한다면 drawRect 를 확인하여야 한다. 그리고 layoutSubviews 방법은 특별히 2 개 장치에 대해 정확히 동작하여야 한다.

새로운 기호에 대한 실시간 검사를 추가하기

iOS 판본의 범위를 지원하는 임의의 앱은 조작체계의 최신판본에 도입된 기호를 사용하여 코드를 보호하기 위해 실시간검사를 리용하여야 한다.그렇기때문에 iOS 3.1 에서 실행하는 앱개발을 위해 iOS 4.2 SDK 를 리용한다면 실시간검사는 새로운 특성들이 가능하면 그것들을 리용할수 있게 해주고 만일 그렇지 않다면 대체코드경로를 따르도록 허용한다.당신의 앱이 존재하지 않는 기호들을 리용하려고 할때 발생하는 충돌들에 대한 결과에 대한 검사들을 포함할수 없다.여기에 당신이 할수 있는 여라가지 형태의 검사가 있다.-iOS4.2 SDK 나 그후로 련결해주는 앱들은 SDK 의 그판본에 도입된 약한 련결지원을 사용할수 있다. 이 지원은 당신이 그 클라스를 사용할수 있는지 결정하기 위해 그 클라스객체의 존재를 검사하도록 한다. 실례로:if ([UIPrintInteractionController class]) {// Create an instance of the class and use it.}else {// The print interaction controller is not available.}이기능을 사용하려면 LLVM 과 Clang 을 리용하여 앱을 만들어야 하며 앱의 배포대상이 iOS 3.1 이나 그후판본으로 되여야 한다.

-iOS SDK 4.1 과 그전을 지원하는 앱들은 클라스가 정의됬는지 보기 위해 NSClassFromString 함수를 리용하여야 한다. 만일 함수가 nil 이 아닌 값을 되돌리는 경우 당신은 그 클라스를 리용해도 된다. 실례로:Class splitVCClass = NSClassFromString(@"UISplitViewController");if (splitVCClass){UISplitViewController* mySplitViewController = [[splitVCClass alloc] init];// Configure the split view controller.}-기존클라스에 메쏘드가 존재하는지 결정하기위해 instancesRespondToSelector: 클라스메쏘드를 사용한다.-C 기반의 함수가 존재하는지 확인하려면 NULL 로 함수이름의 부울 비교를 진행한다. 결과가 YES 라면 당신은 그함수를 리용할수 있다. 실례로:if (UIGraphicsBeginPDFPage != NULL){UIGraphicsBeginPDFPage();}

조건부코드경로를 만들기위해 실시간검사 리용

코드가 기본장치형태에 따라 다른경로를 따라해야 할 경우 어떤 경로를 리용할지 결정하기 위해 UIDevice 의 userInterfaceIdiom 속성을 사용한다.이속성은 iPad 나 iPhone 에서 창조하는 대면부형식의 표시를 제공한다.왜냐면 이속성은 iOS 3.2 나 그후판본에서만 리용가능하기때문이다. 그 이전 iOS 를 지원하는 앱들은 이속성에 접근하기전에 이속성을 리용할수있는지 먼저 검사하여야 한다.물론 이속성을 검사하는 가장 간단한 방법은실시간검사를 필요로 하는 UI_USER_INTERFACE_IDIOM 마크로를 사용하는것이다.if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {// The device is an iPad running iOS 3.2 or later.}else {// The device is an iPhone or iPod touch.}

자원파일들 갱신하기

자원파일들은 보통 사용자대면부를 구현하는데 리용되기때문에 당신의 다음의 변경을 해야 한다.-iPhone 장치들에서 앱을 실행할때 Default.png 파일이 추가적으로 현시되게 하자면 “다른 방향으로 실행그림 제공”(84페지)에 서술된대로 ipad 장치들을 위한 새로운 시작그림들을 추가하여야 한다.-만일 당신이 그림들을 리용하면 ipad 장치들을 지원하기 위해 더 크거나 높은 화상도의 그림들을 추가하여야 한다.-만일 당신이 nib 파일들을 리용한다면 ipad 장치들을 위한 nib 파일들의 새로운 묶음을 지원하여야 한다.-“앱아이콘들”(81페지)에 서술된대로 ipad 에 적합한 앱아이콘크기를 설정해야 한다.매 가동환경마다 서로다른 자원파일들을 리용한다면 코드를 조건부로 실행하듯이 이 자원들도 조건적으로 읽어들일수 있다.실시간검사를 어떻게 리용하는가에 대한 더많은 정보를 위해“Using Runtime Checks to Create Conditional Code Paths” (page 91).를 보시오.

앱사용자대면부상태 유지

앱은 자기 보기조종체구조를 통하여 매 조종체에 대한 정보를 다스크에 저장함으로서 사용자대면부에 대한 상태를 보존할수 있다.보기조종체들을 통하면 빠르며 당신의 앱을 이전 상태로 복귀하는데 충분한 정보를 얻을수 있게 해준다.보기조종체구조를 보면 최소한 다음의 정보를 저장하여야 한다.-현재 보이는 보기조종체

-보기조종체의 구조화된 배렬

-다음실행주기동안에 보기조종체를 다시 창조하기 위해 리용하는 보기조종체클라스이름을 포함한 매개 보기조종체에 대한 정보, 보기조종체에 의해 관리되는 자료에 대한 참조

그림 6-2 프로그람실행으로 URL 열기

프로그람이 실행은 되지만 뒤공간에서 실행중이거나정지상태일때 URL 요구가 들어오면 앞공간으로 옮겨져 URL 을 열게 된다.

체계는 그다음 바로 델리게이트의application:openURL:sourceApplication:annotation 을 호출하여 URL 을 검사하고 실행하게 된다.

델리게이트가 이 메쏘드를 실행하지 않을때(혹은 현재 체계판본이 iOS 4.1 혹은 그전판인 경우) 체계는 대신 델리게이트의 application:handleOpenURL메쏘드를 호출하게 된다.

그림 6-3 은 프로그람을 앞공간으로 옮겨 URL 을 실행하는 수정된 과정을 보여주고 있다.

그림 6-3 뒤공간프로그람을 각성시켜 URL 열기

모든 URL 들은 프로그람에 NSURL 객체로 넘겨지게 된다.

주의: 사용자정의된 URL 체계를 제공하는 프로그람들은 URL 을 관리하는 프로그람을 실행할때 서로 다른 실행화상들을 지정할수 있다. 이 실행화상들을 지정하는데 대한 추가정보들은 “사용자정의된 실행화상제공” 85페지에 있다.

URL 의 형식을 지정하는것은 개발자에게 달려있지만 NSURL클라스는 RFC1808 명세서에 일치하므로 대부분의 URL 형식관례들을 제공하고있다.

특히 클라스는 URL 의 다양한 부분들을 RFC1808 에 정의된대로 돌려주는 메쏘드들을 포함하고있는데 사용자, 암호, 질문사항, 쪼각, 그리고 파라메터문자렬들도 포함하고있다.

사용자정의된 체계에 쓰이는 규약은 다양한 정보를 조사하는데 이 URL 부분들을 리용한다.

목록 6-1 에서 보여주는바와 같이 application:handleOpenURL:의 실현에서 넘겨진 URL 객체는 프로그람특유의 정보를 질문사항과 쪼각부분에 포함하고 있다.

델리게이트는 이 정보를 뽑아내게 되는데 해야 할 과제의 이름과 과제를 끝내야 할 날자같은 경우이다.

이 정보를 가지고 프로그람의 모델객체를 창조하게 된다.

이 실례는 사용자가 그레고리력을 사용한다고 가정한다.

프로그람이 비그레고리력을 사용하는 경우 URL 체계를 그에 따라 설계하고 그 력서형태를 자신의 코드에서 처리할수 있도록 준비하여야 한다.

Listing 6-1 사용자정의된 체계에 기초하여 URL 요구 처리- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {if ([[url scheme] isEqualToString:@"todolist"]) {ToDoItem *item = [[ToDoItem alloc] init];NSString *taskName = [url query];if (!taskName || ![self isValidTaskString:taskName]) { // must have atask name[item release];return NO;}taskName = [taskNamestringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];item.toDoTask = taskName;NSString *dateString = [url fragment];if (!dateString || [dateString isEqualToString:@"today"]) {item.dateDue = [NSDate date];} else {

if (![self isValidDateString:dateString]) {[item release];return NO;}// format: yyyymmddhhmm (24-hour clock)NSString *curStr = [dateString substringWithRange:NSMakeRange(0,4)];NSInteger yeardigit = [curStr integerValue];curStr = [dateString substringWithRange:NSMakeRange(4, 2)];NSInteger monthdigit = [curStr integerValue];curStr = [dateString substringWithRange:NSMakeRange(6, 2)];NSInteger daydigit = [curStr integerValue];curStr = [dateString substringWithRange:NSMakeRange(8, 2)];NSInteger hourdigit = [curStr integerValue];curStr = [dateString substringWithRange:NSMakeRange(10, 2)];NSInteger minutedigit = [curStr integerValue];NSDateComponents *dateComps = [[NSDateComponents alloc] init];[dateComps setYear:yeardigit];[dateComps setMonth:monthdigit];[dateComps setDay:daydigit];[dateComps setHour:hourdigit];[dateComps setMinute:minutedigit];NSCalendar *calendar = [[[NSCalendar alloc]initWithCalendarIdentifier:NSGregorianCalendar]autorelease];NSDate *itemDate = [calendar dateFromComponents:dateComps];if (!itemDate) {[dateComps release];[item release];return NO;}item.dateDue = itemDate;[dateComps release];}[(NSMutableArray *)self.list addObject:item];[item release];return YES;

}return NO;}

URL 로부터 얻어 프로그람에로 넘겨지는 입력정보를 반드시 검사하여야 한다.

URL 처리와 관련한 문제점들을 처리하는 방법은 “입력과 내부처리통신”편에 나와있다.

Apple 이 정의한 URL 구조에 대해 알려면 Apple URL 구조참고편을 보면 된다.

건반 현시 및 감추기

건반의 외형은 보기상태의 응답측에 따라 결졍된다.

보기가 첫번째 응답자라면 체계는 보기가 첫 응답자가 될때마다 건반을 현시한다.

사용자가 첫 응답자가 될수 없는 다른 보기를 탭하면 체계는 현재 건반이 보임상태라면 현시하지 않는다.

UIKit 에서는 본문입력을 제공하는 보기만이 첫 응답자가 될수 있다.

다른 보기에서 건반을 현시하려면 canBecomeFirstResponder메쏘드를 재정의하고 YES 를 돌려주어야 한다.

보기가 첫 응답자가 될때 건반은 기정으로 보여지지만 사용자정의된 입력홈을 제공하는 보기에 관해서는 건반을 바꿀수 있다.

모든 응답객체는 응답자가 첫 응답자로 될때 현시되는 View 를 포함하는 입력보기속성을 가지고 있다.

일반적으로 사용자의 탭은 프로그람에서 어느 보기가 첫 응답자로 되겠는가를 결정하지만 사용자도 역시 어느한 보기가 첫 응답자로 될수 있게 할수 있다.

becomeFirstResponder메쏘드를 호출하여 임의의 응답객체는 그 자신이 첫 응답자가 되도록 시도할수 있도록 한다.

그 응답자가 첫 응답자로 될수 있다면 사용자정의된 입력보기(혹은 표준건반)은 자동적으로 보여진다.

건반사용에 대하여 더 알려면 iOS 의 본문, 웨브 및 프로그람편집지도서를 참고하시오.

화면잠금끄기

iOS 기반장치가 특정한 시간동안 다침사건을 받지 않으면 체계는 화면을 끄고 다침검사를 중단한다.

화면잠금은 전기를 절약하는 중요한 방법이다. 결과 사용자는 일반적으로 이 특성을 동작시켜야 한다.

그러나 입력에 가속계를 리용하는 게임과 같이 다침사건에 의거하지 않는 프로그람들은 사용자가 프로그람과 능동적으로 련계를 가질때만 화면잠금을 비활성화시킨다.

실례로 사용자가 게임을 정지하면 화면이 꺼질수 있도록 화면잠금을 활성화시킨다.

화면잠금을 비활성화시키리면 공유된 UIApplication 객체의 idleTimerDisabled속성을 YES 로 설정하여야 한다.

프로그람에서 화면잠금을 막을 필요가 없을때는 꼭 이 속성을 NO 로 설정하여야 한다.

성능조절

프로그람개발의 매 단계에서 개발자는 설계의 선택과 프로그람의 전체 성능의 련관을 고려해보아야 한다.

iOS 프로그람의 조작환경은 Mac OS X 의 프로그람들보다 더 제한되여있다.

개발자가 개발공정에서 고려하여야 할 요소들을 아래에 서술하였다.

프로그람여분을 더욱 효과적으로 만들어야 한다.

여분은 iCloud 로 무선으로 진행되거나 사용자가 iTunes 로 장치를 동기화할때 생긴다.

여분을 만드는 동안 파일은 장치에서 사용자의 콤퓨터나 iCloud 계좌로 전송된다.

프로그람 sandbox 의 파일경로가 이 파일들이 여분화되여 복귀되는가 아닌가를 결정한다.

프로그람이 자주 변경되는 파일들을 많이 만들고 여분화된 경로에 보관하면 그 결과 여분화가 떠질수 있다.

개발자가 파일관리를 하는 코드작성시 이 사실을 꼭 명심하여야 한다.

무엇이 여분화되는가?

개발자는 프로그람이 여분보관 및 복귀되도록 준비할 필요가 없다.

능동화된 iCloud 계좌가 있는 장치들은 적절한 시각에 프로그람자료를 iCloud 에 여분보관한다.

콤퓨터에 접속되는 장치들에 한해서 iTunes 는 프로그람자료파일의 추가적인 여분화를 진행한다.

그러나 iCloud 와 iTunes 는 다음 등록부의 내용은 여분화하지 않는다.

<Application_Home>/AppName.app <Application_Home>/Library/Caches <Application_Home>/tmp

동기화공정이 오래 걸리지 않도록 하자면 파일들이 프로그람등록부내에 어느 위치에 보관되는가를 잘 선택해야 한다.

용량이 큰 파일들을 보관하려면 iTunes 나 iTunes 에 여분화하는 공정이 떠질수 있다.

이 프로그람들은 또한 사용자의 사용가능한 공간을 많이 소비할수 있으므로 사용자가 프로그람을 지우던가 iCloud 에 프로그람을 여분화하지 못할수 있다.

이것을 알고 프로그람자료를 다음의 기준에 따라 보관하여야 한다.

- 다시 내리적재할수 있거나 재생성될수 있는 파일은<Application_Home>/Library/Caches 등록부에 보관되여야 한다.

Cache 등록부에 보관되여야 할 파일들로서는 실례로(이것이 제한은 아니다.)자료기지완충파일들과 내리적재가능한 파일들로서 여기에는 잡지, 신문, 그리고 지도프로그람들이 포함된다.

- 림시적인 목적으로만 쓰이는 자료는<Application_Home>/tmp 등록부에 보관되여야 한다.

이 파일들을 다 리용한 다음에는 꼭 지워서 사용자의 장치공간을 더이상 소비하지 않도록 하여야 한다.

- 사용자에 의하여 생성됐거나 프로그람에 의하여 다시 리용될수 없는 파일은 <Application_Home>/Documents 등록부에 보관되여야 한다.

iTunes 가 프로그람묶음을 직접 여분화하지 않지만 매 동기화조작마다 이 작업을 진행하지 않는다.

장치에서 직접 구입된 프로그람은 장치가 iTunes 로 동기화되는 다음번에 여분화된다.

프로그람묶음이 변하지 않는한 다음에 일어나는 동기화조작에서 여분화되지 않는다.

프로그람에서 자료를 어떻게 리용해야 하는가에 대해서는 파일체계프로그람작성지도서를 참고하라

프로그람갱신시 보관된 파일

사용자가 프로그람갱신판을 내리적재할때 iTunes 는 새 프로그람등록부에 갱신판을 설치한다.

그다음 낡은 설치판을 삭제하기전에 사용자의 자료파일을 낡은 설치판에서 새 프로그람등록부로 옮긴다.

다음의 등록부에 있는 파일들은 갱신과정에 보존되게 된다.

<Application_Home>/Documents <Application_Home>/Library

다른 등록부의 파일들도 이동되지만 갱신후에 존재에 의거하지 말아야 한다.

기억기를 효과적으로 사용하여야 한다.

기본스레드에서는 작업을 하는 말아야 한다앱의 기본스레드에서 하는 일의 형태에 대하여 반드시 제한하여야 한다. 기본 스레드는 앱이 타치사건과 기타 사용자 입력을 처리하는곳이다. 앱이 사용자에게 항상 응답하려면 기본앱은 다치지 않음로써 망접속과 같은 장시간 또는 잠시적으로 계속 실행되고 있는 과제들을 수행하여야 한다.대신 항상 이러한 과제들을 배경스레드에 옮겨야 한다.

이러한것을 실현하는 좋은 방법으로는 비동기적으로 과제들을 수행하는 Grand Central Dispatch (GCD)나 operation object 를 쓰는것이다.

부동소수점 연산 고찰iOS 기반장치들에 내장되여있는 프로쎄서들은 하드웨어에서 부동소수점 연산을 할수 있다. 만일 쏘프트웨어기반 고정소수점연한서고를 리용하여 계산을 진행하는 프로그람을 가지고 있다면 코드를 고쳐 류동소수점연산을 진행할수 있다. 일반적으로 하드웨어기반 류동소수점연산이 쏘프트웨어기반부동연산보다 빠르다.

iOS4 이상버젼에서는 Accelerate framework 의 함수들을 리용함으로써 복잡한 수학계산을 진행할수 있다. 이프레임워크는 수자신호처리와 선형대수학연산을 위한 고성능 가속화된 벡토서고(high-performance vector-accelerated libraries)를 가지고 있다. 이서고들로 록음 비데오처리, 물리, 통계, 암호화 그리고 복잡한대수학계산을 할수있다.

전력소비를 줄여야 한다모바일장치에서 전력소비는 항상 핵심문제이다. IOS 에 전력처리쳬계는 사용하지 않는 하드웨어기능들을 끊으로써 전력을 전략하고 있다. 다음과같은 아래기능들을 최적화함으로써 배터리수명을 높일수 있다.

The CPU Wi-Fi, Bluetooth, and baseband(EDGE, 3G) radios The Core Location framework The accelerometers The disk

요점:만일 ARMv6 용 앱을 개발하고 류동소수점연산을 광범히 진행한다면 코드를 -mthumb 콤파일 옵션이 없이 콤파일하여야 한다. 쌉부옵션이 모듈의 크기를 줄일수 는 있지만 류동소숨점처리부분코드의 실행속도를 낮출수 있다. ARMv7 용앱을 작성한다면 쌉부옵션을 항상 사용하여야 한다.

최적화의 목적은 대부분의 작업을 가능한 가장 효과적인 방법으로 하는것이다. 항상 기구들을 리용하여 앱의 알고리듬을 최적화 하여야 한다. 하지막 비록 가장 최적화된 알고리듬도 장치의 배터리수명에 나쁜 영향을 줄수가 있다. 그러므로 코드를 작성할때는 다음과 같은 지도서를 참고하여야 한다.

폴링(질문을 물어보는것)을 요구하는 작업을 피해야 한다. 폴링은 CPU 가 잠자는 상태로 가지 못하게 한다. 폴링대신 NSRunLoop 나 NSTimer 클라스를 리용하여 필요한 작업을 진행하여야 한다.

가능할때마다 공유된 UIApplication오브젝트의 idleTimerDisabled 요소를 No로 설정하여야 한다. Idle timer 는 일정한기간 비활동상태에 놓여있으면 장시화면을 끊다. 만일 앱이 화면을 켜놓을 필여가 없으면 체계가 끄도록 하여야 한다. 만일 화면이 꺼서 앱에서 부작용이 일어난다면 필요없이 idle timer 를 끄기보다는 부작용코드를 없애야 한다.

지내 잦은 디스크 접속을 피해야 한다. 실례로 앱이 상태정보를 디스크에 보관한다면 상태정보가 변할때만 보관하여야 한다. 그리고 작은 변화를 자주 쏘는것을 피하기 위해서는 가능할때마다 변화들을 합쳐야 한다.

필요이상 화면에 그림을 빨리 그리지 말아야 한다. 그림그리기는 전력으로 볼때 비용이 많이드는 작업이다. 실질적으로 앱이 필요한 만큼의 프레임만 그려야 한다.

만일 UIAccelerometer클라스를 사용하여 가속도계를 받는다면 필요없을때는 사건발생을 막아야 한다.

망에 많은 자료를 전송할수록 더많은 바테리를 사용하여 무선신호를 보장한다. 사실상 망에 접속하는것이 가장 전력을 집중적으로 쓰는 작업이다. 다음과 같은 방법으로 그시간을 최대만 줄여야 한다.

외부써버에는 필요할때만 접속하여야 한다. 망에 접속하여야 할때는 필요한 최소한량의 자료를 전송하여야 한다. 압축자료형식를 사용하고 초과내용을 포함하지 말아야 한다.

시간이 흐름에 따라 자료를 확산시키는것보단 한번에 보내는것(in burst)이 낳다. 체계는 Wifi 를 사용이 적을 경우 끊다. 자료를 오랜시간에 걸쳐 보내면 똑같은 량의 자료를 단시간에 보낼때보다 훨씬 많은 량의 전력을 소비한다.

가능할때마다 Wifi 를 리용하여 망에 가입하여야 한다. Wifi 는 무선전화보다 전력도 적게 소비하며 효과적이다. 위치자료를 얻기위하여 Core Location Framework 를 리용하는 경우 가능한빨리 위치갱신을 취소하고 정확한 값을 얻으려면 거리 필터와 정확성수준을 설정하여야 한다. Core Location 은

사영자의 위치를 얻기위하여 GPS, 모바일 그리고 Wifi망을 리용한다.비록 Core Location 이 이러한신호들의 리용을 최소화하고 있지만 정확성과 필터값을 설정함으로써 Core Location 이 필요없을때는 하드웨어를 끄는 옵선을 제공한다.

계기앱은 전력관련정보를 얻기위한 여러가지 계기들을 포함한다. 이러한 계기들을 리용하여 전력소비정보나 Wi-Fi, Bluetooth, GPC 수신기, 현시기, 그리고 CPU 와 같은 하드웨어들을 축정정보를 얻는데 사용할수 있다.

코드를 조율하여야 한다.iOS 는 앱의 성능을 조절할수 있는 여러개의 앱을 제공한다. 대부분 앱들이 Mac OS X에서 동작하며 iOS 모의실험에서 코드의 일부기능을 조율할수 있다. 실례로 시물레이터를 리용하여 메모리류출을 없애고 메모리사용을 가능한적게 할수 있다. 시뮬레이터에서 코드를 조율한다음에 계기앱들을 리용하여 장치에서 코드를 조율할수 있다. 실지장치에서 코드를 실행시킬때만이 완전히 코드를 조율할수 있다. 시뮬레이터는 Mac OS X 에서 동작하기때문에 빠른 CPU 와 더많은 메모리를 리용하여 실지장치에서보다 훨씬 좋은 성능을 사용할수있는 장점이 있다. 그리고 실지장치에서 계기를 리용하여 코드를 검사함으로써 조율이 필요한 추가적인 성능오유들을 찾아낼수 있다.

파일접근회수를 개선하여야 한다.디스크에쓰는 자료의 량을 최소화하여야 한다. 파일연산은 비교적 속도가 느리며 제한수명을 가지고 있는 Flash Drive 에 쓰는것을 포함하고 있다. 파일관련연산을 최소화하기위 한 일부 특정한 팁들로서는 :

변경된 파일의 부분만 쓰고 변경된것들을 종합하여야 한다. 1-2바이트를 고치려고 전체파일을 다시쓰는것은 피하여야 한다.

파일형식을 정할때는 자주변하는 자료를 다같이 그릅화 함으로써 매번 디스크에 써야되는 총 블로크의 수를 최소화할수 있다.

자료가 임의적으로 접근되는 구조화된 자료로 되여있으면 Core Data persistent store 나 SQLite 자료기지에 보관하여야 하며 특히 조정하는 자료가 1,2MB 를 넘는경우 더하다.

캐쉬파일을 디스크에 쓰는것을 피해야 한다. 이 규칙의 제외는 오직 엡이 다음번에 실행될때 다시 리용하여야하는 상태정보를 보관하는 경우이다.

망관련코드를 조율하여야 한다.iOS 에서 망은 iOS 장치용 신호하드웨어를 통화여 통신하는 여러개의 대면부를 가지고 있다. 기본 프로그래밍 대면부로는 CFNetwork Framework 이다. CFNetwork Framework 는 BSD 소케트의 맨 웃충에서 동작하며 Core Foundation Framework에서 망들과 통화하기 위한 형들을 불투명화한다.

효과적인 망형성을 위한 비결망상에서 자료를 받기위한 코드를 실현하는것이 장치에서 가장많이 전력을 쓰는것중에 하나이다. 자료전송시간을 최소화하는것이 바테리수명을 개선한다. 그러기 위해서는 망관련코드를 작성할때 다음의 비결들을 참고하여야 한다.

조종규약을 위하여 자려형식을 가능한 압축된것으로 정하여야 한다. chatty규약은 피하여야 한다. 파케트를 한번에 전송하여야 한다.

모바일이나 Wi-Fi 는 사용하지 않으면 전원을 끄게 설계되였다. 그러나 신호에 따라 이러한 단계가 조금 시간이 걸릴수 있다. 만일 앱이 2 초간격으로 작은단위의

자료들을 보낸다면 신호는 비록 하는것이 없다고 하여도 전력을 끄지않고 계속 소비한다. 작은량의 자료를 계속 보내는것보다는 비교적 오랜기간에 한번씩 많은량의 자료를 단번에 보내는것이 낫다.

망상에서 통신이 끝난경우 자료는 아무때나 없어질수 있다. 그러므로 망형성 코드를 작성할때는 실패한경우 처리할수 있게 가능한 튼튼하게 작성하여야 한다. 망조건 변화에 따라 처리를 작성하는것이 가장 합리적이지만 그 처리들의 계속 호출되지 않는다고 하여도 놀랄것 없다. 실례로 Bonjour networking callback 는 망봉사가 사라진 즉시 항상 호출되는것은 아니다.

Bonjour 체계는 봉사가 끝난다는 통고를 받았을때만 즉시 browsing callback 를 호출하지만 망봉사는 통고없이 사라질수도 있다.이러한 정황은 망봉사를 제공하는 장치가 뜻밖에 망접속을 잃거나 통고가 전송중에 사라지면 발생한다.

Wi-Fi 사용만인 앱이 Wi-Fi 신호를 통화여 망에 접속하면 반드시 앱의 Info.plist 파일에 있는 UIRequiresPersistentWIFi키를 포함함으로써 체계에 알려야 한다. 이키를 포함함으로써 체계는 임의의 살아있는 Wifi hotspot 를 찾아 망선택창을 현시함으로써 알려준다. 또한 앱이 기동할동안 Wifi 하드웨어를 끄지 않아도록 체계에 알려준다.

너무 많은 권한을 사용하여 와이파이 하드웨어를 방지하기 위해 IOS 는 하드웨어를 끄고 내장 타이머를 가지고 완벽하게 30 분 후에 더 실행 응용 프로그램은 통해 사용을 요청하지 않은 경우

UIRequiresPersistentWiFi 키.사용자가 키를 포함하는 응용 프로그램을 시작하면 IOS 효과적으로 사용할 수 없게 애플 리케이션의 생명주기의 기간 동안 타이머. 그 응용 프로그램이 종료되거나, 그러나 휴간 마자 시스템 타이머를 reenables.

참고 : 참고 UIRequiresPersistentWiFi 진실의 가치가있다해도, 그것이 아무런 효과가없는 경우

장치 (스크린 잠겨 해당) 유휴 상태입니다.응용 프로그램은 비활성으로 간주되고, 그것은 일부에서 작동할 수 있지만 레벨, 그것은 와이파이 연결이 없습니다.

UIRequiresPersistentWiFi 키와 Info.plist 파일의 키에 대한 자세한 내용은 참조 그림 6-1 (페이지 100).

The Airplane Mode Alert

장치가 비행기 모드에있는 동안 여러분의 응용 프로그램을 실행하면 시스템은 사용자에게 알리도록 경고를 표시할 수 있습니다

그 사실.다음 조건이 모두 충족되는 경우에만 시스템이 경고를 표시합니다

- 당신의 응용 프로그램의 정보 자산 목록 (Info.plist) 파일 UIRequiresPersistentWiFi 키가 포함되어 있습니다

그 키 값을 true 로 설정됩니다.

- 장치가 비행기 모드로 현재 상태 당신의 응용 프로그램이 실행됩니다.- 장치와이파이를 수동으로 비행기 모드로 전환 후 reenabled 되지 않았습니다.

The iOS Environment

IOS 환경은 당신의 애플 리케이션을 디자인하는 방법의 여러 측면에 영향을 미칩니다. 몇 가지 주요 측면에 대한 리해 코드를 작성할 때 도움이됩니다...

특수한 체계행동

IOS 시스템은 즉 맥 OS X 에서 사용하는 동일한 기술, 마하 커널과 BSD 를 기반으로

인터페이스. 따라서 IOS 애플 리케이션이 UNIX 기반 시스템에서 실행하고 스레드, 소켓에 대한 전폭적인지지를 가지고 있고, 여러

그 수준에서 일반적으로 사용할 수있는 다른 기술. 그러나 장소가 어디의 동작

IOS 는 Mac OS X 의 그것과 다릅니다

프로그램 메모리를 관리하기 위해 IOS 는 기본적으로 맥 OS X 에있는 동일한 가상 메모리 시스템을 사용

IOS 는, 각 프로그램은 여전히 자체 가상 주소 공간이를 가지고 있지만, 맥 OS X, 가능한 가상의 양을 들과는 달리

메모리는 사용 가능한 실제 메모리의 양에 의해 제한된다. IOS 가 지원하지 않는 때문입니다

디스크에 페이징 메모리가 가득 다네. 대신, 가상 메모리 시스템은 단순히 읽기 전용 메모리를 출시

이러한 코드 페이지와 같은 페이지,, 그게 더 많은 공간을 필요로 할 때. 이러한 페이지는 항상 메모리로 다시 로드할 수 있습니다

그들이 다시 필요한 경우 나중에.

메모리 제약이 계속되는 경우, 시스템, 실행중인 애플 리케이션에 낮은 메모리 통지를 보낼 수 있습니다

추가 메모리를 확보하도록 요청. 모든 애플 리케이션이 알림에 응답하고 그들의 역할을해야 메모리 압력을 완화하는 데 도움이됩니다. 귀하의 응용 프로그램에서 이러한 알림을 처리하는 방법에 대한 자세한 내용은 참조

"관찰 낮은 메모리 경고"(페이지 107).

IOS 가 배터리 전원을 절약할 수있는 방법 중 하나는 자동 수면 타이머를 통해서이다.시스템은 검색하지 못하는 경우

오랜 기간 동안 이벤트를 만지고, 그것은 처음에 화면을 dims 결국 모두 그것을 끕니다.

당신은 그런 가속도계에 의존 게임 등의 터치 입력을 사용하지 않는 응용 프로그램을 만드는 경우

당신 디밍에서 화면을 방지하기 위해 자동 수면 타이머를 비활성화할 수 있습니다. 이 타이머를 사용해야

아껴서 및 전력을 절약하기 위해 가능한 한 빨리 그것을 다시 시작하십시오. 영상 콘텐츠와를 표시 전용 애플 리케이션 터치 입력에 의존하지 않는 것이 가장 타이머를 비활성화해야합니다. 제출하지 않아도 오디오 애플 리케이션 또는 애플 리케이션

영상 내용은 타이머를 해제해서는 안됩니다.

타이머를 해제하는 과정은 (페이지 104) "화면 잠금을 해제"에 설명되어 있습니다. 추가 하시려면 여러분의 애플 리케이션에 전력을 저장하는 방법에 대한 팁 (페이지 109) "소비 전력을 줄이기"를 참조하십시오....

보안

IOS 의 보안 인프라는 애플 리케이션의 데이터 및 전체 시스템을 보호하고있다. 보안

위반이와 일어날 수 IOS 에서 방어의 첫 번째 라인 등으로 인한 피해를 최소화하는 것입니다 이렇게 자체 샌드 박스에서 별도로 각 응용 프로그램을 확보하여 위반. 그러나 IOS 과 같은 다른 기술을 제공합니다

암호화 및 인증 지원, 당신은 훨씬 더 근본적인 수준에서 데이터를 보호합니다.

보안에 대한 소개 내용과 어떻게 당신의 애플 리케이션의 디자인에 미치는 영향, 보안 개요를 참조하십시오.

The App Sandbox

보안상의 이유로, IOS 는 설치 시에 샌드 박스에있는 각 응용 프로그램을 (해당 환경 설정 및 데이터를 포함)를 넣습니다.

샌드 박스는 파일, 환경 설정, 네트워크 리소스에 대한 응용 프로그램의 액세스를 제한하는 세밀한 컨트롤의 집합입니다

하드웨어, 등등.sandboxing 과정의 일환으로, 시스템 자체의 샌드 박스에있는 각 응용 프로그램을 설치 응용 프로그램과 데이터를위한 가정 역할 디렉토리.

애플 리케이션들이 데이터를 구성하기 위해 각 샌드 박스 디렉터리에 대한 몇 가지 잘 알려진 서브 디렉토리를 포함

파일을 배치.-1 샌드 박스 디렉터리의 기본 레이아웃을 보여줍니다 그림.에 대한 자세한 내용은 샌드 박스 디렉터리와 무엇이 하위 디렉토리 각각에 속하는, 파일 시스템 프로그래밍 안내서를 참조하십시오.

Figure A-1 : Sandbox directories in ios

Keychain Data

키체인 암호 및 기타 비밀에 대한 안전하고 암호화된 컨테이너입니다.키체인을위한 것입니다

귀하의 응용 프로그램에만 해당하는 민감한 데이터의 소량을 저장. 이것은 범용으로 의도되지 않은

데이터를 암호화하고 저장하는 메커니즘.

애플 리케이션을위한 키체인 데이터는 애플 리케이션의 샌드 박스 외부에 저장됩니다.사용자가 사용하는 애플 리케이션 데이터를 백업하는 경우

아이튠즈는 키체인 데이터도 백업됩니다. IOS 4.0 전에 키체인 데이터는 장치에 복원할 수

있는 백업이 만들어졌습니다. 나중에 IOS 4.0, 비밀 번호 보호가 될 수있는 키체인 항목에서

의 접근성로 설정되지 않은 경우에만 다른 장치로 복원 kSecAttrAccessibleAlwaysThisDeviceOnly거나 현재 장치에 그것을 제한하는 다른 가치.

응용 프로그램을 업그레이 드하면 해당 응용 프로그램의 키체인 데이터에는 영향을 미치지 않습니다.

IOS 키체인에 대한 자세한 내용은 키체인 서비스 프로그래밍 가이드의 "키체인 서비스 개념"을 참조하십시오.