어도비는 플래시 플랫폼의 주요 핵심 런타임 기술 중 하나인 AIR 런타임의 후속 버전인 AIR 2.0(코드네임 Athena)에 대해 발표하였습니다.

Adobe AIR는 크로스 플랫폼을 지원하는 데스크탑 런타임으로 2008년 처음으로 배포되었습니다. 그리고 현재 2억대의 컴퓨터에 두루 배포되어 있으며, 수 많은 애플리케이션이 AIR 기반으로 개발되어 배포되고 있습니다.

현재 eBay, MLB.COM, New York Times 등의 서드파티사들이 AIR 기술을 도입 하였고, 현재 까지 배포된 애플리케이션 수가 3000만건에 이를 정도로, AIR는 배포 1년 반 만에 많은 분야에서 자리매김 하고 있습니다.

AIR의 마일스톤이 1.5.2에서 2.0으로 향상 된 만큼 변화사항도 많은 편인데요.
AIR 2.0의 주요 변화 사항들은 아래와 같습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

안녕하세요.
희희덕덕입니다 : )

대학생이라고 하면 무엇이 떠오르나요?

저는 대학이면 노는 곳, 마시는 곳, 토하는 곳 이라고 생각했는데,
사실 이 작은 대학이라는 공간에서도 무한한 경쟁이 휘몰아 치고 있었지요..
(아아 내 학점 orz)

요즘은 특히 천만원 등록금이다, 이태백이 백수다…
대학이라는 곳이 점점 팍팍해지고 있어요.. 후후

이렇게 팍팍해진 대학생활 속에서,
오로지 ‘열정’이라는 키워드로 뭉친 멋진 친구들이 있어 소개하고자 합니다.

바로 Microsoft Student Partner 인데요.
전국 각지의 대학에서 선정된 45명의 열정, 개성이 넘치는 능력자 친구들이랍니다 : )

MSP의 멋진 활동은 이곳 저곳에서 볼 수 있지만,
블로그를 통해서도 정말 많은 정보들을 공유하고 있는데요.

3기 MSP의 글들을 쉽게 살펴 볼 수 있는 프로그램을 공개합니다. 

바로 이름하여, MSP 리더!

MSP 리더는, MSP 분들의 블로그를 돌아다니면서
최근에 올라온 글을 알려주고, 예전에 올라온 글들도 쉽게 읽을 수 있는 프로그램 이랍니다 : )

위의 화면이 메인 화면인데
몬가 깔쌈하고 좋죠? ㅎㅎ

이.. 이렇게 각 MSP 별로 글을 볼 수 있구요.
글타래 태그를 통해서 해당 MSP의 관심 분야를 쉽게 살펴 볼 수 있어요 : )

그리고 메인 화면에서
태그 클라우드를 통해, MSP 분들이 관심 있어하는 트랜드를 쉽게 볼 수 있구요.
(가장 많은 관심을 받은 주제가, 제일 크게 보인답니다.)

태그 클라우드에서 태그를 클릭하면!

요렇고롬
클릭한 태그에 해당하는 글만 따로 볼 수 있어요

그럼 태그 클라우드에 없는 트랜드는 볼 수 없는건가 ㅜㅜ
라고 슬퍼하실 분들을 위해 ㄷㄷ

글 찾기 기능도 있습니다.
글 찾기에서 찾고자 하는 내용을 입력하시고 검색 버튼을 누르면

이렇게, 해당하는 검색어에 맞는 글도
잘 찾아 줍니다!!

그리고, 검색한 글을
최근 30개 올라온 글만 볼것인지, 오늘, 어제, 일주일간 올라온 글만 볼것인지를 설정 할 수도 있구요.

"앜ㅋㅋㅋㅋㅋㅋㅋㅋ 이분이 쓴글 몬가 나의 신경을 자극시키는 것가태"
라는 글을 따로 모아 볼 수 있는 스크랩 기능도 있습니다.

글의 오른쪽 하단의 스크랩버튼을 누르면 해당 글이 스크랩 되구요.

스크랩 버튼을 통해서 내가 스크랩 한 글들만 모아서 볼 수도 있어요 : )

마지막으로 ,새로 글을 작성한 MSP 분들이 있다면,
MSP 리더에서도 뾰옹 하고, 새 글 알림창을 띄운답니다 : )

새로운 트랜드, 그리고 내가 관심있어하는 MSP 분의 일거수 일투족*-_-*을 감시할 수 있어서
정말 유용하겠죠?

MSP리더는 아래의 Install Now를 눌러 설치 할 수 있습니다 : )

MSP, Microsoft Student Partner은 Microsoft의 등록상표이며, 모든 권한은 Microsoft에게 있습니다. MSPReader 에서 제공하는 컨텐츠의 저작권은 각 게시자에게 있습니다.

MSP 리더를 쓰시면서 발생한 버그, 그외의 의견이 있으시면
댓글 부탁 드리겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

AIR는 어도비에서 개발한 크로스플랫폼 런타임으로, 릴리즈한 지 약 1년 반 만에 클라이언트 누적 설치수가 2억건에 돌파할 만큼, 뜨거운 이슈로 부상하고 있습니다.

특히, ebay, nike등의 대형 서드파티사에서 Adobe RIA 기술을 도입하여, AIR 애플리케이션을 공개하였고, 사용자에게 많은 호응을 얻고 있습니다.

국내에서도 픽짜, GS이숍, 현대카드 등의 회사의 자사 서비스에서 AIR 애플리케이션을 도입한 사례가 점차 늘어나고 있는데요.

이처럼, AIR는 국내외적으로 종횡무진 하고 있는 하나의 플랫폼으로 자리매김 하고 있는데요. 미국 최대의 야구리그인 MLB에서 Adobe AIR 애플리케이션을 공개하였습니다.

 
이 프로그램의 이름은 MLB.COM OnBase 인데요. 사용자가 관심 있는 구단이나 선수를 추가하여, 해당 구단이나 선수의 최신소식이나 전적 등을 살펴 볼 수 있습니다.

특히 새로운 소식이 올라오면, 사용자에게 알림창을 통해 안내하는 기능도 있어서, 야구 팬들에게 많은 호응을 받고 있습니다.

외국 스포츠 소식은 국내 언론매체를 통해 신속하게 전달받기가 힘든 편인데요. MLB에 관심이 많은 국내 야구팬들에게 많은 도움이 될 애플리케이션인 것 같습니다.

MLB.COM OnBase는 아래의 경로에서 다운로드 할 수 있습니다.
MLB.COM OnBase

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이번 글은 지난번 제 블로그에서 다룬 Snow Leopard 사용자를 위한 CS4 FAQ에 이어 작성하는 글입니다. 이번 글도 호환성 관련된 이슈에 대해서 알아보고자 합니다.

Snow Leopard는 경쟁사인 MS보다 두 달여 앞선 지난달에 출시되었습니다. 지난 버전에 비해 큰 변화는 없지만, 사용자 인터페이스를 비롯해 여러 기능들이 개선되었다고 합니다.

지난번 글에서도 다룬 것처럼, 새로운 운영체제가 출시하게 될 경우 항상 호환성 이슈에 직면하게 됩니다. 다행히 요즘엔 운영체제 개발사에서 이러한 이슈들을 최대한 줄이기 위해 사전 테스트를 비롯해 다방면으로 노력하고 있는데요.

Adobe AIR는 플래시플랫폼의 일부로, 크로스 플랫폼을 지원하는 런타임입니다. 스노우레오파드에서 앞선 레오파드에서도 정식적으로 지원되었고, 이외에 윈도우, 리눅스 등에서도 공식적으로 지원하고 있습니다.

그리고 다행히도, 어도비 AIR 팀에서는 현재 AIR 1.5.2 런타임이 스노우레오파드에서 정상적으로 구동된다고 밝혔습니다.

다만 개발자들이 AIR 애플리케이션 개발 과정 중 디버깅을 위해 사용했던 ADL에서 약간의 이슈가 발생하고 있는데, 이러한 이슈는 ADL의 위치를 옮겨주는 작업으로 해결 할 수 있으며, 어도비에서도 근본적으로 이러한 이슈가 곧 해결될 수 있도록 노력하겠다고 합니다.
Adobe AIR Support for Mac OS X Snow Leopard ]

아울러, Snow Leopard 기반의 OS와 AIR 런타임에서 문제가 발생할 경우 아래의 경로로 리포팅 할 것을 권장하고 있습니다.
http://www.adobe.com/go/wish

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Adobe AIR는 크로스플랫폼을 지원하는 런타임으로, 기존 플래시의 유연한 인터렉티브 구현과 더불어, 윈도우 및 파일 제어와 같은 Native API 지원으로, 그간 플래시플랫폼을 이용해온 서드파티사로 부터 많은 주목을 받고 있습니다.

특히, AIR 애플리케이션은 Flash, Flex 개발자 뿐만 아니라, ActionScript 개발 경험이 없는 AJAX 개발자도 개발 할 수 있고, 개발자들은 AIR SDK를 이용해 그간 작업해오던 개발 환경에서 그대로 작업 할 수 있다는 장점이 있습니다.

AIR 애플리케이션은 플래시 애플리케이션과는 달리, 데스크탑에서 실행되는 애플리케이션으로, 개발 과정 중 테스트 하려면 ADL(Air Debug Launcher)가 필요합니다.

개발 과정을 모두 마친 AIR 애플리케이션은 단일 설치 파일인 .air 파일을 생성하는 패키징이라는 절차를 거쳐야 하는데, 이 과정은 ADT(AIR Developer Tool)에서 진행 할 수 있습니다.

ADL, ADT는 AIR SDK내에 포함되어 있고, 특이한 점은 AIR 런타임이 설치되지 않은 환경이라도 두 도구를 이용하여 개발을 진행할 수 있습니다. 아울러, 개발자에게 도움이 되는 여러 옵션들이 존재하는데 해당 옵션에 대해서는 차후에 자세히 다루도록 하겠습니다.

일반적으로, Flex Builder나 Flash IDE, Dreamweaver에서 AIR 애플리케이션을 실행 할 때에는 ADL이 프로세스에 실행되고, Break-point를 걸어 디버깅을 하거나, Console, Bug을 통해 발생한 이슈를 확인 할 수 있습니다.

AIR 애플리케이션을 패키징 하는 도구인 ADT는 ADL에 비해 활용 방법이 다소 복잡한데, 우선 패키징 과정 전, 해당 프로젝트를 먼저 swf 파일로 export 해야 합니다.

그리고, AIR 애플리케이션에 사용된 여러 리소스 파일들도 함께 첨부하여야 하며, AIR 애플리케이션 전반의 설정을 담고 있는 디스크립터 파일과, CA 기관으로 부터 발급받은 인증서로 서명 하여야 합니다.

다만, 드림위버, 플래시, 플렉스빌더와 같은 개발 IDE에서는 패키징 과정이 실행되는 동시에, 해당 프로젝트가 swf 파일로 export 되고, 리소스 에셋들도 함께 담기기 때문에, 디스크립터 파일과 인증서 파일 이외에는 별다른 작업을 해 줄 필요는 없습니다.

이렇게 패키징 과정을 모두 마치면, 단일 설치파일인 .air 파일이 생성되며 이 파일을 사용자에게 배포하여 AIR 애플리케이션을 활용하게끔 할 수 있습니다.

그런데, AIR 애플리케이션을 개발 하다 보면 종종 부딪히는 이슈가 한가지 있는데, ADL에서는 정상적으로 실행되는 AIR 애플리케이션이, ADT에서 패키징 되지 않는 문제가 발생하곤 합니다.

이러한 문제점은, 애플리케이션의 소스 코드의 문제점이라기 보단, 패키징 과정 자체의 문제점으로 IDE상에서 별도로 디버깅을 한다거나 에러창을 통해 확인할 수 없어서 난감한 문제이기도 합니다.

하지만, 이 문제점은 개발 상의 실수라기 보단, 패키징 과정 중에서만 발생하는 별도의 문제점으로 앞서 설명한 ADT의 실행 구조를 이해하면 보다 손쉽게 문제점을 찾아낼 수 있습니다.

우선 가장 흔히 발생하는 문제로, ADT에서는 AIR 애플리케이션의 전반적인 설정을 담는 디스크립터 파일을 패키징 과정 중에 함께 첨부하는데, 개발자가 디스크립터 파일의 엘리멘트를 잘못 작성하여 패키징이 정상적으로 진행되지 않는 경우입니다.

일반적으론, SystemChrome와 같이 입력사항에 제한이 있는 엘리멘트에서 흔히 발생하며, 다소 예외인 경우지만, AIR 애플리케이션의 아이콘에서도 문제가 발생하기도 합니다.

예를 들어, AIR 애플리케이션의 아이콘은, 엘리멘트에 정의된 크기를 반드시 유지하여야 하고, 확장자도 PNG 파일만 사용할 수 있습니다. 만약, 16x16 아이콘 엘리멘트에 정의된 이미지 파일의 크기가 16x15일 경우 패키징 과정중에서 에러가 발생하게 됩니다.

그리고, ADL과 ADT의 버전이 일치하지 않을 경우에도 이런 문제가 발생하게 되는데, 가령 1.5.2 ADL에서 테스트한 AIR 애플리케이션을, 1.5.1 ADT에서 패키징 할 경우, 디스크립터 파일의 설정이나, 새로운 API 사용등의 상황으로 패키징이 진행되지 않을 수 있습니다.

또한, AIR 애플리케이션을 패키징 할 때 사용한 인증서의 유효기간이나 키 체인 문제로, 패키징 과정은 모두 마쳤으나 사이닝 과정을 거치지 못해, 최종적으로 .air 파일이 생성되지 않는 경우도 있습니다. 이 경우엔, 다시 ADT에서 AIRI 파일을 생성하여, 인증서의 문제인지 확인 할 수 있습니다.

이번 글을 통해 살펴본 문제점은, 주로 AIR 애플리케이션 개발을 처음으로 경험하는 개발자들이 ADT의 실행원리를 이해하지 못하거나, 실수로 여러 설정을 변경해서 발생한 문제점으로, 그렇게 심각한 문제점은 아닙니다. ^^;; 또한, AIR 애플리케이션 개발을 여러 번 하다 보면 이러한 실수는 점차 줄어들게 되니, 너무 걱정하시지는 않는 편이 좋겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Adobe AIR는 DBMS엔진인 Sqlite를 내장하여 로컬에서도 데이터들을 DB화 시켜 읽고, 쓰기와 같은 데이터 관리를 효율적으로 할 수 있는 장점이 있습니다.

보통, 플래시플랫폼과 같이 Front-End 개발을 주로 하셨던 분의 경우엔, DB와 같이 Back-End단의 작업 수행 방법을 이해하기 어렵기 때문에, AIR 애플리케이션을 개발할 때 어려움이 있는 것 같습니다.

이번 글에서 다뤄볼 내용도, 저에게 메일이나 블로그를 통해 자주 질문하시는 내용 중 하나인데, AIR 애플리케이션에서 대량의 INSERT 문을 수행할 때, 효율적으로 수행할 수 있는 방법과, 런타임에 응답 없음과 같은 오류가 발생하는 원인에 대해 알아 봅시다.

위의 애플리케이션은 트랜잭션을 적용하고, 적용하지 않은 200개의 INSERT문을 실행하고, 수행에 걸리는 시간을 검사하는 애플리케이션 입니다.

실행결과 재미있게도, 200개의 INSERT문을 실행했을 뿐인데, 트랜잭션을 적용한 것과, 적용하지 않은 것의 수행시간 차이는 무려 200배 넘게 차이가 나네요.

수행시간에서 차이가 있는 이유는 간단한데, 트랜잭션을 적용한 예제의 경우, 트랜잭션을 시작한 후, 실행하는 쿼리는 모두 메모리에서 수행하게 되고, 커밋을 함과 동시에 하나의 쿼리 문만 날리게 되며, 하드에 영향을 미치는 작업은 단 한번만 이루어 지게 됩니다.

반면, 트랜잭션을 적용하지 않은 예제의 경우, 매 번 쿼리문을 날리게 되고, 쿼리문을 날릴 때 마다 하드를 탐색하게 되기 때문에, 실행 속도에 차이가 있는 것입니다.

디스크에 데이터를 쓰고 지우는 것과 같은 작업은, 디스크의 성능에 따라 크게 달라지고, 일반적인 작업에 비해 상당히 오랜 시간이 소요되기 때문에, 두 경우에서 같은 데이터를 DB에 추가하였다고 하더라도, 어마어마한 수행 시간 차이가 발생하게 되는 것입니다.

두 경우의 프로파일링을 수행 하였을 때에도, 실행시간에서는 200배 넘는 차이를 보이지만 메모리 점유면에서는 거의 차이가 없는데, 이는 메모리 문제가 아니라 하드와 관련된 문제임을 알 수 있습니다.

다만 트랜잭션을 사용할 경우 주의해야 할 점은, 커밋하기 전에 전원이 제거 될 경우 데이터베이스가 손상 될 수 있기때문에, 적절한 시점에서 커밋을 해 주는 것이 중요합니다.

실제로, Sqlite 개발자도 INSERT 문과 같은 DB에 실질적으로 영향을 주는 쿼리문은 하드를 직접 읽고 쓰기 때문에, 트랜젝션을 적절히 사용할 것을 추천하고 있습니다.

특히, AIR의 Sqlite는 런타임 위에서 실행되기 때문에, 대용량 INSERT와 같이 하드를 많이 제어할 경우엔, AIR 런타임 자체에 메모리 점유가 상당히 높아지게 되어, AIR 런타임이 응답이 없거나 강제종료 되는 상태가 발생 할 수도 있습니다.

따라서, AIR 애플리케이션에서 대용량 INSERT 문을 AIR에서 수행해야 할 경우엔, 트랜잭션을 적절히 활용하는 것이 좋습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Adobe AIR는 기존 Flash Platform에서 더 확장되어 클라이언트의 파일을 쓰고 지우거나, 윈도우 등 여러 설정을 할 수 있는 Native API를 제공합니다.

그리고, Webkit, Sqlite 엔진 등을 탑재하여, 로컬에 데이터베이스 관리를 하거나, AJAX 개발자들도 AIR 애플리케이션을 개발 할 수 있는데 따라서, 기존 Flash Platform 개발자들이 경험하지 못한, 다양한 기능들을 개발 할 수 있는 장점이 있습니다.

그렇다 보니, AIR를 처음 접하는 개발자 분들의 고충이 이만저만 아닌 것 같습니다. AIR의 여러 API들을 익히는데도 시간이 걸리지만, AIR의 여러 장점을 잘 활용하고 관리하는 일도 만만치 않죠.

하지만, 동변상련의 심정일까요? 
이 글을 읽을 여러분 보다, 먼저 이런 고민을 하고, AIR 개발자들에게 도움을 주기 위한 애플리케이션이 여럿 있는데, 오늘 이 글에서는, AIR 개발자를 위해 개발된 몇몇 애플리케이션에 대해 소개하겠습니다.

애플리케이션 디스크립터 관리 프로그램 – ADM

AIR 애플리케이션을 배포하기 위한 단계인 패키징 단계에서, 애플리케이션의 정보를 담는 디스크립터 파일이 반드시 포함되어야 하는데, 이 파일은 XML 구조로 작성 되어있습니다.

플렉스 빌더에서 AIR 애플리케이션을 패키징 할 때에는 프로젝트의 소스 폴더에, 디스크립터 파일이 생성되며 애플리케이션의 설정을 변경 시, 이 파일에서 직접 변경 하시면 됩니다.

그리고, 플래시 드림위버에서 AIR 애플리케이션을 패키징 할 때에는, 환경에 따라 다르지만, 별도의 JRE를 비롯한 Extension을 필요로 하며, 패키징 과정 중 디스크립터 파일을 첨부하거나, 패키징 인터페이스에서 애플리케이션 설정을 할 수 있습니다.

그런데 문제는, 디스크립터 파일이 xml 구조로 이루어 져 있고, 각 엘리멘트의 설정 값을 모르는 경우 작성하기가 어렵습니다. 또, 일부 엘리멘트의 경우엔 지정할 수 있는 값이 한정되어 있고, 값을 비워둘 경우 정상적으로 패키징이 되지 않는 엘리멘트들도 있습니다.

특히, 플렉스빌더에서는 패키징 인터페이스 중에서 이러한 애플리케이션의 설정을 할 수 있는 부분이 없고, 반드시 디스크립터 파일을 열어서 수정하여야 하는데, AIR 개발을 처음 접하는 개발자들에게는 다소 어려운 일이 될 수 있습니다.

David Deraedt는 디스크립터 파일을 쉽게 관리할 수 있는 애플리케이션인 ADM을 개발하였는데, 이 애플리케이션은 AIR 기반으로 개발 되었습니다.

ADM은 애플리케이션의 디스크립터 파일을 연 다음, 각 항목별(필요항목, 옵션항목, 윈도우 등) 엘리멘트를 설정 할 수 있고, 또 엘리멘트에 대한 자세한 설명도 참조 할 수 있습니다.

설정을 마친 파일은 Save 버튼을 누르면, 디스크립터 파일이 작성 되며, File Preview에서 저장될 디스크립터 파일을 미리 볼 수 있습니다.

이처럼, ADM을 잘 활용하면, AIR 개발을 처음 접하는 개발자라도, 필수 작성엘리멘트와, 선택 작성엘리멘트를 구분 할 수 있고, 각 엘리멘트 별 속성 설정도 ADM에 포함된 도움말을 통해 쉽게 파악 할 수 있습니다.

ADM은 아래의 경로에서 내려 받을 수 있습니다.
http://www.dehats.com/drupal/?q=node/55

SQLite 관리 프로그램 – Lita

Adobe AIR는 데이터베이스 엔진인 SQLite를 탑재하여, 기존 Flash 애플리케이션과는 달리 사용자의 로컬에 데이터베이스를 직접 관리 할 수 있습니다.

하지만, 대부분의 플래시플랫폼 개발자 분들은 Front-end 개발을 주로 하셨기 때문에, 백앤드에서 빈번히 일어나는 DB와의 통신을 이해하기가 어렵습니다.

그리고, AIR에서 로컬 데이터베이스 관리를 위해 별도의 API와 더불어, SQLite의 쿼리 방식도 익혀야 하는데, DB를 처음 다루어 보는 Flash Platform 개발자라면 다소 힘든 일이 될 수 있습니다.

특히, 애플리케이션을 테스트 하는 과정 중에서 DB의 필드를 추가한다거나, 데이터를 몇 개 더 추가하는 작업을 할 때마다 AIR에서 SQL을 날리는 건, 다소 비 효율 적인 일이겠죠.

SQLite는, 여러 플랫폼에서 사용되는 DB엔진으로, 데이터베이스 관리와 관련되어 우수한 애플리케이션이 많습니다.
그리고, 앞서 소개한 David Deraedt 라는 분께서도 SQLite 관리 프로그램인 Lita를 Adobe AIR로 개발 하셨네요.. ^^
(정말 열정이 뛰어나신 분인 것 같습니다.)

Lita는 SQLite DB 파일을 열어, 테이블을 만들거나, 필드를 추가하거나 지우고, 데이터베이스를 암호화 하는 작업들을 쉽게 할 수 있는 애플리케이션으로, 아래의 경로에서 내려 받을 수 있습니다.
http://www.dehats.com/drupal/?q=node/58

AIR 배지 생성 프로그램 – ApollocationBadge

AIR 애플리케이션은 Flash Player 기반의 애플리케이션과는 달리, .air라는 단일 파일로 내보내는 패키징이라는 절차를 거쳐야 하며, .air 파일은 AIR 런타임이 설치된 사용자의 경우에만 실행 할 수 있습니다.

어도비에서는 이러한 불편을 줄이기 위해, AIR 런타임이 설치되지 않은 사용자의 경우에도, 플래시 상에서 AIR 런타임을 설치 할 수 있는 브라우저 API를 지원하고 있는데, 이를 기반으로 어도비에서는 AIR배지를 SDK에 함께 포함하여 배포하고 있습니다.

AIR 배지는, swf 파일로, 브라우저 API를 로드 하여 AIR 런타임 설치 여부를 감지한 후 Install 버튼을 누르면, AIR 애플리케이션이 설치 될 수 있도록 만든 도구로, 이를 활용하여 AIR 런타임이 설치되지 않은 사용자에게도 손 쉽게 AIR 애플리케이션을 배포 할 수 있습니다.

다만, AIR 배지 역시 웹 상에 embed 되는 파일이고, AIR SDK내에 제공된 AIR 배지에는 필수 파라미터를 갖춰야 하기 때문에, AIR 애플리케이션을 처음 배포하시는 분들은 많이 당황스러울 수도 있겠네요. ^^;;

이러한 불편을 해소하기 위해, 원영국님께서 AIR 파일을 분석해서 AIR 배지를 자동으로 생성해주는 애플리케이션인 ApollocationBadge를 개발 하여, 배포 하고 있습니다.

ApollocationBadge 애플리케이션은 배경이미지를 비롯한 여러 설정들을 하면 AIR 배지를 생성해 주는 Studio와, AIR 파일을 자동으로 분석해서 AIR 배지를 생성해주는 AVM 으로 두 가지 종류로 나뉘는데, AVM을 통해 AIR 배지 파일을 생성 할 경우엔, 생성 폴더에서 AIR 배지에 보여질 이미지 파일인 BadgeBgImage 파일을 수정 해 주시면 됩니다.

ApollocationBadge 애플리케이션도, AIR로 개발된 애플리케이션 입니다.
설치는 아래의 경로에서 할 수 있습니다.

http://labs.apollocation.co.kr/applications/apollocationBadge/apollocationBadge.php?menu=1

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

안녕하세요. 한글팀 희희덕덕입니다.
플렉스 한글 입력 지연문제 해결에 이어, 기쁜 소식을 전해드립니다.

오늘 Adobe AIR QE팀의 수석 개발자로 부터 AIR 1.1 부터 발견되었던 한글 삭제 문제가 해결되었다고 알려왔고, 한글팀에서도 AIR 2.0(코드명 Athena)에서 해당 문제가 더 이상 발생하지 않는 것을 확인 했습니다.

이 문제는 한글 문자열 삭제 시 제일 마지막 문자의 자음이 남는 문제로, AIR 1.0과 아폴로 베타버전 에는 발생하지 않다가, 작년 6월경 릴리즈 된 AIR 1.1에서 최초로 발견되었고, 최근 제로데이 이슈를 비롯한 여러 이슈들을 해결한 AIR 1.5.2에서도 이 문제가 계속되는 것을 확인하였습니다.

아울러, 플렉스의 halo Textinput를 비롯하여, TextFiled 클래스 등 전반적인 입력 컴포넌트 등에서 문제가 발견 되었으며, 이례적으로 webkit 엔진에서 구현되는 입력폼에서는 해당 문제가 발생하지 않았습니다.

AIR의 한글문자열 삭제 문제가 처음 발견된 후, 한글팀의 희희덕덕, 에이레네님을 비롯해 우야꼬님께서 별도의 해결방법을 제시하였으나, 한글 문자열 삭제 이외에 텍스트 블록이 노란색으로 표시되는 문제에 대한 해결방법은 존재하지 않았습니다.

이 문제는 한글팀에서 올 2월경 어도비 이슈트래킹시스템(http://bugs.adobe.com)에 보고하였으며, AIR 런타임의 문제로 보고 지난 7월 경 종결 되었습니다. 해당 이슈가 종결될 때 까지 총 35분께서 투표해 주셨습니다.
http://bugs.adobe.com/jira/browse/SDK-19158

그리고 이슈트래킹 시스템에 해당 문제의 중요성을 피력해 주신 원동일님과 한글팀 이준하 님께 깊은 감사의 말씀을 드리며, 귀중한 표를 행사 해 주신 한국의 35분의 개발자 분들께도 감사의 말씀을 드리고 싶습니다.

아울러, 한글팀은 금주부터, Flash Player, AIR 차기 버전의 알파 테스트 프로그램과, 어도비 내부 버그트래킹시스템에도 참여 중 이며, 앞으로 어도비 QA,QE팀과 적극적으로 협력하여, 한글 문제가 빠른 시일 이내에 해결될 수 있도록 노력하겠습니다.

한글 문제가 어느 정도 해결 선상에 든 것 같아 한국의 플래시플랫폼 개발자로써 상당히 기쁩니다. 하지만, 아직 남아있는 한글 문제가 많은 만큼, 많은 분들의 관심과 지지를 부탁 드립니다.

감사합니다.

Flash Platform 한글문제 공동대응팀
검쉰/블루메탈/열이아빠/옥고수/에이레네/지돌스타/희희덕덕

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

안녕하세요. 희희덕덕 입니다.

여름 휴가철을 지나, 이제 어느덧 대학생 개강도 얼마 남지 않았습니다 : )

길고도 길었던 여름방학이 끝나 섭섭해 하시는 분들이 많을 것 같고,
또 방학 이후로 자주 보지 못했던 학우들을 보는 기대감도 많을 것 같습니다..

하지만 개강이 꼭 즐거운 것만은 아닐 것입니다.
다니고 있던 알바도 그만 다녀야 하고, 여름방학동안 늘어난 허릿 살 둘레도 정리해야하고
또, 다음학기 학점 풍년을 위해, 한 학기 시간표도 준비해야하는 시기가 왔죠.

사실, 중.고등학교 시간표라고 하면 각 학급별 완성되어 제공되었고,
또 과목수도 적어서 그렇게 큰 어려움은 없었을 것으로 기억합니다만..

대학은 각 전공별로 들을 수 있는 과목도 다양하고
교양선택, 교양필수, 일반, 교직 등 다양한 종류의 개설과목들도 있습니다.

이런 과목들을 하나씩 짜 맞추면서 시간표를 맞추고
학점을 조정하는 일은 참 어려운 일이 되겠죠.

저도 올해부터는 대학생 라이프가 시작되어서, 매 학기 이러한 진통(?)을 겪어야 하지만
진통끝에 산고가 있다고, 학점이 대박이 나거나, 옆에 앉은 여학생이 정말 이쁜학생인 경우를 잘 노려야겠죠.

그래서 개발한 프로그램이 유세윤입니다.

유세윤은 제일 처음 숭실대학교 학생분들을 위해 제공되었지만, 2학기 부터는 세종대, 건국대, 성신여대, 숙명여대, 가톨릭대에도 제공되기 시작하였습니다.

하지만, 이 프로그램은 불쌍하게도(?) 수강신청 기간 이후 잘 사용하지는 않는 프로그램 입니다. 사실, 대학생활을 하다 보면, 수강신청 이후 시간표는 거의 다 외워버려서 유세윤을 켜서 다시 시간표를 볼 일은 없겠죠

한철 장사라 슬프지만, 최근엔 유세윤 아이팟, 유세윤 데스크탑등 다양한 애플리케이션으로 꾸준히 사랑받을 준비를 하고있습니다만, 반응이 어떨지는 잘 모르겠습니다 ㅋㅋ

한철장사긴 하지만, 1년에 두 번 있는 대목(?)에는 정말 많은 분들께서 찾아주시곤 합니다. 다만, 대학생들 이기주의가 그렇듯, 잘 쓴다는 댓글은 찾아보기 힘들고, 문제가 있으면 눈에 불을 키고 고쳐달라고 들이대기만 합니다.

아래는 오늘자 유세윤의 설치자 수 입니다.

오늘 자로 누계를 내보니 약 1만 3천여 분께서 유세윤 플랫폼을 설치해 주셨네요. 재미있게도, 이 분들 중 대다수가 AIR 런타임을 처음으로 설치하시는 분인데, 수강신청(?)의 급박함 때문이었는지, 아니면 AIR 배지의 위력이었는지 몰라도 예상보다 정말 많은 분들이 내려 받아 주셨습니다.

특히, 제가 다니고 있는 학교인 숭실대학교의 재적생 수는 약 1만 4천여명으로, 중복다운을 1000회라 가정해도 전체 학생분들 중에 1/2 가 제 프로그램을 애용해 주고 있다는 거네요. 어찌보면 숭실대는 AIR 홀릭중(?)이 아닐지 모르겠습니다.. ㅋㅋ

나중에는 다운로드 추이를 분석해보거나, AIR의 여러 문제점(?)을 지적해 보는 것도 좋을 것 같습니다. 특히 재밌는 건 특정 플랫폼 사용자의 경우 AIR 애플리케이션을 설치 할 때, 화면이 아예 나오지 않는 문제점도 5건이나 저에게 리포트 되었는데, 이 문제에 대한 원인도 함께 고민해보면 좋을 것 같습니다.

그럼 한철장사(?)이긴 하지만, 남은 수강신청 기간동안
유세윤플랫폼에 많은 관심 부탁드립니다 (__)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

메모리 관리는 모든 플랫폼 개발자가 느끼는 가장 큰 고민거리 일 것입니다. 특히, 웹 상에서 실행하는 애플리케이션은 메모리 설계를 잘못할 경우, 브라우저가 다운되거나, 시스템의 메모리를 독점해서 시스템에 중대한 위협을 끼칠 수 있죠.

하지만, 웹 플래시 애플리케이션 개발자들은 메모리를 직접 관리할 방법은 마땅히 없습니다. 단지, 현재 비 활성화된 객체를 잘 관리해 주는 것이 중요합니다. 특히, Flex의 일부 컴포넌트들은 이러한 메모리 관리에 염두를 두지 않고 설계 된 것이 많아, 개발자들을 골치아프게 하고 있습니다. ^^;;

그리고 재작년 AIR가 아폴로라는 코드네임으로 처음 발표 되었을때에도, 보안전문가들은 현 플래시의 메모리관리 방식을 지적하며, AIR 애플리케이션이 과다한 메모리를 점유하여 사용자의 보안에 중대한 위협을 줄 수 있다고 수 차례 경고하였습니다.

어도비에서는 이러한 보안 전문가들의 권고를 적절히 수렴하여, 디버그용 Flash Player와, AIR 애플리케이션에서 직접적인 메모리 관리가 가능하도록, 가비지컬렉션 기능을 새롭게 도입하였습니다.

아울러 최근 릴리즈 된, AIR 1.5.2 에서도 XML 객체에서 새로운 메모리 관리 방식을 도입하였습니다. 
이 글에서는, AIR의 메모리 관리 방식에 대해 살펴보겠습니다.

가비지 컬렉션

우선 가비지 컬렉션이 무슨 용어인지에 대해 궁금해 하실 분들이 많으실 것 같습니다. 가비지 컬렉션은 말 그대로 메모리 안에 있는 쓰레기들을, 메모리에서 완전히 털어내는 것을 뜻합니다. 좀 더, 전문적으로 얘기해보면, 메모리에 적재된 비활성 객체를 메모리에서 소거하는 것을 뜻합니다.

조금 더 자세한 이해를 위해 아래의 소스코드를 살펴 봅시다.

<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"> <mx:Script> <![CDATA[ private function start_create(): void { var num:Number = 0; var can:Canvas while(num < 1000) { can = new Canvas(); can.setStyle('backgroundColor', Math.round(Math.random()*0xFFFFFF)); can.width = 100; can.height = 100; can.x = Math.random() * 500; can.y = Math.random() * 500; this.canvas.addChild( can ); num++; } } private var lastMemory: Number; public function start_del(): void { while( this.canvas.numChildren ) { var can:Canvas = this.canvas.getChildAt( 0 ) as Canvas; this.canvas.removeChild(can); can = null; } } ]]> </mx:Script> <mx:Canvas x="10" y="58" width="500" height="500" id="canvas"> </mx:Canvas> <mx:Button x="10" y="10" label="캔버스 만들기" click="start_create();"/> <mx:Button x="113" y="10" label="캔버스 지우기" click="start_del();"/> </mx:Application>

위 애플리케이션은 특정 캔버스 안에 랜덤 한 위치를 정해 캔버스를 약 1000개를 생성하고, 다시 지우는 애플리케이션입니다. 아울러, 캔버스를 소거 할 때엔 반드시 해당 객체에 null을 넣어 비 활성화 객체로 지정 하고 있습니다.

위의 방법대로 한다면, 비 활성화된 객체는 곧 메모리에서 소거되어 개발자가 해당 객체에 대한 메모리관리를 개발자가 신경 쓰지 않는 것이 맞지만, 아쉽게도 Flash Player 에서는 비 활성화 객체가 메모리에서 소거되는 시점을 알 수 없습니다.
(테스트는, 플렉스 빌더에서 프로파일링 기능을 이용하거나, 현재 메모리 사용량을 찍어서 알 수 있습니다.)

이렇게, 비활성화 된 객체가 바로 메모리에서 소거되지 않는 이유는 Flash Player의 GC 방식 때문인데, 어도비 에서는 Flash Player의 가비지 컬렉션을 Flash Player가 사용할 수 있는 가용 메모리를 넘어 섰을 때, 적제된 비 활성화 객체 순서대로 진행하고 있기 때문입니다.

이러한 Flash Player의 GC정책이 큰 문제가 되지 않는다고 생각하실 분들이 있겠지만, 사실 상당히 심각한 문제가 될 수 있습니다. Flash 애플리케이션 개발자들은, 가비지 컬렉션이 일어난 시점을 알 수 없기 때문에, 현재 가용 메모리를 관리할 틈이 없고, 이로 인해 애플리케이션의 메모리 설계를 잘못 하게 될 경우엔, 사용자에게 메모리와 관련해서 중대한 영향을 끼칠 수도 있습니다.

특히 AIR는 데스크탑에서 실행되는 애플리케이션인 만큼, 웹에 비해 사용자가 더욱 빈번하게 사용하고, 또 오랜 시간 사용할 가능성이 높습니다. 그리고, 잘못된 메모리 관리로 인한 리스크도 더 클수 있겠죠. 따라서, 메모리 관리가 무엇보다 중요합니다.

다행히도, AIR는 Flash Player와는 달리, 개발자가 가비지 컬렉션이 발생하는 시점을 지정 할 수 있습니다.
시점이라고 하니 다소 이상한가요? Adobe AIR 애플리케이션에서 System.gc 메서드를 호출하게 되면, 현재 메모리에서 비 활성화 된 메모리를 즉각적으로 소거하게 됩니다.

<?xml version="1.0" encoding="utf-8"?> <mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"> <mx:Script> <![CDATA[ private function start_create(): void { var num:Number = 0; var can:Canvas while(num < 1000) { can = new Canvas(); can.setStyle('backgroundColor', Math.round(Math.random()*0xFFFFFF)); can.width = 100; can.height = 100; can.x = Math.random() * 500; can.y = Math.random() * 500; this.canvas.addChild( can ); num++; } } private var lastMemory: Number; public function start_del(): void { while( this.canvas.numChildren ) { var can:Canvas = this.canvas.getChildAt( 0 ) as Canvas; this.canvas.removeChild(can); can = null; } System.gc(); } ]]> </mx:Script> <mx:Canvas x="10" y="58" width="500" height="500" id="canvas"> </mx:Canvas> <mx:Button x="10" y="10" label="캔버스 만들기" click="start_create();"/> <mx:Button x="113" y="10" label="캔버스 지우기" click="start_del();"/> </mx:WindowedApplication>

위의 예제는 앞서 살펴본 Flash Player에서 GC 테스트와 같은 예제입니다. 다만, 캔버스를 제거하고, 비 활성화 객체로 만든 후, 가비지 컬렉션을 실행하는 것을 볼 수 있습니다.

실제 위의 예제를 실행하고, 메모리 변화를 관찰해 보면, 비 활성화 된 객체가 즉각적으로 메모리에서 소거되는 것을 알 수 있습니다.

이처럼, AIR 개발자는 System.gc 메서드를 이용해, 가비지컬렉션이 발생하는 시점을 지정 할 수 있고, 메모리 관리도 좀 더 효율적으로 할 수 있습니다.

다만, 주의해야할 점은 System.gc는 개발 과정중 ADL에서 실행하거나, 클라이언트에 설치된 AIR 애플리케이션, 혹은 디버그용 플래시 플레이어에서 가능합니다.

XML의 가비지 컬렉션

지금까지, AIR의 가비지 컬렉션에 대해서 알아봤습니다. Flash Player는 개발자가 가비지 컬렉션 시점을 알 수 없지만, AIR는 개발자가 가비지 컬렉션이 일어나는 시점을 지정 할 수 있습니다.

아울러 Flash Player와는 별도로, 얼마전 릴리즈된 AIR 1.5.2에서는 XML 객체에 가비지 컬렉션 시점을 지정 할 수 있는 disposeXML 메서드가 추가되었습니다.

그런데, 왜 AIR 1.5.2에서 XML 객체만 별도로 가비지 컬렉션을 할 수 있는 메서드가 추가되었는지 궁금해 하실 분들이 많을 것 같습니다.

XML 객체는 각 노드안에 자식 노드들이 존재하는 상당히 복잡한 자료구조로, 실제 AVM(AAVM)에서는 XML의 각 노드와 자식노드들이 포인트 형태로 묶여 있다고 합니다. 즉, 메모리에서도 각 노드별로 뛰엄하게 띄워져 있습니다.

따라서 가비지 컬렉션을 시행하는 중에서도, XML 객체는 상당히 까다로운 작업을 해야 하고, 이로 인한 메모리릭도 상당히 빈번하게 발생한다고 합니다.

어도비에서 XML 객체에 한해 별도로 GC를 할 수 있게 한 이유도, System.gc를 이용해 가비지컬렉션을 실행하거나, 메모리 임계치 도달에 의해 가비지컬렉션이 도달할 때, XML 객체로 인한 메모리 릭을 미연에 방지하기 위함이라고 하네요.

아래의 예제를 살펴봅시다.

<?xml version="1.0" encoding="utf-8"?> <mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" width="446" height="377"> <mx:Script> <![CDATA[ private var xml:XML; private function load_xml():void { var file:File = File.documentsDirectory.resolvePath('test.xml'); var fstream:FileStream = new FileStream(); fstream.addEventListener(Event.COMPLETE, oncomp); fstream.open(file, FileMode.READ); } private function oncomp(e:Event):void { var fstream:FileStream = e.target as FileStream; xml = new XML(fstream.readUTFBytes(fstream.bytesAvailable)); } private function gc_xml():void { System.disposeXML(xml); xml = null; } ]]> </mx:Script> <mx:Button x="10" y="10" label="load xml" click="load_xml();"/> <mx:Button x="100" y="10" label="gc xml" click="gc_xml();"/> </mx:WindowedApplication>

위 AIR 애플리케이션은, 사용자의 문서 폴더에 저장된 특정 XML파일을 읽어 오고, 비 활성화 객체로 만든 후, XML 객체만 가비지 컬렉션을 실행하게 됩니다.

disposeXML 메서드를 호출하면, 위의 그림처럼 XML 객체가 메모리에서 완전히 소거되는 것을 볼 수 있습니다. 다만, disposeXML 메서드는 현재 비활성화 된 모든 XML 객체가 아닌, 특정 XML 객체에 한해 GC가 발생한다는 점을 주의하여야 합니다.

참고로, disposeXML 메서드를 사용하려면, AIR 1.5.2 SDK로 반드시 업데이트 하셔야 합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.