이건 음.. 부분부분 tagging 해서 parallel 하게 시퀀싱 하는거
http://www.nature.com/nmeth/journal/v7/n2/full/nmeth.1416.html
hybrid assembly
http://genome.cshlp.org/content/19/2/294.long
Tuesday, March 22, 2011
Monday, March 21, 2011
suffix tree (1)
whole genome alignment, Silva에서의 alignment 과정 그리고 금선생 추천 책 등등에서 많이 만나온 용어 suffix tree. 정리해야 겠다. 일단. 참고 문헌은 http://www.cs.ucf.edu/~shzhang/Combio10/lec3.pdf 과 algorithms on Strings, Trees, and Sequence의 5장부터로 한다. 과연 볼수 있을려나..
네이버링으로 대략적으로 알아본 결과 reference가 m길이의 T 문자열일때 query가 n 길이의 S 문자열이면 KMP나 보이어-무어의 방법(이 두가지 방법 다 뇌를 자극하는 알고리즘에 나온다. 기억이 가물하지만)이 O(m)의 시간이 걸리는데 비해 suffix tree는 reference를 한번 preprocessing (O(m)) 하면 O(n)의 시간만에 T에서 S를 찾아낸다(hashing 인건가). 또한 i번째 leaf 노드에서 루트까지 node의 값을 연결하면 T[i:m]의 문자열이 나온다. 그리고 suffix tree를 구하는 방식은 여러가지인데 특정 문자열에 대한 suffix tree는 unique하다. 또한 문자열 안에 substring이 몇번 나오나 혹은 어디에 있나 하는 정보를 root에서 부터 원하는 substring까지의 노드를 찾고 거기서 부터 연결된 leaf 갯수를 새면 그 정보가 나온다. 요정도..
<from UFC >
: ucf 자료를 보면 순서가 suffix의 대한 intro, definition, exact string matching problem, building suffix tree 순으로 되어 있다. 그림은 위 링크의 pdf를 참조하길.
-hash table 보다 suffix tree가 났냐? hash가 더 이해하기 쉽고 뭐.. 시간도 비슷하지만 문젠 hash table은 query의 문자열의 길이가 고정이라는거. 그리고 다른 string match trick이 안먹힌다는데.. 이건 계속 봐야 알겠음.
-suffix tree의 정의 :
1. rooted directed tree로 문자열 길이만큼의 leaves를 갖는다.
2. root 노드를 제외한 internal 노드는 최소한 2개의 자식 노드를 갖으며 각 edge(연결선)은 문자열의 substring으로 labeling되어 있다.
3. 한 노드에서 나가는 edge들의 시작 character는 동일할 수 없다.
4. suffix tree의 key feature는 i 번째 leaf에서 edge의 label들을 연결하면 문자열의 i번째에서 시작하는 substring이 된다.
5. 문자열의 마지막 character는 unique charater여야 한다.
-exact string matching problem
reference 문자열 ST를 O(m) 시간 만큼 걸려서 suffix tree를 만들고 query 문자열 P를 ST에서의 unique path로 찾는다. root 에서부터 query의 문자열이 되는 path를 찾는다. path의 마지막 노드 아래의 leaf가 query를 포함하고 있는 suffix가 되겠다.
-building the suffix tree
1.Naive method : O(m**2)의 시간이 걸린단다. 이해는 잘된다. root에서 부터 제일 긴 suffix 부터 node를 붙인다. 예를 들어 papua 라는 문자열을 suffix tree로 만들려면 우선은 papua에서 제일 긴 suffix 인 papua를 root 노드에서 부터 연결한다. 그 다음의 젤 긴 suffix인 apua를 또 root에서 새로운 노드로 붙인다. 그다음 suffix는 pua인데 suffix tree의 정의에 따라 자식 노드들의 첫 character는 같으면 안되기때문에 아까의 papua와 pua가 첫 글자가 겹치기 때문에 이를 root에서 공통으로 edge를 만들고 apua와 ua로 노드를 분리 시킨다. 이런식으로 마무리.
2. 원래 suffix tree의 reference의 preprocessing 시간이 O(m)이라고 했는데 이는 1973년 Weiner에 의해 소개됐고 이후 space efficient 한 방법을 McCreight가 1976년 소개, 그 뒤 1995년 더 단순한 on-line algorithm이 Ukkonen에 의해 소개
3. Ukkonen's algorithm : 1에서부터 m 까지의 prefix를 하나씩 따서 그것의 suffix들을 tree에 extension하는 방식(이 말이 이해는 안갈건데 pdf 그림보면 안다). 이때 extension은 3가지 rule( 1.s[j:i+1] 을 extend 할때 s[j:i]까지의 label이 있는 edge를 찾으면 그 edge에 i+1번째 character를 extend한다. 2. 만약 root에서 시작되는 edge중 s[j:i]까지 매치되는 edge가 없으면 맞는데까지에서 새로운 edge와 노드를 만든다. 3.이미 s[j:i+1]까지의 문자열이 정확히 매치되면 nothing to do)에 따른다. 여기까지는 기본 방법이고, 여기다가 speed up 방법이 있는데 요건 이해가 안됨.
여전히 알고리즘 시간에 대한 계산이 이해가 잘 안된다. 음.. 그리고 예전 알고리즘 책 볼때도 느낀건데 어떻게 진행하는지는 이해는 하는데 왜는 깊게 이해 안되는 느낌이랄까.. 명화를 감상하는데 아 저기에 뭐가 있고 저기에 뭐가 그려져 있구나. 근데 이게 무슨 느낌으로 그린거지?하고 이해하지 못하는 느낌. 내가 볼때 반복만이 이 느낌을 채울수 있다고 본다.
네이버링으로 대략적으로 알아본 결과 reference가 m길이의 T 문자열일때 query가 n 길이의 S 문자열이면 KMP나 보이어-무어의 방법(이 두가지 방법 다 뇌를 자극하는 알고리즘에 나온다. 기억이 가물하지만)이 O(m)의 시간이 걸리는데 비해 suffix tree는 reference를 한번 preprocessing (O(m)) 하면 O(n)의 시간만에 T에서 S를 찾아낸다(hashing 인건가). 또한 i번째 leaf 노드에서 루트까지 node의 값을 연결하면 T[i:m]의 문자열이 나온다. 그리고 suffix tree를 구하는 방식은 여러가지인데 특정 문자열에 대한 suffix tree는 unique하다. 또한 문자열 안에 substring이 몇번 나오나 혹은 어디에 있나 하는 정보를 root에서 부터 원하는 substring까지의 노드를 찾고 거기서 부터 연결된 leaf 갯수를 새면 그 정보가 나온다. 요정도..
<from UFC >
: ucf 자료를 보면 순서가 suffix의 대한 intro, definition, exact string matching problem, building suffix tree 순으로 되어 있다. 그림은 위 링크의 pdf를 참조하길.
-hash table 보다 suffix tree가 났냐? hash가 더 이해하기 쉽고 뭐.. 시간도 비슷하지만 문젠 hash table은 query의 문자열의 길이가 고정이라는거. 그리고 다른 string match trick이 안먹힌다는데.. 이건 계속 봐야 알겠음.
-suffix tree의 정의 :
1. rooted directed tree로 문자열 길이만큼의 leaves를 갖는다.
2. root 노드를 제외한 internal 노드는 최소한 2개의 자식 노드를 갖으며 각 edge(연결선)은 문자열의 substring으로 labeling되어 있다.
3. 한 노드에서 나가는 edge들의 시작 character는 동일할 수 없다.
4. suffix tree의 key feature는 i 번째 leaf에서 edge의 label들을 연결하면 문자열의 i번째에서 시작하는 substring이 된다.
5. 문자열의 마지막 character는 unique charater여야 한다.
-exact string matching problem
reference 문자열 ST를 O(m) 시간 만큼 걸려서 suffix tree를 만들고 query 문자열 P를 ST에서의 unique path로 찾는다. root 에서부터 query의 문자열이 되는 path를 찾는다. path의 마지막 노드 아래의 leaf가 query를 포함하고 있는 suffix가 되겠다.
-building the suffix tree
1.Naive method : O(m**2)의 시간이 걸린단다. 이해는 잘된다. root에서 부터 제일 긴 suffix 부터 node를 붙인다. 예를 들어 papua 라는 문자열을 suffix tree로 만들려면 우선은 papua에서 제일 긴 suffix 인 papua를 root 노드에서 부터 연결한다. 그 다음의 젤 긴 suffix인 apua를 또 root에서 새로운 노드로 붙인다. 그다음 suffix는 pua인데 suffix tree의 정의에 따라 자식 노드들의 첫 character는 같으면 안되기때문에 아까의 papua와 pua가 첫 글자가 겹치기 때문에 이를 root에서 공통으로 edge를 만들고 apua와 ua로 노드를 분리 시킨다. 이런식으로 마무리.
2. 원래 suffix tree의 reference의 preprocessing 시간이 O(m)이라고 했는데 이는 1973년 Weiner에 의해 소개됐고 이후 space efficient 한 방법을 McCreight가 1976년 소개, 그 뒤 1995년 더 단순한 on-line algorithm이 Ukkonen에 의해 소개
3. Ukkonen's algorithm : 1에서부터 m 까지의 prefix를 하나씩 따서 그것의 suffix들을 tree에 extension하는 방식(이 말이 이해는 안갈건데 pdf 그림보면 안다). 이때 extension은 3가지 rule( 1.s[j:i+1] 을 extend 할때 s[j:i]까지의 label이 있는 edge를 찾으면 그 edge에 i+1번째 character를 extend한다. 2. 만약 root에서 시작되는 edge중 s[j:i]까지 매치되는 edge가 없으면 맞는데까지에서 새로운 edge와 노드를 만든다. 3.이미 s[j:i+1]까지의 문자열이 정확히 매치되면 nothing to do)에 따른다. 여기까지는 기본 방법이고, 여기다가 speed up 방법이 있는데 요건 이해가 안됨.
여전히 알고리즘 시간에 대한 계산이 이해가 잘 안된다. 음.. 그리고 예전 알고리즘 책 볼때도 느낀건데 어떻게 진행하는지는 이해는 하는데 왜는 깊게 이해 안되는 느낌이랄까.. 명화를 감상하는데 아 저기에 뭐가 있고 저기에 뭐가 그려져 있구나. 근데 이게 무슨 느낌으로 그린거지?하고 이해하지 못하는 느낌. 내가 볼때 반복만이 이 느낌을 채울수 있다고 본다.
Friday, March 18, 2011
iphone 개발 수업 2주차
3/18
그 전체 화면의 기본이 되는 객체는 UIWindow 이고 이는 UIApplication 객체가 MainWindow.xib 를 읽어서 생성한다.
IBOutlet [변수] : UIApplication 이 MainWindow.xib 이름의 xml을 가지고 객체 생성하는데 이 때 만든 객체의 주소를 다음 [변수]에 대입하기 위해서 사용.
그 뒤에 그 [변수] 를 가지고 그 객체의 속성을 바꿀 수 있다. [변수].text = @"메시지" 처럼
UIResponder : 화면 관련 객체들에 어떤 이벤트가 발생 하는가를 계속 모니터링 하는 객체, 이는 UIApplication안에 속성으로 있어서 UIApplication이 생성될 때 생긴다.
IBAction 은 이벤트 함수를 선언할 때 쓰이는 것으로 UIReponder에게 UIWindow 의 특정 객체에 특정 이벤트가 생기면 그 이벤트 함수를 호출해 달라고 명시 하는것
UIResponder에 의해 특정 이벤트가 발생하는 것이 모니터링 되고 IBAction이 명시된 이벤트 함수에 맞는 이벤트가 발생하면 그 이벤트 함수를 호출한다. 호출된 이벤트 함수의 return type 이 void 이다.
UIResponder가 이벤트 함수를 호출할때 매개변수인 sender 에는 이벤트가 발생한 객체의 주소가 들어간다.
-----------------------------------------------------------------------------------------
아이폰에서는 폴더를 번들이라는 용어로 사용한다.
개발할때는 classes, Resources등으로 소스들이 나뉘는데 사실은 하나의 번들 안에 들어가 있는 것이다.
개발한 어플을 아이폰에 설치하면 설치자마다 그 어플의 위치(경로)가 다를수 있는데 경로를 알고 싶을때 사용하는 클래스가 NSBundle과 CFBundleRef 가 있다. CFBundleRef 는 NSBundle과 같은 역할을 하나 C 로 구성되어 있어서 내부가 불분명한 불투과형의 함수이다.
NSBundle : 현재 어플의 실행 경로 정보, 어플이 있는 번들에 존재하는 파일, resource를 찾아서 경로를 리턴.
[NSBundle mainBundle] : 현재 자신 어플의 정보(자신의 현재 경로와 그안의 파일과 리소스의 경로) 가지고 있는 객체를 리턴한다.
[[NSBundle mainBundle] pathForResource:@"candle on" ofType:@"jpg"] : NSBundle 클래스의 mainBundle 메소드를 호출해서 NSBundle 객체를 생성하고 candle on 이라는 파일명과 jpg 라는 확장자를 가지는 경로를 리턴한다.
UIImage : 메모리로 이미지 출력(아이폰은 우선 이미지를 메모리로 로딩해서 로딩이 끝나면 화면에 출력. 로딩될 때 버벅대는 과정을 화면에 나타나지 않게 한다)
[[UIImage alloc] iniWithContentOfFile:candleOnPath] : candleOnPath 변수에 들어 있는 경로의 파일을 메모리레 출력
object-c 는 항상 객체의 주소만 가져올수 있다.
---------------------------------------------------------------------------------------------
3/19
<쓰레드>
어플리케이션 그러니까 하나의 프로세스를 구성하는 기능 하나하나를 쓰레드라고 한다. object-c에서는 메소드 하나를 쓰레드 하나라고 생각한다.
NSOperationQueue : 메서드들을 멀티쓰레드로 실행시켜 준다. 실행시키고자 하는 메소드는 메소드대로 생성한 뒤에 그 메소드를 NSInvocationOperation의 객체로 만들어서 NSOperationQueue에 넣어주면 multithread로 프로그램이 돌게 된다.
NSInvocationOperation : 멀티쓰레드로 실행될 메소드의 정보가 들어가게 된다.
[[NSInvocationOperation alloc] initWithTarget:self selector:@selector(come) object:nil] : self 는 멀티쓰레드로 실행할 메서드를 포함한 객체의 주소를 의미, @selector(come)는 come 이라는 메소드의 주소가 return 된다, object:nil은 come 이라는 메소드가 실행될때 전달하고자 하는 메시지를 나타냄.
new 메소드는 alloc이후 init 을 한것과 동일. 즉 [someClass new] == [[someClass alloc] init].
other Sources 에 보면_prefix.pch라는 파일이 있는데 이는 매크로서 다른 소스 파일에서 import 문을 명시하지 않아도 저절로 import 가 된다.
NSMutableArray 클래스 : object-c 에서의 array 클래스로 그 배열안에는 객체만을 넣을 수 있다.
Object-c에서의 동기화 : 하나의 쓰레드에서 작업을 마칠때까지 다른 쓰레드는 공유 객체에 접근 불가. object-c에서는 동기화 방법이 mutex(특정쓰레드에서 객체를 사용할때 다른 쓰레드에서 아예 접근하지 못하게 하는 것) 하나밖에 없다.
@synchronized(array){some thing work} : something work 이 끝나기 까지 array 객체는 다른 쓰레드에서 접근하지 못하게 된다.
property 지정시 attribute의 nonatomic 을 nonatomic 으로 지정하면 multithread에서 접근이 가능
---------------------------------------------------------------------------------------------------
<객체의 life cycle>
someclass *aa = [[someclass alloc] init] 식으로 alloc 메소드를 호출하면 객체가 생성되고 이때 retainCount 속성이 1이 된다. 이 retainCount 속성값이 0이 되는 순간 someclass의 dealloc 메소드가 호출되면서 객체가 소멸된다. 객체가 소멸되면 다른 변수가 그 객체를 참조하더라도 더이상 사용할 수 없게 된다.
retainCount 값을 증가시키는 방법 : retain 메소드를 호출( [aa retain])하거나 array에 추가([array addObject: aa])하게되면 retainCount 값이 증가
retainCount 값을 감소키시는 방법 : release 메소드를 호출([aa release])하거나 array에서 삭제([array removeObject:aa])하게 되면 retainCount 값이 감소하게 된다.
@propery (retain) UIImage *candle : candle 을 다른 변수에 대입시 retain 메소드가 자동 호출되게 한다.
-----------------------------------------------------------------------------------------------------
<iOS project의 종류>
1. Window-Based Application
main 메소드에서 UIApplicationMain를 호출 하면 UIApplication 객체가 생성되어 loop를 돌면서 이벤트가 발생하는 모니터링 발생하면 UIApplicationDelegate 객체에 알려줌. UIApplicationDelegate는 시스템 이벤트, UI 이벤트 때마다 호출되는데 시스템 이벤트 처리, UI 이벤트 처리를 둘 다 담당
그 전체 화면의 기본이 되는 객체는 UIWindow 이고 이는 UIApplication 객체가 MainWindow.xib 를 읽어서 생성한다.
IBOutlet [변수] : UIApplication 이 MainWindow.xib 이름의 xml을 가지고 객체 생성하는데 이 때 만든 객체의 주소를 다음 [변수]에 대입하기 위해서 사용.
그 뒤에 그 [변수] 를 가지고 그 객체의 속성을 바꿀 수 있다. [변수].text = @"메시지" 처럼
UIResponder : 화면 관련 객체들에 어떤 이벤트가 발생 하는가를 계속 모니터링 하는 객체, 이는 UIApplication안에 속성으로 있어서 UIApplication이 생성될 때 생긴다.
IBAction 은 이벤트 함수를 선언할 때 쓰이는 것으로 UIReponder에게 UIWindow 의 특정 객체에 특정 이벤트가 생기면 그 이벤트 함수를 호출해 달라고 명시 하는것
UIResponder에 의해 특정 이벤트가 발생하는 것이 모니터링 되고 IBAction이 명시된 이벤트 함수에 맞는 이벤트가 발생하면 그 이벤트 함수를 호출한다. 호출된 이벤트 함수의 return type 이 void 이다.
UIResponder가 이벤트 함수를 호출할때 매개변수인 sender 에는 이벤트가 발생한 객체의 주소가 들어간다.
-----------------------------------------------------------------------------------------
아이폰에서는 폴더를 번들이라는 용어로 사용한다.
개발할때는 classes, Resources등으로 소스들이 나뉘는데 사실은 하나의 번들 안에 들어가 있는 것이다.
개발한 어플을 아이폰에 설치하면 설치자마다 그 어플의 위치(경로)가 다를수 있는데 경로를 알고 싶을때 사용하는 클래스가 NSBundle과 CFBundleRef 가 있다. CFBundleRef 는 NSBundle과 같은 역할을 하나 C 로 구성되어 있어서 내부가 불분명한 불투과형의 함수이다.
NSBundle : 현재 어플의 실행 경로 정보, 어플이 있는 번들에 존재하는 파일, resource를 찾아서 경로를 리턴.
[NSBundle mainBundle] : 현재 자신 어플의 정보(자신의 현재 경로와 그안의 파일과 리소스의 경로) 가지고 있는 객체를 리턴한다.
[[NSBundle mainBundle] pathForResource:@"candle on" ofType:@"jpg"] : NSBundle 클래스의 mainBundle 메소드를 호출해서 NSBundle 객체를 생성하고 candle on 이라는 파일명과 jpg 라는 확장자를 가지는 경로를 리턴한다.
UIImage : 메모리로 이미지 출력(아이폰은 우선 이미지를 메모리로 로딩해서 로딩이 끝나면 화면에 출력. 로딩될 때 버벅대는 과정을 화면에 나타나지 않게 한다)
[[UIImage alloc] iniWithContentOfFile:candleOnPath] : candleOnPath 변수에 들어 있는 경로의 파일을 메모리레 출력
object-c 는 항상 객체의 주소만 가져올수 있다.
---------------------------------------------------------------------------------------------
3/19
<쓰레드>
어플리케이션 그러니까 하나의 프로세스를 구성하는 기능 하나하나를 쓰레드라고 한다. object-c에서는 메소드 하나를 쓰레드 하나라고 생각한다.
NSOperationQueue : 메서드들을 멀티쓰레드로 실행시켜 준다. 실행시키고자 하는 메소드는 메소드대로 생성한 뒤에 그 메소드를 NSInvocationOperation의 객체로 만들어서 NSOperationQueue에 넣어주면 multithread로 프로그램이 돌게 된다.
NSInvocationOperation : 멀티쓰레드로 실행될 메소드의 정보가 들어가게 된다.
[[NSInvocationOperation alloc] initWithTarget:self selector:@selector(come) object:nil] : self 는 멀티쓰레드로 실행할 메서드를 포함한 객체의 주소를 의미, @selector(come)는 come 이라는 메소드의 주소가 return 된다, object:nil은 come 이라는 메소드가 실행될때 전달하고자 하는 메시지를 나타냄.
new 메소드는 alloc이후 init 을 한것과 동일. 즉 [someClass new] == [[someClass alloc] init].
other Sources 에 보면
NSMutableArray 클래스 : object-c 에서의 array 클래스로 그 배열안에는 객체만을 넣을 수 있다.
Object-c에서의 동기화 : 하나의 쓰레드에서 작업을 마칠때까지 다른 쓰레드는 공유 객체에 접근 불가. object-c에서는 동기화 방법이 mutex(특정쓰레드에서 객체를 사용할때 다른 쓰레드에서 아예 접근하지 못하게 하는 것) 하나밖에 없다.
@synchronized(array){some thing work} : something work 이 끝나기 까지 array 객체는 다른 쓰레드에서 접근하지 못하게 된다.
property 지정시 attribute의 nonatomic 을 nonatomic 으로 지정하면 multithread에서 접근이 가능
---------------------------------------------------------------------------------------------------
<객체의 life cycle>
someclass *aa = [[someclass alloc] init] 식으로 alloc 메소드를 호출하면 객체가 생성되고 이때 retainCount 속성이 1이 된다. 이 retainCount 속성값이 0이 되는 순간 someclass의 dealloc 메소드가 호출되면서 객체가 소멸된다. 객체가 소멸되면 다른 변수가 그 객체를 참조하더라도 더이상 사용할 수 없게 된다.
retainCount 값을 증가시키는 방법 : retain 메소드를 호출( [aa retain])하거나 array에 추가([array addObject: aa])하게되면 retainCount 값이 증가
retainCount 값을 감소키시는 방법 : release 메소드를 호출([aa release])하거나 array에서 삭제([array removeObject:aa])하게 되면 retainCount 값이 감소하게 된다.
@propery (retain) UIImage *candle : candle 을 다른 변수에 대입시 retain 메소드가 자동 호출되게 한다.
-----------------------------------------------------------------------------------------------------
<iOS project의 종류>
1. Window-Based Application
main 메소드에서 UIApplicationMain를 호출 하면 UIApplication 객체가 생성되어 loop를 돌면서 이벤트가 발생하는 모니터링 발생하면 UIApplicationDelegate 객체에 알려줌. UIApplicationDelegate는 시스템 이벤트, UI 이벤트 때마다 호출되는데 시스템 이벤트 처리, UI 이벤트 처리를 둘 다 담당
2. View-Based Application
UIApplicationDelegate : window based application과 유사하나 UIapplicationDelegate가 담당했던 UI 이벤트가 UIViewController로 넘겨줘서 UIViewController가 이를 처리한다. UIApplicationDelegate는 시스템 이벤트만 담당. Window based application에서는 UIapplicationDelegate가 시스템 이벤트와 UI 이벤트를 모두 담당해야 했기에 비대해짐.
3.Navigation-Based Application
화면이 여러개인 application. 화면이 전환되는 Application. 대부분의 어플이 이 타입으로 만들어져 있다.
UIApplicationDelegate가 이벤트를 처리하는데 그 객체 안에 UINavigationController라는 객체가 속성이 있는데 이것이 화면 전환을 한다. 이건 stack으로 되어 있다.
3.Navigation-Based Application
화면이 여러개인 application. 화면이 전환되는 Application. 대부분의 어플이 이 타입으로 만들어져 있다.
UIApplicationDelegate가 이벤트를 처리하는데 그 객체 안에 UINavigationController라는 객체가 속성이 있는데 이것이 화면 전환을 한다. 이건 stack으로 되어 있다.
-----------------------------------------------------------------------------------------------------
<MVC model>
<MVC model>
Model : 데이터, 메시지 - UIPickerViewDataSource. 여기에 있는 내용이 View에 표시되는 것.
View : 화면에 출력되는 객체 - UIPickerView
Control : View와 Model을 연결 - UIPickerViewDelegate
View Control 방식으로 UIViewController 객체를 사용하려면 MVC pattern 으로 사용해야 한다.
instraTwitAppDelegate -> 시스템 이벤트에 대한 컨트롤
instraTwitViewController -> 화면(버튼등)에 대한 컨트롤, UIViewContoroller 를 상속한 클래스, 이 안에 UIPickerView가 속성으로 정의되어 있다.
MyPickerViewDataSource -> Model 로서 UIPickerView 객체의 데이터를 설정
MyPickerViewDelegate -> UIPickerView 객체에 대한 컨트롤
UIPickerView -> View
위 iOS 의 project 종류의 하나인 view-based application 에서의 설명처럼 원래 UIApplicationDeleagate 인 instraTwitAppDelegate 가 UI 이벤트에 대한 컨트롤을 UIViewController인 instraTwitViewController 에게 넘겼다. 그리고 instraTwitViewController가 화면에 전체적인 내용을 컨트롤. 이 UIViewController 갯수만큼 xib파일이 생긴다.
View Control 방식으로 UIViewController 객체를 사용하려면 MVC pattern 으로 사용해야 한다.
instraTwitAppDelegate -> 시스템 이벤트에 대한 컨트롤
instraTwitViewController -> 화면(버튼등)에 대한 컨트롤, UIViewContoroller 를 상속한 클래스, 이 안에 UIPickerView가 속성으로 정의되어 있다.
MyPickerViewDataSource -> Model 로서 UIPickerView 객체의 데이터를 설정
MyPickerViewDelegate -> UIPickerView 객체에 대한 컨트롤
UIPickerView -> View
위 iOS 의 project 종류의 하나인 view-based application 에서의 설명처럼 원래 UIApplicationDeleagate 인 instraTwitAppDelegate 가 UI 이벤트에 대한 컨트롤을 UIViewController인 instraTwitViewController 에게 넘겼다. 그리고 instraTwitViewController가 화면에 전체적인 내용을 컨트롤. 이 UIViewController 갯수만큼 xib파일이 생긴다.
Monday, March 14, 2011
metagenomics를 위한 논문 탐험
<A core gut microbiome in obese and lean>
http://www.nature.com/nature/journal/v457/n7228/full/nature07540.html
원래는 위에 것 할려고 했는데 윗분의 BGI언급으로 인해 아래 논문으로 수정
<A human gut microbial gene catalogue established by metagenomic sequencing>
http://www.nature.com/nature/journal/v464/n7285/full/nature08821.html
이 논문의 위의 논문보다 나중에 나온것. 둘다 gut의 microbe 를 metagenome 연구를 했다는 공통점. 위 논문의 abstract만 보면 위 논문은 16s rRNA도 하고 전체 microbe의 genome (microbiome)을 시퀀싱 한거 같다. 이 논문은 Genome analyser (GA)를 가지고 124명의 유럽인들의 똥의 미생물의 microbiome, 그러니까 전체 genomic DNA를 시퀀싱. => 그래서 576.7 Gb 를 만들어냄(이전 논문의 200배, BGI에서 돈많이 썻다고 자랑함). => 그 뒤 assembly,=> 3.3 M 의 unique ORF 만들어냄. 그리고 마지막 말, 이 결과는 short read sequencing으로도 metagenomics를 할수 있음을 보인다는건데 이건 BGI가 illumina 계열의 기기만 있기 때문에 이것으로도 metagenome을 해도 된다. 뭐 이런 support를 위한 논문인냥 느껴지는 멘트이다. 그러면 short read sequencer로도 가능하냐? 이 문제에 대해선 다음의 논문[1] 을 추천하려 했지만.. 16s rRNA 에 대해서 물어본다면 답이 안되는 논문인듯 하다.
metagenomic sequencing of gut microbiomes
124명의 건강하거나 과체중이거나 비만 혹은 염증성 장내질환(IBD)를 갖은 사람의 변의 microbe를 시퀀싱했다.두당 평균 4.5Gb 만들어냈고 이를 개인 각각 SOUPdenovo로 어샘블. 500bp 이상의 contig가 총 6.58M개 총 사이즈는 10.3Gb(N50 : 2.2kb), read의 42.7 %가 contig 만들어 지는데 이용됨. confirm으로 두 개체를 골라서 sanger 방법으로 시퀀싱한 리드를 contig에 매핑, 그 결과 98.7%가 맵핑됨. 이 값을 또 FLX와 비교(한 개체를 FLX로 시퀀싱한뒤 assembly해서 sanger read를 매핑해봄, 무서운 놈들). error-rate[2]와 뭐 이것저것 FLX에 떨어지지 않음을 증명. 어셈블 안된 리드들을 개체에 상관없이 모아서 다시 어셈블, 결과 0.4M개 총 370Mb(N50: 939bp) 의 contig 생성. 거꾸로 read들을 90% identity를 threshold(시퀀싱 error, strain variability를 고려해서)로 매핑, 결과 80%의 read가 매핑. 다른 논문의 데이터, 그리고 genbank와도 비교. 우월함을 입증.
a gene catalogue of the human gut microbiomes
ORF prediction에 MetaGene 사용. 100bp 이상의 ORF를 총 14,048,045개 찾음. 이건 총contig길이의 86.7%. 이는 평균적인 microbe의 비율과 비슷. (2/3의 ORF가 incomplete하다는데.. 이걸 어떻게 알지? incomplete하다의 의미가 정확히 뭔지 모르겠다). 그 ORF들의 redundancy를 없애고 총 3,299,822의 ORF로 추려냄, 이를 prevalent genes 이라고 함. 이 prevalent gene을 genome sequence가 있는 장내 세균과 비교. 상당수 매치됨. 음.. EstimateS 라는 프로그램을 써서 ICE를 계산해서 자기네들이 찾은 prevalent gene이 전체 추측되는 prevalent gene의 몇 %를 capture했나 라는 말이 나오는데 아.. 이는 잘 이해가 안된다[3]. 결론은 85% 이상을 capturing 한것으로 여겨진다는 것. 그리고 개체간에 얼마나 common gene이 있나를 체크했는데, 생각보다 prevalent gene이 생각보다 소수에 치우쳐 있다는 식으로 이야기함. 이것의 한 factor로 sampling depth를 들음. 그러나 역시나 개체간에 share하는 prevalent gene은 상당함. 재밌는것은 IBD 환자의 prevalent gene이 정상보다 갯수가 적음. 이는 IBD환자의 장내 미생물 diversity가 일반인보다 적다는 것과 일맥 상통.
common bacterial core
functions encoded by the prevalent gene set
ORF들을 NCBI의 NR(protein)과 KEGG, COG, eggNOG[4]에 있는 gene에다가 align함.[5]
bacterial functions important for life in the gut
functional complementarities fo the genome and metagenome
[1]http://aem.asm.org/cgi/reprint/74/5/1453.pdf 이논문이 2008년 초에 나온건데 abstract를 보면 100-200 bp의 read로 16s rRNA 시퀀싱 분석이 괜찮냐를 본 논문. 방법은 간단해 보인다. 거의 full length의 16s rRNA와 random하게 만들어낸 short read의 blast와 cog 분석 결과를 비교한다. blastx의 결과 당연하지만 full length에 비해 homolog hit이 현저하게 떨어진단다. 주의할 건 400bp 까지 read의 길이를 늘려도 내지는 depth를 늘려도 마찬가지라는거. 결국 Evalue가 낮은 hit 아니면 찾기 어렵다는것. 그리고 cog 분석도 마찬가지로 full... 근데 이거 16s rRNA에 국한된게 아닌듯 싶다. 그리고 nature 논문은 assembly후에 분석한 거라 이 의미가 없을 듯
[2]error-rate :
[3]EstimatorS, ICE : http://viceroy.eeb.uconn.edu/EstimateSPages/EstSUsersGuide/EstimateSUsersGuide.htm
[4]eggNOG : http://eggnog.embl.de/
[5]rarefaction analysis :
metagenomics를 위한 잡다지식 but 완전 기초
누구랩의 분석레포트를 보는데 미생물의 분류학적 개념부터 나온다. 이것 부터 제대로 정립해야 하는게 사실이다. 그래서 정리해보자.
미생물이란
미생물(microbe) 라고 함은 바이러스(virus), 세균(bacteria), archaea,균류(fungi), 원생생물(protist) 로 나뉜단다.
한국말로 하면 원생이랑 원핵 생물이라하면 헷갈리는데 원핵은 하나의 핵이란게 아니라 원시핵을 의미 하는 것으로 prokaryote을 말한다. 반면 protist은 eukaryote으로 대부분 단세포 생물.
그럼 protist와 fungi가 뭐가 다르냐?(둘다 eukayote인데..) 아래 링크. 우선은 protist는 거의 단핵 생물. 그리고 fungi는 주로 saprotrophic (sapros+trophic = rotten+food = cell 밖에서 음식을 썩혀서 영양분을 soluble 하게 만든담 uptake). 그리고 세포벽도 차이.
archaea는 핵이 없는데 원핵 생물(prokaryote)과는 다른데 가장큰 차이는 세포벽을 구성에 큰차이 세포막에 있어서는 진핵생물과 차이.그런데 분자 생물학적으로 보면 eukaryote와 유사한 측면이 있다(chromatin 구조랑 RNA polymerase와 start codon도 eukaryote랑 유사).
자세한건 아래 링크
archea : http://100.naver.com/100.nhn?docid=828465
protist : http://navercast.naver.com/contents.nhn?contents_id=4203
difference between protist & fungi : http://answers.yahoo.com/question/index?qid=20080508155624AAVlMGj
종의 분류 in prokaryote
fungi랑 protist의 종의 개념은 형태나 reproductive behavior 에 많이 의존한다고 한다. 반면 prokayote의 종의 개념은 분자계통학적 연구방법에 따라 분류가 되는데 다음과 같은 두가지 기준이 있다. 두종이 구별되기 위한 조건 1. genome sequence가 달라야 한다. 그럼 어느정도? DNA-DNA hybridizaion 비교 일시 70% 이하로 hybridization되야 하고 2. 16sRNA 비교시 sequence similarity가 97% 이하여야 한다. 3. 단 위 두조건이 충족되더라도 형태나 생리적 표현 형질의차이가 없으면 다른 종으로 분류 할수 없다.
microbial community analysis (어떤 미생물이 얼마만큼 있는지 분석)
DGGE, TGGE, t-RFLP, SSCP 는 PCR로 16S rRNA gene을 증폭한담에 전기 영동으로 gel 상에 band의 형태로 미생물 군집의 변화를 본다. 음. 말 그대로 gel 걸어서 비슷한 것들끼리 분리되서 뭉치니까 그걸로 판단을 하는거 같고 근데 이것으론 데이터베이스와 그리고 종의 정보는 얻지 못함.
species richness : 시료내 종의 수
OTU (operational taxonomic unit)으로 분류 대상이 되는 생물체의 개체 또는 군. 거의 종을 의미, 그러니까 species richness를 구한다는건 OTU의 수를 수한다는 구한다는 것과 동일하다고 할수 있을거 같다.
1.일차적으로 read들을 filtering을 잘해서(quality filter, barcode & primer trimming) 2.CD-HIT과 같은 프로그램으로 read들을 clustering 후 3. 통계적 방법으로 실제의OTU를 추정 3.전체적인 종의 분포를 나타내는 diversity index를 구함.
의문점 및 checklist
1.누구랩 레포트를 보아하니 query를 blastn도 하고 megaBlast도하는데.. 음 왜 그러지 blastn만 하면 megablast 까지 커버가 되는거 아닌가? 굳이 둘다 하는 이유가 있나.
2.그리고 blast후 비슷한 시퀀스를 뽑아낸 다음에 global alignment 를 하는데 여기서 말하길 clustalW의 것과 동일한 것을 사용한다고 하는데 (http://bioinformatics.oxfordjournals.org/content/4/1/11.abstract) 이건 일반적으로 알고 있는 needleman이랑은 다른 것인가?
3.read trimming을 할때 pairwise alignment를 해서 barcode와 primer를 제거해야 하는데 이를 어떤식으로 할것인가?
4.CD-HIT 관련 논문
5.species richness 의 통계적 추정 관련 논문
6.Mothur program
7.쌍둥이 내장내 miocrobiome metagenomics 논문
미생물이란
미생물(microbe) 라고 함은 바이러스(virus), 세균(bacteria), archaea,균류(fungi), 원생생물(protist) 로 나뉜단다.
한국말로 하면 원생이랑 원핵 생물이라하면 헷갈리는데 원핵은 하나의 핵이란게 아니라 원시핵을 의미 하는 것으로 prokaryote을 말한다. 반면 protist은 eukaryote으로 대부분 단세포 생물.
그럼 protist와 fungi가 뭐가 다르냐?(둘다 eukayote인데..) 아래 링크. 우선은 protist는 거의 단핵 생물. 그리고 fungi는 주로 saprotrophic (sapros+trophic = rotten+food = cell 밖에서 음식을 썩혀서 영양분을 soluble 하게 만든담 uptake). 그리고 세포벽도 차이.
archaea는 핵이 없는데 원핵 생물(prokaryote)과는 다른데 가장큰 차이는 세포벽을 구성에 큰차이 세포막에 있어서는 진핵생물과 차이.그런데 분자 생물학적으로 보면 eukaryote와 유사한 측면이 있다(chromatin 구조랑 RNA polymerase와 start codon도 eukaryote랑 유사).
자세한건 아래 링크
archea : http://100.naver.com/100.nhn?docid=828465
protist : http://navercast.naver.com/contents.nhn?contents_id=4203
difference between protist & fungi : http://answers.yahoo.com/question/index?qid=20080508155624AAVlMGj
종의 분류 in prokaryote
fungi랑 protist의 종의 개념은 형태나 reproductive behavior 에 많이 의존한다고 한다. 반면 prokayote의 종의 개념은 분자계통학적 연구방법에 따라 분류가 되는데 다음과 같은 두가지 기준이 있다. 두종이 구별되기 위한 조건 1. genome sequence가 달라야 한다. 그럼 어느정도? DNA-DNA hybridizaion 비교 일시 70% 이하로 hybridization되야 하고 2. 16sRNA 비교시 sequence similarity가 97% 이하여야 한다. 3. 단 위 두조건이 충족되더라도 형태나 생리적 표현 형질의차이가 없으면 다른 종으로 분류 할수 없다.
microbial community analysis (어떤 미생물이 얼마만큼 있는지 분석)
DGGE, TGGE, t-RFLP, SSCP 는 PCR로 16S rRNA gene을 증폭한담에 전기 영동으로 gel 상에 band의 형태로 미생물 군집의 변화를 본다. 음. 말 그대로 gel 걸어서 비슷한 것들끼리 분리되서 뭉치니까 그걸로 판단을 하는거 같고 근데 이것으론 데이터베이스와 그리고 종의 정보는 얻지 못함.
species richness : 시료내 종의 수
OTU (operational taxonomic unit)으로 분류 대상이 되는 생물체의 개체 또는 군. 거의 종을 의미, 그러니까 species richness를 구한다는건 OTU의 수를 수한다는 구한다는 것과 동일하다고 할수 있을거 같다.
1.일차적으로 read들을 filtering을 잘해서(quality filter, barcode & primer trimming) 2.CD-HIT과 같은 프로그램으로 read들을 clustering 후 3. 통계적 방법으로 실제의OTU를 추정 3.전체적인 종의 분포를 나타내는 diversity index를 구함.
의문점 및 checklist
1.누구랩 레포트를 보아하니 query를 blastn도 하고 megaBlast도하는데.. 음 왜 그러지 blastn만 하면 megablast 까지 커버가 되는거 아닌가? 굳이 둘다 하는 이유가 있나.
2.그리고 blast후 비슷한 시퀀스를 뽑아낸 다음에 global alignment 를 하는데 여기서 말하길 clustalW의 것과 동일한 것을 사용한다고 하는데 (http://bioinformatics.oxfordjournals.org/content/4/1/11.abstract) 이건 일반적으로 알고 있는 needleman이랑은 다른 것인가?
3.read trimming을 할때 pairwise alignment를 해서 barcode와 primer를 제거해야 하는데 이를 어떤식으로 할것인가?
4.CD-HIT 관련 논문
5.species richness 의 통계적 추정 관련 논문
6.Mothur program
7.쌍둥이 내장내 miocrobiome metagenomics 논문
Sunday, March 13, 2011
네트워크 원리
우선은 책의 구성이 참 맘에 든다. 일본인 저자인데.. 의외로 일본인이 지은 책을 실망한적이 없는거 같다. 이들은 참 생각을 많이 하고 책을 만들어 낸 느낌이 있다. 꼭 정석적으로라기 보다 어떻게 하면 조금 더 이해를 잘 시킬수 있을까라는 생각을 많이 하고 책을 만든다. 일단 첫부분에 전체 적인 내용을 요약한 테이블이 있는데. 음.. 이부터도 참 잘되어 있다. 고고
Saturday, March 12, 2011
iphone 개발 수업 1주차
3/11
프레임워크라는 것은 package 와 같은 개념. 그러니까 클래스 묶음.
iOS 는 4개의 계층으로 구성되어 있는데 맨 위의 계층만 거의 object-c로 구성. 그렇기에 개발 자체는 꼭 object-c일 필요는 없으나 프레임워크를 사용하려면 object-c 필요
NSLog 나 NSString 클래스는 UTF-8 을 사용한다. 그렇기에 ""앞에 @를 붙여서 @"somthing" 방식으로 사용한다.
3/12
alloc 하면 클래스를 메모리에 올림, 단 super, self 는 초기화된다. self에는 자기 자신의 메모리 주소를 가르킨다.
init 을 호출해야 그 클래스의 속성들 (refCount, )이 초기화 된다.
nil = Nil = NULL = 0
nil : alloc 했는데 오류, 포인터가 더이상 객체를 가르키지 않는다.
Nil : 포인터가 클래스 메소드를 더이상 가르키지 않는다.
NULL : 객체를 가르키는 포인터가 아닌 변수, 구조체를 가르키는 포인터가 더이상 변수 구조체를 가르키지 않는다.
사실 구분하지 않고 사용해도 효과는 동일
objective-c 2.0 버젼에서는
클래스 안의 속성값은 다른 클래스에서 접근할 수 없기 때문에 속성을 리턴하거나 수정하는 메소드를 정의해야 했다. 그런데 3.0버젼부터는 property를 사용하면 컴파일러가 자동으로 속성과 관련된 메소드를 만들어 준다. 그리고 3.0 에서는 자동 구현된 메소드는 . 연산자에 의해 접근이 가능하다(원래는 [object setAttr] 식으로 해야 하는데 object.setAttr가 가능하다, 단 자동 구현 메소드만).
property
선언부, interface 에서는 @property 구현부, implementation 에서는 @synthesize를 명시해야한다. retain은 객체 타입, assign은
아. set, get 메소드가 생긴다라고 보기보다는 C++처럼 그냥 . 연산자로 속성에 접근이 가능하게 하는 효과가 생긴다. 그렇기에 set메소드처럼 사용하려면 class.attr = something, get메소드처럼 사용하려면 NSLog(@"%@",class.attr) 과 같이 사용한다. 이는 사실 컴파일러가 set, get 메소드를 정의하면서 동시에 연산자(=) 오버로딩에 의해 가능해진 것이다.
@property (<#attribute#>) <#type#> <#name#>
<#attribute#> 에는 3종류가 있는데 setter(assign, retain), nonatomic(atomic, nonatomic), getter(readwrite, readonly) 가 있다.
<#attribute#> 안써주면 default로 atomic 으로 설정된다. atomic 은 한번에 하나의 쓰레드에서만 접근 가능한 객체. nonatomic 으로 설정해주면 여러쓰레드가 동시 접근이 가능한 객체. 대부분의 속성은 nonatomatic 이다.
아이폰 앱의 Architecture 와 life cycle
앱의 아이콘 터치 => main 실행 => UIApplicationMain 함수 실행(이는 cocoa내부에 구현되어 있는 것으로 그 메소드의 인자에 의해 저절로 project 이름이 넘어가면서 3번 스텝에서 UIApplicationDelegate 클래스를 상속받은 클래스가 무엇인지 판단하게 된다) : 1. 프로젝트명-info.plist(앱전체 설정파일) 을 읽고 2. plist 파일에서 main nib file base base name 키를 보고 화면설정이 있는 파일 이름을 찾음(MainWindow.nib; xml 파일) 3. UIApplicationDelegate를 상속받은 클래스의 객체를 생성([[someClass alloc] init])(UIApplicationDelegate 클래스를 상속받은 객체는 반드시 하나), 이때 2번에서 읽은 파일에 읽은 xml 파일에 있는 화면 객체들을 생성해서 someClass 안에 있는 UI window 객체 타입의 window 변수에 넣는다. UI window는 기본적으로 안보이게 되어 있다. 4. UIApplication 객체 생성 5.그리고 UIApplication 객체가 무한 루프를 돌면서 event가 발생하는지 monitoring 하고 event에 따라서 거기에 맞는 someClass, 즉 3에서 생성한 클래스의 메소드 호출. 무한 루프는 iphone3 에서 home 버튼 누르면 끝났으나 4버젼부터는 home 버튼을 눌러도 background 로 돌고 메모리가 OS 에서 메모리가 부족하면 그 때 끝낸다.
무작정 따라하기
1. Main
프레임워크라는 것은 package 와 같은 개념. 그러니까 클래스 묶음.
iOS 는 4개의 계층으로 구성되어 있는데 맨 위의 계층만 거의 object-c로 구성. 그렇기에 개발 자체는 꼭 object-c일 필요는 없으나 프레임워크를 사용하려면 object-c 필요
NSLog 나 NSString 클래스는 UTF-8 을 사용한다. 그렇기에 ""앞에 @를 붙여서 @"somthing" 방식으로 사용한다.
3/12
alloc 하면 클래스를 메모리에 올림, 단 super, self 는 초기화된다. self에는 자기 자신의 메모리 주소를 가르킨다.
init 을 호출해야 그 클래스의 속성들 (refCount, )이 초기화 된다.
nil = Nil = NULL = 0
nil : alloc 했는데 오류, 포인터가 더이상 객체를 가르키지 않는다.
Nil : 포인터가 클래스 메소드를 더이상 가르키지 않는다.
NULL : 객체를 가르키는 포인터가 아닌 변수, 구조체를 가르키는 포인터가 더이상 변수 구조체를 가르키지 않는다.
사실 구분하지 않고 사용해도 효과는 동일
objective-c 2.0 버젼에서는
클래스 안의 속성값은 다른 클래스에서 접근할 수 없기 때문에 속성을 리턴하거나 수정하는 메소드를 정의해야 했다. 그런데 3.0버젼부터는 property를 사용하면 컴파일러가 자동으로 속성과 관련된 메소드를 만들어 준다. 그리고 3.0 에서는 자동 구현된 메소드는 . 연산자에 의해 접근이 가능하다(원래는 [object setAttr] 식으로 해야 하는데 object.setAttr가 가능하다, 단 자동 구현 메소드만).
property
선언부, interface 에서는 @property 구현부, implementation 에서는 @synthesize를 명시해야한다. retain은 객체 타입, assign은
아. set, get 메소드가 생긴다라고 보기보다는 C++처럼 그냥 . 연산자로 속성에 접근이 가능하게 하는 효과가 생긴다. 그렇기에 set메소드처럼 사용하려면 class.attr = something, get메소드처럼 사용하려면 NSLog(@"%@",class.attr) 과 같이 사용한다. 이는 사실 컴파일러가 set, get 메소드를 정의하면서 동시에 연산자(=) 오버로딩에 의해 가능해진 것이다.
@property (<#attribute#>) <#type#> <#name#>
<#attribute#> 에는 3종류가 있는데 setter(assign, retain), nonatomic(atomic, nonatomic), getter(readwrite, readonly) 가 있다.
<#attribute#> 안써주면 default로 atomic 으로 설정된다. atomic 은 한번에 하나의 쓰레드에서만 접근 가능한 객체. nonatomic 으로 설정해주면 여러쓰레드가 동시 접근이 가능한 객체. 대부분의 속성은 nonatomatic 이다.
아이폰 앱의 Architecture 와 life cycle
앱의 아이콘 터치 => main 실행 => UIApplicationMain 함수 실행(이는 cocoa내부에 구현되어 있는 것으로 그 메소드의 인자에 의해 저절로 project 이름이 넘어가면서 3번 스텝에서 UIApplicationDelegate 클래스를 상속받은 클래스가 무엇인지 판단하게 된다) : 1. 프로젝트명-info.plist(앱전체 설정파일) 을 읽고 2. plist 파일에서 main nib file base base name 키를 보고 화면설정이 있는 파일 이름을 찾음(MainWindow.nib; xml 파일) 3. UIApplicationDelegate를 상속받은 클래스의 객체를 생성([[someClass alloc] init])(UIApplicationDelegate 클래스를 상속받은 객체는 반드시 하나), 이때 2번에서 읽은 파일에 읽은 xml 파일에 있는 화면 객체들을 생성해서 someClass 안에 있는 UI window 객체 타입의 window 변수에 넣는다. UI window는 기본적으로 안보이게 되어 있다. 4. UIApplication 객체 생성 5.그리고 UIApplication 객체가 무한 루프를 돌면서 event가 발생하는지 monitoring 하고 event에 따라서 거기에 맞는 someClass, 즉 3에서 생성한 클래스의 메소드 호출. 무한 루프는 iphone3 에서 home 버튼 누르면 끝났으나 4버젼부터는 home 버튼을 눌러도 background 로 돌고 메모리가 OS 에서 메모리가 부족하면 그 때 끝낸다.
무작정 따라하기
1. Main
Subscribe to:
Posts (Atom)