싱글톤은 SharedInstance라는 명목으로 코코아 내에서도 상당히 자주 쓰이는 패턴이다. SharedApplication이나 NSFileManager, NSNotificationCenter 등에서 많이 활용된다. 쉽게 생각하면 다음과 같은 식으로 구현하면 될 것이라 보는데…
static SomeClass *sharedObject;
+ (SomeClass *)sharedInstance {
if (sharedObject == nil) {
sharedObject = [[self alloc] init];
}
return sharedObject;
}
프로그래밍 언어에서는 종종 필수 지시어가 사람에게는 별 의미 없는 것이 되곤 한다. 오브젝티브 C에서는 #pragma 디렉티브, 메소드 타입 인코딩같은 것들이나 기본적인 저장 클래스는 기본적으로 의미가 없는 것으로 보이며, 실제로 컴파일러가 똑똑해지면서 그 의미가 퇴색된다. 그럼에도 불구하고 이러한 것들은 코드 그 자체가 다른 개발자에게 힌트를 줄 수 있는 수단이 되기도 한다.
이제 막 코코아나 코코아터치를 시작한 개발자에게 IBAction, IBOultet, IBOutletCollection과 같은 매크로는 이러한 현상의 일부이다.
다른 두글자 접두어들과는 달리 IB-라는 접두어는 시스템 프레임워크와는 아무런 상관이 없고 그저 인터페이스 빌더와 관련이 있는 말이다. 인터페이스 빌더는 오브젝티브 C의 초창기에 그 근원을 두고 있는데, 88년에 “프로젝트 빌더”는 “NeXTSTEP 개발 도구”로 발전하였고, Xcode에 이르기까지 그 구조가 크게 바뀌지 않았다. 아마 요즘의 iOS 개발자들도 NeXTSTEP 워크스테이션을 접해보면 컨트롤들을 뷰에 끌어다 놓는 이 환경이 익숙하게 느껴질 것이다. 더 보기 »IBOutlet
이 글은 애플의
The Swift Programming Language의 서두에 해당하는 챕터를 간략히 요약했다. 이 책의 웹 버전은은 이 곳에서 확인할 수 있다.
전통에 따라 Hello World를 찍어보자.
println("Hello, world")
스위프트에서 이 코드 한 줄은 그 자체로 완전한 프로그램이다. 별도의 헤더 반입이나 보일러 플레이트가 없다. 전역적으로 작성된 코드는 곧장 프로그램의 진입점(entry point)이 된다. 따라서 별도의 main 함수를 작성할 필요는 없다. 또한, 한 라인에 한 구문씩 작성하는 경우 라인의 끝에는 세미콜론을 따로 붙이지 않아도 된다.더 보기 »Swift Tour
Objective-C는 그자체로는 메소드 호출을 C함수 호출로 변경해주는 objc_msgSend 함수를 동작하게 해주는 런타임에 의존하는, 따라서 실질적으로는 C언어와 크게 다를 것 없는 언어였다. 처음부터 C에 객체지향 개념을 더해서 확장을 만들어보는 실험의 결과물이었던 관계로 언어자체의 새로운 기능은 매우 부족했고, 이후 NeXT에 의해서 Foundation 프레임워크가 만들어졌는데, 사실 Objective-C 언어의 기능이라 여겨지는 많은 것들은 사실 Foundation 프레임워크가 제공하는 기능이라고 봐도 무방할 것이다. NeXT는 이 프레임워크를 통해서 모든 객체 클래스의 원형이되는 NSObject 클래스와 기본적인 자료형인 여러 클래스들을 디자인하였다.
Objective-C의 명분은 C를 기반으로 객체지향을 가능케하는 언어를 만드는 것이었지만, 이는 완전히 새로운 언어가 아닌 기존 언어에 약간의 확장을 덧붙인 개념으로 구현되었다. NeXT가 시작하는 시점에, 이들은 객체지향언어를 개발플랫폼의 중심으로 삼고 싶었지만, 이 시기에는 이러한 개념이 널리 통용되고 있지 않았으며, 제한적인 언어들만이 이 개념을 구현에 옮기고 있었다. 따라서 당시로서는 Objective-C는 나쁘지 않은 선택이었다. Objective-C는 객체지향적인 기능을 사용하면서도 동시에 기존의 C 코드들을 그대로 사용할 수 있었다.
더 보기 »swift에 대한 단상
기본적인 Sprite Kit 기반 애니메이션 앱을 만들어보면서 스프라이트 킷의 대략의 흐름을 살펴보자.더 보기 »SpriteKit 기본튜토리얼
iOS 7에서 UIKit 에는 UIDynamic이라는 새로운 기술이 도입되었다. 이는 뷰에 대해 강체 물리(rigid-object physics)를 적용한 애니메이션을 구현할 수 있도록 한다. 뷰가 중력의 영향으로 떨어지거나 다른 뷰에 충돌하는 효과를 표현할 수 있다. 이는 이전에는 매우 복잡한 알고리듬을 적용하여 표현할 수 있었으나, UIDynamicItem은 매우 간단히 구현할 수 있다.
더 보기 »iOS 7 : UIDynamic의 이해
지금까지 iOS앱을 구성하는 화면이 어떻게 구성되고, 또 그 화면을 구성하는 요소들이 기본적으로 어떤 특징을 가지고 있는지 알아보았다. 이번에는 iOS앱을 구성하는 화면외의 구성요소들을 살펴보도록 하자.
앱을 구성하는 요소는 다음과 같다.
이 들 객체가 있으면 앱은 실행되고 첫 화면을 표시할 수 있게 된다.더 보기 »[iOS 앱 만들기 007] iOS 앱의 최소 단위
이 포스팅과 관련하여 스토리보드에서 Segue를 사용하여 화면을 전환하는 사이에 두 뷰 컨트롤러 간의 데이터를 교환하는 방법에 대한 예시를 최근에 추가로 포스팅하였으니, 참고해주세요. – Segue를 통한 뷰 컨트롤러 전환과 데이터 교환 방법 가장 단순한 iOS의 앱을 하나 구성한다고 하면 이 앱은 앱 델리게이트과 기본 뷰(root view)의 뷰 컨트롤러, 즉 루트 뷰 컨트롤러로 구성이 될 수 있다. 물론 클래스를 디자인하기에 따라서는 앱 델리게이트와 뷰 컨트롤러가 하나의 객체일 수도 있다. (앱 델리게이트가 UIViewController의 서브클래스이면서 애플리케이션 프로토콜을 따르면서 이 두가지 일을 모두 수행하도록 만들면… 더 보기 »[iOS앱 만들기 006] 뷰 전환하기
iOS앱을 만들 때, 가장 많이 작성하고 다루는 클래스 중의 하나가 뷰 컨트롤러(UIViewController)일 것이다. 그리고 거의 십중팔구 이 기본 클래스를 서브 클래싱하여 커스터마이징한 뷰 컨트롤러를 사용하게된다. 물론 이러한 커스텀 뷰 컨트롤러만 사용해서 전체 앱을 만드는 것도 가능한데, 코코아터치에는 보다 유용한 몇가지 확장된 뷰 컨트롤러들이 존재하고, 이들을 잘 활용하면 전체적으로 작성해야 하는 코드의 양을 크게 줄일 수 있다. (그리고 무엇보다 잘 구현되어 있다.)더 보기 »[iOS 앱 만들기 005] 뷰 컨트롤러의 종류
뷰 컨트롤러의 주된 역할인 뷰의 제어에 대해 알아보려면 먼저 MVC 패턴에 대해 살짝 이야기하고 넘어갈 필요가 있을 것 같다. MVC 패턴은 객체 지향 프로그래밍의 디자인 패턴이지만, 코코아터치 프레임워크 곳곳에 적용되어 있으며, iOS 앱을 만들 때에도 필연적으로 가장 많이 사용될 수 밖에 없는 패턴이다.더 보기 »[iOS 앱 만들기 004] 뷰 컨트롤러 아웃렛과 액션