- Not function list

 - Define application statement in one sentence. 

Define your users’ mental model 

 - Not developer’s mental model

 - Identify 

    – Objects and their hierarchiy and relationships

    – Concepts

    – Tasks ans workflow

    – Roles

 - Prioritize

 - Excellent cross-functional exercise

Reflect your users’ mental model

 - Presentation

 - Interaction

 - Terminology and labeling

Always ask “What’s important NOW?” (Is this to die for?)

 - Main interface is the most valuable real estate 

   – Do Not averload

   – Keep it fresh

 - Is something of secondary importance?

   – Use drawers and panels

Define your applications’ Objects, Concepts and prioritize them.

 - Objects impact design of interface, its’ emelements and locations of elements.

 - A Concept has more than one Tasks

Check contents at about 50 minutes for more Tip.

 - Start your Labels with Capitalized Letter and Verbs  

Because the order in which objects are instantiated from an archive is not guaranteed, your initialization methods should not send messages to other objects in the hierarchy. Messages to other objects can be sent safely from within awakeFromNib—by which time it’s assured that all the objects are unarchived and initialized (though not necessarily awakened, of course).

 즉, Interface Builder에서 사용할 오브젝트의 기본적인 초기화는 init 메소드 안에서 이미 완결해 둘 필요가 있다. awakeFromNib 멧세지는 각 오브젝트의 초기화가 끝난 후, 실제 User로부터의 인풋을 처리하기 이전의 처리로써 사용한다. 단 awakeFromNib가 복수의 오브젝트 안에 지정되어 있을 때 그 실행순서를 지정하는 것은 불가.

 awakeFromNib의 실행순서를 지정하고 싶을 때에는 각 윈도우를 별개의 nib 파일로 지정하는 꼼수가 있다고 하지만 그 역시 완전한 답은 되지 못 한다. 

 awakeFromNib와 관련된 보다 심도 있는 토론이 Theocacao에도 있으니 참조하는 것이 좋을 듯.

(단, 이 페이지의 본문의 내용에는 오류가 있다. 오류의 상세에 대해서는 댓글을 참조할 것.)

해서, Tiger등 Leopard 이하의 버젼에서도 가동할 수 있는 어플리케이션을 만들기 위해서는 수동으로 메모리를 관리해야만 한다. 이에 대한 간단한 정리.

Objecrive-C의 메모리 관리

그 외에, 아래 링크에서 실질적인 소스코드의 샘플과 주의점을 확인할 수 있다.

http://www.stepwise.com/Articles/Technical/2001-03-11.01.html

- 개발환경은 Leopard로 한정됨.

- 빌드 시에는 런타임의 버전을 설정할 수 있지만 이 경우에도 Objective-C 2.0의 문법을 사용한 경우에는 Leopard 이전의 버젼을 지정할 경우, 에러가 발생한다.

추가로, 가베지콜랙션을 사용할 경우 이러한 제약사항은 증가된다. 런타임에서의 가베지콜렉션의 사용여부에 대해 필수, 서포트, 서포트 안함의 3가지 옵션이 있는데, 이것이 각각 가베지콜렉션을 On/Off 하는데 사용된다. 특정 프로그램의 플러그인을 작성할 경우엔 프로그램과 플러그인의 설정이 서로 동일해야 한다. (다만 서포트의 경우, 어떤 설정에도 사용할 수 있다.)

이상을 고려했을 때, 그리고 아래 포스팅에서 기술한 바와 같이, 현재 Leopard의 시장 점유율이 20퍼센트가 안되는 상황에서 (정확히는 19퍼센트) Objective-C 2.0의 문법을 사용한 어플리케이션을 만드는 것은 나머지 거대한 점유율의 타이거 등 Leopard 이전 버전의 사용자 시장을 포기한다는 것을 의미한다. 즉, 수익성을 고려했을 때, 현재 Objective-C 2.0의 문법을 도입한다는 것은 아직은 시기상조라 하겠다.

더 자세한 숫자는 내일 키노트의 영상이 공개되면 다시 정리할 예정.

Objective-C 1.0에서는 클래스는 프로토콜에 선언된 메소드를 모두 구현할 필요가 있었다. 하지만 Objective-C 2.0에서부터는 필수 메소드와 선택적인 메소드를 선언할 수 있다. 아래에 소스코드의 예를 든다.

@protocol MyProtocol
- (void)requiredMethod; // 디폴트는 @required
@optional // 선택적 메소드
- (void)anOptionalMethod;
- (void)anotherOptionalMethod;
@required // 필수 메소드
- (void)anotherRequiredMethod;
@end

이하에 그 기술예를 정리.

Fast Enumeration Summary

아래에 프로토콜의 간단한 설명을 링크.

Objective-C Protocol Summary

참고로, 이 프로토콜은Objective-C 2.0이 되면서 약간 개선되었다.

그에 대해선 별도 기술 예정.

카테고리명을 기술하지 않고 공란으로 남겨둔다.
확장에서 선언된 메소드는 메인 클래스의 구현파일(@implementation 과 @end 의 사이)에 정의되어야 한다.

확장이 적용된 소스의 예는 아래와 같다.

@interface Card ( )
- (int) methodP;
@end

@implementation Card

- (int)methodP{
…
}
…
@end

이 설명은 Objective-C 1.0(Leopard이전의 버전)을 기준으로 하고 있다.

Objective-C 2.0에서 추가 및 강화된 기능(Extension)에 대해서는 별도 정리할 예정.

Objective-C Category Summary