Drawtree

물론 그 모양이나 동작은 전혀 다르다.

나는 이것을 쓰고 있고, 내가 만든 일정을 웹사이트에 게시할 수 있지 않을까 하는 생각이 들었다.

곧바로  iCal 서버를 찾아보았다.

iCal은 서버가 있으며 Mac OS X Server 에 포함되어 있다.

또한, 이 서버는 오픈된 표준 칼렌더 프로토콜을 사용하며 서버 프로그램은 오픈소스로 공개되어 있다.

오. 굿인데?

맥 서버를 사지 않아도 쓸 수 있다는 거구나.

하지만 서버를 설치하고 어쩌구 하기는 귀찮으니 어디선가 무료로 서비스하고 있지 않을까.

구글님ㅠㅠ...

이것은 모든 맥 어플리케이션들이 마술같이 동일한 파일 핸들링을 보여주는 핵심 요소중에 하나다.

이것의 핵심은 NSDocument 클래스이다.

이는 NSDocumentController, NSWindowController, NSWindow등과 같이 연동되어 사용자가 쉘에서 파일을 클릭하는 순간부터 핸들링을 시작해 응용프로그램은 최종적으로는 해당 파일의 URL만 받아서 처리하면 되도록 구성되어 있다.

이 프레임워크의 주요사항 몇가지를 소개한다.

1. 자동 파일 타입 연결.

프로그램이 다룰 수 있는 문서는 메타데이터화되어 프로그램 패키지 안에 저장된다. OS X는 정해진 때에 프로그램들을 검사하여, 해당 파일 형식에 대한 핸들러를 자동 검출/제거한다.  시스템에 수동으로 등록시킬 필요가 없다. 하지만 디폴트 어플리케이션으로 등록하고 싶다면 몇가지 절차가 필요하다.

2. 자동 문서 파일 핸들링

해당 프레임워크를 사용하면 중간과정이 모두 자동으로 처리되고 URL만 받아 문서 뷰어/편집기의 로직에 집중할 수 있다. 사용자가 같은 파일을 실행하면 기존에 열린 편집기가 자동으로 포커스된다. 즉, 파일이 URL이 창에 바인딩된다. 또한 현재 바인딩된 파일 URL을 교체할 수도 있다.

하나는 가비지 컬렉션이다. 이는 전자동 개체 소멸이며, 일반적인 스크립팅 언어와 같이 메모리를 관리한다. Java, C#, ActionScript 등에서 사용했던 방식으로 할당하고 버리면 된다.

하지만 아이폰에서는 가비지 컬렉터가 지원되지 않는다.

그래서 남은 한가지 방식을 서야만 한다.

이는 레퍼런스 카운터다.

이 방식은 해당 개체를 보유한 수만큼 해제하는 것이다.

alloc/retain 으로 개체를 보유하고, 이 수만큼 release시킨다. 동수의 릴리스가 발생하면 개체의 dealloc 메서드가 호출되고, 곧 소멸된다.

문제는 개체의 보유(alloc/retain)자가 이 개체를 책임지고 해제(release)해야 한다는 것이다.

일반적으로 개체를 만들거나 할당한 쪽에서는 이를 명확히 알고 있으니 문제가 없다.

문제는 새로운 개체를 만들어 리턴하는 메서드이다.

일반적으로 이렇게 만들어진 개체는 받은 쪽에서 해제해줘야 한다고 생각하기 쉬우나, oc는 여기에 다른 룰을 적용한다.

해제는 만든거나 보유한 쪽만 해야 하는 거다. 만들어진 개체를 받은 쪽은 할당도 보유도 하지 않는다면 해제할 의무가 없다.

이를 위해 autorelease라는 메서드가 존재한다. 개체에 이 메서드가 실행되면 일단 해제된 것으로 인식하지만 즉시 소멸되지는 않는다.

개체는 해당 개체를 넘겨받은 스쿠프가 끝날 때까지 살아남아 있으며, 그 이후에 소멸된다. (이 소멸시점은 명확하지 않다)

여기에는 예외가 있는데, 개체 생성을 전문으로 하는 메서드일 경우이다. (팩토리 메서드)

Cocoa프레임워크에서는 alloc-, new-,  copy- 프리픽스는 이런 메서드를 의미한다. 이런 메서드로 생성된 개체는 명확하게 해제(release)해 주어야 한다. 그 외의 메서드에서는 새 개체가 반환되더라도 생성용이 아니라, 짧게 쓰고 끝내도록 하는 '편의' 메서드로, 이러한 개체는 해제하면 안된다. 또한 대부분의 경우, 이러한 개체는 생성 위치가 불명확하다. 명확하게 생성하는 메서드가 아닌 이상 해제하지 않으면 된다. 

정리하면 다음과 같다.

새로운 개체를 생성(alloc)하거나, 보유(retain)한 수만큼만 해제(release)한다.

다른 메서드에서 만들어진 경우, 해당 메서드가 생성( alloc- new-. copy-) 메서드일 경우는 자신이 생성한 것과 같이 취급해 해제한다. 그 외의 경우는 외부에서 만들어진 것이므로, (보유하지 않는 이상) 해제하지 않는다.

관련글:

"메서드는 외부의 메시지에 대한 반응일 뿐이므로, 진정한 OO개념에서는 private/protected/internal 메서드란 존재하지 않는다."

"단지 내부용 유틸리티 함수가 필요하다면 스태틱 함수로 구현하라."

위의 글에서 답자의 설명이다.

함수와 메서드에는 차이가 있다.

한글의 로마자 표기법이 아니라

한국어의 영문 표기법이다.

회전이 없는 경우라면 가능하다는 것?

시간 소스는 프레임마다 발행되는 틱으로 구성되며, 일반적으로 고정 간격과 가변 간격으로 나뉜다.

- 고정 간격은 일정한 시뮬레이션이 필요할때 사용되어야 하며,

- 가변 간격은 프레임간 매끄러운 애니메이션이 필요할때 사용되어야 한다.

그런데 두가지 다 필요하다면 어떻게 해야 하나?

고정 간격 시간의 특성상 일정한 간격으로 시뮬레이션을 수행하므로 시뮬레이션 해상도가 항상 같다.

그러므로 시간에 따라 시뮬레이션 결과가 달라지지 않는다.

이것은 항상 같은 결과를 내어야 하는 룰 엔진에 적합하다.

하지만 비주얼 프레임은 항상 가변 간격으로 렌더링된다.

여기에 딜레마가 발생한다. 룰은 고정 간격으로 돌리면서 가변 간격의 프레임에 맞추어 렌더링을 수행하면

애니메이션을 매끄럽게 할 수 없다. 

프레임 간격이 넓어지면서 1.8틱이나 2.5틱의 룰을 수행해야 하는 경우가 생긴다.

성능상 서브틱단위로 계산할 수는 없다. 하지만 틱마다 간격을 달리할 수도 없다.

2.5틱의 경우 2틱과 3틱을 교대로 수행할 수도 있지만, 애니메이션이 오차가 더 커져서 매끄럽지 못하게 된다.

연속적으로 2틱이나 3틱으로 적당히 조정할 수 있지만 이렇게하면 실제 시간과 싱크가 맞지 않아 실시간 흐름이 이상하게 느껴진다.

결론은, 고정 간격 시간이나 가변 간격 시간 어느 한쪽으로 일정한 시뮬레이션과 매끄러운 애니메이션 양쪽을 동시에 구현할 수는 없다. 이 모두가 필요하다면 이 두 가지 시스템을 같이 채용하고, 필요에 따라 적절히 조정해여 병용해야 한다.

기본적으로 두 가지 시간을 모두 발행하고, 룰 계산은 고정 간격을 쓴다.

렌더링은 가변 간격을 쓴다. 애니메이션은 모두 curve로 지정되어 연속적인 수치로 표현할 수 있게 해야 한다. 

실수로 표현된 진행 시간에 기반해 매끄럽게 애니메이션되도록 말이다.

모든 종류의 출력이 시간/수치 커브에 기반해 연속적으로 표현 가능해야 한다는 것이 핵심이다.

(차후에 네트워크 지연에 따른 에러 보정을 할 때도 편하게 된다)

구체적으로는 애니메이션 구현은 이렇다.

모든 애니메이션은 시간/수치 커브로 나타낼 수 있다. 3차벡터의 경우 개별적인 x/y/z 축에 대한 시간/수치 커브로 표현가능하다. 이 수치 커브를 함수화해 사용하는 것이다.

어떤 수치가 변화하는 것이라면 모두 이렇게 표현할 수 있다.

예를 들어 시간이 지나면서 차오르는 진행 상태 바 같은 경우 이런식으로 쉽게 표현 가능하다.

SRT(크기/회전/이동)라는 기본 애니메이션은 틱 기반의 누적 애니메이션으로 구현해야 한다고 생각하기 쉽지만 그렇게 해서는 안된다. 항상 시작 상태와 최종 상태가 정해지고, 애니메이션은 이 사이가 보간되는 형식으로 구현해야 한다.

룰 계산과 출력의 타이밍은 이렇게 어긋나게 된다.

입력은 어떨까?

룰 계산은 고정 간격으로 틱단위 계산된다. 그러므로 이 틱간에는 어떤 변화가 생기더라도 룰 자체에는 영향이 없다.

그러므로 입력은 즉시 수행되어도 좋다.

하지만 어떤 입력은 여러 프레임에 걸쳐 수행된다.

드래그나 키홀딩 같은 입력이 그러하다. 특히 드래그는 여러 프레임에 걸쳐 이산적인 좌표들로 구성된 입력값이다. 문제는 이 입력 프레임들의 간격은 항상 가변이라는 것이다.

사실 이 입력을 그대로 써도 별 문제는 없다. 약간의 입력 오차만이 발생할 뿐이며, 어떤 유저들은 이러한 입력에 익숙하기도 하다.

문제가 생길 경우에는 각 입력값을 보간해 매끄럽게 한 뒤 필요한 수치를 사용하면 된다. 이 경우 최소한의 바른 범위의 보간을 위해 최소한의 샘플이 필요하게 되며, 이만큼의 지연 시간이 생긴다. 어느쪽을 선택할지는 게임의 디자인에 달려 있다.

하지만 ASP.NET은 태생적인 한계로 인한 치명적인 단점이 있다.

그것은 MS사 제품이라는 것이다.

MS자 제품은 전통적으로 자사 제품에 대해서는 상당한 품질을 보여주었지만,

타사 제품, 특히 경쟁 제품과의 호환성은 극도로 좋지 않았었다.

현재 브라우저들이 많이 표준화되었다고는 하지만

아직 개별적으로 약간씩 다른 부분들이 있다.

MS 브라우저는 차이가 더욱 심하다.

그리고 이 차이는 HTML뿐만 아니라 DOM및 자바스크립트 엔진에서도 나타난다.

MS는 경쟁 제품에 대해 자사의 높은 점유율을 무기로 하여 

호환성을 떨어뜨리는 폐쇄적인 방식으로 일관해왔다.

결국 이는 그들의 점유율을 떨어뜨리는 결과를 가져왔다.

이에 반해 구글은 가능한한 높은 호환성을 위해 어떤 짓도 마다하지 않는다.

GWT는 범용 AJAX컴파일러로, 어떤 브라우저단이든 커버가 가능하다.

브라우저 호환성을 높이기 위해 어쩔수 없는 브라우저간 차이를 없애는 방법으로

모든 브라우저들의 세부적인 차이를 자동으로 추적해 컴파일하는 프로그램으로 해결하는 것이다.

솔직히 MS가 이러한 기술이 없을리 없다.

ASP.NET+AJAX로 그러한 맥락에서 나온 것이리라 생각한다.

더욱이 호환성을 무기로 걍쟁시장을 파고드는 전략은 MS가 초기에 즐겨쓰던 방법이며, 그 결과 현재의 MS가 있다.

맘만 먹으면 어떤식으로든 완벽하게 호환되는 제품을 내놓지 못할리가 없다.

엄청난 수의 개발자를 거느리고, 모든 종류의 표준화 단체마다 한발을 걸치고 있는 MS다.

하지만 MS는 IE시리즈에서 너무 많은 죄를 지었다. 현재 MS가 표준를 지킬 거라고 믿는 사람은 아무도 없다. (특히나 웹쪽이라면 말이다) 그들이 표준화에 대한 신뢰를 회복하기 전에는 ASP.NET+AJAX가 아무리 좋은 기술이라 한들, 호환성이 가장 중요한 이슈가 되는 웹 시장에서는 그다지 환영받지 못할 것이다.

GWT는 아직 초기단계이지만, 구글이 지금껏 해왔던 일들을 생각해보면 최소한 브라우저간 호환성만큼은 제대로 보여줄 것이다.