iOS의 실행 환경은 프로그램의 빠르고 안전한 실행을 위해 디자인 됐다. 다음 절들은 이 실행 환경의 주요 관점을 설명하고 어떻게 응용프로그램이 그 안에서 최적으로 운영될 수 있는지에 대한 안내를 제공한다.
빠른 실행, 짧은 사용(Fast Launch, Short Use)
iOS 기반 장치들의 강력함은 그 즉시성에 있다. 일반적인 사용자는 주머니나 가방에서 장치를 꺼내고 다시 집어넣기 전에 몇 초 간이나 혹은 몇 분간 사용한다. 그 사용자는 그 시간 동안 전화를 받거나 연락처를 찾아보거나 현재 듣는 노래를 변경하거나 정보 몇 가지를 얻을 것이다. 응용프로그램은 실행되고 동작하는데 직관적으로 되고 빨리 실행되야 한다. 응용프로그램이 실행되는데 오래 걸린다면, 사용자는 사용하기를 꺼릴 것이다.
iOS에서, 사용자는 한번에 하나의 응용프로그램만 상호작용 한다. 따라서, 새로운 응용프로그램이 실행될 때, 이전 응용프로그램의 사용자 인터페이스는 사라진다. iOS 4 이전에, 이것은 응용프로그램 자신이 종료되고 메모리에서 제거된다는 것을 의미했다. 그러나, iOS 4와 이후에는, 종료한 응용프로그램은 백그라운드로 이동한다. 응용프로그램은 다시 실행되거나 시스템이 사용 중인 메모리를 반환하도록 할 때까지 백그라운드에 유지된다.
백그라운드에서 돌아가기 위한 능력은 응용프로그램 재실행이 매우 빨라진다는 것을 의미한다. 백그라운드로 이동할 때, 응용프로그램의 객체들은 메모리에 유지되며 대부분의 경우에 응용프로그램 자신은 서스펜드 상태로 들어간다. 사용자가 응용프로그램을 재실행하면, 사용자 인터페이스를 재적재하고 이전 상태로 복구하는 것 없이 정확한 지점으로 간단하게 돌아온다.
응용프로그램이 백그라운드에서 돌아갈 수 있음에도 불구하고, 그렇게 계속 된다고 보장되지는 않는다. 메모리가 부족해지면, 시스템은 최근에 실행되지 않은 응용프로그램들을 제거한다. 이 일이 언제든, 그리고 어떨때는 아무 통보없이 일어날 수 있기 때문에, 응용프로그램은 여전히 백그라운드로 이동할 때 모든 저장안된 데이터 외에도 현재 상태에 대한 정보를 저장해야 한다. 언젠가 재실행되야 한다면, 이 정보를 이전 상태로 복귀해서 항상 실행됐던 것처럼 보이는데 사용할 수 있다. 그렇게 하는 것이 사용자가 응용프로그램을 마지막 사용했을 때로 바로 돌아가도록 해서 더 일관된 사용자 경험을 제공한다.
특화된 시스템 동작들(Specialized System Behaviors)
대부분에서, iOS는 Mac OS X와 같은 방법으로 같은 기능과 동작을 한다. 그러나, iOS의 동작이 Mac OS X와 다른 곳이 있다.
가상 메모리 시스템(The Virtual Memory System)
프로그램 메모리를 관리하기 위해서, IOS는 Mac OS X과 본질적으로 같은 가상 메모리 시스템을 사용한다. iOS에서, 각 프로그램은 여전히 그 자신의 가상 주소 공간을 갖지만, (Mac OS X와 다르게) 사용할 수 있는 가상 메모리는 이용 가능한 물리 메모리의 양에 의해 제약 된다. 이 이유는 메모리가 꽉 찼을 때, iOS가 휘발성 페이지들을 디스크에 쓰지 않기 때문이다. 대신에, 실행 중인 응용프로그램이 필요한 공간을 가질수 있게 하기 위해, 가상 메모리 시스템은 필요한대로 휘발성 메모리를 풀어준다. 이런 작업은 사용되지 않으며 코드 페이지처럼 읽기 전용 컨텐츠를 가진 메모리 페이지를 제어하는 것으로 한다. 그런 페이지들은 다시 필요해지면 이후에도 항상 메모리에 다시 불려질 수 있다.
메모리가 계속 제약 받는다면, 시스템은 실행 중인 응용프로그램에 추가적인 메모리를 해제하라고 요청하는 통지를 보낼 수도 있다. 모든 응용프로그램들은 이 통지에 응답해야하고 메모리 압박을 푸는데 협조하기 위해 자신의 역할을 해야한다. 어떻게 응용프로그램에서 그런 통지들을 다루는지에 대한 정보에 대해, "메모리-부족 경고 관찰하기"를 보라.
자동 슬립 타이머(The Automatic Sleep Timer)
iOS가 전력을 절약하기 위해 하는 한 방법은 자동 슬립 타이머를 통한 것이다. 시스템이 장기간 터치 이벤트를 감지하지 못하면, 초기에는 화면을 어둡게 하고 결국에는 완전히 꺼버린다. 대부분의 개발자들이 이 타이머를 그냥 두지만, 응용프로그램이 터치 입력을 사용하지 않는 게임 개발자들은 응용프로그램이 돌아가는 동안 화면이 어두워지는 것을 방지하기 위해 이 타이머를 끌 수 있다. 타이머를 끄기 위해, 공유되는 UIApplication 객체의 idleTimerDisabled 속성을 YES로 설정한다.
이 동작은 엄청나게 전력을 소비하기 때문에, 슬립 타이머를 끄는 것은 무슨 짓을 해서라도 피해야 한다. 사용을 고려해야 하는 응용프로그램은 지도 응용프로그램이나 게임이나 터치 입력에 의존하지 않지만 장치의 화면에 시각적 내용을 표시해야하는 응용프로그램 뿐이다. 오디오 응용프로그램은 오디오 컨텐트는 화면이 어두워져도 계속 플레이 할 수 있기 때문에 타이머를 끌 필요 없다. 타이머를 끈다면, 시스템이 더 많은 전력을 보존하도록 가능한 빨리 다시 켜야 한다. 어떻게 응용프로그램에서 전력을 절약하는지에 대한 추가적인 팁에 대해서, "전력 소비 줄이기"를 보라.
멀티태스킹 지원(Multitasking Support)
iOS 4와 그 이후에서, 응용프로그램은 백그라운드에서 돌아가는 동안 작업을 수행할 수 있다. 사용자가 응용프로그램을 나가면, 그 프로세스가 종료되는 대신에, 응용프로그램이 백그라운드로 이동된다. 백그라운드로 이동되자마자, 대부분의 응용프로그램은 서스펜드되서 돌아가지 않고 추가적인 전력을 소비하지 않는다. 그러나, 계속 돌아가야 하는 응용프로그램은 시스템에 돌아가야하는 실행 시간을 요청할 수 있다.
응용프로그램이 백그라운드에서 도는지 서스펜드 됐는지와 상관없이, 응용프로그램이 계속 메모리에 있다는 사실은 응용프로그램 재실행이 아주 적은 시간에 된다는 것을 의미한다. 응용프로그램의 객체(윈도우와 뷰를 포함한)는 보통 메모리에 유지되며 따라서 응용프로그램에 이후에 사용자에 의해 재실행될 때 재생성될 필요가 없다. 그러나, 메모리가 모자라지면, 시스템은 포어그라운드 응용프로그램에 더 많은 공간을 주기 위해 백그라운드 응용프로그램을 제거할 수 있다. 응용프로그램이 계속 백그라운드에 있었던 것처럼 나타나게 하기 위해, 응용프로그램은 백그라운드로 이동할 때 현재 상태에 대한 정보를 저장해야 하고 이후에 재실행에서 그 상태로 자신을 복귀할 수 있어야 한다.
멀티태스킹에 대한 개요와 무엇을 지원해야 하는지에 대해, "멀티태스킹"을 보라.
보안(Security)
iOS의 중요한 작업은 사용자의 장치와 그 위에서 돌아가는 응용프로그램의 보안을 보장하는 것이다. 그러기 위해서, iOS는 사용자 데이터의 무결성을 보장하고 응용프로그램이 다른 응용프로그램이나 시스템을 침범하지 않는다는 것을 보장하기 위해 몇 가지 기능을 수행한다.
응용프로그램 샌드박스(The Application Sandbox)
보안상의 이유로, iOS는 파일 시스템에서 하나의 장소에 응용프로그램(설정과 데이터를 포함하여)을 제약한다. 이 제약은 응용프로그램의 "샌드박스"로 알려진 보안 기능의 부분이다. 샌드박스는 파일과 설정, 네트웍 자원, 하드웨어 등등에 대한 응용프로그램의 접근을 한정하는 세밀한 제어의 집합이다. iOS에서, 응용프로그램과 그 데이터는 다른 응용프로그램이 접근 할 수 없는 보안 위치에 들어있다. 응용프로그램이 인스톨되면, 시스템은 응용프로그램에 대해 유일하고 불투명한 식별자를 산출한다. 루트 응용프로그램 디렉토리와 이 식별자를 사용하여, 시스템은 응용프로그램의 홈 디렉토리에 대한 경로를 구성한다. 따라서 응용프로그램의 홈 디렉토리는 다음의 구조를 갖도록 표현된다:
/ApplicationRoot/ApplicationID/
인스톨 과정 동안에, 시스템은 응용프로그램의 홈 디렉토리과 몇개의 주요 하위디렉토리를 생성하고, 응용프로그램 샌드박스를 설정하고, 홈디렉토리에 응용프로그램 번들을 복사한다. 각 응용프로그램과 그 데이터에 대해 하나의 장소를 사용하는 것은 백업과 복구 작업과 응용프로그램 업데이트와 언인스톨을 단순하게 한다. 각 응용프로그램에 대해 생성된 응용프로그램-특화 디렉토리에 대한 더 많은 정보는, "몇 가지 중요한 응용프로그램 디렉토리들"을 보라. 응용프로그램 업데이트와 백업과 복구 작업에 대한 정보는, "백업과 복구"를 보라.
중요: 샌드박스는 공격자가 다른 응용프로그램과 시스템에 발생시킬수 있는 손해를 한정하지만, 일어나는 공격을 막을 수는 없다. 달리 말하면, 샌드박스는 악의적인 존재에 의한 직접 공격에서 응용프로그램을 보호하지 않는다. 예를 들면, 입력 처리 코드에 이용가능한 버퍼 오버플로우가 있고 사용자 입력을 검사하는데 실패했다면, 공격자가 프로그램을 충돌하도록 할 수 있고 공격자의 코드를 실행하는데 사용할 수도 있다.
파일 보호(File Protection)
iOS 4와 그 이후에, 응용프로그램은 사용자의 장치가 잠겼을 때 파일을 암호화하고 접근할 수 없게 하는 파일 보호를 사용할 수 있다. 파일 보호는 민감한 데이터로 작업하는 응용프로그램에 대한 보안 단계를 추가하기 위한 특정 장치(iPhone 3GS 같은)에서의 내장형 암호화 하드웨어의 이점을 가진다. 보호된 파일들은 디스크에 항상 암호화된 형식으로 저장된다. 사용자의 장치가 잠겨진 동안에는, 데이터를 소유한 응용프로그램조차도 암호화된 파일에 있는 데이터에 접근할 수 없다. 사용자는 파일에서 해독된 데이터를 응용프로그램이 가져오도록 하기 전에 장치를 완전히 잠금해제해야(적절한 암호 입력으로) 한다.
장치에서 파일을 보호하는 것은 몇 가지 단계를 요구한다:
- 사용자의 장치에서 파일 시스템은 파일 보호를 지원하도록 포멧되어야 한다. 기존 장치에서는, 사용자가 장치를 다시 포멧하고 백업으로 모든 내용을 복구해야 한다.
- 사용자의 장치는 패스코드 잠금 설정이 켜져야 하고 유효한 패스코드를 설정해야 한다.
- 응용프로그램은 보호되어야 할 데이터 파일을 지정하고 적절한 메타데이터 속성을 넣어야 한다; "보호되는 파일 만들기"를 보라.
- 응용프로그램은 파일이 잠궈지는 상황에 적절하게 반응해야 한다; "보호된 파일의 이용 가능 여부 결정하기"를 보라.
어떤 파일을 응용프로그램이 보호되는 걸로 구분할지를 결정하는 것은 당신에게 달려있다. 응용프로그램은 파일 별로 파일 보호를 켜야하고, 한번 켜진 보호는 제거될 수 없다. 또한, 응용프로그램은 데이터 파일들이 보호되어야 하지만 현재는 안되는 상황을 준비해야 한다. 이런 상황은 파일 보호가 아직 추가되지 않았던 이전 백업에서 장치를 복구 했다면 발생될 수 있다.
응용프로그램에서 파일 보호 지원 구현에 대한 더 많은 정보에 대해서는, "보호된 파일로 작업하기"를 보라.
키체인 데이터(Keychain Data)
키체인은 암호와 그외의 기밀을 위한 안전하고, 암호화된 컨테이너다. 응용프로그램에 대한 키체인 데이터는 응용프로그램 샌드박스 바깥에 저장된다. 응용프로그램이 언인스톨되면, 그 데이터는 자동으로 제거된다. 사용자가 iTunes를 사용하여 응용프로그램 데이터를 백업할 때, 키체인 데이터도 또한 백업된다. 그러나, 백업이 만들어졌던 곳에서 장치로 단지 복원될 뿐이다. 응용프로그램의 업그래이드는 키체인 데이터에 영향을 주지 않는다.
iOS 키페인에 대한 더 많은 것은 키체인 서비스 프로그래밍 가이드에 있는 "키체인 서비스 개념"을 보라.
파일 시스템(The File System)
응용프로그램과 생성한 모든 파일들은 플래쉬-기반 메모리에 있는 사용자의 미디어 및 개인용 파일들과 공간을 공유한다. 응용프로그램은 다른 파일 시스템처럼 작동하고 표준 시스템 루틴을 사용하여 접근되는 로컬 파일 시스템을 사용하여 파일에 접근할 수 있다. 다음의 절들은 로컬 파일 시스템에 접근할 때 주의해야하는 몇 가지 것들을 설명한다.
몇 가지 중요한 응용프로그램 디렉토리들
보안 목적을 위해, 응용프로그램은 그 데이터와 설정을 기록할 수 있는 몇 개의 위치만 가진다. 응용프로그램이 장치에 인스톨될 때, 홈 디렉토리가 그 응용프로그램에 대해 생성된다. 표 1-1은 접근해야 될 수 있는 홈 디렉토리 안에 있는 몇 가지 중요한 하위디렉토리를 나열한다. 이 표는 각 디렉토리에 대한 정해진 용도와 접근 제한을 설명하고 디렉토리의 내용이 아이튠즈에 의해 백업될지를 가리쳐준다. 응용프로그램 홈 디렉토리에 대한 더 많은 정보에 대해서는, "응용프로그램 샌드박스"를 보라.
표 1-1 iOS 응용프로그램의 디렉토리
디렉토리 | 설명 |
|---|
<Application_Home>/AppName.app | 응용프로그램 자신이 들어있는 번들 디렉토리다. 응용프로그램은 사인되었어야 하기 때문에, 실행시에 이 디렉토리의 내용을 변경하면 안된다. 그렇게 하면 나중에 실행에서는 응용프로그램이 막힐 것이다. iOS 2.1과 그 이후에는, 이 디렉토리의 내용은 아이튠즈에서 백업되지 않는다. 그러나 아이튠즈는 앱스토어에서 구매된 모든 응용프로그램의 처음 동기화를 수행한다. |
<Application_Home>/Documents/ | 이 디렉토리는 사용자 문서와 응용프로그램 데이터 파일을 저장하는데 사용한다. 이 디렉토리의 내용은 파일 공유를 통해서 사용자에게 이용가능해질 수 있다. 이 디렉토리의 내용은 아이튠즈에서 백업된다. |
<Application_Home>/Library/ | 이 디렉토리는 응용프로그램-특화 파일들의 최상위 디렉토리다. 보통 표준 하위디렉토리 중에 하나에 파일들을 넣지만 커스텀 하위디렉토리도 생성할 수 있다(어떻게 표준 하위디렉토리에 대한 참조를 얻는가는, "응용프로그램 디렉토리에 대한 경로 얻기"를 보라). 사용자 데이터 파일에 대해 이 디렉토리를 사용하면 안된다. 이 디렉토리의 내용은 아이튠즈에서 백업된다. |
<Application_Home>/Library/Preferences | 이 디렉토리는 응용프로그램-특화된 설정 파일들을 가진다. 설정 파일들을 직접 생성하면 안되지만 대신에 응용프로그램 설정을 얻고 넣기 위해 NSUserDefaults 클래스나 CFPreferences API를 사용한다. 이 디렉토리의 내용은 아이튠즈에서 백업된다. |
<Application_Home>/Library/Caches | 응용프로그램의 실행 사이에나 응용프로그램 업데이트 동안에 유지하고 싶은 모든 응용프로그램-특화된 지원 파일들을 작성하기 위해 이 디렉토리를 사용한다. 응용프로그램은 보통 이 파일들을 추가하고 삭제할 책임이 있다. 또한 아이튠즈는 장치의 완전 복구 동안에 이 파일들을 제거하기 때문에 필요하면 재생성할 수도 있어야 한다. iOS 2.2와 그 이후에, 이 디렉토리의 내용은 아이튠즈에서 백업되지 않는다. |
<Application_Home>/tmp/ | 응용프로그램의 실행 사이에 유지하지 않아도 될 임시 파일들을 기록하는데 이 디렉토리를 사용한다. 응용프로그램은 더이상 필요하지 않을 때 이 디렉토리에서 파일들을 제거해야 한다(시스템은 또한 응용프로그램이 돌아가지 않을 때 이 디렉토리에서 남아있는 파일들을 제거한다). iOS 2.1과 그 이후에, 이 디렉토리의 내용은 아이튠즈에서 백업되지 않는다. |
어떻게 특정한 디렉토리의 경로를 얻나에 대한 정보는, "응용프로그램 디렉토리에 대한 경로 얻기"를 보라. 어떤 응용프로그램 디렉토리가 백업되는 가에 대한 자세한 정보는, "무엇이 백업되나?"를 보라.
대소문자 구분 파일 시스템(A Case-Sensitive File System)
iOS-기반 장치를 위한 파일 시스템은 대소문자 구분이다. 파일명으로 작업할 때마다, 대소문자 구분을 정확하게 하지 않으면 파일을 열수 없거나 접근할 수 없을 것이다.
사용자의 데스크탑 컴퓨터와 파일 공유하기
사용자 데이터 파일에 접근하고 싶어하는 응용프로그램은 응용프로그램 파일 공유를 사용하여 그렇게 할 수 있다. 파일 공유는 응용프로그램과 사용자의 데스크탑 컴퓨터 간에만 파일의 공유를 가능하게 해준다. 응용프로그램이 같은 장치에 있는 다른 응용프로그램과의 파일을 공유하는 것은 허가되지 않는다. 응용프로그램 간에 데이터와 파일을 공유하기 위해, 클립보드나 문서 상호작용 컨트롤러 객체를 사용한다.
어떻게 응용프로그램에서 파일 공유를 지원하는가에 대한 정보는, "사용자와 파일 공유하기"를 보라.
백업과 복구(Backup and Restore)
iTunes 응용프로그램은 적절한 상황에 자동으로 사용자 데이터의 백업과 복구를 처리한다. 그러나, 응용프로그램은 경우에 따라 파일들이 백업되고 복구되는 것을 보장하기 위해 파일들을 어디에 넣어야 하는지 알아야 한다.
무엇이 백업되나?(What Is Backed Up?)
백업과 복구 작업에 대한 어떤 방법으로도 응용프로그램을 준비할 필요는 없다. iOS 2.2과 그 이후에서, 장치가 컴퓨터에 연결되고 동기화될 때, iTunes는 다음 디렉토리에 있는 것들을 제외하고는, 모든 파일의 증분 백업을 수행한다:
- <Application_Home>/AppName.app
- <Application_Home>/Library/Caches
- <Application_Home>/tmp
iTunes는 응용프로그램 번들 그 자신을 백업하지만, 모든 동기화 작업 때마다 하는 것은 아니다. 장치 상에서 App Store로부터 구매한 응용프로그램은 장치가 다음번에 아이튠즈와 싱크될 때 백업된다. 응용프로그램은 자신이 변경(예를 들면, 응용프로그램이 업데이트 됐다던지)되지 않는다면 그 다음 싱크 작업에는 백업되지 않는다.
장시간 걸리는 동기화 작업을 방지하기 위해서, 응용프로그램의 홈 디렉토리 안에 어디에 파일들을 넣을지를 선택해야 한다. <Application_Home>/Documents 디렉토리는 사용자 문서와 응용프로그램 데이터 파일을 저장하는데 사용되야 한다. 임시 데이터를 저장하는데 사용되는 파일들은 Application Home/tmp 디렉토리 안에 위치해야 하고 더이상 필요없을 때 응용프로그램에 의해 삭제되어야 한다. 응용프로그램이 이후의 실행에서 사용될 수 있지만 백업될 필요는 없는 데이터 파일을 생성한다면, 그런 파일들은 Application Home/Library/Caches 디렉토리에 위치해야 한다.
주의: 응용프로그램이 커다란 데이터 파일이나 자주 변경되는 파일을 생성한다면, <Application_Home>/Documents 디렉토리가 아니라 Application Home/Library/Caches 디렉토리에 저장할 것을 고려해야 한다. 커다란 데이터 파일을 백업하는 것은 백업 과정을 현저하게 느려지게 할 수 있다. 정기적으로 변경(따라서 자주 백업되야하는)되는 파일에 대해서도 마찬가지다. 이들 파일을 Caches 디렉토리에 위치시키면 매번 동기화 작업마다 백업(iOS 2.2와 그 이후에서)되는 것이 방지된다.
응용프로그램에서 어떻게 디렉토리를 사용해야 하는지에 대한 추가적인 안내는, 표 1-1을 보라.
응용프로그램 업데이트 중에 저장되는 파일들(Files Saved During Application Updates)
사용자가 응용프로그램 업데이트를 다운로드할 때, 아이튠즈는 새로운 응용프로그램 디렉토리에 업데이트를 설치한다. 그런 다음 예전 설치를 삭제하기 전에 새로운 응용프로그램 디렉토리에 예전 설치에서 사용자의 데이터 파일을 이동한다. 다음 디렉토리에 있는 파일은 업데이트 과정 중에 보관된다는 것이 보장된다:
- <Application_Home>/Documents
- <Application_Home>/Library
다른 사용자 디렉토리에 있는 파일도 이동될 수 있지만, 업데이트 후에 그 존재가 있는지 의존하면 안된다.
시뮬레이터(The Simulator)
iPhone Simulator는 앱스토어에 배포하기 전에 응용프로그램을 테스트 하는데 사용하는 도구다. 시뮬레이터는 실제 장치에 있는 것에 가깝지만 동일하지는 않은 실행 환경을 제공한다. 디스크 페이징 지원에서 지연과 같은 장치에서 일어날 수 있는 많은 제약이 시뮬레이터에는 존재하지 않는다. 또한, OpenGL ES 같은 몇몇 기술들은 장치에서 할 때와 시뮬레이터에서 같은 방식으로 작동하지 않을 것이다.
시뮬레이터와 그 기능에 대한 더 많은 정보는, iOS Development Guide에 있는 "Using iPhone Simulator"를 보라.
이용 가능한 하드웨어 지원 결정하기
iOS를 위해 디자인된 응용프로그램은 서로다른 하드웨어 기능을 가진 장치에서 실행될 수 있다. 가속도계나 Wi-Fi 네트워킹 같은 기능은 모든 장치에서 이용가능하지만, 몇몇 장치는 카메라나 GPS 하드웨어를 가지고 있지 않을 수 있다. 응용프로그램이 그런 기능을 요구한다면, 그 응용프로그램을 구매하기 전에 사용자에게 항상 그 사실을 알려야 한다. 필수적이지는 않지만, 현재 지원하는 기능에 대해서는, 그 기능을 사용하기 전에 이용가능한지 체크해야 한다.
중요: 어떤 기능이 응용프로그램을 돌리기 위해서 반드시 제공되야 한다면, 응용프로그램의 Info.plist 파일에 UIRequiredDeviceCapabilities 키를 적절하게 설정한다. 이 키는 사용자가 장치에서 제공되지 않는 기능을 요구하는 응용프로그램을 설치하는 것을 방지한다. 그러나 응용프로그램이 해당 기능이 있거나 없거나 작동할 수 있다면 키를 포함하지 않아야 한다. 이 키를 설정하는 것에 대한 더 많은 정보는, "필수적인 장치 기능 선언하기"를 보라.
표 1-2는 어떤 형식의 하드웨어가 이용가능한지를 결정하기 위한 기술을 나열한다. 그 기능이 없어도 작동할 수 있지만 제공되면 사용하게 되는 경우에 이 기술들을 사용해야 한다.
표 1-2 이용가능한 하드웨어 기능 식별하기
Feature | Options |
|---|
멀티태스킹이 되는지 결정하기 위해... | UIDevice 클래스에 있는 multitaskingSupported 속성의 값을 얻는다. 멀티태스킹 이용가능성을 결정하는데 대한 더 많은 정보는 "멀티태스킹 지원이 이용 가능한지 결정하기"를 보라. |
인터페이스를 iPad-크기 화면으로 할지 iPhone-크기 화면으로 할지 결정하기 위해... | UIDevice 클래스의 userInterfaceIdiom 속성을 사용한다. 이 속성은 내용이 iPad를 위한 건지 iPhone과 iPod touch를 위한 건지에 따라 서로다른 배치를 지원하는 유니버셜 응용프로그램에만 적합하다. 유니버셜 응용프로그램을 구현하는데 대한 더 많은 정보는, iPad Programming Guide에 있는 "Starting Your Project"를 보라. |
외부 화면이 붙어있는지 결정하기 위해... | UIScreen 클래스에 있는 screens 속성의 값을 얻는다. 그 배열은 하나 이상의 화면 객체를 가지며, 객체들 중에 하나는 메인 화면에 해당하고 다른 것은 외부 화면에 해당한다. 추가적인 화면을 사용하는데 대한 더 많은 정보는, UIScreen Class Reference를 보라. |
하드웨어-수준 디스크 암호화가 이용가능한지 결정하기 위해... | 공유되는 UIApplication 객체에 있는 protectedDataAvailable 속성의 값을 얻는다. 디스크 내용 암호화에 대한 더 많은 정보는, "보호된 파일로 작업하기"를 보라. |
네트웍이 이용가능한지 결정하기 위해... | 현재의 네트웍 연결성을 결정하는 System Configuration 프레임웍의 접근도 인터페이스를 사용한다. System Configuration 프레임웍을 어떻게 사용하는지의 예제는, Reachability를 보라. |
스틸 카메라가 이용가능한지 결정하기 위해... | 카메라가 이용가능한지를 결정하기 위해 UIImagePickerController 클래스의 isSourceTypeAvailable: 메소드를 사용한다. 더 많은 정보는, Device Feature Programming Guide를 보라. |
장치가 동영상을 찍을 수 있는지 결정하기 위해... | 카메라가 이용가능한지 결정하기 위해 UIImagePickerController 클래스의 isSourceTypeAvailable: 메소드를 사용한 다음 UIImagePickerControllerSourceTypeCamera 원본에 대한 형식을 요청하기 위해 availableMediaTypesForSourceType: 메소드를 사용한다. 리턴된 배열이 kUTTypeMovie 키를 가진다면, 동영상 캡춰가 이용가능하다. 더 많은 정보는, Device Feature Programming Guide를 보라. |
오디오 입력(마이크)을 이용가능한지 결정하기 위해... | iOS 3과 그 이후에는 오디오 입력이 이용가능한지 결정하기 위해 AVAudioSession 클래스를 사용한다. 이 클래스는 내장 마이크와 헤드폰 잭과 연결된 악세사리를 포함한 iOS-기반 장치 상의 많은 여러가지 원본의 오디오 입력에 대해 책임진다. 더 많은 정보는, AVAudioSession Class Reference를 보라. |
GPS 하드웨어가 존재하는지 결정하기 위해... | 응용프로그램에 업데이트 되는 위치를 전달하기 위해 CLLocationManager 객체를 설정할 때 고 정밀도 수준을 지정한다. Core Location 프레임웍은 특정한 하드웨어의 이용가능성에 대한 직접적인 정보를 제공하지는 않지만 대신에 필요한 데이터를 제공하기 위해 정확도 값을 사용한다. 이후의 위치 벤트에서 보고된 정확도가 불충분하다면, 사용자가 알도록 할 수 있다. 더 많은 정보는, Location Awareness Programming Guide를 보라. |
특정 하드웨어 악세사리가 이용가능한지 결정하기 위해... | 적절한 악세사리 객체를 찾고 거기에 연결하기 위해 External Accessory 프레임웍의 클래스들을 사용한다. 더 많은 정보는, External Accessory Programming Topics를 보라. |
장치의 현재 배터리 잔량을 얻기 위해... | UIDevice 클래스의 batteryLevel 속성을 사용한다. 이 클래스에 대한 더 많은 정보는, UIDevice Class Reference를 보라. |
근접 센서의 상태를 얻기 위해... | UIDevice 클래스의 proximityState 속성을 사용한다. 모든 장치가 근접 센서를 가진 것은 아니므로, 이 센서가 이용가능한지 결정하기 위해 proximityMonitoringEnabled 속성도 체크해야 한다. 이 클래스에 대한 더 많은 정보는 UIDevice Class Reference를 보라. |
장치-수준이나 응용프로그램-수준 기능에 대한 일반적인 정보를 얻기 위해, UIDevice와 UIApplication 클래스의 메소드와 프로퍼티를 사용한다. 이들 클래스에 대한 더 많은 정보는, UIDevice Class Reference와 UIApplication Class Reference를 보라.
다운로드한 다음 설치하면 [시스템 환경설정]에 [Fan Control]항목이 생겨서 위의 화면처럼 설정할 수 있습니다.
최근 덧글