Adobe AIR 애플리케이션은, 개발자 없는 AIR 애플리케이션, AIR 개발자가 바라본 실버라이트3 OOB 에서 소개 드린 것 처럼, 플래시 애플리케이션과는 별도로 AIR 런타임이 필요하며, 패키징 된 단일 설치파일인 .air 파일을 내려 받아 설치할 수 있습니다. 하지만, 일반적으로 클라이언트에 AIR 런타임이 설치되어 있지 않은 경우가 많아, AIR 애플리케이션을 배포시 별도의 안내가 필요합니다.
어도비에서는 이러한 단점을 극복하기 위해, 작년 AIR 릴리즈와 동시에, 플래시 형태의 AIR 배지도 SDK에 함께 포함하여 배포하기 시작하였습니다. AIR 배지는 플래시 플레이어 9이상인 사용자는 누구나 사용할 수 있고, AIR 런타임이 설치되어 있지 않은 환경에서도, 애플리케이션과 AIR 런타임을 함께 설치할 수 있다는 장점이 있습니다.
이베이와, 뉴욕타임스와 같이 AIR 애플리케이션을 채택한 서드파티사의 경우에도, 주로 AIR 배지를 통해 애플리케이션을 배포하였고, 쉬운 설치 방식(Seamless Install)을 비롯해 크로스 플랫폼을 지원하는 장점 등으로 사용자들에게 많은 호응을 얻고 있습니다.
AIR 배지는 AIR SDK내에 포함되어있는 배지파일을 그대로 활용할 수 있지만, 사용 용도에 맞게 적절하게 커스트 마이징 할 수 있습니다. 어도비에서는 AIR SDK내에 AIR 배지와 함께 플래시 파일과 액션스크립트 소스코드 파일을 제공하고 있습니다.
AIR 배지를 커스트마이징 하는 방법은 아래와 같이 크게 두 가지 방법으로 나눌 수 있습니다.
UI를 커스트 마이징
AIR 배지의 사용자 인터페이스(UI)를 커스트마이징 할 때 주로 사용하는 방법으로, AIR SDK내에 포함된 Badge.fla 파일을 커스트마이징 하여 AIR 배지 파일의 배치를 변경할 수 있습니다.
그리고 간단한 UI수정 이외에도 AIR 배지에 부가적으로 추가할 기능이 있을 경우 Badge.fla 파일에 구현하여 사용할 수 있습니다.
위와 같은 방법으로 AIR Badge를 커스트마이징 할 때 특별히 유의해야 할 점은, badge.fla의 Display Class는 AIRBadge.as 파일을 기반으로 하기 때문에, UI 변경과정 중 무비 클립이나 레이어 이름이 변경되지 않도록 특히 유의하여야 하며, 불가피하게 변경이 필요한 경우 반드시 AIRBadge.as 파일을 수정하여야 정상적으로 동작됩니다.
Badge.fla 파일을 이용하여, AIR 배지의 커스트마이징 작업을 모두 마쳤다면 플래시 파일로 export 하여 바로 사용할 수 있습니다. 커스트마이징 과정중 별도로 기능 구현을 위해 추가한 매개변수가 있다면 flashvars에 포함하여 사용하면 됩니다.
AIR 브라우저 API파일을 활용하여 커스트 마이징
AIR SDK에 제공된 AIR Badge의 소스코드를 사용하지 않고, 완전히 새롭게 커스트마이징 하는 방법으로, 주로 AIR Badge에 추가될 부가기능이 많거나 UI를 완전히 새롭게 구현할 때 주로 사용합니다.
일반적으로 위의 방법은 AIR Badge를 완전히 새롭게 개발해야 하기 때문에 주로 많이 이용되지는 않는 편이지만, 최근엔 자바스크립트와 AIR Badge간의 연동을 위해 사용되기도 합니다.
AIR 브라우저 API을 활용한 커스트마이징은 우선 AIR Badge의 작동 구조에 대한 이해가 필요합니다.
AIR Badge는 AIR 브라우저 API파일을 기반으로 작동하게 되는데, 모든 AIR Badge는 이 파일을 경유해야 합니다. AIR 브라우저 API파일은 AIR 런타임의 환경 설정과 설치, AIR 애플리케이션의 설치와 실행 등 AIR런타임과 애플리케이션에 관련된 전반적인 사항을 담고 있습니다.
AIR 브라우저 API파일의 위치는 http://airdownload.adobe.com/air/browserapi/air.swf 그 위치는 이후에도 계속 유지됩니다.
AIR Badge는 초기화 과정중 위와 같이 AIR 브라우저 API 파일을 로드하여 사용하게 됩니다. AIR 브라우저 API파일을 정상적으로 로드하였다면, air.swf API들을 사용할 수 있습니다.
AIR Badge는 AIR 브라우저 API파일에서 사용할 수 있는 api 를 활용하여 설치 전반을 진행하게 되는데, 사용자가 설치 버튼을 누르게 되면 위의 순서와 같이 진행됩니다.
우선 제일 처음으로 진행하는 절차는 AIR 애플리케이션을 섪치할 사용자의 컴퓨터에 AIR 런타임이 설치되어 있는지 확인하게 된다. AIR API에서는 getStatus 메서드를 사용하여, AIR 런타임 환경 정보를 알아낼 수 있습니다.
getStatus 메서드를 호출하게 되면 사용자의 컴퓨터의 런타임의 상태에 따라 아래의 문자열중 하나를 반환하게 됩니다.
|
문자열 |
설명 |
|
available |
런타임이 설치가 가능한 환경으로, 아직 설치되지는 않았다. |
|
unavailable |
런타임이 설치가 불가능한 환경이다. |
|
installed |
런타임이 이미 설치되어 있다. |
getStatus 메서드를 호출해서, AIR 런타임이 이미 설치되어있거나, 설치가 가능한 환경이라면, 다음 환경으로 진행 하고, 설치가 불가능한 환경이라면 사용자에게 적절한 에러메세지를 출력하면 됩니다.
AIR 런타임이 설치 되지 않은 환경이라도, 다음 과정을 진행하는데 별도의 메서드를 호출할 필요가 없으며, AIR 애플리케이션 설치과정중 자동적으로 진행됩니다.
AIR 런타임이 실행이 가능한 환경임이 확인되었다면, 설치할 AIR 애플리케이션의 설치 여부를 확인하는 과정으로 넘어가게 됩니다. AIR API에서는 getApplicationVersion 메서드를 이용하여, AIR 애플리케이션 설치 여부를 알아낼 수 있습니다.
getApplicationVersion은 에플리케이션의 버전 정보를 알아내는 메서드 이지만, 반환된 버전 정보가 없을 경우 사용자의 컴퓨터에 사실상 아직 AIR 애플리케이션이 설치가 되지 않았다는 것을 확인할 수 있습니다.
getApplicationVersion 메서드의 매개변수는 아래와 같습니다.
|
매개 변수 |
설명 |
|
Appid |
응용프로그램의 고유 ID, 디스크립터 파일의 id엘리멘트와 같다 |
|
Pubid |
응용프로그램의 배급자 ID |
|
callback |
헨들러 함수 역할을 하는 콜백 함수를 지정한다. 메서드를 호출후 버전정보를 확인할 수 있거나 없을경우 콜백 메서드가 호출되며, 콜백 메서드는 버전 문자열을 담은 매개변수가 하나 포함되어야 한다. 응용프로그램이 설치되지 않은경우 버전 정보는 null 값으로 지정된다. |
getApplicationVersion 메서드는 비 동기적으로 호출되기 때문에, 사용자의 컴퓨터에 AIR 애플리케이션의 설치 여부를 알기 위해서는 반드시 콜백 함수를 지정해주어야 합니다.
또한, getApplicationVersion 메서드의 매게변수를 모두 지정해주어야 정상적으로 메서드가 호출됩니다.
사용자의 컴퓨터에 AIR 애플리케이션의 설치여부를 확인 하였다면, 사용자의 환경에 따라 AIR 애플리케이션을 설치 또는 실행을 진행 할 수 있습니다.
AIR 애플리케이션의 설치를 할 수 있는 AIR API의 메서드는 installApplication가 있습니다.
특별히 유의해야 할 점은 installApplication 메서드는 사용자의 마우스 클릭과 같은 직접적인 인터렉션을 반드시 거쳐야 실행할 수 있습니다.
installApplication 메서드의 매개변수는 아래와 같습니다.
|
매개 변수 |
설명 |
|
url |
설치할 AIR 파일의 URL |
|
runtimeVersion |
설치할 AIR 애플리케이션의 필요한 런타임 버전 |
|
arguments |
설치시 시작되는 응용프로그램에 전달할 인수 |
위의 매개 변수중 arguments는 생략이 가능한 매개변수 이다. Argument는 설치 완료 후 시작되는 AIR 애플리케이션에 전달할 인수로, BrowserInvokeEvent를 통해 객체를 전달하게 됩니다.
이어서, AIR 애플리케이션 실행할 수 있는 AIR API의 메서드는 launchApplication 가 있습니다.
launchApplication은 실행될 AIR 애플리케이션의 디스크립터 파일의 설정이 중요한데, 반드시 allowBrowserInvocation의 설정이 true일 경우에만 실행이 가능합니다.
launchApplication 메서드는 앞서 설명한 installApplication 메서드와같이 사용자의 마우스 클릭과 같은 직접적인 인터렉션에 의해 동작해야 합니다.
launchApplication 메서드의 매개변수는 아래와 같습니다.
|
매개 변수 |
설명 |
|
Appid |
응용프로그램의 고유 ID, 디스크립터 파일의 id엘리멘트와 같다. |
|
Pubid |
응용프로그램의 배급자 ID |
|
aruguments |
애플리케이션이 실행될 때 전달할 인수 |
위의 매개 변수중 앞서 설명한, installApplication 메서드처럼 arguments는 생략이 가능한 매개변수 입니다. Arguments는 AIR 애플리케이션이 실행후 전달할 인수로, BrowserInvokeEvent를 통해 객체를 전달하게 됩니다.
지금까지 AIR 브라우저 API 파일에서 사용할 수 있는 메서드에 대해 알아보았습니다. AIR 브라우저 API 파일은 로컬에 있는 자원을 제어할 수 있는 만큼, 어도비 사이트에서 직접 로드해야 하며, 설치나 실행과 같은 동작은 마우스 클릭과 같은 사용자의 직접적인 인터렉션이 필요하다는 점도 주의하여야 합니다.
그럼 아래에서는 플렉스에서 AIR 브라우저 API파일을 이용해 AIR 배지를 커스트마이징 하는 방법에 대해 알아봅시다.
1. UI 설계
AIR 배지를 커스트마이징 하는 방법은 위에서 다루어 본 것 처럼, AIR SDK에 제공된 badge.fla 파일을 커스트마이징 하는 방법과, AIR 브라우저 API파일을 이용해 AIR 배지를 개발하는 방법이 있습니다.
Badge.fla 파일을 커스트마이징 하는것과는 달리, AIR 브라우저 API파일을 이용해 AIR 배지를 개발하는 것은, AIR 배지의 전반적인 사용자 인터페이스나 기능들을 모두 직접 설계하여야 합니다.
따라서, 가장 먼저 AIR 배지에 포함될 기능에 대한 정의와, 유저 인터페이스를 설계하여야 합니다.
일반적으로, Adobe에서 제공하는 AIR 브라우저 API파일을 이용해 사용자에게 제공할 수 있는 정보는 아래와 같습니다.
- AIR 런타임 지원가능여부
- AIR 애플리케이션 설치 여부 및 버전
- AIR 애플리케이션 설치
- AIR 애플리케이션 실행
AIR 브라우저 API 파일을 이용해 제공할 수 있는 기능과, 부가적으로 추가할 기능들을 종합하여 사용자 인터페이스를 설계할 수 있습니다.
아래의 예제에서는 위의 그림과 같이 설치화면, AIR 런타임 지원 불가 환경 알림화면, AIR 애플리케이션 업데이트 화면 등으로 사용자 인터페이스를 설계할 것입니다.
이 예제에서는 화면 전환 및 설계에 viewstack 컴포넌트를 사용하였다. 물론, 이외의 UI컴포넌트를 적절히 활용 하여 AIR 배지 사용자 인터페이스를 설계할 수 있습니다.
2. AIR 브라우저 API 파일 불러오기
커스트마이징 할 AIR 배지의 기능정의와 사용자 인터페이스 설계를 모두 마쳤다면, 이제 본격적으로 AIR 배지에 대한 개발을 진행 할 수 있습니다.
AIR 브라우저 API 파일을 이용해 AIR 배지를 커스트마이징 하는 과정 중 제일 중요한 과정은 AIR 브라우저 API 파일을 불러오는 과정입니다. AIR 브라우저 API 파일은 Adobe 사이트에서 제공하며, http://airdownload.adobe.com/air/browserapi/air.swf 에서 불러와서 사용할 수 있습니다.
AIR 브라우저 API파일은 로컬에 있는 자원을 제어할 수 있는 만큼, 반드시 어도비 사이트를 경유하여야 사용할 수 있습니다. (Adobe에서 제공되는 AIR 브라우저 API파일을 내려받아 다른 위치에서 불러오는 경우 제공되는 메서드들을 사용할 수 없습니다.)
AIR 브라우저 API파일의 위치는 이후에도 변경되지 않기 때문에, swf 파일 위치 변경에 대해 크게 염려할 필요는 없습니다.
위의 예제는 Loader 클래스를 이용해 ,AIR 브라우저 API파일을 로드 하는 과정이다. 플렉스 기반으로 개발을 할 경우 ModuleLoader 컴포넌트를 활용해 AIR 브라우저 API 파일을 로드 할 수도 있습니다.
다만 주의할 점은, AIR 브라우저 API 파일은 Adobe 사이트에 위치하기 때문에, 외부 파일의 API를 사용할 수 있도록, ApplicationDomain 설정에 유의하여야 합니다.
3. 예외 처리
AIR 브라우저 API파일을 로드하였다면, 이제 AIR 브라우저 API파일에서 제공되는 메서드들을 활용할 수 있습니다.
일반적으로 가장 먼저 해야 할 작업은, AIR 애플리케이션을 설치할 수 없거나, 이미 설치되어 있는 사용자들에 대한 예외 처리입니다.
AIR 브라우저 API파일에서는 아래와 같이 사용자 로컬 환경에 대한 정보를 제공한다.
- AIR 런타임이 설치여부
- AIR 애플리케이션이 설치여부
AIR 런타임의 설치여부는 설치가능, 설치됨, 설치불가와 같이 총 세가지 분류로 제공되며, 사용자의 환경이 설치 불가(unavailable)일 경우에는 별도의 예외처리를 해주어야 합니다.
그리고, 사용자의 컴퓨터에 AIR 애플리케이션이 설치되어 있는지 체크하는 것도 좋다. 설치된 AIR 애플리케이션의 버전과, AIR 배지에 포함된 애플리케이션의 버전이 다를 경우 업데이트를 유도할 수 있고, AIR 애플리케이션을 실행 할 수도 있습니다.
다만 주의해야할 점은, 사용자의 컴퓨터에 AIR 애플리케이션의 설치 여부를 확인할때에는 애플리케이션의 ID, 배급자 ID가 필요합니다.
애플리케이션의 ID는 디스크립터에서 설정한 ID 엘리멘트 이다. 배급자ID는 ADT에서 AIR 애플리케이션을 패키징 할 때 인증서를 기준으로 자동 생성되는 고유 정보로, 해당 인증서를 계속 사용한다면 배급자 ID는 동일합니다.
배급자 ID정보는 NativeApplication.nativeApplication.publisherID를 통해 알 수 있습니다.
애플리케이션의 ID와, 배급자 ID가 모두 일치하여야, 설치 여부가 정상적으로 리턴되므로 유의하여야 합니다.
(AIR SDK에 포함된 badge.swf 에는 사용자의 컴퓨터에 AIR 애플리케이션이 설치를 체크하지는 않습니다.)
위의 예제에서는, AIR 런타임의 설치가 불가능한 환경에서는, AIR 애플리케이션이 설치가 불가능하다고 알려주고, 설치가 가능한 환경에서는, AIR 애플리케이션의 설치 여부를 체크해, AIR 애플리케이션이 이미 설치되어 있는 경우, 설치된 애플리케이션의 버전 정보를 알려주게 됩니다
.
4. 동작 처리
AIR 배지의 예외 처리과정은 꼭 필요한 과정은 아니지만, 사용자의 환경을 분석해 좀 더 직관적인 설치 과정을 제공하기 위해서 반드시 처리해 주는 것이 좋습니다.
예외 처리를 모두 마쳤다면, 이제 마지막으로 AIR 배지의 여러 동작들을 처리하는 과정만 남았다. AIR 브라우저 API파일을 이용하여, 다음과 같은 동작을 처리 할 수 있다.
- AIR 애플리케이션을 설치한다.
- AIR 애플리케이션을 업데이트한다.
- AIR 애플리케이션을 실행한다.
일반적으로 AIR 배지에서 사용자들은 AIR 애플리케이션을 설치, 업데이트 하거나 실행하는 동작을 처리하게 됩니다.
AIR 애플리케이션을 설치 할 때에는, 패키징된 .air 파일의 주소, AIR 런타임의 버전 정보가 필요합니다.
그리고, 위에서는 업데이트를 별도의 카테고리로 빼두었지만, 사실 AIR 애플리케이션을 설치하는 동작과 함께 처리하면 됩니다.
AIR 애플리케이션 설치 과정 중 이미 설치된, AIR 애플리케이션의 버전과, AIR 배지에서 설치할 AIR 애플리케이션의 버전이 다르다면, 표준 AIR 애플리케이션 업데이트 화면이 나오게 됩니다.
AIR 애플리케이션을 실행할 때에는 반드시, 애플리케이션 ID와 배급자 ID가 필요하며, 설치된 AIR 애플리케이션의 디스크립터 설정중 allowBrowserInvocation가 true일 경우에만 실행이 가능합니다.
(AIR SDK에 포함된 badge.swf에는 AIR 애플리케이션을 실행하는 기능은 포함되어있지 않습니다.)
위의 예제는 airinstall 메서드를 호출하게 될 경우, AIR 애플리케이션의 설치와 업데이트 동작을 처리하게 되며, airexecute 메서드를 호출할 경우, 설치된 AIR 애플리케이션을 실행하게 됩니다.
지금까지 AIR 브라우저 API파일을 이용해 AIR 배지를 커스트마이징 하는 과정에 대해 알아보았습니다.
그럼, 위에서 설명한 4가지 과정을 종합해, 플렉스 기반의 AIR 배지를 개발하는 예제에 대해 살펴봅시다.
위의 예제는, 사용자의 화면이 모두 초기화 된 이후 AIR 브라우저 API파일을 불러오고, AIR 런타임의 설치 가능 여부와, AIR 애플리케이션의 설치 여부를 확인하여, 사용자의 환경에 맞는 화면으로 전환하게 됩니다.
아울러, 전환된 화면에서 설치나 업데이트, AIR 애플리케이션의 실행과 같은 동작들을 처리할 수 있습니다.
지금까지, AIR 애플리케이션의 설치방법과, AIR 배지의 사용방법, 그리고 AIR 배지를 사용용도에 마침맞게 커스트마이징 하는 방법에 대해 알아보았습니다.
AIR 배지를 통해 AIR 애플리케이션을 배포할 경우, 몇몇 작업이 필요하지만 목적에 맞게 커스트마이징 하여 사용자들에게 좀 더 편리한 설치 환경을 제공 할 수 있고, AIR 애플리케이션 설치현황등의 자료 수집에도 활용할 수 있습니다.
일반적으로, AIR SDK에 포함된 badge.swf는 AIR 애플리케이션 설치 여부확인과, AIR 애플리케이션 실행은 지원되지 않습니다. 따라서, 부가적으로 위의 기능들이 필요하다면, AIR 브라우저 API파일을 이용한 커스트마이징을 하는것이 좋고, 그리고 간단한 UI 편집이나 기능추가는 AIR SDK에 포함된 fla 파일이나 as파일을 활용하는 편이 유용합니다.
아울러, AIR 브라우저 API 파일을 이용해 커스트마이징 한 AIR 배지를 주로 사용한다면, ASDOC이나 코드 힌트 팝업등을 활용하려면 별도의 클래스를 만들어 두는 것이 좋습니다.



