BLOG main image
분류 전체보기 (92)
Cocoa Touch (11)
Cocoa (10)
Objective-C (13)
Swift (6)
Development (11)
Tools (11)
Books (7)
etc (21)
Application release (1)
Document Project (1)
105,797 Visitors up to today!
Today 0 hit, Yesterday 2 hit
daisy rss
tistory 티스토리 가입하기!
'cocoa'에 해당되는 글 11건
2011. 1. 1. 23:18
Asset Library를 사용해서 AssetsGroup을 가져오기 위해서 사용하는 block인 ALAssetsLibraryGroupsEnumerationResultsBlock(휴.. 길다.)을 사용할 때 enumeration을 중단 시키고 싶을 때는 어떻게 하라고 되어있는데 어이없게도 enumeration이 종료 되었을 때를 어떻게 판단할 지는 문서화 되어있지 않다.
별도로 completion block을 설정하거나 completion  notification이 정의 되어있지 않은걸 보니 결국 ALAssetsLibraryGroupsEnumerationResultsBlock 파라메터 가지고 어떻게든 확인해봐야 한다는 결론이 나는데...
파라메터라는게  ALAssetsGroup과 BOOL *형의 stop(이것은 enumeration을 중단 시키기 위해서 사용된다.) 밖에 없다.
결국, ALAssetsGroup이 nil이면 enumeration이 종료된 것이라고 판단 할 수 밖에 없는데 (일단 그렇게 들어오는 듯 하다. 하지만 문서에는 없다.) 참 불안하지 않을 수 없다. 이왕이면 확실하게 문서화 해주던지 그걸로 판별하지 말라고 써놓던지...

결국, 결론은 "문서화 되어있지 않지만 ALAssetsGroup의 값이 nil로 들어오면 끝난것 같다." 이다.

사족 : 굳이 completion 정보를 알 필요 있을까 싶기도 하다. 어차피 async로 작동되고 언제 끝날지도 모르는데 enumeration 될 때마다 정보를 모델에 넣고 UI를 갱신해도 될 것이라는... 그렇지만 asset의 수가 엄청나게 많을 때 reload되는데 문제 없을까? (이건 나중에 걱정하기로 하고...)
Name
Password
Homepage
Secret
2010. 9. 19. 22:47
Mac OS X와 iOS의 outlet을 assign으로 할지 retain으로 할지 달라지는 이유는 Nib loading 매카니즘의 차이 때문이다. 이거 두번이나 확인한 건데 분명 몇달 지나면 또 까먹을지도 몰라서 블로깅 해둠.
상세한 설명은... 기억 안나면 그때 다시 문서보면 되지 뭐...
Name
Password
Homepage
Secret
2010. 5. 10. 18:24

직접 세터를 구현해서 사용할 때, 실제로 값이 바뀌지 않아도 노티피케이션이 날아가기 때문에 비효율적일 수도 있으므로 수동으로 노티피케이션을 보낼 필요가 있음. 그때 사용.


요런 설명... This can be useful to help minimize triggering notifications that are unnecessary, or to group a number of changes into a single notification.



+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)aKey

{

    BOOL sAutomatic = NO;

    

    if ([aKey isEqualToString:@"key"])

    {

        sAutomatic = NO;

    }

    else

    {

        sAutomatic = [super automaticallyNotifiesObserversForKey:aKey];

    }

    

    return sAutomatic;

}


Name
Password
Homepage
Secret
2009. 12. 24. 11:00
예전에 잠깐 검토하다가 엄청난 삽질을 해야 한다는 걸 알고 보류해뒀는데 그 사이 누군가 그 삽질을 해놨군요.
폰트에 대해서 매우 잘 알고 있는 사람이 만든것 같습니다. :)
한글도 잘 출력되는 것을 확인했습니다.


라이센스도 착하군요!
Name
Password
Homepage
Secret
2009. 12. 1. 17:54

아무래도 한글을 처리 할 일이 많다.

그 중 소팅은 단연 중요하고 많이 처리되는 일인데, 코코아에서 아래와 같은 코드는 어떤 결과를 보여주게 될까?



NSArray *sTemp        = [NSArray arrayWithObjects:@"하루", @"허씨", @"한국인", @"호빵", @"하늘", nil];

NSArray *sSortedArray = [sTemp sortedArrayUsingSelector:@selector(compare:)];


for (NSString *str in sSortedArray)

{

    NSLog(str);

}



결과

2009-12-01 17:47:58.369 Test[1859:10b] 하늘

2009-12-01 17:47:58.371 Test[1859:10b] 호빵

2009-12-01 17:47:58.372 Test[1859:10b] 한국인

2009-12-01 17:47:58.372 Test[1859:10b] 허씨

2009-12-01 17:47:58.372 Test[1859:10b] 하루


이건 뭐... T_T;;;

(Mac OS X 10.5, 10.6, iPhone 모두에서 발생)


애플에 이야기 하긴 했는데 언제나 고쳐질지는 의문.

difro | 2009.12.01 23:28 | PERMALINK | EDIT/DEL | REPLY
@selector(compare:) 대신 @selector(localizedCompare:) 를 쓰니까 잘 되네요. (Mac 10.6 에서 테스트)
2009-12-01 23:26:36.602 Untitled[4808:a0f] 하늘
2009-12-01 23:26:36.603 Untitled[4808:a0f] 하루
2009-12-01 23:26:36.603 Untitled[4808:a0f] 한국인
2009-12-01 23:26:36.604 Untitled[4808:a0f] 허씨
2009-12-01 23:26:36.608 Untitled[4808:a0f] 호빵
maccrazy | 2009.12.02 09:59 신고 | PERMALINK | EDIT/DEL
흐잇.. 감사합니다. localizedCompare에서는 문제가 없군요. 다른 방법으로 해결했는데 localizedCompare를 쓰는게 더 편하군요. 그래도 compare:쪽 버그도 해결되어야 할 것 같기는 해요.
Name
Password
Homepage
Secret
2008. 11. 26. 14:10
UIView를 생성할 때 특정 사이즈 이상에서 자주 문제가 발생해서 골탕을 먹고 있었다. 2.2로 업데이트 된 후로 더 제약이 많아진 것 같다는 생각을 하면서 UIView의 문서를 봤다.
2.2 문서에 예전에 없던 문장이 추가된게 보인다.

Note: UIView instances have a maximum height and width of 1024 x 1024. Views larger than this must be creating using CATiledLayers.


애플... 때려버리고 싶다. T_T
han9kin | 2008.11.26 21:26 신고 | PERMALINK | EDIT/DEL | REPLY
Note대로 CATiledLayer를 사용하는 View를 만들면 되지 않나요?
maccrazy | 2008.11.27 09:46 신고 | PERMALINK | EDIT/DEL
문제는 예전 버전 부터 쭉~ 저 문제를 내포하고있었는데 이제야 도큐먼트에 올라왔다는게... T_T
박종암 | 2008.12.06 13:58 | PERMALINK | EDIT/DEL | REPLY
Google Phone!!!!!
이 기회에 스위칭 하시죠오~ :)
아! Google Phone은 자바다!!!
Name
Password
Homepage
Secret
2008. 11. 12. 15:03
상상력이 부족해서인가... 코코아 터치의 황당한 부분들이 자주 이해가 안된다.
코코아의 경우 NSTableView의 슈퍼클래스는 NSView...
그렇다면 UITableView의 슈퍼클래스는? UIView일까? No!
UITableView > UIScrollView > UIView > ...
헉... UIScrollView야 넌 왜 거기 들어가있니?
또치가 UIWindow가 UIView를 상속받았다고 해서 뜨아했었는데.. 이건 뭐...
뒤통수를 때려도 이렇게 때리는 구나.
littlehj | 2008.11.14 09:50 신고 | PERMALINK | EDIT/DEL | REPLY
첨에 보고 나도 화들짝 했지.....이거 뭐여~
박종암 | 2008.11.18 06:15 | PERMALINK | EDIT/DEL | REPLY
UIView가 UIWindow의 super class인건, single window interface가 아무래도 iPhone/Touch에선 주종을 이뤄서 그러려니 이해는 했는데, 왜 굳이 UITableView를 UIScrollView에 붙박이로 넣었는지는 영..
근데 아무래도 Scroll View안에서 쓸 가능성이 높아서 아예 붙박이로 넣어놔서 최적화를 하려고 한게 아닌지..
사실 전 이런 것보다 더 이해 못하겠는게 있어요.
이를테면 NSSplitView에서 Splitter혹은 Divider의 두께를 결정하는게 있는데, 이게 Tiger에서 안되요. 분명 함수는 Tiger에도 있는 함수인데.. 그래서 Apple에 리포트했더니, Leopard에선 해결되었다 이렇게 오더군요.
그럼 다 Tiger를 버리란 소리인지. Panther까지는 그래도 괜찮았는데, Tiger는 안정된 OS이고 feature set도 괜찮아서 많이들 그냥 쓰고 있는데요. 기존 버젼에 대한 지원을 요새는 확확 버리는거 같더군요.
에고....
잘 지내시죠?
maccrazy | 2008.11.19 10:18 신고 | PERMALINK | EDIT/DEL
:) 뭐 어쩌겠어요.. 적응해야겠죠..
그나저나 요즘 종암님 너무 바쁘신거 같아요.. ㅋㅋ
박종암 | 2008.11.21 01:18 | PERMALINK | EDIT/DEL | REPLY
아... 네.. 요새 몇달 동안 정말 정신 없네요. 계속 Windows와 Mac, Assembler와 C/C++/Objective-C를 왔다 갔다 하면서, 프로젝트를 한 10개 이상 소화하고 있어요. 2세 계획은 잘 되고 있으신가요?
Name
Password
Homepage
Secret
2008. 11. 11. 13:22
Cocoa에서는 여러가지 다양한 방법으로 이미지를 저장할 수 있는 방법이 있었다. 주로 NSImageRep군의 객체들을 이용하면 쉽게 되는데 문제는 Cocoa touch에서는 UIImageRep라는 넘이 없다.
이런... 이미지를 저장하고 싶은데... 
그럴 때는 아래의 두 함수를 사용하면 된다. (왜 Cocoa랑 통일성이 없는 것이냐!)
덤으로 이건 포토앨범에 저장해주는 함수.
어떻게 보면 더 편해진거 같기도 하고 어떻게 보면 일관성 없어보이기도 하고...

아무래도 모바일 디바이스다 보니 이래 저래 예전 방식으로 하기엔 비효율적이거나 힘든 부분이 있었겠지.
littlehj | 2008.11.14 09:50 신고 | PERMALINK | EDIT/DEL | REPLY
일관성이 없다...에 한표...지금 수준을 보면 서두른 기미가 많이 보이는 편이네~
박종암 | 2008.11.18 06:19 | PERMALINK | EDIT/DEL | REPLY
요새 iPhone쪽으로 많이 하시나 보네요?
아마 Mac용 코코아와 iPhone용 코코아가 많이 달라지면, iPhone의 매력이 떨어질텐데.. Apple로써는 Android를 조심해야겠습니다. 요런거 잘못하면 Android가 팍 치고 올라올 수있겠죠.
근데 Android용 Java의 함수들은 컴퓨터용 Java의 그것들이랑 얼마나 차이가 있으려나..
Name
Password
Homepage
Secret
2008. 11. 5. 23:45
아이폰 덕분인지 코코아, Objective-C 개발 저변이 확대되고 있다는 생각이 많이 든다.
대부분의 신규 Objective-C 개발자들이 C++이나 Java 개발을 하던 사람들인데 가끔 코드를 보면 예전 스타일을 고수하는 것을 볼 수 있다. 그래, 솔직히 고백하건데 나도 처음에는 그렇게 쓴 적이 있었다.
로마에 가면 로마법을 따르라고 했던가 Cocoa/Objective-C 세상에서는 그 룰을 따라주는게 좋을 것 같다.
많은 부분에 대해서 이야기 할 내용이 있지만 이번에는 "get"으로 시작하는 메소드에 대해서 이야기 해보고자 한다. 일반적으로 set, get으로 시작하는 메소드를 accessor라고 하고 보편적인 다른 언어에서는 set은 맴버 변수에 값을 넣을 때, get은 반대로 값을 가지고 올 때 사용한다. Set, Get 처럼 대문자로 시작하는 경우는 있을 지언정 대부분이 이렇게 사용했을 것이다.
사실 여기에도 의문이 조금 있다. get이라는 단어 자체가 너무 의미가 포괄적이지 않나 하는 것이 내 생각인데 변수의 값을 복사해서 받는다는 말인지 포인터만 가져오겠다는 것인지, 다른 어느 곳에서 부터 받아오겠다는 건지...
뭐, 이런 의미에 대한 이야기는 나중에 기회가 되면 다시 이야기 하기로 하고 Objective-C에서는 어떻게 쓰나 알아보자.
Objective-C의 경우 set은 "set"으로 명시하지만 get은 기본적으로 맴버 변수 이름을 그대로 사용한다.
만일 맴버 변수 이름이 frame이면 get메소드 이름도 frame이 되는 것이다. 만일 변수 이름이 _frame이면 역시 frame, mFrame이라도 역시 frame이 되는 것이다.
변수에 사용된 프리픽스를 제외한 단어가 메소드 이름으로 사용된다. 이 규칙은 단순하지만 꽤 중요한데 Key-Value Coding에서 진 면목을 드러낸다.(이에 대해서는 차차...)
그렇다면 언제 "get"을 사용하는가? 아래의 경우를 보자

<예>
NSValue의 - (void)getValue:(void *)buffer
NSData의 - (void)getBytes:(void *)buffer
NSString의 - (void)getCharacters:(unichar *)buffer
등등

자, 보면 알겠지만 값을 복사해서 돌려주는 포인터를 받아올 때 사용한다. 만일 이런 용도 이외에 get을 사용한다면 다른 협업하는 개발자에게 혼란을 주는 행동을 하게 되는 것이다.
박종암 | 2008.11.06 18:14 | PERMALINK | EDIT/DEL | REPLY
이거 예전에 쓰셨던 내용이죠? 이글루스에서 본거 같은데...
get과 set을 쓰는 것은 getter/setter라는 용어를 그대로 반영한거 같습니다.
요새 다른 사람들의 코드를 손보느라고 시간을 많이 쓰는데, 제가 발견한 문제가 바로 이 글과 관련이 많습니다. method의 이름으로 도대체 뭘하는 것인지 알아먹기가 힘들다는 것입니다. 결과적으로 data encapsulation/hiding이 되지를 않습니다. 클래스의 내부 구조를 모르고도 가져다 쓸 수있다가 OOP의 장점 중 하나인데, 이게 되지를 않으니..
maccrazy | 2008.11.06 18:35 신고 | PERMALINK | EDIT/DEL
예전에 쓴 내용은 아닌데요. 예전 회사에서 이 문제로 한참을 시끄럽게 토론했던 기억이 나서 한번 써봤습니다.
뭐, get도 나쁘진 않지만... 글쎄요... 자주 혼란스러운 경우게 생기더군요.
Name
Password
Homepage
Secret
2008. 7. 30. 15:26
Fast enumeration은 Objective-C 2.0에 새로 추가된 기능 중 하나인데 컬렉션의 모든 맴버를 접근하는 쉽고 간단한 방법이며 NSEnumeration보다 빠르게 작동할 뿐 아니라 코드도 더 읽기 쉽다.
아래와 같이 간단하게 사용할 수 있다.
무엇보다 큰 장점은 실수로 바운더리를 벗어나는 억세스를 만들어 내지 않고 안전하게 enumeration할 수 있다는 점이다. 멀티 쓰레드 환경에서 동시에 enumeration 할 수 있지만, 만일 enumeration 중에 값이 변경되면 익셉션을 발생시킨다.
NSFastEnumeration 프로토콜을 지원하는 모든 컬렉션(NSArray, NSDictionary, NSSet, NSEnumerator)에서 사용가능하다.
만일 직접 만든 컬렉션에서 fast enumeration을 지원할려고 하면 NSFastEnumeration 프로토콜을 지원하면 된다.

자, 그럼 커스텀 컬렉션에서 fast enumeration을 지원하는 방법을 알아보자.
MyCollection이라는 새로운 컬렉션을 하나 만들고 메인 코드를 다음과 같이 작성하고 빌드를 했다.
어라.. 아래와 같은 워닝이 발생한다. 당연하지. 아직 프로토콜을 구현하지 않았다.

/Users/cgkim/FastEnumTest/FastEnumTest.m:11: warning: 'MyCollection' may not respond to '-countByEnumeratingWithState:objects:count:'

자 다음 코드를 보자. 프로토콜을 지원하기 위해 MyCollection안에 새로 구현한 메소드이다.
이게 조금 복잡해서 일단 파라메터를 2개로 나눠서 생각해야 한다.

먼저 NSFastEnumerationState라는 구조체가 있고 id *인 aStackbuf와 NSUInteger인 aLen이 있다.일단 뒤에 두 파라메터는 사용하지 않겠다.
aState->state안에는 현재 어디까지 enumeration했는지에 대한 정보가 들어있다. 단순히 C 어레이를 이용했으니 그 값은 그냥 인덱스로 사용하겠다. 처음 countByEnumeratingWithState... 메소드가 불리면 0이 들어있을 것이다.
처음 불렸을 때 aState->state 안에 돌려 줄 아이템의 갯수를 넣는다. 그리고 itemsPtr에는 아이템이 들어있는 C 어레이를 넣는다. 그리고 mutationsPtr에는 self를 넣어주면 되겠다.
그리고 마지막으로 리턴 값으로는 몇개의 아이템을 넣어보내는지 알려주면 된다.

자, 그럼 뒤에 두 파라메터는 언제 쓰는가?
만일 컬렉션 안에 C 어레이 형태의 스토리지가 없다면, 뒤에 딸려오는 두개의 파라메터를 이용하면 편할 것이다. 먼저 aLen에는 aStackbuf의 크기가 오는데 객체를 aStackbuf안에 최대 aLen만큼 넣어주면 된다.
그리고 aState->state는 어디까지 enumeration했는지에 대한 정보를 aState->itemsPtr에는 aState를 aState->mutationsPtr에는 self를 넣어주면 된다. 그리고 리턴 값은 처음의 경우와 동일하게 몇개의 아이템을 넣어보냈는지 알려주면 된다. 별도의 코드는 작성하지 않겠다.

이것이 별로 마음에 들지 않는 이유 중 하나는 편의를 위해서 랭귀지를 임의로 확장했다는 것이고 다른 하나는 랭귀지의 확장이 랭귀지에서 그치지 않고 프레임웍(NSFastEnumeration)과 연결되어 버렸다는 점이다. 랭귀지의 특정 기능을 이용하기 위해서 더 상위개념인 프레임웍을 반드시 이용해야 하는 상황이 이상한 것은 나 뿐인 것인지 궁금하다.
홍민희 | 2008.07.30 16:00 | PERMALINK | EDIT/DEL | REPLY
프레임웍이 언어의 일부라고 본다면 이상하지 않을 수도 있지요. 실제로 Python, Ruby, Java, C# 등의 많은 언어가 특정 인터페이스를 구현하면 언어 구조로 제공되는 for, foreach 문 따위를 사용할 수 있게 해놓았습니다. Objective-C 같은 경우에도 모든 클래스는 NSObject 클래스를 상속받아야 한다는 스펙이 이미 있지 않았나요?
maccrazy | 2008.07.30 17:25 신고 | PERMALINK | EDIT/DEL
프레임웍을 언어의 일부로 봐야 할지는 조금 더 논의가 있어야 하겠지만 Objective-C에서 모든 클래스가 꼭 NSObject로 부터 상속 받아야 하는것은 아닙니다. 예로 NSProxy같은 것은 그 자체로 루트 클래스이죠. NSObject 이외에 다른 루트 클래스도 있을 수 있다는 것이죠. 물론 NSObject가 구현해놓은 많은 것들을 직접 구현해야 한다는 괴로움이 있지만 가능은 합니다.
예를 들어주신 많은 언어들이 비슷한 방식을 사용하고 있지만 마지막에 제가 이야기 한 부분은 그게 정말 맞는 접근 방법일까 하는 것이죠.
좀 고전적인 언어로 비교하면 이상하겠지만, MFC가 C++ 자체의 일부가 아닌것 처럼 프레임웍이랑 언어는 때 놓고 보는게 맞지 않냐는 것이지요.
어떤 프레임웍이 꼭 특정 언어만으로 사용되지도 않고 (Cocoa가 루비나 파이썬 같은 언어로 코딩될 수 있는것 처럼) 또, 만일 저런 식의 확장이 계속 된다면 다른 어떤 플랫폼에서 Objective-C를 사용하고 싶어도 프래임웍까지 줄줄 끌고 오지 않으면 그 기능을 다 쓸 수 없다는 것도 문제가 될것 같군요.
박종암 | 2008.07.30 21:45 | PERMALINK | EDIT/DEL | REPLY
framework은 언어의 일부로 절대 볼 수가 없습니다.
framework은 전통적으로 library로 볼 수있는데, 전통적인 것과의 다른 점은 library + 연관된 리소스인 것이죠.

홍민희 님 안녕하세요? 제가 egloos에 있을때, 종종 들어오시던 분이네요.
han9kin | 2008.07.30 23:33 신고 | PERMALINK | EDIT/DEL | REPLY
maccrazy님은 프레임웍과 프로그래밍언어가 같이 섞이는 것이 말도 안되고 이상하게 생각되나 봅니다. 흐흐..
뭐, 종암님말씀처럼 프레임웍을 전통적으로는 라이브러리처럼 보신다면 그렇긴 하죠.. 하지만. 꼭 그런 건 아니라 생각됩니다.
저도 잘은 모릅니다만, Ruby on Rails와 같은 경우 이미 프레임웍과 언어의 경계가 모호해져있는 상황인 것 같구요. 코코아와 Objective-C도 사실은 이미 이런 경계가 거의 무너졌는데 인정을 안하고 있었던 것 뿐이 아닐까 생각합니다.
그리고, 말씀하신 NSObject와 NSProxy... 맞는 말씀입니다만, 애플의 코코아에서 NSObject와 NSProxy이외의 루트클래스를 만들 수 있습니까? 가능하지 않은 것으로 압니다만...
마지막으로, Objective-C 2.0의 fast enumeration 기능상, 편의상 좋은것은 인정합니다만, 속도가 더 빠르다라는 증거가 있나요? 왠지, 애플의 광고일 뿐일 것 같다는 생각이 듭니다. 제가 간단한 테스트를 해봤었거든요. 속도차이를 별로 못 느끼겠다라는... 너무 간단한 거라서 그런가요?
박종암 | 2008.07.31 13:33 | PERMALINK | EDIT/DEL
제가 보기에도.. 언어를 프레임워크랑 밀접하게 연결시켜버린 것은 좀 아니라고 생각이 듭니다.
그런데 한편으론 이해가 가는 면이 있어요.
우선은 Objective-C이 minimalism을 표방하기 때문에, 가능한 언어 자체를 안바꾸고 편의를 제공한다라는 면이 있겠구요. 그러다보니 프레임워크의 도움을 받았다라는... 그리고 gcc에서 objective-c는 그다지 활동이 활발하지 않다는..
근데 조만간 Apple이 Objective-C 2.0을 GNU의 gcc에 반영한다고 했는데, 현재 어떤 상태인지 모르겠네요. 반영하게 되면 이 fast enumeration이 어떻게 될지 궁금해집니다.
maccrazy | 2008.07.31 14:05 신고 | PERMALINK | EDIT/DEL
Objective-C 2.0 문서에서 발췌한 내용입니다.
만들기 힘들다는 말은 있어도 못 만든다는 말은 없죠. :)

Note: Implementing a new root class is a delicate task and one with many hidden hazards. The class must duplicate much of what the NSObject class does, such as allocate instances, connect them to their class, and identify them to the runtime system. For this reason, you should generally use the NSObject class provided with Cocoa as the root class. For more information, see the Foundation framework documentation for the NSObject class and the NSObject protocol.
박종암 | 2008.07.31 13:22 | PERMALINK | EDIT/DEL | REPLY
에.. Ruby on Rails가 그런가요? 글쎄요. Cocoa와 Objective-C는 거의 둘을 떼고선 생각할 수가 없을 정도가 되었다는 면에선 그렇겠지만, 사실 Cocoa만 쓸 필요는 없는거잖아요? 어떻게 하다보니, 그게 주된 프레임웍이 된 것일 뿐이죠. 그렇다면.. Ruby Cocoa binding이 되면 Cocoa는 Objective-C에 속하는건지, ruby에 속하는 건지... F-Script같은 경우는 또 어떤지..
어떤 면에선 이런 구분이 의미가 있을지는 모르겠지만..

그리고 NSObject외에 루트 클래스를 만들 수있는지에 대해선.. 만들 수있는거죠. Apple이 하는 식으로 하면 되는거죠. 혹은 잘 아시다시피 GNUStep의 그것대로 만들어도 될거구요.
사실 이 쪽에 대해서 제가 예전에 블로깅을 했는데.. 뭐 아주 기술적인 이야기는 아니구, 가쉽 말하듯이 했죠. http://jongampark.wordpress.com/2008/05/02/objective-c-without-cocoa/

그리고 Fast Enumeration은.. 더 빠르다고 합니다. 예전에 어디서 읽었어요. 속도 테스트까지 했구요. 항상 빠르진 않았던거로 기억합니다. 이유가 뭐였더라....
han9kin | 2008.07.31 16:46 신고 | PERMALINK | EDIT/DEL | REPLY
죄송합니다. 제가 헛소리를 좀 했군요.
maccrazy님께서 제 코멘트를 보고 루트클래스를 만들다가 살짝 열받으신 모양인데.. ㅋㅋ
어떻든 루트클래스 자체를 만드는 건 쉽네요. 다만, 돌아가게 할려면 NSObject protocol을 구현해야하는 등 삽질을 해야하겠지만...
그리고, 저는 개인적으로 코코아 프레임웍없는 Obj-C는 "별로"라는 생각이라 애플이 더욱 공격적으로 코코아와 Obj-C를 개선하기를 바라는 사람입니다. maccrazy님께서는 반대로 코코아없이도 Obj-C를 편하게 사용할 수 있기를 바라시는 것 같고 그 이유도 충분이 이해됩니다... ㅋㅋ
저는 Obj-C가 @""로 NSString도 생성시키면서 @[ @"", 1, nil ] 따위로 NSArray나 @{ @"" => 1 } 따위로 NSDictionary를 만들지 못하는지 불평하는 한사람입니다. 흐..
maccrazy | 2008.07.31 16:49 신고 | PERMALINK | EDIT/DEL
못말려...
그래도 @[ @"", 1, nil ], @{ @"" => 1 } 는 재미있군요.
han9kin님이 너무 편한 랭귀지만 쓰다보니 많이 게을러진 것 같네요. :)
박종암 | 2008.08.01 00:08 | PERMALINK | EDIT/DEL
두 분.. 벌로다가 구현하신 루트 클래스! 블로깅 해 주세요. 그냥 버리기 아깝습니다.
어제 maccrazy님은 han9kin님이 루트 클래스 구현하느라 머리 싸맸다고 그랬는데, 이 글을 보니 반대인거 같군요. 제가 잘못 들었나요?
그제 지진이 났더랬습니다. 그래서 인터넷 접속도, 패킷이 가다 안가다.. 어제도 좀 그러더군요. 그래서 거의 글을 못 썼습니다. 이해 바랍니다.
박종암 | 2008.08.01 00:11 | PERMALINK | EDIT/DEL | REPLY
같은 사람이 쓴 글인데, 하나는 CodeProject에 있고 다른 하나는 자기 웹 사이트같은 곳에 있군요.
무엇이 framework인가에 대한 대단히 추상적이어서 알기가 좀 뭐하지만, 폼은 나는 글입니다.
저의 정의는 간단했는데.. 이렇게 말을 풀어낼 수가 있군요.

http://www.codeproject.com/KB/architecture/WhatIsAFramework.aspx
http://www.marcclifton.com/Articles/DesignAndArchitecture/WhatIsAFramework/tabid/95/Default.aspx
박종암 | 2008.08.28 15:22 | PERMALINK | EDIT/DEL | REPLY
오늘 Apple의 Obj-C 메일링 리스트에 Fast Enumeration의 속도를 비교한 문서가 있는지 질문을 했더니, 한 링크를 주더군요. http://www.cocoabuilder.com/archive/message/cocoa/2008/5/24/208090

그런데, 이상한게 왜 index를 이용한 iteration은 잘 사용하지 않을까요?
사실 현재 3가지 방법이 있죠? NSEnumerator, Fast Enumerator, 그리고 index를 이용한 iteration..
maccrazy | 2008.08.29 10:02 신고 | PERMALINK | EDIT/DEL
제 경우 대부분 index를 이용한 iteration인데요.. :)
하지만 index를 이용하는 방법은 속도문제를 떠나 치명적인 약점이 있는거 같습니다. 바로 index의 바운더리를 항상 체크해줘야 한다는 것이죠.
김지영 | 2008.09.01 10:24 | PERMALINK | EDIT/DEL | REPLY
안녕하세요.
사이텍미디어 출판사의 미디어개발부 김지영입니다.

저희가 현재 번역출간 계획 중인 도서가 Programming in Objective-C 2.0 (2nd Edition) 9780321566157 by Kochan(Pearson Technology Group)입니다. 이 책에 대해서 좀더 자세한 내용을 알고자 이리저리 검색을 하다가 이곳을 방문하게 되었습니다. 괜찮으시다면 책에 대해서 의견을 구하고자 합니다. edita0912@scitech.co.kr로 연락주시면 감사하겠습니다.
행복하고 즐거운 하루 되세요.
maccrazy | 2008.09.01 10:55 신고 | PERMALINK | EDIT/DEL
메일 보내드렸습니다. :)
| 2008.09.03 04:43 | PERMALINK | EDIT/DEL | REPLY
비밀댓글입니다
| 2008.09.06 12:00 | PERMALINK | EDIT/DEL | REPLY
비밀댓글입니다
Name
Password
Homepage
Secret
prev"" #1 #2 next