on 3:07 AM
기존에 제작 하였던 오토마타는 성능이나 표현상에 문제가 많아 다시 제작 하게 되었다
27
Mar
2010
09
Feb
2010
on 11:17 PM
28
Oct
2009
on 4:52 PM
1.concept
.크게 보면, ImageViewer와 ListViewer는 같은 Viewer이다.
2.구현사항
.screenMode Change 가능
.viewMode Change 가능
.drag, flick 가능
26
Aug
2009
on 7:17 PM
본인이 본 flash 관련 서적중 가장 수준있는 책들만 출간하는 Friends of ED 의 책중에서 눈에 띄는 책이 출간될 예정.
제목부터 ‘플래시 개발자를 위한 아이폰 어플리케이션 개발 필수 가이드’
그와 동시에 FITC Mobile 2009에서도 이런 발표가 있을 예정이다.
이쯤 해서 본인도 액션 스크립터를 위한 아이폰 개발 관련 포스팅을 올릴예정.
on 1:45 PM
정작현업에 있으면서 플래시가 아닌 영역에 대해서 무지한경우가 많다.
사실 협업하는데 있어서는 큰걸림돌 그렇다고 native담당자들이 FL을 이해하는 것도 아니구
자세하진 않지만 우리가 보내는 통신이 어떻게 native code상에서 보여지고 통신이 이루어지며 porting구조와 흐름도에 대한 이해도를 돕기엔 충분한 자료가 아닐까 생각한다.
자료는 COMMON>02_Library>FlashLite
20
Aug
2009
on 1:06 AM
var a:int;
var b:uint;
var c:Number
trace(a,b,c); //0 0 Nan
-> 이유 좀 알려주세요 ^^;
on 12:43 AM
IK에 대한 기본적인 Class를 만들었다.
기본적인 구조는
“점(Class)들을 생성할 때, 그 점들의 이웃이 되는 점들과 거리를 설정해주고, 이벤트가 일어난 점을 기준으로 자신의 이웃의 점들을 움직여 주어 유기적으로 작동한다”이다.
아직 적용해야 할 부분이 많다.
서로 다른 방향으로 점들이 향할 때, 기본 소스에서는 살짝 떨리는 느낌이 드는데, 이 부분을 부드럽게 넘겨주는 것이 첫번째 과제이다.
소스는 서버에 
->Common/IK/basic
on 12:19 AM
데코레이터 패턴(Decorator pattern)이란 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있다.[위키백과]
데코레이터 패턴의 구성요소
- 데코레이티드/데코레이터 인터페이스
- 구상 데코레이티드 클래스
- 추상 데코레이터 클래스
- 구상 데코레이터 클래스
상속을 하다보면, 변경할 사항이 증가할수록 요구되는 클래스의 수도 늘어나게 된다.
이를 보완하기 위해, 데코레이터 패턴을 사용하게 된다.
데코레이터 패턴의 핵심은 구상 데코레이티드 클래스를 구상 데코레이터 클래스에서 변수로 사용하고, 같은 인터페이스로 구현함으로써,
마치 구상 데코레이터 클래스가 구상 데코레이티드 클래스를 상속받은 것처럼 사용한다는 것이다.
이는, 상속이 아닌 합성을 사용하였지만, 상속처럼 흐름을 같이 한다는 뜻이기도 하다.
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 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 | //인터페이스 package com { public interface IWidget { function getDescription():String; function run():void } } //구상데코레이티드 클래스 package com { public class Widget implements IWidget { public function Widget() {} public function getDescription():String { return “Widget”; } public function run():void { trace(“running”); } } } //추상 데코레이터 클래스 package com { public class AbstractWidgetDecorator implements IWidget { protected var decorated:IWidget; public function AbstractWidgetDecorator( decoratedWidget:IWidget ) { decorated = decoratedWidget; } public function getDescription():String { return decorated.getDescription(); } public function run():void { decorated.run(); } } } 구상 데코레이터 클래스 package com { public class DigitalWidget extends AbstractWidgetDecorator { public function DigitalWidget(decorated:IWidget) { super(decorated); } override public function getDescription():String { var description:String = decorated.getDescription(); return “digital” + description; } } } |
14
Aug
2009
on 5:37 PM
모바일, 데스크탑을 막론하고 많이 쓰이는 컴포넌트의 형태는 List이다.
특히 List에서 데이터양이 많아졌을때, 그리고 데이터가 이미지와 같이 무거울때
최적화 하기위한 많은 방법들을 고민하게된다.
iPhone이나 iPod에서 Coverflow가 많은 데이타량에도 불구하고 원활하게 리스팅시켜주는 모습을 봐왔을것이다.
그래서 그 iPhone의 List에서 자원관리하는 방법을 소개한다.
MVC 디자인에 대해서는 많이들 알고 있겠지만 이를 List를 설계하는것으로 맵핑해보면..
Model은 리스트의 정보를 모아놓은 Array나 ArrayCollection, XML, XMLCollection 과같은 형태가 될것이다.
좀더 신경써서 만들었다면 Tree의 형태로 자료를 담고 있을것이고.
View는 데이타와는 완전히 별개로, 리스트를 보여주는 테이블 형태의 MovieClip이 된다. 물론 이 MovieClip은 더 작은 단위의 MovieClip의 집합이 될수도 있고.
Controller는 사용자의 인터렉션을 처리하는 클래스 또는 함수라고 할 수 있게된다.
iPhone의 UITableView 컨트롤은 MovieClip이라고 볼수있다. 그리고 사용자의 ‘선택’이나 ‘편집’등의 데이타에 접근하는 인터렉션이 아닌이상 스크롤과같은 이벤트는 UITableView 자체에서 해결한다.
데이타가 1,000,000개가 있다고 생각해보자. 이를 TextField, Bitmap객체에 담아서 모두 리스팅하고 스크롤하려면 아무리 좋은 컴퓨터라도 원활하게 동작하기 힘들다. DisplayObject의 속성을 건드리는 일은 매우 무거운 작업인것을 모두 알고 있듯.
이 방법에 문제가 있는것은 바로 Model과 View가 구분되지 않아서 생긴것이다. 100만개의 TextField에 모두 데이타를 담았다는것부터가 오류인것. 실제로 TextField나 Bitmap 객체는 눈에 보이는 갯수만 필요하다. 그 이상은 화면이 넘어가서 보이지 않고 퍼모먼스를 갉아먹는 좀벌래의 역활밖에 못한다.
따라서 Tree이든 Array이든 자료는 검색이 용이한 형태로 구조화하고 화면에는 최대로 필요한 View(여기서는 TextField, Bitmap)만 뿌려놓는다. 그리고 각 상황에 맞는 데이타를 View에 적용한다. 스크롤할 때에는 화면에 가려진 view를 다시 재활용을 하여 새로 보여질 view로 재활용하고, 여기에 적절한 데이타를 동적으로 심는것.
쉽게 생각하면 플래시 롤링 베너를 제작할때 화면에 가려진 이미지를 반대쪽에 이어 붙여서 루핑(Looping)를 만들어 내듯이, 한 화면에 보여질 수 있는 최대의 View만 생산해서 루핑을 시키고 내용물을 동적으로 변화시킨다는 개념이다. 그리고 자원이 된다면 View 개수를 조금 늘려주면 캐쉬나 버퍼를 만들 수도 있겠다.
iphone 개발시에는 실제로 UITableViewCell이라는 단위로 리스트가 관리된다. 그리고 각 Cell에는 id가 주어지고 새로 보여질 Cell이 필요할때 가려진 Cell중에서 하나를 골라 재활용하는 방식을 취하고 있다.
액션스크립트에 이를 반영하기 위해선 동적으로 데이터를 MovieClip에 담는것에 신경을 많이 써야 한다. 그러기 위해서 추가적으로 우리에게 필요한 스킬은 ‘빠른 검색’ 방법을 적용하는것. 그리고 적절히 캐시를 활용하는것이 될 수 있겠다. 이는 리스팅할 데이타의 형태나 정렬방법에 따라서 달라질 수 있다.
또한 스크롤바의 크기를 결정하는것은 MovieClip들의 높이에 의해서 결정되는것이 아니고 Model 데이타에 의해서 이루어져야한다. 이를 미리 예상해서 Model을 설계하는것이 스크롤바 문제를 발생시키지 않는 예방책.
05
Aug
2009