Tag : 3.0, as3, Tip & Tech, 플래시
ActionScript 3.0,
What’s different from AS2.0
Written by Wooyaggo.
at SWF LAB Seminar
Misunderstood and expected about ActionScript 3.0
1. ActionScript 3.0 에 대한 오해와 기대.
오해.
- ActionScript 3.0 은 ActionScript 2.0 을 잘하면 공부하기 더 쉽다.
- ActionScript 3.0 은 ActionScript 2.0 과 비슷한 부분이 많다.
- ActionScript 3.0 은 너무 어렵다.
- ActionScript 3.0 을 잘할려면 OOP 나 Class 등 너무 알아야할게 많다.
- ActionScript 2.0 으로 어느정도 할 줄 알면 굳이 ActionScript 3.0 을 할 필요 없다.
기대.
- ActionScript 3.0 은 제대로 된 OOP 언어이다.
- ActionScript 3.0 으로 ActionScript 2.0 에서 안되던게 거의 다 가능하다.
- ActionScript 3.0 은 소켓, 바이너리, 보안 다 가능하다.
Review of ActionScript 2.0
2. ActionScript 2.0 되돌아 보기.
- ActionScript 의 배경.
- ActionScript 2.0 의 장점.
- ActionScript 2.0 의 단점.
- ActionScript 2.0 활용 범위
What is possible by ActionScript 3.0
3. ActionScript 3.0 으로 가능한 것은 무엇인가?
- OOP 를 지향한다.
- 엔터프라이즈 어플리케이션이 가능하다.
- 프레임웍이 보다 수월해진다.
- 유지보수, 협업, 버전관리, 문서화등이 더 편리해진다.
What’s new in ActionScript 3.0 ?
4. ActionScript 3.0 에서 새로운 것은?
- Event Model.
- Display List Model.
- DisplayObject 와 DisplayObjectContainer 그리고 Sprite.
- 새로운 클래스들.
- 도큐먼트 클래스.
- Array 와 숫자형의 확장.
Important Classes of ActionScript 3.0.
5. ActionScript 3.0 의 주요 클래스들.
- Event 와 EventDispatcher 클래스.
- DisplayObject 와 DisplayObjectConatiner 클래스.
- int 와 uint 클래스.
- Bitmap 과 BitmapData 클래스.
- String 과 RegExp 클래스.
- XML 과 E4X.
What else is importance of ActionScript 3.0 ?
6. ActionScript 3.0 의 그외의 핵심.
- 새로운 접근자.
- DOM3 모델.
- Text 기능 향상.
- Low-Data Access 기능.
- Drawing 클래스의 분리.
- Application Domain Model.
What is a our state of mind about ActionScript 3.0 ?
7. ActionScript 3.0 에 대해 우리가 가져야할 마음가짐은?
- 항상 겸손하자.
- 영어 공부를 하자.
- 서두르지 말자.
- ActionScript 3.0 을 마음대로 다룰 수 있을 때, 그때부터 진짜 공부는 시작이다.
- 용어를 공부하자.
- 클래스명, 변수명, 함수명 네이밍에 더 많은 노력을 기울이자.
일단 한마디를 하고 넘어가겠습니다.
저는 보안에 대해서 그다지 지식을 많이 가지고 있지 않지만
ActionScript 3.0 의 보안 모델은...
"참 거지같습니다."
일관성이라고는 눈을 씻고 찾아봐도 없고
융통성이라고는 코를 씻고 찾아봐도 없으니
강좌 마지막에 재미있는 에피소드를 하나 말씀드릴께요. ㅎㅎ
이런 어정쩡한 보안 모델에 대해서
처음에 맨땅에 3.0 공부할때 정말 애 많이 먹었습니다.
결국은 핵심적인 부분은 옆팀의 선준님께서 해결해주셔서 큰 무리는 없었지만
이렇게 저렇게 보안에 대해서 많이 걸리고 넘어져보니
어느정도 갈피가 서더군요.
참고로 플래시 보안모델이 정해놓은 개념이 아니라
제가 겪다보니 이런식으로 정리가 되더라~ 말이죠.
때문에 ActionScript 3.0 으로 외부 데이타를 사용할때 참고하면 내용을 정리한것이지
절대로 레퍼런스나 어도브가 권하는 정보가 아니니 분별력있게 받아들이시기를 발바니다.
자 본론으로 들어갑니다.
1. Information
보안 모델이 다루는 정보의 종류는 두가지 입니다.
- 가공해야만 정보로써 가치가 있는 데이타.
- 존재 자체로도 정보로써 가치가 있는 데이타.
jpg 나 flv 는 그 데이타 자체로는 우리가 어떤 정보인지 알 수 없습니다.
사진 프로그램이나 동영상 프로그램으로 돌려봐야지만 어떤 영상인지 알 수 있다는 이야기죠.
Flash 에서는 로드해서 클래스로써 감싸야지만 비로소 사용할 수 있습니다.
이런 가공해야만 정보로써 가치가 있는 데이타는 바이너리로 압축이 되어 있다는게 특징입니다.
하지만 Text, Variables(변수=값&변수=값 형태), XML 은 그 자체로도 정보로써 활용할 수 있습니다.
이렇게 정보는 두가지로 구분될 수 있습니다.
2. Use & Access
보안 모델이 판단하는 "정보의 사용"은 두가지로 나뉩니다.
- 원본 자체를 그대로 사용하는 행위.
- 원본에서 가공할 수 있는 데이타로 변환하는 행위.
자 말이 조금 헷갈리는데
원본 자체를 그대로 사용하는 경우는 말그대로
로드해서 걍 보여주는 겁니다.
이미지는 로드해서 Bitmap 한테 줘서 보여주고
FLV 는 스트림으로 감싸서 재생만 하고
MP3 도 사운드로 감싸서 재생만 하는겁니다.
원본에서 가공할 수 있는 데이타로 변환하는 행위는
이미지의 경우는 BitmapData.draw() 가 있을테고
사운드의 경우는 Sound.computeSpectrum() 이 있을겁니다.
이미지는 비트맵정보를 가져와 그것을 바탕으로 가공을 할 수 있을테지요.
사운드는 바이너리 정보를 가져와 사운드변형을 할 수 있을테지요.
이렇게 두가지 사용으로 나뉠수 있습니다.
3. Security don't allow all.
Flash 보안 모델의 기본은
"모든 보안을 일단 막고, 승인된 것만 풀어준다." 입니다.
우리가 아무조치를 취하지 않으면 기본적인 보안은 모두 막힌다 입니다.
단지 기본적인 보안에 해당되지 않는 보안에는 여러가지가 있겠죠.
localWithFile 이라던지 localTrusted 는 기본으로 모두 풀려있습니다.
이처럼 Flash 보안 모델은 "상당히 까다롭습니다."
Flash 보안 모델은 아래와 같이 보안을 나눌 수 있습니다.
- 가공해야 정보로써 가치가 있는 정보를 있는 그대로 사용하는 행위는 보안을 허가한다.
- 그외의 보안은 모두 금지한다.
즉, 이미지나 flv 를 가져와서 마냥 보여하는것은
보안이 기본적으로 풀려있습니다.
하지만 그외의 보안, 비트맵을 가져온다거나 사운드를 딴다거나(?) 하는 행위는
보안이 막혀있는 것이지요.
4. Get allow.
간단하게 말씀드리겠습니다.
제가 보안 모델에 대해서 맹비난하는 이유가 여기 있는데
보안을 푸는 방식에 있어서
참 재밌게도 일관된 방법이 전혀 없습니다.
URLLoader 는 알아서;;
Loader 는 load() 메소드 파라미터로;;
NetStream 은 프로퍼티로...;;
LocalConnection 은 별 거지같은 방법으로;;;
SWF Accessing 은 static 클래스로;;;
RTMP는 무조건 꺼지라하고...;;; (님하 매너연~)
이건 뭐 장난하는것도 아니고
보안 모델이 어려운 이유가 있었습니다.
결코 자신이 머리가 나쁜게 아니고 Flash 가 난잡하게 꼬여있었던 겁니다.
사실 저보고 일관성있게 하라그러면
도망가겠지만
그래도 이건 좀;;; 그렇지 않나요?
그렇다고 또 막아놓은것도 완전 막아놓은것도 아닙니다.
꼼수 쓰자면 후훗... 곰방하죠.
암튼 디테일한건 각자 레퍼런스형님께 여쭤보시기 바랍니다.
5. Summary
Flash 보안 모델은 일단 개념에 있어서
잘 정리되어 있어야 합니다.
그래야 정보를 다루고 복잡한 컨트롤에 있어서 체계적인 구조를 잡을 수 있을것입니다.
가장 중요한것은 정보의 종류와 사용함에 있어서의 종류.
이 두가지 구분은 알아두셔서 보안 모델을 미리 감지하고 시행착오 없으시길 바랍니다.
그럼 도움 되셨길.
6. 후원금 좀;;
가상의 후원금인데 이상하게 구걸하게 되네요 -_ㅡa
후원하고 5일후면 다시 후원할 수 있어요.
굽신굽신;;
Tag : 3.0, as3, flash, Tip & Tech, 굽신굽신, 플래시, 후원금좀
이제 슬슬 3.0이 자리를 잡아가는거 같은 느낌이 듭니다.
그래서 3.0을 처음 공부하시는 분들이 아닌
2.0을 하시다가 3.0을 공부하시는 분들께
특히 다른 언어를 경험해보지 않으셨던 분들
즉, 2.0에 푹 길들여져있던 분들께 도움을 되지 않을까 싶네요.
- 2.0때 되던 기능이 3.0에는 없어서 불편하다.
가장 많이 물어보는 질문이 onReleaseOutside 랑 duplicateMovieClip 을 가장 많이 물어봅니다.
물론 굉장히 편리한 메소드이기는 하죠.
하지만 3.0을 공부하면서 가장 밑바닥 개념으로 깔아놔야될 점이 바로
"제대로 된 언어" 이라는겁니다.
즉, 안되는건 없습니다.
다만 여러가지 기능을 하나로 묶어서 2.0때 하나의 메소드로 제공했거나
플래시가 스스로 처리했던 부분을 우리가 컨트롤 할 수 있도록 되었다는 것입니다.
3.0에서 안될리가 없습니다.
분명히 장담하지만 2.0때 되던게 3.0에서 못하는건 없습니다. (심지어 duplicate 도 만든다면 만들 수 있습니다.)
onReleaseOutside 는 아래와 같은 구조로 되어 있습니다.
1. 마우스를 누를때 mouseOut 이벤트를 걸어놓습니다.
2. 마우스를 누른 상태에서 마우스가 빠져나가면 mouseOut 이벤트를 캐치해서 이번엔 mouseUp 이벤트를 걸어놓습니다.
3. 이때 mouseUp 이벤트가 발생하면 이것이 바로 onReleaseOutside 입니다.
위 구조를 알고 있다면 3.0에서 똑같이 구현할 수 있습니다.
- 클릭하나 체크하는데 너무 불편해요~
글쵸 기존에는 onMouseDown = function(){} 으로 바로 선언했지만
3.0에서는 이벤트 걸어주고 이벤트 받는 메소드 만들고
메소드도 타입 정해주고 메소드도 나눠지다보니까 값을 참조하려면 난감해지고
이상하게 자꾸 소스가 지저분해지는것 같죠.
자 여러분, 기존에는 자전거 부품가게에서 브레이크나 핸들, 뾱뽁이을 사다가
자전거를 만들었었습니다. 이때가 2.0 이었죠.
이제는 프레임을 만드는데 쓰이는 철, 알루미늄, 스뎅을 구할 수 있게되었고
핸들을 만드는데 쓰이는 고무, 와이어, 실리콘등을 구할 수 있게 된것이 바로 3.0 입니다.
즉 더 low 한 기능을 우리가 직접 컨트롤 할 수 있게 된것이죠.
가장 대표적인 부분이 Event 와 DisplayObjectContainer 그리고 Document Class 입니다.
3.0때 새로 나왔다고 생각하시는 분이 많은데
새로워지긴 했지만 2.0때 플래시가 자동으로 처리해주던 부분이
더 이쁘게 다듬어져서 나온것입니다.
onMouseDown 은 해당 무비클립에 이미 addEventListener 를 걸어놓고
리스너에서는 onMouseDown 이라는 함수를 실행하도록 미리 선언을 해놓았던 겁니다.
그렇기 때문에 우리는 onMouseDown 을 만들어주기만 하면 되었던 겁니다.
또 우리는 바닥에 무비클립을 만들어서 걍 돌리기만 하면 됐는데
3.0에서는 Document Class 선언해줘야되고
무비클립 하나하나 public 으로 선언해줘야되고
아 짜증나죠?
근데 2.0때는 플래시가 스스로 이미 그런 처리를 하고 있었던겁니다.
이제 그걸 우리가 할 수 있도록 제공되는것이죠.
그만큼 우리는 더 디테일하게 컨트롤 할 수 있고
더더욱 좋은 퍼포먼스, 더 최적화된 플래시를 만들 수 있게 된것이죠.
- 일일이 addChild 하기 귀찮고 root 도 될때 안될때 있고 귀찮아요~
위에서 말했다시피 mc.createEmptyMovieClip() 은
var newMC: MovieClip = new MovieClip();
mc.addChild( newMC )
라는 메소드를 하나로 묶어놓은것 뿐입니다.
이 덕분에 우리는 그토록 갈망하던 이 인스턴스에서 저 인스턴스로 무비클립을 이동시킬 수 있게 되었죠.
그런데 이 기능은 안되는것이 오히려 이상했던겁니다.
OOP 입장에서 가장 기본이 되는 클래스가 인스턴스화되는 순간 특정 부모의 자식으로 고정되어버린다는것은
엄청난 제약을 받는것이라고 볼 수 있습니다.
- 절대 2.0에서 쓰던 방식으로 3.0을 구현하려고 하지 마십시요.
onMouseDown 이 편했던건 사실입니다.
하지만 편했던 만큼 디테일하게 다룰 수 없었고
변수 스코프문제나 변수 전달등의 문제가 있었습니다.
그렇다고해서 3.0에서 public var onMouseDown: Function 으로 선언해놓고
mc.onMouseDown = function(){} 이렇게 하지 마십시요.
의외로 2.0때 쓰이던 방식을 3.0때도 그렇게 구현해서 쓰려고 애쓰는 사람 많습니다.
절대로 그렇게 하지 마십시요.
바로 이점 때문에 2.0을 하던사람이 오히려 새로 배우는 신입보다 3.0을 익히는 속도가 느린 이유입니다.
2.0 때의 습관이 몸에 베서 어떤게 더 효율적이고 어떤게 더 OOP 적인지 모르는 현상입니다.
특히 다른 언어를 모르는 상태에서 2.0만을 접한 사람들의 특징입니다.
클래스나 변수, 리턴타입, static, 상속에 대해서 잘 받아들이지 못하고
이해하는데 굉장히 힘들어합니다.
속마음은 이럴껍니다. "뭐하러 저렇게 복잡하게하지? 그냥 parent 로 가져다 쓰면 되는데..."
반박할 논점은 많지만
가만히 생각해보면 자바나 C 같은 언어진영에서 50년이 넘게
쓰이던 방식인데 설마 그걸 몰라서 안 그랬을까요?
아직은 모르겠지만 다 그만한 이유가 있기 때문이고 그럴 필요가 있기 때문에 그럴꺼라는
믿음을 가져보십시요.
이제 플래시가 UCC 를 필두로해서
어플리케이션으로써의 면모를 대중에게 선보이기 시작했습니다.
이는 곧 우리의 고객들이 비슷한 수준을 원하게 될거라는 의미며
고객이 원한다는것은 이제 우리가 그런것을 할 줄 알아야 한다는 의미입니다.
이웃팀 팀장님께서 알려주신것 처럼 "붉은 여왕 효과" 라는 말이 있습니다.
제자리에 있으려면 힘껏 달려야합니다.
왜냐면 모두가 달리고 있기 때문이죠.
솔직히 말해서 3.0의 등장은 기존의 2.0 개발자들에게
굉장히 불리한 언어입니다.
왜냐면 2.0 은 말이 스크립트지 언어도 아니며 스크립트도 아니며
좀 이상한 명령어들의 집합이었다고들 합니다.
누가 그러냐구요? 자바나 C 처럼 오랜 역사를 가지고 있는 언어쪽의 개발자들의 말입니다.
사실입니다.
그래서 3.0 이 제대로된 언어의 모습으로 세상에 나왔을때
우리가 우와 이게 뭐야? 하면서 멀뚱 멀뚱할때
이미 자바나 C 진영에서 새로운 아이디어를 갈구하던 많은 개발자들은
나오자마 엄청난 라이브러리들을 만들기 시작했습니다.
그게 벌써 1년이 지났네요.
요즘 AIR를 타겟으로 수많은 개발 방법론, 아키텍쳐, 개발 지원 툴들이
어마어마하게 쏟아져 나오고 있습니다.
얼마나 어마어마하냐면
이렇게 설명하면 이해가 되겠네요.
자바나 C 에서 50년도 넘게 걸쳐서 확립되고 논의를 거쳐 정리된 이론들이
플래시쪽으로 다이렉트로 적용되고 있습니다.
안타깝게도 우리는 따로 공부할 시간이 없습니다.
이미 남들은 그런 경험을 바탕으로 엄청난 소프트웨어를 만들고 있을때
우리는 현장에서 허겁지겁 익혀야합니다.
왜냐구요? 남들보다 잘할려고 하기보다 "제자리"에 있기 위해서죠.
늦지 않았습니다.
나이 먹어서 장사나 하려고 프로그램 하는 사람들은
어차피 그러다가 다른 쪽에서 돈 더 준다고하면 가차없이 플래시를 버릴 사람들입니다.
뼛속까지 개발하고 싶어하는
내가 만든 코드가 돌아갈때 희열을 느끼는 골수 플래시 개발자들에게는
이제 업그레이드할 시기가 왔습니다.
오히려 이제 진정한 "개발자"로써 탈피할때이죠.
2.0의 습관이나 메소드는 과감히 버리십시요. (회사에서 짤리지 않을 만큼만 ㅋㅋ)
이제 플래시로도 Language 입니다.
다들 홧팅~
p.s) 시간나면 야꼬한테 후원해주세요^^ 가상의 후원금입니다. ㅎㅎ
Tag : 3.0, as3, flash, 강좌, 플래시
Tag : 3.0, as3, flash, Tip & Tech, 강좌, 클래스, 플래시
| public function onDragEnter(e:NativeDragEvent):void { var data:TransferableData = e.data } |
| public function onDragEnter(e:NativeDragEvent):void { var data:Clipboard = e.clipboard } |
Tag : AIR, Tip & Tech, 에어
Flash CS3 가 출시되고 AS3.0 이 널리 퍼지고 있는 요즘
Document Class 에 대한 문의가 많은것 같습니다.
처음 배우는 분들도 기본적인 개념만 익혀서 사용하는데 전혀 문제 없기 때문에
디테일하게 다루다 보면 생각의 장벽에 부딪히는 경우가 많더군요.
Document Class (이하 DC)는 한줄로 표현하자면 "fla 의 하얀 바탕 그 자체가 Document Class다." 이라고 할 수 있습니다.
물론 이정도만 알고 있어도 사용하는데 큰 불편함은 없지만
Application Domain 을 사용한다던지
Loader 를 이용해서 외부 클래스를 사용한다던지
Stage 에 대한 디테일한 컨트롤을 할때는 어김없이 DC에 대한 개념이 발목을 잡을때가 많습니다.
DC 에 대한 가장 정확한 표현은
"Stage 에 가장 먼저 자동으로 addChild 되는 DisplayObject 다."
라고 할 수 있습니다.
자 하나씩 구체적으로 살펴보도록 합시다.
우리가 사각형을 만들때 보통
소스 보기
이렇게 하죠?
자 그러면 네이밍을 좀 바꿔서
소스 보기
소스 보기
Tag : 3.0, DocumentClass, 강좌, 도클
AS3.0 에 들어와서 가장 많은 분들이 어려워하고 계시는 부분이 이벤트와 더불어 container 개념인거 같습니다.
제가 메신져로 가장 많이 듣게 되는 질문이 이벤트랑 DisplayList 를 이해하고 있지 못해서 발생하는 문제들이 많은거 같습니다.
2.0때도 눈에 안보이게 이미 존재했었고 몇몇 고수분들은 잘 이해하고 사용하고 계셨기 때문에 전혀 생소한 개념은 아니지만
마냥 this.parent.friend.child 로 접근하던 방식이 이제는 그 틀을 벗어날때가 된거 같습니다.
이미 2.0때부터 빠삭하게 파악하고 계신분들에게는 식상한 얘기일수도 있겠으나 이제 시작하시는 분들을 위해 마련해봤습니다.^^
자세한 내용 들어가기 전에 용어를 먼저 정리하죠.
DisplayObjectContainer : 클래스입니다. Sprite나 Stage의 상속클래스죠. 눈에 보이는 클래스가 아닙니다.
DisplayObject : 클래스입니다. 눈에 보이게 되는 모든 요소의 상속클래스죠. Bitmap, Video, MovieClip 의 상속클래스를 따라가다보면 반드시 DisplayObject 클래스가 있게 됩니다.
DisplayList : 화면에 보여줘야할 목록이라는 의미의 단어입니다. 실존하는 클래스가 아닙니다.
contains : "포함한다"라는 추상적인 의미입니다. 집안에 내가 있고, 내 안에 심장이 있고, 심장안에 혈액이 있겠죠.
자 살살 시작해보겠습니다.
우리는 무비클립 안의 무비클립에 접근할때 2.0때는 main.sub 로 바로 접근했었죠.
물론 3.0에서도 똑같이 접근할 수 있습니다.
바로 이 점 때문에 많은 분들이 2.0때의 그대로 모든것을 시도하기 때문에 혼동이 일어납니다.
우선 DisplayObject 라는 것은 화면에 보여질 수 있는 "보이는 객체"입니다.
즉 화면에 보여질 수 있는 데이타를 가지고 있는 객체라는 뜻이죠.
int 3 이나 string "abc" 는 화면에 보이는 그런 값이 아니죠.
하지만 BitmapData 나 Shape 은 화면에 보여질 수 있는 객체입니다.
이런 객체들은 DisplayObject 라고 불려집니다.
이런 객체들이 "①화면에 보여줘야할때"는 render 라는 과정을 거쳐서 실제 모니터에 그 모습을 보여주게 되죠.
우리가 swf 를 실행하면 FlashPlayer 가 실행되서 그안에서 우리가 만든 플래시가 보이게 됩니다
이 FlashPlayer 를 우리는 Stage 라고 이해합시다.
Stage 는 swf안에 있는게 아닙니다.
즉, 우리가 this.stage 라고 접근하는것이 내가 만들고 있는 객체의 "그냥 모든것"이라고 치부하면 안됩니다.
Stage 라는 것은 FlashPlayer 의 "화면 자체"를 의미한다고 보면 됩니다.
그래서 this.stage 에 이벤트를 걸면 어디서든 다 작동하는게 바로 그 원리입니다.
stage 에 MoueEvent를 걸면 어떤 위치에서든 다 작동하고 무조건 최상위로 작동하는게 그 원리입니다.
swf 보다 한단계 위에 있는 객체라는 뜻이죠.
①에서 말한 보여줘야 할때라는 것은
바로 이 Stage 에 "②포함되었을때" 를 말합니다.
왜냐면 Stage 에 포함되지 않은건 어디에도 보일 일이 없다는 뜻이기 때문에 render 를 할 필요가 없는것이죠.
위에서 말한 "②포함되었을때" 라는 것이 바로 contains 개념입니다.
child 라는 객체를 뜻하죠.
DisplayObject 는 누군가에게 child 가 될 수 있습니다.
하지만 동시에 두군데에 child 될 수는 없습니다.
새롭게 child 하게 되면 이전에 contain 되었던 곳에서는 사라지게 됩니다.
이 점 꼭 잊지 마시길 바랍니다.
자 그럼 실제로 하나 예를 들어서 풀어보겠습니다.
참고로 FrameScript 는 고려하지 않겠습니다.
권장하는 방법도 아니며 올바른 객체지향 개발도 아니기때문에 전혀 고려할 대상이 아니라고 판단하기 때문입니다.
2중 뎁스 메뉴를 예로 들겠습니다.
fla 안에는 menu 라는 무비클립이 있습니다.
이 menu 안에는 sub라는 무비클립을 생성해서 그때 그때 메뉴의 갯수가 달라지는 그런 메뉴라고 하겠습니다.
menu 안에는 txt 라는 텍스트가 있어서 메뉴의 이름을 정해주도록 하겠습니다.
그러면 2.0방식으로는 root 메인 프레임에
var sub:SubMenu = this.menu.attachMovie();
sub.txt.text = "홈으로";
이런식으로 개발을 했겠죠.
그렇다면 3.0은 어떻게 개발하는게 좋은지 살펴보죠.
우선 가장 처음부터 다르게 시작하죠.
DocumentClass 를 만듭니다.
fla 의 Property 창에서 하단에 Document class : 라는 곳이 있죠.
이곳에 클래스 명을 적습니다.
MenuSample 이라고 가정하죠.
그러면 fla 와 같은 위치에 MenuSample.as 라는 파일이 있어야겠죠.
package
{
import flash.display.Sprite;
public class MenuSample extends Sprite
{
public function MenuSample():void
{
}
}
}
라고 기본 소스를 적어줍니다.
클래스를 생성해줬죠.
자 그렇다면 바탕에 있는 menu 라는 무비클립에 접근하려면 어떻게 해야할까요?
(여기서 잠깐. Properties > Settings > ActionScript version > ActionScript 3.0 Settings > Stage 에서 자동으로 인스턴스 선언해주는 부분에 체크가 되어 있다면 반드시 풀어주십시요. 편하다고 능사가 아닙니다. 우리는 정석을 배워야하죠.)
위에 적힌 DC (DocumentClass)는 에러를 발생합니다.
왜냐면 menu 라는 객체가 이미 있는데 저 클래스의 내용을 보아하니 menu 라는 무비클립을 인식시켜주는 부분이 없기 때문에죠.
DocumentClass 는 fla 자체라고 보시면 됩니다.
fla 바탕에 menu 라는 무비클립이 있으면 DC 에도 menu 라는 무비클립이 있어야합니다.
자 이렇게 적어줍니다.
package
{
import flash.display.Sprite;
import flash.display.MovieClip;
public class MenuSample extends Sprite
{
public var menu:MovieClip;
public function MenuSample():void
{
}
}
}
그러면 이제 Ctrl + Enter 를 해도 에러가 나지 않습니다.
올바르기 때문이죠.
그러면 menu 안에 sub 를 만들어서 넣어야합니다.
MenuSample() 메소드 안에 이렇게 적습니다.
var sub:SubMenu = new SubMenu();
menu.addChild(sub);
이렇게 하면 SubMenu 라는 객체를 만들어서 menu 에 child 로 추가한것입니다.
즉 생성을 한 후에 menu 라는 무비클립에 contain 시킨것입니다.
2.0때는 바로 menu 라는 무비클립 안에 만들어버렸죠.
생성과 child 개념은 다른것이기 때문에 보다 올바른 개발방법이 된것입니다.
그러면 menu 안에 넣은 sub 라는 객체의 텍스트를 변경하려면 어떻게 해야할까요?
여기서 2.0때의 습관을 못버리신 분들이 많이 골탕먹는 부분이 이부분입니다.
menu.sub.txt.text = "홈으로";
이렇게 하면 에러가 나죠.
위에서 var sub:SubMenu = new SubMenu() 라고 선언했죠.
var 라는것은 변수를 의미합니다.
여기서 만든 객체를 menu 안에 addChild 했다고 객체가 menu 안으로 들어가는게 아닙니다.
객체는 그대로 존재합니다.
var sub:SubMenu = new SubMenu();
menu.addChild(sub);
sub.txt.text = "홈으로";
라고 코딩하시면 됩니다.
addChild 한다는 뜻은 화면에 보여주기 위해서 menu 안에 넣어서 보여주겠다라는 의미입니다.
객체를 menu 안에 주겠다라는 뜻이 아닙니다.
menu 는 이미 fla 안에 있기 때문에 자동으로 DisplayList 에 포함되어 있습니다.
때문에 menu 에 sub 를 contain 시키면 자동으로 DisplayList 에 꼬리를 물고 포함되겠죠.
여기서 또한가지 많이 물어보는 것이 있습니다.
바로 menu 를 "없앨려면" 어떻게 해야하는것이죠.
이 질문에는 두가지 뜻이 혼동되어 있습니다.
즉, DisplayList 에서 사라지게만 할것이냐, 아니면 객체를 메모리에서 지우겠느냐
라는 두가지 뜻이 불분명한것이죠.
단지 눈에서만 사라지게 하려면 this.removeChild(menu) 하면 DisplayList에서 제거되기 때문에 눈에 보이지 않습니다.
하지만 객체를 없애려면 객체 자체를 없애야겠죠.
객체를 없애는 방법은 쉽지 않습니다.
플래시는 메모리를 직접 건드릴 수 없기 때문에 한번 생성한 객체를 지우려면 여러가지 조건이 있어야합니다.
때문에 2.0때의 removeMovieClip 이라는 애매모호한 메소드에 익숙해있던 개발자들에게
removeChild 는 먼가 구리고 개운치 않게 느껴질수도 있습니다.
하지만 removeChild 라는 의미는 굉장히 정확합니다.
더이상 나의 chlid 가 아니라는 의미기 때문이죠.
이제 child 가 아니게된 menu 는 어디에든 속할 수 있습니다.
아마 많은 현장에서 직접 경험해보시면 이해하실 수 있을겁니다.
여기서 child 가 되고 DisplayList 에 포함되었다가 빠졌다가 하는 개념이 바로
DisplayObjectContainer 클래스가 하는 역할입니다.
즉, 눈에 보여질 수 있는 객체(DisplayObject)를 넣었다 뺐다(contain) 하는 것이죠.
이때 대상이 되는게 바로 DisplayObject 인것입니다.
DisplayObject들은 어디든지 addChild, removeChild 될 수 있습니다.
이 개념이 바로 3.0들어서 가장 많이 어려워하시는 DisplayObjectContainer 개념과 DisplayObject 라는 클래스의 의미입니다.
p.s) 3.0 에 대해서 많이 푸념하시는것들 중에 하나가 바로 "소스가 너무 길어진다" 인데요,
소스가 짧다고 능사가 아니며 소스가 짧다는 이야기는 그 소스 한줄로 "많은" 처리가 이뤄진다는 이야기입니다.
즉, 내가 모르는 일들이 많이 일어나고 있다는 뜻이며
소스가 길어졌다는 의미는 "모든 처리"가 내 손에 의해서 이뤄진다는 것을 의미합니다.
저는 3.0을 하고부터 얼마나 개발이 재밌어졌는지 모릅니다.
거의 모든 일을 처리해주는 이벤트와 정확한 OOP 구조를 가지게 된 구조,
물론 2.0때도 있었다고 하면 할말이 없지만
거의 활용성이 없었죠.
한가지 자신있게 말씀드릴수 있는건
2.0 때의 습관으로 3.0 을 접하신다면
아예 모르는 쌩초보보다 늦게 배우실 수도 있습니다.
왜냐면 제가 그랬듯이 아주 기본적인 개념부터 달라졌기 때문입니다.
"달라졌다"라는 의미보다는 "제대로" 됐다 라는 의미가 정확하겠죠.
이상, 도움되셨길 바랍니다.
이올린에 북마크하기