* 글의 길이가 길어짐에 따라, 2부에 이어, 별도로 3부를 이어서 진행합니다. 2부는 여기에서 보실 수 있습니다.
Data/Service
Adobe Flahs Platform이 RIA라는 명칭을 얻게 된 계기는 웹에 있는 자원과 통신을 하게 된 것이 시초라고 해도 과언이 아닐것입니다. Flash가 웹에 있는 정보를 불러와, 사용자에게 제공함으로써, 단순한 동적인 애니메이션 플레이어가 아닌, 정보를 제공할 수 있는 UI/UX의 새로운 돌파구로 까지 변모하게 되었습니다.
Flex에는 웹의 자원과 통신을 하기 위해, HTTPSerivce, WebService, RemoteObject와 같은 RPC 서비스와, LCDS와 통신할 수 있는 데이터서비스를 지원하고 있습니다.
하지만, 애플리케이션을 개발할때 마다 매번 웹과 통신하는 부분을 백앤드, 프론트앤드에 나눠 코딩해야 햐기 때문에, 실제 코딩에서는 만만치 않은 분량을 차지하게 됩니다.
(실제로, 이러한 작업을 줄이기 위해 mysql과 바로 데이터 통신을 할 수 있는 asql 프레임워크도 있지만, 백앤드와는 달리, swf파일은 리버스엔지니어링을 통한 디컴파일이 가능하기 때문에 권장하지 않습니다.)
어도비에서는 이처럼 웹의 자원과 통신하는 부분의 코딩을 자동화 해주는 기능인 스캐폴딩을 Flex3에서도 도입했으나, 로컬의 데이터베이스를 직접 불러와서 백앤드의 코딩으로 생성해 주기 때문에, 반응은 다소 좋지 않았습니다.
Flex Builder Gumbo에서는 Flex3의 스캐폴딩 기능의 단점을 보안한 Data/Services가 새롭게 추가되었습니다.
Data/Services가 플렉스3의 "Create Application from data Services"와 다른점은, 백앤드에서 작성된 규칙에 맞게 클래스를 자동적으로 생성 해 주기 때문에, 로컬의 데이터베이스가 필요가 없으며, 백앤드 개발자와도 조금 더 효율적으로 협업할 수 있습니다.
또한, ODBC/백앤드 언어로 스캐폴딩 되었던 기존의 플렉스 3와는 달리, Flex의 데이터 통신 방법을 기준으로 스캐폴딩 되기 때문에, 백앤드 언어의 제약 없이, 스캐폴딩을 할 수 있습니다.
Flex Builder Gumbo에서 현재 지원되는 Data/Services는 HTTPService와 WebSerivce 두종류이지만, 정식버전에서는 콜드퓨전의 차기버전인 "Spark"를 이용한 스캐폴딩도 지원될 예정입니다.
위의 그림처럼, 생성될 서비스명이나, URL등을 지정해 주면
자동적으로 웹과 통신하는 클래스들이 생성됩니다.
이 클래스들을 활용하여, 개발을 진행 할 수 있습니다.
아울러, 위의 클래스를 활용하여, 자동적으로 데이터 그리드를 생성해주는 기능도 추가되었습니다.
디버깅환경의 변화
애플리케이션 개발 과정 중 코딩 보다 어쩌면 디버깅이 더 많은 작업분량을 차지한다고 해도 과언이 아닙니다. 그 만큼 버그없는 완벽한 애플리케이션을 개발하려면 코딩은 필요조건 디버깅은 충분조건이라고 볼 수 있겠네요.. ^^
Flex Builder Gumbo에서는 조금 더 편리하게 디버깅 할 수 있도록, 새로운 기능들이 추가되었습니다.
건너 뛰기
디버깅을 하면서, 개발자가 가장 두려워 하는 부분이 for문과 같이 계속 반복되는 구문에 브레이크포인트가 걸려있을 경우가 아닐까 생각됩니다. ^^;; 이 경우 브레이크 포인트를 해제해야 무사히 넘어갈 수 있겠죠?
이외에, 디버깅 상황에 따라 필요없는 브레이크 포인트를 만난다거나, 브레이크포인트가 걸려있지 않은 곳으로 이동하고 싶은 경우가 생길 수 있습니다.
Flex Builder Gumbo에서는 이러한 상황을 위해(?), 라인건너뛰기 기능을 지원합니다. 브레이크포인트가 걸려있는 상황에서 건너뛰고 싶은, 라인에서 오른쪽 버튼을 눌러 Run to Line를 클릭하거나, Ctrl+R을 눌러, 해당 라인으로 건너뛸 수 있습니다.
(사실 이런기능이 이전버전 부터 지원했어야하는데.. 라는 아쉬움도 남습니다.. ㅎㅎ)
컨디션 브레이크포인트
위의 상황처럼 디버깅을 진행하면서 반복된 구문을 계속해서 돌고 있는데, 브레이크 포인트가 걸려있다면, 반복 과정중 무시할 수 있는 경우의 수에서도, 브레이크가 걸리게 됩니다.
따라서, 이런 경우에는 if와 같은 조건문으로, 브레이크를 조절 할 수 있지만, 조건문의 설정으로 애플리케이션에 예상하지 않은 문제가 발생할 수도 있습니다.
Flex Builder Gumbo에서는 브레이크 포인트가 브레이크 걸리는 조건을 제한을 둘 수 있는 컨디션 브레이크가 새롭게 추가되었습니다.
예를들어 위의 애플리케이션은 350ms마다 ontimer가 디스패치 되고, 디스패치 될때마다 '잇힝~'이라는 문자열을 콘솔에 출력하게 됩니다.
만약, '잇힝~'이 세번 출력될 경우 브레이크가 걸리도록 지정하고 싶다면, 브레이크 포인트를 걸어두고, Breakepoint Properties에 들어가면,
위의 그림처럼, 브레이크 포인트를 설정 할 수 있는 창이 나타나게됩니다. 이 창에서 브레이크포인트가 걸리는 조건을 설정 할 수 있는데, 컨디션 조건문은 if의 조건문과 같이 설정 할 수 있습니다.
그리고, 컨디션 조건문의 브레이크가 걸리는 경우를 설정 할 수 있는데, 컨디션 조건문이 true이거나, 컨디션 조건문의 상태 변화가 있을경우로 지정할 수 있습니다.
컨디션 브레이크포인트를 지정하게 되면, 일반 브레이크 포인트와는 달리, 브레이크 포인트 위에 물음표가 나타나게 됩니다.
컨디션 브레이크포인트를 지정하고 테스트한 모습입니다. 콘솔창에 '잇힝~'이라는 문자열을 3회 출력한 후에 브레이크 포인트가 걸리게 됩니다.
컨디션 브레이크포인트를 적절히 잘 활용하면, 디버깅 과정중 반복문도 경우의 수에 따라, 조건에 마침맞게 디버깅 할 수 있습니다.
Unit Test 지원
개발자는 애플리케이션을 개발 하는 과정 중, 디버깅을 통해 애플리케이션의 버그를 해결할 수 있습니다. 이후, QA팀이 있는 조직일 경우, QA팀에서 애플리케이션의 문제점을 날카롭게 살펴보게 됩니다.
이러한 QA테스트 이전에, 개발자가 기계적으로 여러 조건을 걸어두어 해당 애플리케이션을 테스트 할 수 있습니다. 이러한 테스트를 유닛테스트(Unit test)라고 하며, Java에서는 JUnit라는 프레임워크를 통해 Unit Test를 할 수 있습니다.
어도비에서는 플래시/플렉스 애플리케이션에서 이런 유닛테스트를 할 수 있도록, FlexUnit 프레임워크를 개발하여 배포하고 있습니다. FlexUnit는 오픈소스(New BSD)이며, JUnit와 기능적으로 거의 흡사합니다. 다운로드는 여기에서 할 수 있습니다.
Flex Builder Gumbo에서는 위에서 설명한 Flex Unit 프레임워크를 기본적으로 포함하고 있고, 손쉽게 유닛테스트를 할 수 있도록 지원하는 기능이 추가되었습니다.
Unit Test를 하기 위한, Test Case Class와 Test Suite Class가 File의 New 탭에 추가 되었습니다. Test Class를 생성하게 되면, FlexUnit 프레임워크가 자동적으로 임포트됩니다.
위의 그림처럼, TestCase를 추가 할 수 있습니다. 패키지명은 Test Class가 생성될 패키지 위치로, 변경 할 수 있습니다. 그리고, Select Class to test를 선택해, 테스트할 클래스의 탬플릿을 자동적으로 생성 할 수 있습니다.
Test Class를 생성하게 되면, 디버깅 버튼 하단에 Execute Flexunit Tests 탭이 나타나게 됩니다. 이 탭을 누르면,
Test Class에서 지정한 조건에 맞게 유닛 테스트를 시작하게 됩니다.
Flex Unit 프레임워크는 Unit 테스트 결과를 플래시 형태의 Test Runner로 결과를 보여주기 때문에, Flex Builder Gumbo의 Flex Unit Result View 탭 이외에도 인터넷 창에서 Unit Test의 실행결과를 알려주게 됩니다.
Unit Test를 적절히 활용하면, 개발 과정중 예기치 않은 문제들을 조기에 발견 할 수 있고, 또 기계적으로 테스트를 진행할 수 있어서 큰 노력없이 애플리케이션의 테스트를 할 수 있습니다.
지금까지 1년여에 이은, Flex Builder Gumbo 살펴보기 시리즈를 모두 마칩니다. Flex Builder "Gumbo"는 올 H1중에 퍼블릭 베타가 예정중입니다. 퍼블릭 베타는 아래의 경로에서 신청할 수 있습니다.
Flex Builder Gumbo 퍼블릭 베타 신청하기
그럼 이어서 더 좋은글....로 찾...아뵐려고 하는데
어랏?
뭔...가 거시기한걸 깜빡한것 같은데(?)
Flash Catalyst 지원
Flex Builder Gumbo에서는 그간 코드네임 Thermo로 알려진 Flash Catalyst를 공식적으로 지원합니다.
Flash Catalyst는 개발자-디자이너간 중계자 형성 툴로, MS의 익스프레션 블렌드와 다소 흡사한 성향을 가지고 있습니다.
디자이너는, 자신이 디자인한 결과물(일러스트레이터, 포토샵) 파일을 Flash Catalyst로 불러와, 컴포넌트의 역할, 사용자의 인터렉션이나 화면 전환등을 지정 할 수 있고, 완성된 결과물을 개발자에게 전달하여 프로젝트에 바로 활용 할 수 있습니다.
Flex Builder Gumbo에서는 Flash Catalyst로 작업된 결과물(FXP포맷)을 불러와 바로 개발 할 수 있도록 지원하며, 개발 과정중 디자이너가 UI나 UX를 바꿀경우에도, FXP포맷을 불러와 리팩토링 하는 기능을 지원하고 있습니다.
그럼 이 글에 이어서, 3부에 걸쳐 Flash Catalyst에 대해서 자세히 살펴보겠습니다.
Data/Service
Adobe Flahs Platform이 RIA라는 명칭을 얻게 된 계기는 웹에 있는 자원과 통신을 하게 된 것이 시초라고 해도 과언이 아닐것입니다. Flash가 웹에 있는 정보를 불러와, 사용자에게 제공함으로써, 단순한 동적인 애니메이션 플레이어가 아닌, 정보를 제공할 수 있는 UI/UX의 새로운 돌파구로 까지 변모하게 되었습니다.
Flex에는 웹의 자원과 통신을 하기 위해, HTTPSerivce, WebService, RemoteObject와 같은 RPC 서비스와, LCDS와 통신할 수 있는 데이터서비스를 지원하고 있습니다.
하지만, 애플리케이션을 개발할때 마다 매번 웹과 통신하는 부분을 백앤드, 프론트앤드에 나눠 코딩해야 햐기 때문에, 실제 코딩에서는 만만치 않은 분량을 차지하게 됩니다.
(실제로, 이러한 작업을 줄이기 위해 mysql과 바로 데이터 통신을 할 수 있는 asql 프레임워크도 있지만, 백앤드와는 달리, swf파일은 리버스엔지니어링을 통한 디컴파일이 가능하기 때문에 권장하지 않습니다.)
어도비에서는 이처럼 웹의 자원과 통신하는 부분의 코딩을 자동화 해주는 기능인 스캐폴딩을 Flex3에서도 도입했으나, 로컬의 데이터베이스를 직접 불러와서 백앤드의 코딩으로 생성해 주기 때문에, 반응은 다소 좋지 않았습니다.
Flex Builder Gumbo에서는 Flex3의 스캐폴딩 기능의 단점을 보안한 Data/Services가 새롭게 추가되었습니다.
Data/Services가 플렉스3의 "Create Application from data Services"와 다른점은, 백앤드에서 작성된 규칙에 맞게 클래스를 자동적으로 생성 해 주기 때문에, 로컬의 데이터베이스가 필요가 없으며, 백앤드 개발자와도 조금 더 효율적으로 협업할 수 있습니다.
또한, ODBC/백앤드 언어로 스캐폴딩 되었던 기존의 플렉스 3와는 달리, Flex의 데이터 통신 방법을 기준으로 스캐폴딩 되기 때문에, 백앤드 언어의 제약 없이, 스캐폴딩을 할 수 있습니다.
Flex Builder Gumbo에서 현재 지원되는 Data/Services는 HTTPService와 WebSerivce 두종류이지만, 정식버전에서는 콜드퓨전의 차기버전인 "Spark"를 이용한 스캐폴딩도 지원될 예정입니다.
위의 그림처럼, 생성될 서비스명이나, URL등을 지정해 주면
자동적으로 웹과 통신하는 클래스들이 생성됩니다.
이 클래스들을 활용하여, 개발을 진행 할 수 있습니다.
아울러, 위의 클래스를 활용하여, 자동적으로 데이터 그리드를 생성해주는 기능도 추가되었습니다.
디버깅환경의 변화
애플리케이션 개발 과정 중 코딩 보다 어쩌면 디버깅이 더 많은 작업분량을 차지한다고 해도 과언이 아닙니다. 그 만큼 버그없는 완벽한 애플리케이션을 개발하려면 코딩은 필요조건 디버깅은 충분조건이라고 볼 수 있겠네요.. ^^
Flex Builder Gumbo에서는 조금 더 편리하게 디버깅 할 수 있도록, 새로운 기능들이 추가되었습니다.
건너 뛰기
디버깅을 하면서, 개발자가 가장 두려워 하는 부분이 for문과 같이 계속 반복되는 구문에 브레이크포인트가 걸려있을 경우가 아닐까 생각됩니다. ^^;; 이 경우 브레이크 포인트를 해제해야 무사히 넘어갈 수 있겠죠?
이외에, 디버깅 상황에 따라 필요없는 브레이크 포인트를 만난다거나, 브레이크포인트가 걸려있지 않은 곳으로 이동하고 싶은 경우가 생길 수 있습니다.
Flex Builder Gumbo에서는 이러한 상황을 위해(?), 라인건너뛰기 기능을 지원합니다. 브레이크포인트가 걸려있는 상황에서 건너뛰고 싶은, 라인에서 오른쪽 버튼을 눌러 Run to Line를 클릭하거나, Ctrl+R을 눌러, 해당 라인으로 건너뛸 수 있습니다.
(사실 이런기능이 이전버전 부터 지원했어야하는데.. 라는 아쉬움도 남습니다.. ㅎㅎ)
컨디션 브레이크포인트
위의 상황처럼 디버깅을 진행하면서 반복된 구문을 계속해서 돌고 있는데, 브레이크 포인트가 걸려있다면, 반복 과정중 무시할 수 있는 경우의 수에서도, 브레이크가 걸리게 됩니다.
따라서, 이런 경우에는 if와 같은 조건문으로, 브레이크를 조절 할 수 있지만, 조건문의 설정으로 애플리케이션에 예상하지 않은 문제가 발생할 수도 있습니다.
Flex Builder Gumbo에서는 브레이크 포인트가 브레이크 걸리는 조건을 제한을 둘 수 있는 컨디션 브레이크가 새롭게 추가되었습니다.
예를들어 위의 애플리케이션은 350ms마다 ontimer가 디스패치 되고, 디스패치 될때마다 '잇힝~'이라는 문자열을 콘솔에 출력하게 됩니다.
만약, '잇힝~'이 세번 출력될 경우 브레이크가 걸리도록 지정하고 싶다면, 브레이크 포인트를 걸어두고, Breakepoint Properties에 들어가면,
위의 그림처럼, 브레이크 포인트를 설정 할 수 있는 창이 나타나게됩니다. 이 창에서 브레이크포인트가 걸리는 조건을 설정 할 수 있는데, 컨디션 조건문은 if의 조건문과 같이 설정 할 수 있습니다.
그리고, 컨디션 조건문의 브레이크가 걸리는 경우를 설정 할 수 있는데, 컨디션 조건문이 true이거나, 컨디션 조건문의 상태 변화가 있을경우로 지정할 수 있습니다.
컨디션 브레이크포인트를 지정하게 되면, 일반 브레이크 포인트와는 달리, 브레이크 포인트 위에 물음표가 나타나게 됩니다.
컨디션 브레이크포인트를 지정하고 테스트한 모습입니다. 콘솔창에 '잇힝~'이라는 문자열을 3회 출력한 후에 브레이크 포인트가 걸리게 됩니다.
컨디션 브레이크포인트를 적절히 잘 활용하면, 디버깅 과정중 반복문도 경우의 수에 따라, 조건에 마침맞게 디버깅 할 수 있습니다.
Unit Test 지원
개발자는 애플리케이션을 개발 하는 과정 중, 디버깅을 통해 애플리케이션의 버그를 해결할 수 있습니다. 이후, QA팀이 있는 조직일 경우, QA팀에서 애플리케이션의 문제점을 날카롭게 살펴보게 됩니다.
이러한 QA테스트 이전에, 개발자가 기계적으로 여러 조건을 걸어두어 해당 애플리케이션을 테스트 할 수 있습니다. 이러한 테스트를 유닛테스트(Unit test)라고 하며, Java에서는 JUnit라는 프레임워크를 통해 Unit Test를 할 수 있습니다.
어도비에서는 플래시/플렉스 애플리케이션에서 이런 유닛테스트를 할 수 있도록, FlexUnit 프레임워크를 개발하여 배포하고 있습니다. FlexUnit는 오픈소스(New BSD)이며, JUnit와 기능적으로 거의 흡사합니다. 다운로드는 여기에서 할 수 있습니다.
Flex Builder Gumbo에서는 위에서 설명한 Flex Unit 프레임워크를 기본적으로 포함하고 있고, 손쉽게 유닛테스트를 할 수 있도록 지원하는 기능이 추가되었습니다.
Unit Test를 하기 위한, Test Case Class와 Test Suite Class가 File의 New 탭에 추가 되었습니다. Test Class를 생성하게 되면, FlexUnit 프레임워크가 자동적으로 임포트됩니다.
위의 그림처럼, TestCase를 추가 할 수 있습니다. 패키지명은 Test Class가 생성될 패키지 위치로, 변경 할 수 있습니다. 그리고, Select Class to test를 선택해, 테스트할 클래스의 탬플릿을 자동적으로 생성 할 수 있습니다.
Test Class를 생성하게 되면, 디버깅 버튼 하단에 Execute Flexunit Tests 탭이 나타나게 됩니다. 이 탭을 누르면,
Test Class에서 지정한 조건에 맞게 유닛 테스트를 시작하게 됩니다.
Flex Unit 프레임워크는 Unit 테스트 결과를 플래시 형태의 Test Runner로 결과를 보여주기 때문에, Flex Builder Gumbo의 Flex Unit Result View 탭 이외에도 인터넷 창에서 Unit Test의 실행결과를 알려주게 됩니다.
Unit Test를 적절히 활용하면, 개발 과정중 예기치 않은 문제들을 조기에 발견 할 수 있고, 또 기계적으로 테스트를 진행할 수 있어서 큰 노력없이 애플리케이션의 테스트를 할 수 있습니다.
지금까지 1년여에 이은, Flex Builder Gumbo 살펴보기 시리즈를 모두 마칩니다. Flex Builder "Gumbo"는 올 H1중에 퍼블릭 베타가 예정중입니다. 퍼블릭 베타는 아래의 경로에서 신청할 수 있습니다.
Flex Builder Gumbo 퍼블릭 베타 신청하기
그럼 이어서 더 좋은글....로 찾...아뵐려고 하는데
어랏?
뭔...가 거시기한걸 깜빡한것 같은데(?)
Flash Catalyst 지원
Flex Builder Gumbo에서는 그간 코드네임 Thermo로 알려진 Flash Catalyst를 공식적으로 지원합니다.
Flash Catalyst는 개발자-디자이너간 중계자 형성 툴로, MS의 익스프레션 블렌드와 다소 흡사한 성향을 가지고 있습니다.
디자이너는, 자신이 디자인한 결과물(일러스트레이터, 포토샵) 파일을 Flash Catalyst로 불러와, 컴포넌트의 역할, 사용자의 인터렉션이나 화면 전환등을 지정 할 수 있고, 완성된 결과물을 개발자에게 전달하여 프로젝트에 바로 활용 할 수 있습니다.
그럼 이 글에 이어서, 3부에 걸쳐 Flash Catalyst에 대해서 자세히 살펴보겠습니다.
