맥의 키보드 키 기호를 이미지가 아닌 글자로 입력하는 방법
맥의 키보드 키 기호를 이미지가 아닌 글자로 입력하는 방법입니다.
http://macbiblioblog.blogspot.com/2005/05/special-key-symbols.html
맥의 키보드 키 기호를 이미지가 아닌 글자로 입력하는 방법입니다.
http://macbiblioblog.blogspot.com/2005/05/special-key-symbols.html
전에 Xcode의 단축키 목록을 링크했었는데요, 스택오버플로우에서 누가 Xcode의 틱&트릭에 대해서 질문했습니다:
http://stackoverflow.com/questions/146297/what-are-those-little-xcode-tips-tricks-you-wish-you-knew-about-2-years-ago
유용한 기능이 많아서 따로 모아봤습니다. 제가 알아낸 기능도 포함했습니다.
읽는 법입니다:
http://support.apple.com/kb/HT1343
추가:
http://blog.eonil.com/archive/2010/01/11/맥의-키보드-키-기호를-이미지가-아닌-글자로-입력하/
플랫폼과 라이브러리, 언어는 독립적이지 않으며 솔루션의 일부로 유기적이어야 한다고 생각합니다.
크로스플랫폼 라이브러리는 실제로 특정 언어로 만들어진 인터페이스 정의에 가깝습니다. 해당 라이브러리가 여러 언어의 인터페이스로 제공되는 경우도 있지만, 대부분 래퍼이며, 네이티브가 아닙니다. 많은 경우, 래퍼는 느린 성능과 비호환 문법 등으로, 부자연스러운 상호운용이라는 의미이죠.
크로스언어 플랫폼 역시 마찬가지입니다. 대부분 이들은 기반 언어를 정해두고 있으며, 해당 플랫폼의 라이브러리는 기반 언어에만 자연스럽게 통합됩니다.
사실 여러 곳에서 사용될 수 있다는 것은 전용의 특징이 없다는 것과 같습니다. 그래서 가장 좋은 품질은 항상 전용 솔루션에서만 가능합니다.
이 솔루션을 나누는 기본 단위는 플랫폼이라고 생각합니다. 크로스플랫폼 라이브러리라도 구현된 플랫폼에 따라 특성을 타는 경우가 많으며, 제대로 된 처리를 위해서는 플랫폼별 핸들링을 해 주어야 합니다. 이들의 의미는 기능 세트를 제공하는 최소한의 공통 인터페이스에 있으며, 동일한 동작을 의미하는 것은 아닙니다. 언어의 경우에도, 많은 언어가 플랫폼을 떠나 작동할 수 있지만, 플랫폼별 특성을 매우 강하게 탑니다. 플랫폼별로 많은 것을 해주어야 합니다.
그래서 블로그의 개발 관련 카테고리는 플랫폼별로 나눠어져 있습니다. 언어나 라이브러리로는 나누지 않으며, 항상 특정 플랫폼에 바인딩된 실제 형태에 대해서만 다룹니다.
또한, 플랫폼은 차별화된 기능과 특성을 제공하는 기본 단위입니다. 특정 플랫폼에서 독자적인 기능을 제공하기 위한 라이브러리가 프레임워크입니다. 프레임워크 라이브러리가 여러 플랫폼에 걸쳐 똑같이 구현되어 있고 프레임워크만으로 솔루션 구성이 가능하다면 해당 프레임워크를 별도의 플랫폼이라고 부를 수 있을 것입니다. 자바같은 가상 머신 기반 플랫폼이 그런 경우이죠. 가상 머신 기반 플랫폼은 특정 없는 범용 하드웨어와 OS 플랫폼들을 통합하는데는 적합하지만, 개성있는 전용 하드웨어나 OS플랫폼의 기능을 제공할 수 없습니다. 자신의 목적에 맞는 플랫폼와 라이브러리 언어를 선택하는 것이 중요합니다.
개체의 동일성 비교는 언어의 중요한 요소입니다. Objective-C(이하 objc)는 기본적으로 C이기 때문에 비교 연산자는 수치 비교를 합니다. 따라서 포인터의 경우, 포인터 값 비교가 되므로, 개체 참조 비교가 됩니다.
하지만 OO개념에 따라, 동일성의 의미가 개체에 따라 달라질 수 있어야 하므로, 코코아에서는 프로토콜로 동일성 비교 기능을 제공하고 프레임워크 전체적으로 이 기능을 사용해 개체 스스로 동일성 비교를 수행할 수 있게 합니다. 이 기능은 isEqual 메서드로 제공되는데, 문서를 보면 isEqualTo라는 메서드도 있습니다. 둘의 차이는 무엇일까요?
http://www.mail-archive.com/cocoa-dev@lists.apple.com/msg18003.html
켄씨에 따르면, isEqual이 기본적으로 제공되는 의미상 개체 비교 기능이고, isEqualTo는 스크립팅 지원을 위한 것이라고 합니다. 스크립트용으로 별도의 의미상 비교를 수행할 수 있도록 말이죠.
두 메서드 다 기본적으로는 수치(포인터) 비교를 사용하나, 필요에 따라 오버라이드 할 수 있습니다. 코코아는 프레임워크 전반적인 비교 루틴에 이들을 사용하므로, 쉽게 의미상 비교를 오버라이드할 수 있습니다.
이유는 알 수 없지만, ScrollView 안에는 기본적으로 CustomView가 들어 있으며, 이 커스텀뷰를 제거하거나 바꿀 수 없습니다. 스클로뷰 안에 다른 컨트롤을 넣으려면 메뉴에서 Layout > Embeds Objects In > … 을 사용해야 합니다.
http://cocoadev.tistory.com/12
참고로 현재 사용환경은 Snow Leopard 10.6의 Xcode 3.2.1입니다.
개체 생성은 [[NSObject alloc] init] 패턴을 사용합니다. alloc 메서드는 메모리를 할당하고, 초기화는 init 메서드가 담당합니다. ‘생성자’ 역할은 init 메서드가 담당하죠.
그래서 커스텀 초기화를 수행하려면 init 메서드를 오버라이드해 사용합니다. init 메서드는 기본적인 사용 패턴이 있으면 그 패턴은 다음과 같습니다.
- (id) init
{
self = [super init]
if(self!=nil)
{
// Do something here.
}
return self;
}
개체 소멸 시점에 처리해야 할 일이 있다면 dealloc 메서드를 오버라이드하면 됩니다. dealloc 의 사용 패턴은 다음과 같습니다.
- (void) dealloc
{
// Do something here.
[super dealloc];
}
* = pointer to / value of.
& = address of.
// Declares ‘a’ as integer, and sets 1.
// Declares ‘b’ as pointer to an integer, and sets address of ‘a’.
// Declares ‘c’ as integer, and sets value of ‘b’.
// Returns equality of ‘a’ and ‘c’. This is true.
int a = 1;
int* b = &a;
int c = *b;
return a==c; // Returns true.
Xcode 단축키 목록입니다:
다음 글에 따르면 C 배열과는 달리 NSArray 에는 기본형식(int 등) 값을 저장할 수 없다는군요. 대신 NSNumber로 박싱하는 방식으로 사용한다고 합니다. 이 말이 사실이라면 기본형의 사용은최대한 피해야겠습니다.
http://lists.apple.com/archives/Cocoa-dev/2003/Dec/msg01222.html
하지만 이 글은 2003년 글이므로 현재는 맞지 않을 수 있습니다.
다음 링크는 C 기본 배열과 NSArray의 성능 비교입니다.
http://memo.tv/nsarray_vs_c_array_performance_comparison
http://memo.tv/nsarray_vs_c_array_performance_comparison_part_ii_makeobjectsperformselector
NSArray가 여러가지 편리한 기능과 환경을 제공하지만, 성능만큼은 C 기본 배열을 따라갈 수 없습니다. 테스트 범위 내에서 100배~500배의 성능 차이가 보이네요.
이 테스트 결과만을 보면 C 배열이 매우 우월해 보이지만, 사실은 그렇지 않습니다. 두번째 포스팅의 답글 중, 이 내용에 대한 반박이 있습니다. 이 포스팅은 오래된 것이라 예전에는 맞을지 몰라도 지금은 그렇지 않다는군요. 그리고 이 비교는 순수한 이터레이션 성능만을 논하고 있는데, 실제 병목은 이터레이션 자체보다 이터레이션간 수행하는 작업에 의해 좌우되므로 이 테스트가 큰 의미가 없다는 뜻입니다.
또한, 필자는 아이폰에서의 최적화를 위해 이 비교를 했는데, 실제 현 세대의 아이폰에서는 C 배열이나 NSArray 배열은 거의 차이가 없다고 합니다. 3GS에서는 아예 완전히 같은 결과가 나오므로 하드웨어 수준의 Objective-C에 최적화가 이루어져을 가능성이 있다는 답글도 있습니다. 답글의 필자가 직접 비교한 결과는 여기에 있습니다.
http://www.formconstant.net/diagrams/?p=40&preview=true
테스트 내용만 두고 보면 C 기본 배열을 사용하는 것이 좋겠다고 생각했지만, 답글의 내용까지 고려한다면 코코아 프레임워크의 기능을 전혀 제공하 수 없는 C 기본 배열을 굳이 사용할 필요는 없다고 생각됩니다.