요즘 OAuth 인증 때문에 고생좀 했습니다. 머리속에 있는 개념을 정리도 할겸 제가 사용해본 OAuth 라이브러리에 대해 소개 합니다. 

OAuth 란?

실 서비스 외부에서 API 를 사용할 때 이 OAuth 를 이용하여 인증을 하게 됩니다. 요즘 많이 사용하는 Twitter, facebook, Dropbox에서 제공 하는 API 모두 이 OAuth 를 지원하고 있고 지원하는 버전은 대부분 1.0 입니다. API 를 제공하는 곳에 따라서 2.0 을 제공하는 곳도 있습니다.  저 자세한 내용은 아래 링크에 자세히 설명 되어 있으니 생략하고 Flash 에서 OAuth 를 사용하는 방법에 대해 다뤄 보겠습니다.

Actionscript3.0 으로 구현 된 OAuth 라이브러리

OAuth인증을 하기 위해서는 서비스 프로바이더와 몇번의 통신을 해야 하고 결과적으로 accessToken 과 accessTokenSecret 을 발급 받게 됩니다. 일종의 로그인을 위한 허락 키를 발급 받는 거지요. 이 키와 몇가지 OAuth 에서 원하는 값들을 조합해서 리퀘스트를 날릴때 Header 나 리퀘스트 URL 에 포함 시켜서 보내게 되면 서비스 프로바이더는 해당 리퀘스트를 분석하여 제대로된 인증을 가지고 있을 경우에만 결과 값을 내려 주는 구조로 되어 있습니다. 

OAuth 인증을 거치는 과정이 accessToken 과 accessTokenSecret을 발급 받는 과정이지만, 인증이 끝나고 나서 이 값들만 포함 시켜서 리퀘스트를 날리는건 아님니다. OAuth 에서 원하는 값들이 많이 있는데요. 이 값들을 http://oauth.net/ 에 구현 된데로 개인적으로 만들어서 사용해도 되지만, 이미 많은 라이브러리가 구현 되어 사용 되고 있기 때문에 기존 라이브러리를 사용 하는 걸 추천 합니다. (OAuth 인증 절차상 인증이 잘못된 경우 어디서 무엇이 잘못된건지 디버깅 하기가 어렵습니다.)

oauth-as3

oauth-as3은 actionscript3.0으로 구현된 oauth 라이브러리 입니다. 기본적인 기능들만 구현 되어 있어서 바로 사용하기 보다는 이 라이브러리를 이용하여 따로 구현해 줘야 할 것들이 많습니다. 그럼 인증을 받는 순서대로 라이브러리를 사용해 보겠습니다.

사용하기 전에 알아 두면 좋은 이론은 라이브러리에 포함 되어 있는 OAuthRequest 는 실제로 서비스프로바이더와 통신을 하기 위해 리퀘스트를 만드는 클래스 이고, 이 클래스에서 OAuth 인증을 할때 필요한 oauth_nonce, oauth_timestamp, oauth_signature 등을 생성하게 됩니다. 서비스 프로바이더와의 통신은(인증할때) URLLoader 를 사용하지만 이 URLLoader의 값을 세팅할때 참조 해야 하는 클래스가 인증에 대한 정보를 가지고 있는 OAuthRequest 클래스 입니다. 그럼 requestToken을 받는걸로 시작해서 코드를 작성해 보겠습니다. Twitter(https://dev.twitter.com/docs/api) 인증을 예를 들겠습니다.

1. 서비스 프로바이더에서 requestToken 을 받는다.

우선 인증을 시작하기에 앞서 인증을 해야 하는 대상 어플리케이션이 존재 합니다. Twitter 등의 서비스 프로바이더에서 어플리케이션을 생성하면 해당 어플리케이션이 갖게 되는 고유의 consumerKey 와 consumerSecretKey 을 알 수 있습니다. 이 값들을 이용해서 OAuthRequest를 생성 합니다. 

그리고 Twitter의 경우 requestToken 을 발급 받는 api 가 post 를 사용하므로 셋팅을 해주고 oauthRequest에 인증에 필요한 모든 값들이 들어 있기 때문에 buildRequest 메소드를 이용해서 OAuth인증 값들이 포함 되어 있는 url 을 리턴 받아서 서비스프로바이더에서 리퀘스트를 날리게 됩니다.

buildRequest 에 들어가는 첫번째 파라미터는 oauth_signature_method 값이고 두번째 인자는 OAuth 인증 리퀘스트 값을 어떤 방식으로 받을 것이냐 선택 하는 것 입니다. 파라미터에 따라 URLRequestHeader값 또는 String 으로 받을수 있습니다.

2. requestToken 을 이용하여 서비스 프로바이더에게 접근 한다.

1번에 대한 response 값으로 oauth_token을 받게 되는데요. 이 값을 이용해서 또 다시 서비스 프로바이더에게 인증을 요청해야 합니다. 이번에 요청하는 인증은 URLLoader 를 이용한 인증이 아니라, 직접 URL로 이동하여 사용자가 아이디와 비번을 입력하여자신의 권한을 해당 어플리케이션에 수락 시키는 절차 입니다.

위의 URL로 Desktop AIR의 경우 HTMLLoader 를, Mobile AIR의 경우 StageWebView를 이용해서 해당 사이트로 이동하면 위와 같이 인증 화면이 뜨게 됩니다. 

사용자가 아이디와 비번을 입력하고 인증을 마무리 하게 되면 Twitter의 경우 어플리케이션을 등록할때 지정 했던 callback URL 로 이용하게 되는데요. 이동할때 URL 뒤로 추가적으로 필요한 정보들을 전달 받게 됩니다. 이 인증 절차를 통해 OAuthRequest가 가지고 있는 token 값은 이제 accessToken 을 접근 할 수 있는 인증권한을 갖게 됩니다.  

위의 callback URL 로 전달 되는 oauth_token값은 요청할때 전달했던 값과 같습니다. oauth_verifier값은 이 예제에서는 사용되지 않습니다. 다음 링크를 참조 하세요. 

3. 서비스 프로바이더에서 accessToken 을 받는다.

이제 인증의 마지막 절차 입니다. accessToken 을 받는 방법은 requestToken 을 받을때와 같습니다. 

4. 인증 끝. 

위의 과정을 통해 accessToken 과 accessTokenSecret을 갖게 되어 인증이 끝났습니다. 이제 oauthRequest값에 인증 값들이 모두 포함 되어 있기 때문에 이를 이용해서 api 호출을 하면 됩니다.

OAuth를 이용한 인증은 개념을 파악하면 간단하지만 처음 개념 없이 무작정 사용하기엔 어렵습니다. 서비스 프로바이더에 따라 OAuth 인증 실패 이유를 제대로 반환해 주는 곳도 있지만 한번 꼬이기 시작하면 어디서 잘못된건지 찾기도 힘든게 OAuth 인증 같습니다. 

웹상에서 Flash 로 Twitter 나 Dropbox 같이 OAuth를 제공하는 서비스를 사용하고 싶으면 서버에 Proxy를 만들어서 서버를 통해서 인증을 받아야 합니다. 클라이언트 단에서 인증이 가능한 서비스 제공 업체도 있겠지만, 대부분은 서버를 통해서 인증을 받아야 보안 제약을 받지 않습니다. 그래서 FLash 를 이용한 방법은 주로 AIR(Desktop, Mobile)에서 사용 가능 합니다. 

많이 사용 되는 Twitter API 는 tweetr (http://wiki.swfjunkie.com/tweetr)는 있지만, 인증에 문제가 있는지 잘못 쓴건지 제대로 동작을 하지 않아 따로 만들어 사용하고 있습니다. 검색을 해 보니 github에 Twitter API를 구현한 소스가 올라와 있는데요. 아직 구현중인걸로 보이네요; 

조만간 사용하고 있는 라이브러리도 정리 해서 공유해 보겠습니다. 

잘못된 점이나 궁금한 점이 있으면 댓글로 문의 주세요~

 ApplicationDomain 에 대한 개념만 잘 이해 하고 있다면, 이 포스팅은 보지 않으셔도 됩니다. 최근까지 ApplicationDomain 에 대한 개념 자체를 다르게 이해 하고 있어서 어렵다고 생각했던 부분들은 정리 합니다.

 Flash/Flex 를 사용하면서 가장 많이 사용하는 클래스중 하나는 Loader 일 것 입니다. Loader 클래스는 SWF 나, 이미지 (JPG, PNG 등등) 을 로드 하는데 사용 합니다. 많은 분들이 이미지를 로드 하는데 자주 사용하고 있을거라 생각 합니다. 외부에서 이미지를 로드 하면 로드된 리소스는 Bitmap 으로 처리가 되어 BitmapData 의 clone 메소드를 통해서 해당 이미지를 재사용 할 수 있습니다. 코드는 아래와 같습니다.

이미지는 위와 같이 재사용하면 되고, 이미지가 아닌 SWF 파일은 어떻게 재사용 할까요? 제가 사용한 방법은 ApplicationDomain 을 이용한 것 입니다. ApplicationDoamin 에 대한 자세한 내용은 다음 블로그에 잘 정리 되어 있으니 참고해 주세요.

 Loader 를 통해 외부 리소스를 로드 하면 해당 리소스는 load 메소드의 LoaderContext 의 ApplicationDomain 설정에 따라 새로운 ApplicationDoamin 또는 로드를한 객체의 ApplicationDoamin 에 정의가 저장 됩니다.

LoaderContext 에서 applicationDoamin 값을 (new ApplicationDoamin, ApplicationDomain.currentDoamin 등) 어떤 값으로 설정하는가에 상관 없이 로드된 외부 리소스는 자신의 ApplicationDomain 을 알 수 있습니다. 

 // 로드된 리소스 ApplicationDomain 알기
package {    

    import flash.display.Loader;    
    import flash.display.Sprite;
    import flash.events.Event;
    import flash.net.URLRequest;        

    public class ApplicationDomainTest extends Sprite {        

        public function ApplicationDomainTest()    {

            var loader:Loader = new Loader();
            loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loadCompleteHandler);
            loader.load(new URLRequest("TestAsset.swf"));    
        }

        private function loadCompleteHandler(event:Event):void {

            var swf:* = event.target.content;

            trace(swf.loaderInfo.applicationDomain);
        }
    }
}

이 ApplicationDomain 에는 로드된 자기 자신의 정의 들을 가지고 있기 때문에 해당 정의(클래스)를 불러와서 사용 할 수 있습니다. 예를 들어 아래와 같이 작성 되어 있는 외부 SWF 를 로드 한다고 하면 각각의 객체 정의 들은 불러 오는 방법은 다음과 같습니다. 

 // Main
package {    

    import flash.display.Loader;
    import flash.display.Sprite;
    import flash.events.Event;
    import flash.net.URLRequest;
    import flash.system.ApplicationDomain;

    public class ApplicationDomainTest extends Sprite {
        

        public function ApplicationDomainTest()    {

            var loader:Loader = new Loader();
            loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loadCompleteHandler);
            loader.load(new URLRequest("TestAsset.swf"));    

        }


        private function loadCompleteHandler(event:Event):void {
            var swf:* = event.target.content;
            trace(ApplicationDomain(swf.loaderInfo.applicationDomain).getDefinition("com.ddongkang.AssetLoader"));
            trace(ApplicationDomain(swf.loaderInfo.applicationDomain).getDefinition("com.ddongkang.Circle"));

            trace(ApplicationDomain(swf.loaderInfo.applicationDomain).getDefinition("com.ddongkang.List"));

        }

    }

}

getDefinition 으로 불러온 정의는 클래스 정의 이기 때문에 객체를 생성 할 수 있습니다. 

var circle:* = new ((swf.loaderInfo.applicationDomain).getDefinition("com.ddongkang.Circle"))();
addChild(circle);            
trace(circle); 

로드된 TestAsset.swf 는 AssetLoader, Circle, List 정의를 가지고 있기 때문에 컴파일 될때 해당 정의도 SWF 에 포함됩니다. 로드한 클래스는 TestAsset 이지만, TestAsset 이 가지고 있는 정의들이 같은 ApplicationDomain 안에 포함되어 있기때문에 이러한 접근이 가능 합니다. 여기서 SWF 자체인 TestAsset.swf 도 다음 코드를 통해 접근 가능 합니다.

// TestAsset 접근 

var asset:* = new ((swf.loaderInfo.applicationDomain).getDefinition("TestAsset"))(); 

주의할 점은 getDefinition 에 사용한 이름이 package 까지 포함된 이름이라는 점 입니다. getDefinition 을 통해 해당 클래스 정의에 접근 할때는 해당 정의가 ApplicationDomain 에 존재 하지 않을수도 있기 때문에 hasDefinition 를 통해 있는지 확인 후 접근해야 런타임 에러를 방지 할 수 있습니다.

            
     var applicationDomain:ApplicationDomain = loaderInfo.applicationDomain;
     if(applicationDomain.hasDefinition(name)) {
          return new (applicationDomain.getDefinition(name))();                
     }
            
     return null;
            
}

로드할 자원을 만들때, Flash Builder/ Flex Builder 를 사용할 경우 컴파일 된 자원 이름 (위의 경우에는 TestAsset.swf)이 클래스 이름(TestAsset)과 동일 하기 때문에 외부 리소스가 단일 자원으로 컴파일 될 때는 swf 이름으로 클래스를 접근해도 무방 합니다. 해당 swf 이름을 이용하여 Dictionary 를 만들어서 정의를 저장해 놓고 사용할 수도 있습니다. (http://mrdoob.com/blog/post/612) 

 하지만 Flash IDE 로 외부 리소스를 만들때는 반드시 Document 클래스를 지정하고 지정된 Document 클래스 이름을 통해 클래스를 접근해야 합니다. Flash/Flex Builder 에서 만든 리소스는 swf 자체가 클래스가 되지만 Flash IDE 에서는 Document 클래스로 연결이 안되어 있는 swf는 swf 자체가 클래스가 아니기 때문에(?) 정의를 불러 올 수 없습니다. 그러나Flash IDE 를 통해 Linkage 를 이용하여 클래스를 정의한 경우에는 Builder 에서 만들때와 마찬가지로 컴파일된 SWF 에 Linkage 를 통해 클래스화 된 객체 정보들을 가지고 있기 때문에 접근이 가능 합니다.  정리해 보면 다음과 같습니다.

로드한 자원 (클래스) 를 재사용하기 위해서는 로드된 클래스 이름을 알아야 한다는게 핵심입니다. 그 클래스정의는 로드된 swf 의 ApplicationDomain 안에서 있고 해당 클래스 이름을 통해서 가져 올 수 있습니다. 그리고 그 정의를 통해 new 를 통해 객체를 생성하여 사용 합니다.

잘못된 내용이나 개발 중 고민하고 있는 부분들은 댓글을 통해 공유 주세요~ 

 Flash Player 는 다양한 멀티미디어를 불러오고 재생 할 수 있다. 그 중에서 오디오 관련 파일은 기본적으로 MP3 파일을 재생 할 수 있으며, popforge (http://code.google.com/p/popforge/) 와 같은 라이브러리를 사용하면 WAVE 파일도 재생 가능 하다. 하지만 이 문서에서는 Actionscript3 에서 제공하고 있는 기본 API 를 가지고 파일을 불러오고 재생 하기 위한 기본적인 이론에 대해 다룬다.

 Flash 에서 오디오 파일을 재생 하기 위해서는 Sound, SoundChannel 를 사용한다. 디테일한 플레이어를 구현하기 위해서는 다른 클래스도 알아야 하지만 기본 기능만 만든다면 위 두가지 클래스의 레퍼런스만 봐도 충분히 구현 할 수 있다. 

Sound Class

 Sound Class 를 MP3 파일을 로드 하고 재생 하는 기능을 담당한다. 파일을 로드 하기 위한 load, 재생하기 위한 play, 재생을 끈어버리기(재생의 멈춤이 아니다) 위한 close 메소드 등을 가지고 있다. MP3 파일을 재생 하기 위해서는 다음과 같은 절차를 따라야 한다.

 오디오 파일을 로드 하는 방법은 URLLoader 나 Loader 에서 사용하는 방법과 동일하다. 다음은 위의 절차를 코드화 한 것이다.

package
{
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.IOErrorEvent;
	import flash.events.SecurityErrorEvent;
	import flash.media.Sound;
	import flash.net.Socket;
	import flash.net.URLRequest;
	
	public class SoundPlayerTest extends Sprite
	{
		private var _player:Sound;
		public function SoundPlayerTest()
		{
			_player = new Sound();
			_player.addEventListener(Event.COMPLETE, playerReadyHandler);			
			_player.addEventListener(IOErrorEvent.IO_ERROR, playerIOErrorHandler);
			_player.addEventListener(SecurityErrorEvent.SECURITY_ERROR, playerSecurityErrorHandler);
			
			_player.load(new URLRequest("remote/file/10cm_01.mp3"));
		}
		private function playerReadyHandler(event:Event):void 
		{		
			_player.play();
		}		
		private function playerIOErrorHandler(event:IOErrorEvent):void 
		{
			trace("로드에러");
		}
		private function playerSecurityErrorHandler(event:SecurityErrorEvent):void 
		{
			trace("보안에러");
		}
		
	}
}

 위와 같은 방법으로 로드를 하면 해당 파일에 대한 length 로 음원의 길이를 알수 있고, MP3 파일은 곡의 정보를 담고 있는 id3 태그를 가질수 있기 때문에 해당 파일에 id3 태그가 있다면 접근 할 수 있다. 기본적으로 접근 할 수 있는 id3 는 다음과 같다.

_player.addEventListener(Event.ID3, id3TagLoadHandler);
private function id3TagLoadHandler(event:Event):void 
{
	trace("album : "+_player.id3.album);
	trace("artist : "+_player.id3.artist);
	trace("comment : "+_player.id3.comment);
	trace("genre : "+_player.id3.genre);
	trace("songName : "+_player.id3.songName);
	trace("track : "+_player.id3.track);
	trace("year : "+_player.id3.year);
}

id3 태그에 대한 더 자세한 내용은 뒷부분에서 다루고 있다.

주의 해야 할 점은 새로운 파일을 로드 할때마다 Sound 객체를 새로 생성해 줘야 한다. 재사용할시 에러가 발생한다.

SoundChannel Class 

Sound Class 가 중요한 기능을 하고 있지만 모든 기능을 제공 하지는 않는다. SoundChannel Class 를 이용하여 사운드를 재생 하면서 디테일한 조작을 할 수 있다. SoundChannel Class 를 보면 다음과 같은 메소드와 속성이 정의 되어 있다.

위의 Sound 객체에 stop 메소드가 없고, SoundChannel 에 stop 메소드가 정의 되어 있다. 그 이유는 Sound 객체는 play 메소드를 이용하여 로드한 파일을 열어 주는 역할을 하고 SoundChannel 은 열린 파일 스트림에 대해 조작 역할을 한다.

load 메소드를 이용해 파일을 로드 하고 play 를 할때 play 메소드의 반환값으로 SoundChannel 객체가 넘어오므로 사운드를 조작 하기위해서는 이 반환객체를 조작 하여 사운드를 컨트롤 할 수 있다.

var channel:SoundChannel = new SoundChannel();

channel = _player.play();

일시 정지 및 재생 위치 변경

Sound Class 나 SoundChannel Class 나 모두 일시정지하는 메소드가 없다. 일시정지 기능은 SoundChannel 의 position 값과 Sound Class 의 play 메소드를 사용하여 구현 할 수 있다. 먼저 사운드를 일시 정지 할때 SoundChannel 의 position 값을 저장하고, 다시 재생 하면 Sound 의 play 메소드의 파라미터로 해당 position 값을 넘겨 줘서 사운드를 재생 하면 된다. 코드는 다음과 같다.

 
private function play(position:Number = 0):void 

{	
		
	_channel = _player.play(position);

}


private function pause():void 

{

	_channel.stop();

}

// 재생 버튼 클릭

private function playButtonClicked(event:MouseEvent):void

{

	play(_channel.position);

}

// 일시 정지 버튼 클릭		

private function pauseButtonClicked(event:MouseEvent):void

{

	pause();

}

재생 위치를 변경하는것도 위와 같은 방식으로 하면 된다. 단 play 할때 position 의 위치가 로드된 파일 길이보다 길면 재생이 안된다. 그러므로 Sound 객체의 length 보다 긴지 확인이 필요하다.

private function play(position:Number = 0):void 

{		

       if(position > _player.length)	
       { 
                 position  = _player.length; 
       }

       _channel = _player.play(position);

}

볼륨 변경

볼륨은 SoundChannel 의 soundTransform 을 이용한다. soundTransform 속성은 SoundTransform 객체 이다. 이 객체는 사운드 볼륨을 조작 하기 위한 여러 속성을 가지고 있다. 이 속성 중 volume 값을 변경 하면 된다. 값은 0 ~ 1 사이 이다.

var soundTransform:SoundTransform = new SoundTransform();

soundTransform.volume = 변경할 값;

_channel.soundTransform = soundTransform;

주의할 점은 SoundChannel 객체의 soundTransform 값을 직접 변경 하는것이 아니라, 새로운 SoundTransform 을 생성하여 값을 변경한 후에 적용해 주는 방식이다.

id3 태그

Adobe 에서는 Flash Player 10 부터 TLF( Text Layout Framework ) 를 제공하고 있다. 기존 TextField 를 사용하는 방식은 사용 방법이 편하긴했지만, 텍스트를 다루는데 기능적으로나 퍼포먼스 측면에서 부족한게 많았다.

TLF 에서는 이러한 단점들을 Text 를 다루는 Flash Player 의 low level 에 접근하는 프레임워크를 제공하므로 부분적으로 해결되고 있는 움직 임이다. 더 자세한 내용은 Adobe Labs - TLF 에서 확인 가능 하다.

사용 방법은 Adobe Labs 에 자세히 나와 있고, 한가지 주의할 점은 Flash CS5 에서 작업할때 Actionscript 3.0 Settings 패널에서 Runtime Shared Library Settings 가 Runtime shared library(RSL) 로 되어 있는데 이 설정은 textLayout.swc를 외부에서 불러와서 사용하기 때문에 외부 서버 상태에 따라 로딩 지연이 있을수 있으니 swf의 용량이 증가되더라도 Merged into code 로 바꿔 주는게 좋다.

문제는 TLF 를 사용한 프로젝트에서 loaderInfo 에 있는 FlashVars 를 접근할때 parameters 에 있는 값들이 null 로 인식 되는 버그가 있다. Main.swf 에서 TLF 를 로드하는 과정에서 loaderInfo 가 달라져서 발생하는 문제 인데 다음과 같은 방법으로 해결 가능 하다.

if (stage) {
	init();	
} else {
	addEventListener(Event.ADDED_TO_STAGE, init);	
}		

function init( e:Event = null ):void {

        var flashVars:Object = {};
	removeEventListener(Event.ADDED_TO_STAGE, init);
			
	if (parent != null && parent.parent != null) {
		flashVars = parent.parent.loaderInfo.parameters;
	} else {
		flashVars = this.root.loaderInfo.parameters;
	}
}

TLF flashvars bug : http://forums.adobe.com/message/3259520?tstart=0

Actionscript 3.0 의 Event Model 은 이벤트를 dispatch 하는 방식으로 이루어져 있습니다. 많은 클래스들이 클래스 내부적으로 "어떠한 행동"에 대해 이벤트를 외부로 알려주는 방식을 사용하고 있습니다. 예를 들어 Loader 클래스를 사용할때, 이미지나 파일들을 로드한 후에 Loader 클래스 내부적으로 이벤트 dispatch 가 일어나서 사용자나 개발자는 그 상황에 따른 후 처리를 할 수 있습니다.

import flash.display.Loader;
import flash.events.Event;
import flash.events.EventDispatcher;

var ld:Loader = new Loader();
ld.addEventListener(Event.COMPLETE, hnLoaded);

function hnLoaded( e:Event ):void{   
	// 로드끝
}

// Loader 내부
public class Loader extends EventDispatcher{
	public function Loader(){}
	private function loaded(){
		dispatchEvent(new Event(Event.COMPLETE));
	}
}

개발자들은 addEventListener 를 이용하여 내부적으로 dispatchEvent 되는걸 청취(addEventListener) 하고 있다가 반응이 오면 다운로드 된 데이터에 접근 가능 하게 됩니다. 이렇게 대부분의 AS3 이벤트 모델은 dispatch event 에 근거 하고 있습니다.

저도 AS3을 공부하고 초기에는 dispatchEvent 의 개념에 익숙하지 않아, 바보 같은 짓을 하곤 했는데요. 예를 들어 Event.ENTER_FRAME 으로 이벤트가 끝날때 까지 기다린다던지, Timer 를 이용하여 비슷한 방법을 사용하곤 했습니다. 

var ld:Loader = new Loader();
ld.addEventListener(Event.ENTER_FRAME, hnLoaded);

function hnLoaded( e:Event ):void{    
   // 로드끝
   if(ld.content) {

        // null 이 아니면 로드끝이라 판단
	ld.removeEventListener(Event.ENTER_FRAME, hnLoaded);
	
        // 로드후 후처리 로직 구현    
   } 
}

dispatch Event 는 그 밖에도 클래스의 재사용성에 대한 강점을 가지고 있습니다. 내부적으로 dispatch 되는 이벤트(행동)들을 addEventListener를 이용하여 청취하기만 하기 때문에 객체 유연성이 높습니다. 그 밖에도 여러 장점이 있지만, 자랑은 여기까지 하겠습니다.

dispatchEvent를 사용하지 않고 대안으로 사용할 수 있는 방법이 해당 행동에 대한 callback 메소드를 이용하는 것 입니다. Adobe에서 제공한 flashplatform optimizing content 문서를 보면 플래시 콘텐츠 최적화 방법중에 이벤트 구현을 dispatchEvent를 사용하기 보단 callback 을 사용하는게 더 효율적이라고 하고 있습니다. 이유는 여러가지가 있겠지만, 제가 생각하는 걸 나열해 보면 다음과 같습니다.

• dispatchEvent 가 일어났다는걸 알기 위해서 addEventLister 를 등록해야 한다.
  
• 너무 많은 addEventListener 사용은 메모리나 퍼포먼스에 영향을 줄수 있다.
  
• 너무 많은 addEventListener 사용 코드를 지져분 하게 한다. (개인적 취향입니다.)
  

그래서 그 문서에서는 dispatchEvent 를 사용하지 말고 callback 메소드를 전달하여 이벤트 후처리를 수행하는게 퍼포먼스에 이점이 있다고 말하고 있습니다. 아래와 같은 방식으로요.

var ld:LoaderCallback = new LoaderCallback(hnLoaded);

public class LoaderCallback extends EventDispatcher{
	private var _callback:Function;   
	private var _ld:Loader;    
	
	public function LoaderCallback() {
		_ld = new Loader();
		_ld.addEventListener(Event.COMPLETE, loaded);
	}    
	public function load(url:String,callback:Function):void {
		_callback = callback;       
		_ld.load(new URLRequest(url));
	}    
	private function loaded(e:Event) {
		callback(e);
	}
}

callback 메소드를 로드를 수행하는 LoaderCallback의 load 메소드에 파라미터로 넘기기 때문에 따로 addEventListener를 등록할 필요도 없고 이벤트 관리를 효율적으로 할 수 있습니다.

프로젝트를 하면서 고민했던 부분이 바로 이 부분이었는데요. 퍼포먼스를 생각하면 (그밖에도 여러이점이 있겠지만) callback 을 사용해야 하지만, dispatchEvent 를 이용하면 나중에 API 로 변경 했을때 추가 작업없이 바로 사용 할 수 있다는 장점 때문에 두가지 선택 사항에서 고민을 많이 하였습니다. 그래서 내린 결론은 addEventLister 등록을 최소한으로 하고 API 로서 기능을 수행할 가능성이 적은 클래스는 callback 를 사용하고 API 의 기능을 수행해야 하는 객체에는 dispatchEvent 를 사용하였습니다. dispatchEvent 도 일일히 각각의 이벤트를 등록하여 청취하는 방법이 아니라, 하나의 이벤트를 수신하여 커스텀 이벤트에 있는 type 으로 이벤트 유형을 판단 하도록 하였습니다.

아래와 같은 방법은 3번의 addEventListener를 해야 되지만

stream.addEventListener(StreamEvent.PLAY,hnStreamPlay);
stream.addEventListener(StreamEvent.STOP,hnStreamStop);
stream.addEventListener(StreamEvent.PAUSE,hnStreamPause);

public class Stream extends EventDispatcher{ 
	public function Stream(){}
        public function play():void { 
		dispatchEvent(new StreamEvent(StreamEvent.PLAY));
	}  
	public function stop():void {
		dispatchEvent(new StreamEvent(StreamEvent.STOP));
	}
	public function pause():void {
		dispatchEvent(new StreamEvent(StreamEvent.PAUSE));
	}
}

function hnStreamPlay( e:StreamEvent ):void{}
function hnStreamStop( e:StreamEvent ):void{}
function hnStreamPause( e:StreamEvent ):void{}

아래 방법은 한개의 등록만으로 처리가 가능 합니다.

stream.addEventListener(StreamEvent.ECHO,hnStreamEcho);

public class Stream extends EventDispatcher{ 
	public function Stream(){}       
	public function play():void {
		dispatchEvent(new StreamEvent(StreamEvent.ECHO,StreamEvent.PLAY));
	}
	public function stop():void {
		dispatchEvent(new StreamEvent(StreamEvent.ECHO,StreamEvent.STOP));
	}
	public function pause():void{
		dispatchEvent(new StreamEvent(StreamEvent.ECHO,StreamEvent.PAUSE));
	}
}
function hnStreamEcho( e:StreamEvent ):void{ 
	// StreamEvent 에 label 을 구현함    
	if(e.label == StreamEvent.PLAY){} 
	else if(e.label == StreamEvent.STOP){}
	else if(e.label == StreamEvent.PAUSE){}
}

개인적으로 두번째 방법을 더 선호 하는데요. 그때 그때 상황에 따라 선택이 중요한것 같습니다.

Flashplatform 개발 작업이 다른 언어에 비해 이벤트를 관리해야 되는 상황이 많은데요. 사용하기 편한것도 좋지만, 메모리나 퍼포먼스, 코드 가독성을 생각하여 판단하는 능력이 필요 하다는 생각이 드네요.

posted by dongkang

작년에 썼던 Javascript vs Actionscript 라는 글에서는 비교 관련 자료가 06년도의 Flash player 9 와 그때 당시의 브라우져를 대상으로 테스트한 것인데요. jacksondunstan.com 블로그에서 최근에 AS3 기반의 Flash player 10과 최근 브라우져의 Javascript 와 Performance 테스트를 한 포스팅이 있었네요. 아래는 테스트 한 결과 입니다.

참고 자료 :  AS3 vs Javascript Performance Test

                AS3 vs Javascript Performance Test Followup

외부 데이터를 불러 와서 TextField 에 넣어 줄때, 외부 데이터 문자 길이를 UI 에 맞게 잘러서 나타내는 경우가 있습니다. 기본적으로 String 클래스에서 제공하는 substr 등을 이용하여 문자열을 보기 좋게 자르는데요. 여기서 소개 하는 방법은 substr 과 TextField 의 getLineOffset를 이용하여 한정된 라인에만 글짜를 출력 하는 방법 입니다.

var field:TextField = new TextField();
field.width = 250;
field.wordWrap = true;
field.text = "안녕하세요.이것은 테스트 입니다.안녕하세요.이것은 테스트 입니다.안녕하세요.이것은 테스트 입니다.";
addChild(field);

위와 같이 width 값은 고정되어 있고 wordWrap = true 로 TextField 의 자동 줄바꿈이 설정 되어 있을때 getLineOffset 을 이용하여 원하는 최대 라인수 보다 넘어 갔을때 그 다음 라인의 첫번째 문자 인덱스 값을 가져온 뒤에 그 인덱스의 -2 만큼 String 값을 잘라 버리는 방식 입니다. getLineOffset 의 설명은 아래와 같습니다. 

var field:TextField = new TextField();
field.width = 250;
field.wordWrap = true;
field.text = "안녕하세요.이것은 테스트 입니다.안녕하세요.이것은 테스트 입니다.안녕하세요.이것은 테스트 입니다.";
cutNumLines(field,2);
addChild(field);
function cutNumLines( $field:TextField,$maxLen:int ):void{
	if($field.numLines-1 < $maxLen) return;
	
	var idx:int = $field.getLineOffset($maxLen);
	$field.text = $field.text.substr(0,idx-2)+"..";
}

위의 함수를 실행한 후의 결과는 다음과 같습니다.

 오랜만에 블로그를 둘러 보다 흥미로운 포스팅을 보았는데요. Actionscript 로 작업할시 숫자 타입의 int 를 사용을 자제 하라는 내용 입니다. 일반적으로 생각하면 int 가 Number 보다 크기가 작으니 int 로 처리 하면 더 빠르다고 생각하는 분들이 많으실텐데요. 이 포스팅에서는 여러 이유를 통해 부정 하고 있습니다.

이유 1. Number 를 사용하는게 int를 사용하는 것 보다 빠르다.

아래 코드를 실행 시키면 어떤 결과가 나올까요? 

public function timingTest() : void
{
	var intTime : Number;
	var numberTime : Number;

	var i : int;
	var j : int = 0;

	intTime = (new Date()).time;
	for (i=0; i<10000000; i++)
		j = (j + 15) / 7;

	intTime = (new Date()).time - intTime;

	var n : Number;
	var m : Number = 0;

	numberTime = (new Date()).time;
	for (n=0; n<10000000; n++)
		m = (m + 15) / 7;

	numberTime = (new Date()).time - numberTime;

	var message : String =
		"int version: " + intTime + "ms\n" +
		"Number version: " + numberTime + "ms";

	Alert.show(message);
}

  조금 의아해 할수도 있는데요. number 가 조금 빠르게 나왔습니다. 여기서는 조금한 차이지만 더 많은 루프를 돌리면 더 많은 차이를 낼 것 입니다. 일반적으로 number 가 더 많은 대역의 숫자를 커버 하기 때문에 연산할때 더 느릴텐데 왜 number 를 사용한 코드가 더 빠르게 나온걸까요? 

 j = ( j + 15 ) / 7;

 연산 비교에 사용된 코드를 보면 나누기 연산을 하고 있습니다. 이 나누기 연산이 number 가 더 빠른 연산 속도를 낼 수 있었던 이유 입니다. 연산이 이루어 질때 시스템은 내부적으로 int 범위 내에서 처리 할 수 없는 것은 number (double) 로 바꾸어 처리 하기 때문에 int - > number 로 변환 하는 처리 비용이 더 들기 때문에 number 가 더 빠른 결과를 낸 것 입니다. 

이유 2. Number 는 더 많은 bit 를 가지고 있다.

Number를 나타내는 데이터 format 은 아래와 같습니다. int 에 비해 더 많은 데이터 범위를 저장 할 수 있고 ( 12 ~ 63 ) 연산이 손실되는 데이터 없이 이루어 집니다. 그 만큼 오차를 줄여서 계산할 수 있다는 의미 입니다. 

실제로 + 연산이나 - 연산에서는 int 를 이용한 연산이 더 빠릅니다. 하지만, number 에 비해서 많이 빠르지 않습니다. 아래 결과를 보면 gskinner 가 "Types in AS3: ints not so fast, uints slow!" 포스팅을 통해 퍼포먼스 테스트를 한 결과 입니다. int 는 number 에 비해 많이 빠르지 않고, 느릴때도 있으니 차라리 데이터 손실 없이 연산이 이루어 지는 number 를 주로 사용하는게 좋다는 내용 입니다.  

가장 좋은 방법은 상황에 따라서 Number 와 int 를 골라 쓰는 건데요. 그 판단이 항상 좋을 수는 없으니, 잘 생각해서 써야 할 것 같습니다. 실제로 "Types in AS3: ints not so fast, uints slow!" 의 댓글에서 Number 의 연산 퍼포먼스가 휠씬 떨어 진다는 내용도 있었습니다. 그러면 언제 int 를 사용하면 좋을까요? 

아무리 여러 테스트가 있어도, 정답은 "상황에 따라 맞는 방법을 쓴다." 이네요.

목적 : 애플리케이션을 특정 구현으로 부터 분리시킨다. 객체를 만드는 일을 한다.

(크리에이셔널 패턴 : 생성과정과 관련된 패턴)

결론 : 팩토리는 구상 클래스가 아닌 추상 클래스/인터페이스에 맞춰서 코딩할 수 있게 해 주는 기법이다.

DisplayList 란?

DisplayList 란 SWF안에 존재 하는 객체들 중에 눈에 보이는 객체들을 총칭한다. 눈에 보이는 객체라고 하니 잘 이해가 안될수도 있으나, 간단하게 MovieClip 과 같이 addChild 를 통해 사용자에 눈에 보일수 있는 객체들을 뜻한다. 반면에 Date 클래스와 같은 객체는 단순히 시간에 대한 데이터를 처리 하는 객체 이므로 DisplayList 에 속하지 않는다. (빈 MovieClip 이나 Sprite, Shape 도 비어 있지만 모두 DisplayList 이다)

DisplayList의 3가지 요소

Flash Actionscript 에서는 이러한 DisplayList 구조가 아래와 기본 골격을 가지고 있다.

가장 상위에 Stage가 존재 하고 그 아래 MainTimeline 그리고 사용자가 만들어 내는 객체들로 눈에 보이게 되는 것이다. 그러면 어떠한 객체들이 "만들어지는 객체" 에 속하는 것인가? 바로 DisplayObject 와 DisplayObjectContainer 클래스를 상속받은 객체 들이다.

- DisplayObject : 화면에 표시 되는 객체 (Shape, Sprite, MovieClip, SimpleButton 등등)

- DisplayObject : 화면에 표시 되고 다른 객체들을 포함 할수 있는 객체 (Sprite, MovieClip, Loader 등등)

결국 SWF 안에 존재 하는 DisplayList 구조는 위와 같은 구조로 만들어 지게 된다.

DisplayList 구조의 장점

AS1.0, AS2.0 때 까지만 해도 위와 같은 DisplayList 구조를 가지고 있지 않았다. Flash CS3 이전 버젼에서는 MovieClip 이 거의 대부분의 객체의 기본이 되었고 그렇기 때문에 단점이 많았다. 하지만 위와 같은 DisplayList 를 가지게 되고 여러 장점을 가질수 있게 되었다.

- Shape, Sprite, MovieClip 등과 같이 객체가 다양해 져서, 효율적인 화면 구성을 할수 있다 되었다.

AS2.0 까지만 해도 MovieClip 만이 화면을 구성 하였으므로, 효율성이 떨어졌었다. 하지만, MovieClip 에서 타임라인을 제거한 Sprite 와 단지, 드로잉 기능만 가지고 있는 Shape 객체로 인해 좀더 효율적인 렌더링이 가능해 졌다.

Depth 개념에서 Index 개념으로 변화

AS2.0 까지는 객체의 위,아래 순서 개념을 Depth 개념이다. Depth 개념을 말 그대로 절대적인 깊이를 적용하여 z-index를 바꾸는 방식이었다. 예를 들어 mc 라는 객체가 depth 10에 존재 하고 mc2 라는 객체가 depth100에 존재 한다면 mc는 mc2 보다 아래 위치하게 되고 만약 영역히 겹쳐 졌을 경우에는 mc가 mc2에 가려 않 보인다. 여기서 중요한 점은 depth10 과 depth100 사이에는 아무것도 존재 하지 않아도 된다는 점이다. 빈 공간으로 둬도 상관없는 상태 이다. 하지만 AS3.0 부터 적용된 Index 개념에서는 조금 다르다. 항상 순서에 맞게 객체에 index 가 적용 된다. addChild 메소드를 통해 객체를 DisplayList 에 등록했다면, 제일 처음으로 등록한 객체는 index 0 을 할당 받고 그 다음은 1 다음은 2. .....7,8,9 등등 순서대로 할당 받게 된다. 순서를 가지고 있다는 점은 여러 가지 특징을 함께 가지고 있다는 뜻과 같다. 일상 생활에서 10개의 박스가 아래에서 부터 순서대로 쌓여 있다는 경우를 예로 들어 보면, 어떠한 사람이 제일 아래 있는 1 index 에 있는 박스를 가지고 간다면, 1 index 위치가 비게 되므로 위에 있는 박스들이 차례로 아래로 다시 쌓여 제 정렬 되게 됩니다. (1<-2 , 2<-3, 3<-4 등등) AS3.0 에서의 Index 도 같은 개념 이다.

Depth방식에 비해 Index방식이 효율적인 점

 첫번째로 Index방식은 객체에 순서를 부여 하므로 해서 부모 객체에서 자식 객체를 탐색할 때, 매우 빠르게 조회 할 수 있게 해준다. 아래 코드는 어떠한 DisplayObjectContainer 에 속해 있는 객체들을 탐색 하는 메소드 이다.

 두번째로 또 다시 일상생활의 예를 들어 보면, Depth 방식으로 책을 만드는 사람들과 Index 방식으로 책을 만드는 사람들이 있다고 하자. 두 사람 모두 150쪽 짜리 책을 완성 하였다. 하지만, 중간에 잘못된 부분을 발견하여 50쪽에 100쪽 분량의 내용을 삭제 하려고 한다. Depth 방식의 사람들은 엄청 고생을 해야 할 것이다. 왜냐하면 기존에 있던 100쪽 부터 150쪽까지의 분량을 일일히 앞으로 옮겨야 하기 때문이다. 하지만 Index 방식으로 책을 만드는 사람들은 옮기는 수고를 할 필요가 없다. 50쪽부터 100쪽까지 의 분량을 삭제 하면 알아서 100쪽에서 150쪽까지 있었던 분량이 알아서 정렬하기 때문이다. Actionscript 에서도 이 예제와 똑같은 원리가 적용 된다.

DisplayObject 와 DisplayObjectContainer

아래 구조도에서 볼수 있듯이 AS3.0 의 DisplayList 는 DisplayObject 와 DisplayObjectContainer 를 통해 만들어 진다. 자주 사용하는 MovieClip 이나 Sprite 의 속성중 x, y, visible, alpha 등등의 속성을 가지고 있는 것은 모두 DisplayObject 클래스를 상속 받았기 때문이다. DisplayObject 란 DisplayList (표시목록) 에 배치 할 수 있는 모든 객체의 기본 클래스 이다. 그러면 DisplayObjectContainer 는 무엇인가 아래 구조도를 보면 DisplayObjectContainer 가 DisplayObject의 상속을 받아서 만들어 졌다는 것을 볼 수 있다. 이 말은 DisplayObject 의 기능은 모두 가지고 있으면서 어떠한 것을 포함 할 수 있는 즉, addChild 와 removeChild 와 같은 DisplayObject 의 객체 컨테이너(바구니) 역할을 할 수 있는 객체들의 기본 클래스 이다.

DisplayObject

속성 및 메소드

http://help.adobe.com/ko_KR/AS3LCR/Flash_10.0/flash/display/DisplayObject.html

root / parent / stage 의 의미 알기

DisplayObjectContainer

속성 및 메소드

http://help.adobe.com/ko_KR/AS3LCR/Flash_10.0/flash/display/DisplayObjectContainer.html

Welcome to "Flash platform"

Flash platform 이란?

Flash 컨텐츠를 개발 하기 위한 방법은 여러 가지가 있다. Flash IDE (CS3, CS4) 를 이용하는 방법이나, Flex Builder 나 Flash Builder 를 이용하여 MXML 이나 Actionscript Project 를 컴파일 하는 방법, 또는 FDT 를 이용하여 컴파일 하여 SWF 를 생성하는 방법이 있다. 이 모든 Flash 컨텐츠의 결과는 SWF 형식으로 되어 있고 이러한 작업들은 Flash 컨텐츠 개발이라 한다. (곧 Flash Catalyst 가 정식 배포 되지만, 논외로 하겠다.)

얼마 전까지만 해도 Flash 와 Flex 의 네이밍은 따로 따로 존재 했다. 애초 부터 Flex Builder 라고 개발툴을 만들고, Flex 개발 방법을 강조해 오던 Adobe의 잘못으로 인해, Flex 를 새로운 툴이라고 생각하는 사람들이 많다. 하지만, Flex Builder 의 차기 버젼으로 준비되고 있던 Flex 4가 Flash Builder로 네이밍을 변경하여 나오게 되고, Flash IDE 와 Flash Bulder  그리고 Flash Catalyst 등을 이용하여 Flash 컨텐츠를 만드는 모든 것들을 Flash platform 이라고 통합 되었다.

Flash 와 Flex 그리고 AIR 는 무엇인가?

Flash 를 처음 시작 하는 사람이 가장 궁금해 하는 것이 "Flash 와 Flex 그리고 AIR가 무엇인가" 하는 것이다. 우선 AIR 에 대해 말하면 Flash player 와 같은 역할을 하는 환경을 말한다. Flash player 는 웹 브우저나, 모바일 디바이스에서 실시간으로 SWF 를 실행할 수 있는 환경을 제공해 주는데, AIR 는 데스크톱에서 Flash platform 환경에서 만들어진 어플리케이션을 설치하여 실행 시키는 환경이다. Flash player 와 같은 Runtime 환경이므로 Flash IDE 를 이용하여 만들든 Flex framework 를 이용하여 만들던 AIR 환경에서 돌아 가게 만들수 있다. 단 AIR 로 만드면 Flash player 에서 제공되지 않고, 제약 사항이 많았던 환경에서 벗어나서 여러 가지 장점을 가질 수 있다.

Flash 와 Flex 는 무엇인가? 많은 사람들이 Flash IDE (Flash 툴)로 만든 것을 Flash 컨텐츠라 하고 Flex Builder 로 만든 것을 Flex 컨텐츠 라고 알고 있다. 일부는 맞고 일부는 틀리다. Flex Builder 란 Flex framework를 구현하여 Flash 컨텐츠를 만들기 위한 툴이지만 Flex Builder 에서 Flex framework 를 사용하지 않고도 컨텐츠를 만들수 있다. 다만 Flex framework 를 사용하기에 편하게 만들어져 있다. Flex 란 단지 Framework 인데, 이 사실을 잘 알지 못하고 Flash 는 디자이너가 하는거고 Flex 는 개발자가 하는거다 라는 잘못된 생각을 가지게 된 것이고, Flash 와 Flex 가 전혀 다른 컨텐츠라고 생각하게 되는 오류를 발생한 것이다. 결론 적으로 Flash IDE와 Flex Builder는 같은 SWF 를 만들어 내는 툴이다. 다만 Flex Builder 는 Flex Framework 를 사용하기 쉽게 되어 있을 뿐이고 Flash platform 개발을 할때 코드를 짤 수 있는 비교적 편한 환경을 제공해 준다. (이클립스 기반으로 만들어져 있다.) 

Flash platform 개발언어인 Actionscript

Actionscript는 초기 Actionscript1.0 버젼을 시작하여, 현재 3.0 버젼까지 나왔다. Flash 버전 별로 나타낸 표는 다음과 같다.

위의 표와 같이 Actionscript 는 Flash player 의 변화에 맞추어 버전업을 하였다. 버전이 2단계 밖에 바뀌지 않았지만, Actionscript1.0 과 3.0 의 차이는 전혀 다른 언어라고 봐도 될 정도로 다르다. 이 때문에 디자이너나 비 전공자가 Actionscript3.0을 시작하기 어려운 이유이기도 하다. 하지만  그리고 AS1.0 , 2.0 과 AS3.0 은 스크립트를 해석하여 컴파일 하는 엔진 자체가 다르다. Actionscript는 AVM(Actionscript Virtual Machine)에서 돌아가는데, 1.0과 2.0 은 AVM1 에서 돌아 가고 3.0은 AVM2에서 돌아 간다. AVM2가 AVM보다 엄청나게 좋은 퍼포먼스를 내므로 AS3.0 은 1.0, 2.0에 비해 몇배에서 몇십배 백배 차이가 나는 퍼포먼스를 낼수 있다.

Actionscript 의 버전별 언어 형식은 다음과 같다.

Flash player 에 대해

 위와 같이 Actionscript 버전이 바뀌었다고 해서, 상위 버전의 Flash player에서 AS1.0과 AS2.0 을 실행할 수 없는건 아니다. Flash player 들은 하위 호환성에 맞게 제공 되고 있으므로, 버전에 관계 없이 실행 가능 하다. 하지만, Flash player의 하위버전 즉, Flash player 9 이전 버젼에서는 Actionscript3.0 으로 만든 Flash 컨텐츠를 실행 할 수 없다. 실행 했을때는 상위 버전의 Player 를 설치하라는 경고창이 뜬다. 

OpenCV란 무엇인가?

OpenCV 라이브러리를 이용하여 할 수 있는것?

OpenCV를 이용하면 영상처리 기술을 비교적 손쉽게 구현 할 수 있다. 입력과 출력 그리고 영상 처리에 대한 기본적인 기능들이 대부분 구현 되어 있다. 예를 들어 다음과 같은 작업 들을 할 수 있다.

OpenCV in Flash

OpenCV 라이브 러리를 Actionscript3.0 으로 컨버팅 하여 Flash 에서도 OpenCV 의 물건 인식 기능을 사용할 수 있게 되었다. Ohtsuka Masakazu 가 만든 이 라이브러리를 Marilenna 라는 프로젝트 명으로 Spark Project 에서 받아 볼 수 있다.

예제)
http://www.quasimondo.com/examples/face_detection/FaceDetector_Camera.html

http://www.francois-tarlier.com/blog/wp-content/uploads/2009/03/Marilena01/

flashvars.zip

package
{
    import flash.display.LoaderInfo;
    import flash.display.Sprite;
    import flash.text.TextField;
   

    public class FlashVarsExample extends Sprite
    {
        private var field:TextField;
        public function FlashVarsExample()
        {
            field = new TextField();
            field.autoSize = "left";
            addChild(field);
           
            var keyStr:String;
              var valueStr:String;
           
            var paramObj:Object = LoaderInfo(this.root.loaderInfo).parameters;
            for (keyStr in paramObj) {
                valueStr = String(paramObj[keyStr]);
                field.appendText("\t" + keyStr + ":\t" + valueStr + "\n");
            }
        }
       
    }
}

if(ExternalInterface.available){// 통신 실행}

if (ExternalInterface.available) {             
                output.appendText("Adding callback...\n");
                ExternalInterface.addCallback("sendToActionScript", receivedFromJavaScript);
                if (checkJavaScriptReady()) {
                    output.appendText("JavaScript is ready.\n");
                } else {
                    output.appendText("JavaScript is not ready, creating timer.\n");            
                }
               
            } else {
                output.appendText("External interface is not available for this container.");
            }

private function receivedFromJavaScript(value:String):void {
            output.appendText("JavaScript says: " + value + "\n");
        }

function thisMovie(movieName) {

         if (navigator.appName.indexOf("Microsoft") != -1) {

             return window[movieName];

         } else {

             return document[movieName];

         }

     }

package
{
	import flash.display.LoaderInfo;
	import flash.display.Sprite;
	import flash.external.ExternalInterface;
	import flash.text.TextField;	

	public class FlashVarsExample extends Sprite
	{
		private var field:TextField;
		public function FlashVarsExample()
		{
			field = new TextField();
			field.autoSize = "left";
			addChild(field);
			
			var keyStr:String;
  			var valueStr:String;
			
			var paramObj:Object = LoaderInfo(this.root.loaderInfo).parameters;
			for (keyStr in paramObj) {
				valueStr = String(paramObj[keyStr]);
				field.appendText("\t" + keyStr + ":\t" + valueStr + "\n");
			}			
		}		
	}
}

[PDF]AS2.0에서 AS3.0으로의 변화.pdf

문서 원본 : Adobe 기술문서
작성된 날짜 : 2009-05
저자 : 강동혁(동강)
저자 소개 : Daum communications 에서 UI 개발 업무를 하고 있으며, Flash 커뮤니티에서 ‘동강’ 이라는 닉네임으로 활동하고 있다. 뭐든지 사용하기 편해야 한다는 생각을 가지고 개발을 하고 있으며, 최근엔 새로산 자전거를 자주 못타고 다녀 아쉬워 하고 있다.

Flash를 하던 많은 사람들이 AS3.0이 나오고 나서 혼란스러웠던 이유는 두 가지이다.

첫 번째로 Flash에서 핵심이라고 할 수 있는 Display 객체생성을 정의하는 구조가 바뀐 점이고, 두 번째로는 사용자의 반응에 따라 이벤트를 발생 시켜 주는 이벤트 모델이 바뀐 점이다.

또한 AS2.0은 직관적인 문법이지만, AS3.0에서는 간단한 마우스 이벤트를 만들려고 할 때도 코드의 길이가 길어져 버려, AS2.0 사용자들에게 'Flash가 애니메이션 툴의 기능은 사라져 버리고 개발자를 위한 툴로 바뀌었다.' 는 원성을 듣기도 하였다.

하지만, AS3.0에서 코드를 길게 작성해야 이벤트를 만들 수 있다는 말은 AS3.0을 겉으로만 접한 사람들의 오해다. 오히려 AS3.0 은 이벤트 구조를 잘 설계하여 코드를 줄일 수 있고, 덩달아 SWF가 시스템에서 차지하는 메모리의 용량도 줄일 수 있는 장점을 안겨 주었다.

이번 장에서는 AS3.0이 AS2.0에 비해 어떤 점이 달라졌고, AS3.0과 하위 언어와의 호환성에 대해 이야기해 보겠다.

-Display 객체들의 다양화

Flash 8까지의 AS1.0과 2.0에서는 거의 대부분의 객체들은 MovieClip을 통해서 생성됐다.

여러 유형의 객체들이 MovieClip 객체 하나에 모두 포함됐기 때문에 불필요한 메모리와 시스템 리소스를 차지하는 원인이 되었다.

예를 들어 타임 라인이 필요 하지 않는 원을 만들거나, Flash에서 image를 불러와서 사용할 때도 MovieClip을 통해 객체를 만들었기 때문에, 만들어진 객체에는 항상 타임라인이 존재하였다. 이 타임라인이 불필요한 메모리를 차지했던 것이고, MovieClip에 있는 타임라인을 관리하기 위해 사용되었던 시스템 리소스가 증가하게 됐다. 하지만 AS3.0에서는 AS2.0에서 대부분 MovieClip으로 만들어졌던 Display List 객체들을 상황에 맞는 객체들로 만들 수 있도록 객체의 유형이 다양해졌다.

대표적인 유형은 MovieClip, Sprite, 그리고 Shape이다. Sprite는 MovieClip에서 Timeline을 제거한 객체이다. 타임라인을 제거하였기 때문에 MovieClip에 비해 메모리 및 리소스 사용을 줄일 수 있고, Timeline 외에는 MovieClip과 같은 속성 및 메소드를 가지고 있기 때문에 거의 비슷한 용도로 사용할 수 있다.

Shape는 Sprite와 비슷한 부분이 많다.(Graphics에 포함되어 있는 드로잉API를 이용할 수 있다.)

하지만, 자식 객체를 가질 수 없고 마우스 클릭 이벤트를 지원하지 않는 차이를 가지고 있다. Shape는 Sprite에 비해 오버헤드가 적고 Sprite가 지원하는 속성에 대한 메모리를 사용하지 않아도 되기 때문에 속도가 향상되고 메모리를 적게 사용한다.

그래서 마우스 이벤트가 필요없는 그래픽 객체를 만들고 싶을 때는 Shape를 사용하는 게 좋다.

각각의 객체를 하나씩 비교 한다면, 많은 차이가 없다. 하지만 객체의 수가 많아진다면, 덩달아 컴퓨터에 부담을 많이 주게 된다. 예를 들어 MovieClip과 Sprite가 컴퓨터 리소스를 차지하고 있는 양의 차이가 10이라고 하면, 이러한 객체들을 100개를 쓸 일이 생기게 되면 컴퓨터가 감당해야 할 리소스 부담은 MovieClip을 사용했을 때 Sprite보다 1000이 더 나게 된다.

덩치가 큰 프로그램에서 이러한 차이는 곧바로 퍼포먼스의 차이로 이어 지기 때문에, Timeline이 필요 하지 않은 객체는 Sprite로 정의 하는 습관을 가지고 있어야 한다.

- Display List구조의 변화

앞 절에서 자식 객체를 포함할 수 있는 객체는 Sprite이고, 포함할 수 없는 객체는 Shape라고 설명했다.

Sprite는 DisplayObjectContainer(표시객체컨테이너)이기 때문에 자식 객체를 가질 수 있고, Shape는 DisplayObject(표시객체)이기 때문에 자식 객체를 소유할 수 없다.

AS3.0에서 달라진 Display List의 구조는 DisplayObject를 기본으로 하여 구성된다.

SWF에서 사용자에게 보이게 되는 모든 객체들은 모두 DisplayObject 또는 DisplayObjectContainer의 상속을 받아서 만들어진 것이다. Display List의 구조는 아래와 같다.

그림 1 AS3.0의 Display List 구조도

 그림에서 볼 수 있듯이 MovieClip, Sprite, Shape 모두 DisplayObject의 상속을 받아서 만들어진다. 하지만, MovieClip과 Sprite는 DisplayObjectContainer의 속성을 한 번 더 상속 받기 때문에 자식 객체를 포함하는 속성을 가지고 있다.

자식 객체를 소유할 수 있다는 의미는 바구니가 되어 이것, 저것을 담을 수 있다는 의미이다.

DisplayObjectContainer의 상속을 받은 객체 만이 addChild(담기)와 removeChild(꺼내기) 메소드를 사용할 수 있다. AS2.0에서는 아래 그림과 같은 구조로 객체들을 정의 하고 있다.

그림 2 AS2.0의 객체 구조도

 객체들을 AS3.0과 같이 상속에 의해 구현한 것이 아니라, Object를 통해 직접적으로 구현하고 있다. 그만큼 직관적으로 구조를 이해 할 수 있다는 장점이 있지만, 객체의 속성을 중복 구현하여, 효율이 떨어진다는 단점이 있다.

새로운 Display List는 Flash의 가장 핵심이라고 할 수 있다.

Flash에서 사용되는 모든 기능들은 Display List를 통해 구현이 되고 사용되기 때문이다. 그 만큼 중요한 부분을 차지하고 있기 때문에 비교적 이해하기 어려운 내용을 담고 있다.

- 객체의 심도 관리 향상(Depth에서 index로)

Flash의 Display List에는 심도가 존재한다.

Layer와 별개로 같은 레이어 상에 존재하는 객체들도 위, 아래가 존재하여 위에 있으면 보이고 아래 있으면 위에 있는 객체에 가려서 안보인다. AS1.0과 2.0에서는 다음과 같은 메소드를 사용하여 객체의 위, 아래를 조절 하였다.

AS3.0에서는 Display List 구조가 바뀜에 따라, 위와 같은 메소드는 모두 아래와 같이 바뀌었다.

메소드 변경에 대한 더 자세한 내용은 Adobe에서 제공하는 AS2.0마이그레이션을 보면 자세히 기술 되어있다.

AS2.0에서 getNextHighestDepth()를 이용하여, 가장 높은 Depth를 할당하여 다른 객체들 보다 위에 위치하게 함으로서 사용자들에게 보이게 한다거나, swapDepths를 이용하여 이미 존재하고 있는 객체들의 Depth를 바꿔서 객체들끼리 가려지는 정도를 조절하였다.

AS2.0에서 적용되어 있던 심도 관리 개념은 Depth(깊이) 였지만 AS3.0에서는 메소드 이름 뿐만 아니라, 객체의 심도를 관리하는 개념 자체가 바뀌었다.

AS2.0에서는 Depth(깊이)개념을 사용하였다.

깊이란 순서가 없이 사용자가 지정한 깊이에 객체를 올려놓을 수 있음을 뜻한다. 사용자가 지정하는 깊이는 음수든 양수든 상관없고, 지정한 값들 사이에 빈 공간이 존재해도 상관없다. 아래 그림이 Depth의 특징에 대해 말해 주고 있다.

 

1) -1 depth부터 2 depth까지 객체들이 놓여 있다.

2) 100 depth에 객체를 추가한다. 100 depth는 추가되어, 존재하지만, 3~99depth까지의 공간은 빈 공간으로 남아 있다.

3) removeMovieClip()을 통해 1 depth에 있는 객체를 제거하면 1 depth는 빈 공간으로 존재하게 된다.

4) 2 depth에 객체가 있음에도 불구하고, 2 depth에 새로운 객체를 올려놓게 되면 기존에 있던 객체는 사라지게 된다.

 이렇게 AS2.0에서는 Depth로 절대적인 위치를 결정 하였다. 하지만 AS3.0에서는 Index라는 개념을 사용하여, 객체의 위치를 상대적으로 결정하도록 바뀌었다.

Index는 순서라는 의미이다.

Display List에 보여지는 객체들은 모두 순서가 부여 되고, 순서가 높을수록(숫자 크기가 클수록) 위에 위치하게 됩니다. 순서는 양수 값만이 가능하고, 0부터 차례대로 부여하게 된다. Depth처럼 2depth 다음에 100depth가 올 수가 없고, 빈 공간이 존재하지 않는다. 아래 그림이 Index의 특징에 대해 말해 주고 있다.  

1) 0 index부터 3 index까지 객체들이 놓여 있다.

2) 100 index에 객체 추가를 시도하였지만, 에러가 발생한다.

3) 1 index에 객체를 추가하니, 기존의 index들이 한 칸씩 위로 올라가며 재정렬된다.

4) 3 index에 있는 객체를 삭제하니, 4 index에 있던 객체가 3 index로 내려오며 재정렬된다.

이렇게 AS3.0에서는 index를 이용해 상대적으로 위치를 정하는 방식으로 변경하였다.

-Depth방식에 비해 Index방식이 효율적인 점

Index방식은 객체에 순서를 부여해서, 부모 객체에서 자식 객체를 탐색할 때, 매우 빠르게 조회할 수 있게 해 준다. 이 Index들은 단일 배열로 만들어져 getChildIndex() 나 getChildAt()으로 탐색하는 것을 도와준다. 예를 들어 다음과 같은 코드를 사용하면, 파라미터로 넘어온 객체의 자식객체에 대해 빠르고, 쉽게 알 수 있다.

 그에 비해 Depth방식은 깊이의 위, 아래는 있어도, 그 위, 아래 정보가 단일 배열로 정리가 되어 있지 않기 때문에 탐색에 오랜 시간을 소요된다. 예를 들어, 1쪽부터 200쪽 분량의 책이 있다고 가정해보자. 그런데 갑자기 계획이 변경되어 100쪽 부근에 50쪽 정도의 새로운 챕터를 넣어야 한다.

Index 방법에서는 우리가 현실 생활에서 대처하는 방법대로, 새로운 챕터는 101쪽부터 번호가 매겨지고, 뒤에 있던 내용들은 50쪽이 끝나면 이어져서 250쪽 짜리 책이 완성된다.

하지만 Depth 방식으로 하면 문제가 발생한다. 기존의 200쪽 분량의 책에 50쪽 분량의 새로운 챕터를 넣으려면 기존의 100쪽부터 150쪽까지가 새로운 내용으로 덮어 씌어지게 된다. 이런 상황을 막기 위해 미리 swapDepths()를 통해 100쪽부터 200쪽까지를 150쪽부터 250쪽까지로 옮기고 빈 공간에 새로운 챕터를 넣으면 되지만, 시간과 리소스 낭비가 많아지게 된다. 더구나, 여기에서는 50쪽만 추가하는 것이었지만, 이 50쪽이 100쪽이 될 수도 있고, 1000쪽이 될 수도 있다. 이와 같이 Index방식은 Depth방식에 비해 사용하기 편하고, 휠씬 효율이 높은 심도 관리 방법이라고 말할 수 있다.

- 이벤트 모델의 변화

Flash에서 중요한 부분을 차지하고 있는 이벤트 모델 역시 바뀌었다. 이전 버전의 AS에서는 이벤트를 처리하는 방법이 여러 가지가 있었다. 

AS2.0에서의 이벤트 핸들링 방법

- on() 이벤트 핸들러와 onClipEvent()핸들러 : 객체 안에 코드를 입력하여 해당 객체에 대한 이벤트를 발생시키는 방법이다. 쉽게 사용할 수 있지만, 객체 안에 있는 코드를 찾기가 어려워서 프로젝트 협업 작업에 어려움이 발생한다.

- 콜백 함수 이벤트 핸들러 : 객체. onRelease나 XML.onload와 같이 객체에 직접 콜백 함수를 등록함으로써 발생시키는 방법이다. 지정된 이벤트에 대해 콜백 함수 하나만 사용할 수 있다. 예를 들어 AS2.0에서 아래와 같은 코드를 실행하면 두 번째 콜백 함수만이 동작 하게 된다.

- 이벤트 리스너 : addListener()나 addEventListener()를 이용하여 발생시키는 방법으로 리스너 객체와 함수를 만든 후에 리스너를 등록해야 하므로 번거롭지만, 콜백 함수와는 달리 해당 이벤트에 여러 개의 리스너를 만들어서 모두 사용할 수 있다.

여러 개의 이벤트 처리 방식이 상황에 따라 사용되었지만, AS3.0에서는 하나로 통일되었다. 하나로 통일된 새 이벤트 모델은 DOM Level3 이벤트를 기초로 하고 있다.

이 DOM Level3 이벤트는 기존의 이벤트 모델보다 더 빠르게 이벤트를 발생시킨 객체를 찾아낼 수 있고, 그에 따른 이벤트를 호출해준다. 또한 이전 버전의 이벤트 모델은 이벤트 흐름을 가지고 있지 않았다. 무조건 이벤트를 발생시킨 객체만이 콜백 함수나 이벤트 리스너를 호출 할 수 있었지만, AS3.0에서는 이벤트 흐름에 연관된 객체들은 모두 이벤트 리스너를 호출할 수 있다. 예를 들어 그림 3과 같이 A, B 객체가 있고 B 객체에 마우스 이벤트를 등록했다면, A와 B 두 객체 모두 이벤트 흐름 안에 있기 때문에 이벤트 리스너를 호출할 수 있다.

AS3.0을 시작하는 분들이 시작부터 어렵다고 느끼는 이유 중 하나가 바로 이벤트 모델 때문이다.

AS2.0에서는 그림4 코드와 같이 단 3줄에 끝나는 것이 AS3.0에서는 이벤트 리스너를 추가하고, 이벤트 핸들러를 만들고, 이벤트 핸들러에 해당 이벤트(MouseEvent)에 대한 파라미터를 넘기는 작업을 해야 하기 때문에 비교적 복잡하게 보이기 때문이다. 하지만 사용해 보면 휠씬 효율적이라는 것을 느낄 수 있다.

AS3.0의 이벤트모델만이 가지고 있는 이벤트 흐름을 이용하여 복잡한 이벤트 발생 구조도 단순화 시킬 수 있으며, 이벤트 리스너의 등록과 제거 과정을 통해, 효율적인 메모리 관리와 객체지향 코드를 구현할 수 있다.

글을 마치면서

1부와 2부에 걸쳐서 AS3.0을 왜 사용해야 되고, 어떻게 사용해야 하는가에 대해 다루었다. 많은 사람들이 Flash platform을 도입하면서 Flash 시장도 많이 넓어 지고 있지만, 한간에서는 아직도 “Flash는 배너를 만드는데 사용하는 애니메이션 툴이다.” “Flash를 사용하면 느려진다.” 라고 생각하는 사람들이 있다.

하지만, 이러한 걱정들은 구시대의 산물이 되어 가고 있고, Flash platform이 단지 표현(User Interface)을 위한 수단만이 아니라, 표현과 퍼포먼스를 모두 만족시킬 수 있는 도구로서 나아 가고 있다.

AS3.0은 좀 더 사용자를 만족 시키기 위해 반드시 이용해야 하는 언어이다.

관련 문서: 왜 Actionscript3.0을 사용해야만 하는가?

package{                

	import flash.display.MovieClip;		
	import flash.display.Sprite;		

	/**	 * @author kang	 */		

	public class ResourceTest extends Sprite {		

		public function ResourceTest() {						

			var mc : MovieClip = new MovieClip();                        

			addChild(mc);			

			mc.addEventListener(Event.ENTER_FRAME, onEnterframeHandler);		

		}	
		private function onEnterframeHandler(event : Event) : void {			

			trace("execute event");		

		}	

	}

}

private function disposeMc(_mc:MovieClip):void{	
	if(_mc.parent != null)		
	_mc.parent.removeChild(_mc);		
	_mc = null;


}

addEventListener()메서드

public function addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void

이와 비슷한 경우가 MovieClip을 사용할때 발생할 수 있다. 예를 들어 다음과 같이 1~40frame까지 계속

 

루프를 도는 MovieClip이 있다고 하자. 이렇게 루프를 돌고 있는 도중 갑자기 이 무비 클립을 메모리 상에서 제거 하면 어떤 일이 발생 할까?? 결과는 위 ENTER_FRAME 이벤트에서와 같이 계속 루프를 도는 현상이 발생한다. 계속 루프를 돈다는 것은 그 만큼 CPU를 사용한다는 말이 되고, 메모리 낭비를 하고 있다는 말이 된다. 하지만, 이걸 인식 하지 못하고 그냥 MovieClip만 제거 하면 해당 무비 클립에 대한 모든 것들이 메모리 상에서 없어 진다고 잘 못 생각하고 있는것이다. 그러므로 위와 같이 MovieClip을 사용한 작업을 할때는 꼭 MovieClip을 stop() 해 준뒤에 메모리를 해제 해 줘야 한다. stop 해주지 않고 메모리를 해제 했다간, 모든 참조 값들이 사라 졌기 때문에 해당 타임라인을 멈출 수 있는 방법이 존재 하지 않는다. 

이러한 리소스 관리 문제는 위의 두가지 경우에만 국한된 것이 아니다. AS에서 제공하는 Sound 나 Loader를 이용한 이미지로드 및 SWF 로드 또는 Video 작업을 할때 모두 위와 같은 메모리 문제가 발생 할 수 있다. 이 사실을 항상 유념하고 Flash 작업을 해야 한다. 더 자세한 AS3에서의 메모리 관리 방법은 다음 링크를 통해 확인 하길 바란다. 

AS3: Resource Management

http://www.gskinner.com/blog/archives/2006/06/as3_resource_ma.html

http://www.gskinner.com/blog/archives/2006/07/as3_resource_ma_1.html

http://www.gskinner.com/blog/archives/2006/08/as3_resource_ma_2.html

예제다운로드

MemoryTest.zip

아무리 여러 테스트가 있어도, 정답은 "상황에 따라 맞는 방법을 쓴다." 이네요.

dispatchEvent(new Event("playheadreached");

this.addEventListener("playheadreached",headreachedHandler);


private function headreachedHandler(e:Event):void{

// 코드 실행
}

package {

	import flash.display.MovieClip;

	public class FrameTest extends MovieClip{
		public function FrameTest()
		{
			this.addFrameScript("29",onFrameHandler);
			
		}		
		private function onFrameHandler():void
		{
			trace("reached");
		}
	}
	
}