지난 1부에서는 PSD 가져와서 화면 기본 구성하는 것을 완성했다면 이번에는 게시판의 기본형태를 만들고 페이지를 만들어서 3부에 할 인터랙션/이펙트를 위한 과정을 해야 합니다. 만약 1부를 보지않고 이 페이지로 바로 오셨다면 1부를 보시고 다시 여기로 오셔야 합니다.
1부에 이어 계속 진행해 보겠습니다.
따라하기
아래와 같이 게시판에서 반복되는 부분들을 (아래의 라인까지) 선택해줍니다.
메뉴-Modify-Group을 선택하거나 Ctrl-G 또는 Command-G를 눌러 그룹을 만들어줍니다.
만들어진 그룹이 선택된 상태에서 화면에 둥둥 떠다니는 HUD Interface를 살펴보면 Group으로 바뀌어 있는 것을 확인할 수 있습니다. (HUD 인터페이스에는 그래픽 컴포넌트의 실제 사용할 컴포넌트로의 변환이나 간단한 State 정보 확인, 편집으로 바로가기등을 수행할 수 있습니다) 여기서 하단의 Convert Artwork to Component 를 클릭하고 DataList 컴포넌트로 변환해줍니다.
변환하면 Group이 Data List로 변경된 것을 확인할 수 있습니다. 우리는 이로써 매우쉽게 데이터를 리스트 형태로 반복하여 보여주는 DataList 컴포넌트를 만들게 되었습니다. 더불어 Component Issue 경고가 나타나는데 이것은 Data List 컴포넌트가 반드시 선택해야 하는 부분(플렉스4에서는 이것을 Part라 부릅니다)이 있다는 뜻 입니다. 이와같이 모든 컴포넌트가 그런것은 아니지만, 반드시 선택해야 하는 Part가 있을 수 있습니다. 그럴땐 이렇게 노란 이슈아이콘이 만들어 집니다. 이제 왼쪽의 Edit Parts 버튼을 클릭합시다
그럼 기존의 Group이 선택된 상태로 나타나는데 이는 플래시의 심볼안으로 들어온 것과 비슷하다고 생각하시면 되겠습니다. 여기서 Convert Artwork to DataList Part 콤보박스를 누르면 Repeated Item(Required) 가 나옵니다.
우리는 선택한 그룹을 반복시킬 것이므로 여기에 체크박스를 클릭합니다. 만약 다른 반복하길 원하는 아이템이 있다면 (ex:이미지) 그것도 함께 선택한 후 버튼을 누르시면 가능합니다. 그러면 아래와 같이 데이터가 반복되어 보여집니다.
원하는 사이즈로 적절히 조절해 줍니다. 저는 5개의 글을 보여주는 크기로 조절했습니다.
조금 전 심볼과 비슷하다고 말씀드렸는데, 플래시의 심볼편집 인터페이스와 동일합니다. 좌 상단에 DataList2라는 컴포넌트에 들어와 있는데 다시 Writeform을 클릭하여 메인으로 돌아갑니다.
DataList 컴포넌트가 선택되어 있는 상태로 창 아래에 위치해있는 DesignTime Data를 열어봅니다. 그러면 화면에 보여지는 디자인 작업을 위한 임의의 데이터가 보여집니다. 원하는 대로 아래와 같이 수정해 봅시다.
이제 거의 됐습니다. 지금까지는 List라는 State를 만들었으니 페이지 이름을 아래와 같이 더블클릭하여 List로 변경해줍니다.
그리고 보기 State를 만들기 위해 현재의 리스트 State를 아래의 Duplicate State버튼을 클릭하여 복사해줍니다.
그리고 복사된 State를 View 로 수정해줍니다.
View 스테이트가 선택된 상태에서 오른쪽 위의 Layers를 클릭하여 아래와 같이 눈 아이콘을 설정합니다. 잠김버튼은 메인,BG,Background를 설정합니다.
그리고 아래의 화면과 같이 되도록 이리저리 조절해 주고 마무리 합니다.
마지막으로 상단의 List, View 스테이트 버튼을 눌러보면 화면이 성공적으로 전환되는 것을 확인해 볼 수 있습니다. 여기까지 따라오시느라 수고하셨습니다.
이제는 지금까지 작성한 페이지에 생명력을 불어넣는 시간입니다. 수많은 디자이너 여러분 힘내세요!!
TRACKBACK ADDRESS : http://drumcap.com/trackback/76
IT 이야기 |
2010/02/16 00:19 |
Posted by 드럼캡
드디어 AIR 어플리케이션 for Android 가 MWC(Mobile World Congress)에서 발표되었습니다. 드디어
플래시/플렉스 개발자들이 아이폰용 어플리케이션 뿐만 아니라, 안드로이드용 어플리케이션도 동시에 개발할 수 있는 환경이 마련되었습니다. 이로써 어도비는 FlashCS5로 아이폰용 어플리케이션과 안드로이드용 어플리케이션을 동시에 배포할 수 있는 환경을 마련하면서 개발자들이 서로 다른 언어와 API를 익혀서 어플리케이션을 배포해야 하는 스트레스를 받지 않아도 되었습니다. 이러한 환경이 잘 다듬어 지면 정말 좋겠습니다. 2010년 상반기에 Flash Player 10.1이 런칭되고, 안정화 된 이후에 2010년 하반기에 AIR for Android가 런칭될 가능성이 큽니다. 이러한 이야기를 Adobe의 에반젤리스트
Ted Patrick이 예고하고 있습니다..
사실 모바일에서는 성능이 중요한 이슈인데, 모바일에 맞춰 CPU, 배터리, 메모리등을 최적화 했다고 했으니 (아마도 안드로이드에서는 플래시가 올라가는 형태이겠죠) 이건 뚜껑을 열어봐야 알겠지만 점차 개선되는 형태로 진행될 가능성이 높다고 보여집니다.
이미 예견된 일이었지만 이렇게 빨리 진행될 줄은 몰랐네요. 최근 어도비의 행보는 정말 마음에 듭니다. 애플의 스티브 잡스 덕이라 해야하나요? ㅋㅋ 잡스형 쌩유!!
TRACKBACK ADDRESS : http://drumcap.com/trackback/74
IT 이야기 |
2010/02/12 10:00 |
Posted by 드럼캡
현재 iPad에 플래시 플레이어 탐재에 관한 이슈가 떠오르면서 플래시 플레이어의 성능에 대한 관심이 많이 높아졌습니다. 어도비는 플래시 플레이어에 대한 성능향상과 모바일 탑재는 큰 테마로 준비해 오고 있었으며, 이를 증명하듯 Adobe MAX 09 (2009년 10월 개최된 어도비 기술 행사)에서 시연해 보이기도 했습니다.
이미 아는 사람들은 다 아는 내용이지만, 사람들이 잘 모르는 부분을 정리하자는 의미로 Adobe Labs의 Flash Player 10.1 Features 의 내용을 중심으로 정리해 드리겠습니다.
사실 10.1의 기능은 끝 버전 하나 올라간 것 치곤 꽤나 큰 업데이트 입니다. 사실 제 생각으론 Flash Player 10 메이저 업데이트에 맞춰 나와줬어야 하는 기능들 인데 개발 일정을 못 맞춰 이리 되었다 살짝 짐작해 볼 수 있습니다. 처음 Player10 에서 3D가 지원된다고 했을때 하드웨어 가속이 되는줄 알았다가 Ryan Stewart가 Flash Player는 제외라는 소리를 들었을때 엄청 실망했었던 기억이 납니다.
이번 버전의 큰 명분은 Open Screen Project의 첫번째 런타임 플레이어라는 것입니다. 인터넷 연결이 가능한 모든디바이스에 동일한 뷰 환경을 만들고 동일한 사용자 경험을 주자는 프로젝트인 Open Screen Project는 다양한 디바이스, 컨텐츠, 칩셋 회사들이 참여하고 있고 그 중심엔 어도비가 있습니다. 그럼 먼저 Labs에 나온 주요 업데이트 기능에 대한 내용을 확인해 볼까요?
1. Ubiquitous Reach (유비쿼터스에 접근)
2. Global error handling (전역 에러 핸들링)
3. Designed for mobility (모바일을 위한 설계)
4. Expanded options for high quality media delivery (고화질 미디어 전송을 위한 확장옵션)
이렇게 크게 4가지 인데 하나하나가 정말 엄청난 기능이 아니라 할 수 없습니다. 점점 플래시가 진화해 가고 있고 어도비가 이에 역량을 집중하고 있다는 것도 많이 느낄 수 있습니다.
1. 유비쿼터스에 접근
이것은 플래시가 다양한 기기에 설치될 수 있고 업데이트가 가능해졌다는 것을 의미합니다. 기존에 플래시 플레이어는 모바일이나 임베디드에 들어가려면 Flash Lite Runtime 이 별도로 올라갔고 액션 스크립트 코딩도 달리해야 했으며 메모리 관리를 특별히 신경써야 했습니다. 하지만 이제는 이런 것들을 신경쓰지않고 코딩해도 모든 디바이스및 환경에서 동일한 화면과 애니메이션을 볼 수 있게 됐습니다.
2. 전역 에러 핸들링
이 기능은 액션스크립트 개발자에게 환호를 받을만한 것입니다. 뭐냐면 지금까지 플래시 플레이어 디버거를 설치했던 유저들은 종종 런타임 에러 화면이 떴던 것을 발견했을 것입니다. 이벤트 기반으로 구성되어있는 플래시는 어쩔 수 없이 개발자가 코딩시 알아차릴 수 없는 런타임에러가 종종 발생하게 됩니다. 지금까지 개발자는 try/catch 문을 사용해 일일이 커스텀 에러 핸들링을 해줘야 했지만 이제는 전역 에러 핸들링을 설정해 주면 런타임 에러는 여기서 잡히게 됩니다. 개발자 분들 앞으로 편하겠죠? ^^
3. 모바일을 위한 설계
위에서 다양한 디바이스를 지원한다고 했는데, 그 중에서 모바일은 정말 중요합니다. 그리고 고려해야 할 것이 정말 많습니다. 요즘의 고사양 컴퓨터에서는 크게 문제가 되지 않았던 성능,메모리,배터리 등이 문제가 되기 때문입니다. 플래시는 모바일을 위해 메모리를 50% 이상 개선했고(Good!!!!) 하드웨어 그래픽 가속을 지원하며, 렌더링과 스크립팅, 배터리와 CPU를 최적화 했습니다. 또 멀티터치 제스쳐와 가속계, 화면 방향등을 지원하여 모바일 UI의 사용자 경험을 살렸습니다.
4. 고화질 미디어 전송을 위한 확장 옵션
이제 미디어는 점점 고화질로 넘어가고 있고 유튜브는 현재 1080p를 지원하는 서비스를
준비중입니다. 그렇다면 파일 전송은 가장 중요한 이슈가 됩니다. 일단 이부분을 해결하기 위해 여러가지 옵션을 추가했는데, 동영상 파일을 잘개 쪼개서 올리면 (툴이 있겠죠?) 그 정보를 가지고 HTTP로 스트리밍 해주는 것과, 동영상을 Flash Access2를 사용하여 유료 동영상 등의 컨텐츠 보호에 대한 옵션을 마련했습니다. 또 버퍼링 메커니즘 개선 및 RTMFP 프로토콜 기반으로 동료기반 네트워킹이 가능해 짐에 따라 다양한 대용량 미디어에 대한 대안기능을 마련해 둔 상태입니다.
이상을 정리해 보면 MAX09 에서 발표한 내용이 좀 더 눈에 잘 들어온다는 느낌이 드는데 이는 다음과 같습니다.
Flash Player 10.1 기능 리스트
1. Smartphone enabled (스마트폰에서 가능)
2. Multitouch, accelerometer, screen orientation (멀티터치, 가속계, 화면 방향)
3. Optimized memory, power, hardware acceleration (메모리와 파워 최적화, 하드웨어 가속)
4. HTTP video streaming (HTTP 비디오 스트리밍)
5. Content protection (컨텐츠 보호)
6. Peer assisted networking ( 피어 어시스트 네트워킹 - 동료 지원 네트워킹)
메모리 50% 감소효과
배터리 사용시간. 특리 Low Battery 모드 사용시에는 저대로라면 놀랍네요
아무튼 사실 모바일에서는 실체를 보기 전 까지는 확실히 모르지만 어도비도 그동안 게으르진 않고 열심히 준비해 온 것만은 분명합니다.
64비트 지원문제?
사실 저는 Mac OS의 Snow Leopard를 쓰기 시작하면서 64bit 운영체제의 잇점을 몸소 체험하고 있으며 이를 제대로 지원해 주지 못하는 플래시를 번번히 욕했었습니다. 윈도우도 64비트 OS를 설치하고 64비트 익스플로러를 실행하면 플래시는 보지를 못하니까요. 맥에서는 64비트 사파리에서도 플래시는 잘 돌아갑니다만 아래의 이미지와 같이 별도의 32비트 플레이어가 같이 돌아가는 형태로 구동됩니다. 한마디로 비효율 적이며 개발자로써 이 문제는 썩 유쾌하지 않습니다.
사파리는 64비트 플래시 플레이어는 32비트
단지 64비트 전환을 더디게 하는 것은 어도비의 의사결정 속도가 느리다는 점과 기술력이 떨어지는 것으로 생각했었지만, 사실 그렇지 않다는 것을 얼마전에 알았습니다. 지금까지 어도비는 64비트 플레이어를 리눅스에서만 릴리즈 버전만 지원 하고 있는데, 플래시 플레이어 개발자인
Tinic Uro는 그의 블로그에서 64비트 리눅스 버전을 발표했을 당시(2008.11) 이렇게
언급하고 있었습니다.
64비트 플레이어는 32비트 플레이어보다 빠르지는 않습니다. 32비트 플레이어가 최적화가 잘 되어 있기 때문입니다.
현재는 리눅스만 지원하고 있지만 향후에 윈도우와 맥 모두 지원할 예정입니다. (벌써 1년이상 넘었네요)
디버그 버전은 아직 지원하지 않을 생각이며 차후에 지원예정입니다. (이것도 아직 지원하지 않고 있습니다.) 지원하더라도 ActionScript 2.0은 디버깅이 되지 않는데 그 이유는 AS2는 32비트 포인터를 사용하기 때문입니다.
이로써 얼추 짐작해 볼 수 있는 것은 여러가지 부분(GPU지원, 웹캠, 마이크등등) 이 있겠지만, 그중에 바로 AS2의 지원에 관한 부분도 크게 한 몫 하고 있다는 것을 알 수 있습니다. 현재 플래시 플레이어는 AVM1과 AVM2가 동시에 구동되는 형태이며 이는 두개가 동시에 올라가 있는 형태로 매우 비효율 적입니다. 결국은 언젠가 없어질 기술인 AS2가 뒷덜미를 잡고 있는 것일 것이며 이는 아마 플레이어 버전 11쯤 되면 결국 AVM1을 없애지 않을까 조심스레 예측해봅니다. 언제나 성능과 최적화에 대한 이슈로 방망이를 맞고 있는 어도비로써는 갈길이 멀겠지만 오픈스크린 프로젝트를 성공적으로 런칭(버전 10.1) 하고 다음은 64bit 지원도 동시에 이루어져야 할 것입니다.
여담으로 현재 Mac OS용 플래시 플레이어는 기능개선이 많이 이루어진 상태이며 각 브라우저의 특성에 맞춰 기능개선이 이루어진 상태입니다. 마찬가지로
Tinic Uro 의 블로그에 최근 포스트 된 글을 보면 (이친구는 위에서 언급한 2008년 64비트 플레이어 포스팅 이후 이게 첫 포스팅입니다 ^^ 그만큼 바빴고 요즘 어느정도 플레이어 개발 일정이 정리되고 있다고 생각해도 될까요?) 현재 Full Cocoa 코드로 구성이 되어있으며, 사파리4 에서는 애니메이션 엔진으로 Mac OS의 Core Animation을 사용하게되어 비약적인 성능향상이 있습니다. 자세한 내용은 블로그의 포스트를 참고하세요,
[Core Animation 바로가기]
[참고 게시글]
댓글을 달아 주세요