일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- KGC 2013
- CLIK
- 강좌
- flash cs3
- 집합의 연산
- addChild
- scaleform4
- flash player 10
- Document Class
- 수학정석
- DataBinding
- 애드온
- 태그클라우드
- as3.0
- GDC
- as3
- 형변환
- 클릭
- scaleform
- flash
- as2
- scaleform3
- autodesk
- 스케일폼
- MMOKit
- Chart
- watch
- ApplicationDomain
- 샌프란시스코
- 플래시
- Today
- Total
scaleform.minarto.com
Actionscript 만으로 DataBinding 을 구현해보자 2 본문
2012/08/03 - [Communication] - Actionscript 만으로 DataBinding 을 구현해보자 0
2012/09/27 - [Communication] - Actionscript 만으로 DataBinding 을 구현해보자 1
흠... 작년에 썼던 글이라 현재의 코드와는 좀 많이 다릅니다...
현재는
github.com/minarto/minarto-scaleform4/blob/master/as3/src/com/minarto/data/Binding.as
이 코드를 보시면 됩니다.
1. DataBinding 은 어떤 의미가 있는가...
그동안 코드를 좀 변경했습니다.
github.com/minarto/minarto-scaleform4/blob/master/as3/src/com/minarto/data/Binding.as 에 코드를 올려두었습니다
DataBinding 코드를 단순히 CLIK 의 DataBinding 의 as 버전으로만 생각하시면 좀 많이 서운해서 보충설명을 좀 해보려고 합니다.
2. Proxy 동작
DataBinding 의 가장 큰 장점이 프록시로 동작한다는 것입니다.
디자인 패턴으로 치면 퍼사드 패턴이라고 할까요?
클라이언트는 UI Widget 이 로드되기를 기다렸다가 인보크 함수를 실행하는 것이 보통들 사용하는 기존의 CLIK 방식입니다.
UIComponent 의 enableInitCallback 값이 true 라면 위젯이 로드되는 순간 CLIK.queueInitCallback 함수를 이용해서 클라이언트에게 해당 UIComponent 의 이름, staget로 부터의 경로, 객체포인터를 던지게 됩니다.
보통의 경우 클라이언트는 해당포인터 또는 경로를 이용해서 인보크 함수를 실행합니다...
하지만 이제 그럴 필요가 없습니다.
제가 만든 DataBinding 은 객체 내부에 캐시처럼 값을 가지고 있습니다. 바인딩되는 핸들러나 set/get 함수들은 그 캐시된 값으로 동작을 하죠.
null 값을 넣는다던가 일부러 따로 값을 지우지 않는한 그 값은 계속 가지고 있게 됩니다. 그러다가 바인딩이 걸리는 순간과 값이 바뀌는 순간만 그 값을 사용할 뿐입니다.
클라이언트는 해당 위젯에 대해서 전혀 알 필요가 없습니다. 특정한 인보크 함수를 정할 필요도 없죠.
그러다 보니 로드된 UI 위젯이 없어도 됩니다. UI 위젯은 나중에 로드되었을 때 알아서 동작하죠.
UI 개발자가 마음대로 UI Widget 을 로드하고 언로드 해도 아무런 문제가 발생하지 않는다는 뜻입니다.
이러면 어떻게 될까요... 예를 들어보죠...
아이템 제작이나 경매는 마을에서만 된다고 쳐보죠. 그렇다면 캐릭터가 마을에 들어갔을 때만 해당 UI를 로드했다가 필드에 나와 전투를 할때는 언로드해버릴 수도 있을겁니다.
그렇게 되면 전투시에 필요한 UI 이외에는 모두 없애버릴 수 있으니 메모리 점유율이 내려갈 수밖에 없습니다. 반대로 마을에서는 전투와 관련이 없는 메모리 낭비가 없어지죠.
3. 불필요한 Invoke 함수
또 하나의 장점은 서로 인보크 함수를 정의할 필요가 없다는 겁니다.
앞선 글에서는 극도로 인보크 함수 사용이 적어진다고 말했으나, 사실 아예 필요 없습니다.
인보크 함수를 정의하지 않으니 테스트할 필요도 없습니다. 클라이언트와 UI 개발자가 서로 맞춰야 할 것은 String으로 된 key 값일 뿐입니다.
예를 들어 캐릭터가 가진 금액을 날려준다고 쳐보죠.
mmorpg에서 보통 금액은 인벤토리UI 에도 있고, 경매UI 에도 있고, 상점UI 에도 있습니다. 더 많은 곳에 있을 수도 있겠죠. 만약 이걸 인보크 함수로 setMoney(100000) 이런 식으로 정해서 통신을 했다면 클라이언트와 UI 간에 세번 이상의 통신이 일어나야만 합니다.
그뿐만이 아니죠. 각각 테스트도 따로 해야 합니다.
이걸 DataBinding 으로 바꾼다면 클라이언트가 DataBinding.setValue("mc.money", 100000); 이렇게 한번만 통신해주면 됩니다.