AIR 환경은 여타 데스크탑 어플리케이션처럼 자동 업데이트의 구현 가능을 제공합니다. 하지만 플래시로 AIR 어플리케이션을 제작할 때는 자동 업데이트를 구현할 수 있는 컴포넌트가 플래시 내에 없기 때문에 플렉스 SDK의 컴포넌트들을 가져와야 합니다. 업데이트를 구현하기 위해 SDK에서 가져올 최소한의 컴포넌트는 ApplicationUpdaterUI이며 이 컴포넌트를 가져오는 방법은 아래와 같습니다.

  1. File > Publish Settings 선택
  2. 컴파일 세팅 패널에서 Flash탭 클릭
  3. Player: Adobe AIR 1.5  / Script: Action Script 3.0 선택
  4. Script 텍스트 창 옆에 [Settings...] 버튼 선택
  5. Library Path 탭 선택
  6. [+]버튼 (Add New Path) 선택하여 새 주소창 영역 만든 후 Browse to SWC file 버튼 클릭
  7. 파일 선택 패널로 컴포넌트 선택
    (Flex SDK가 있는 폴더)\frameworks\libs\air\applicationupdater_ui.swc



 이렇게 컴포넌트를 가져온 후에 사용하는 방법의 예는 아래와 같습니다.

import air.update.ApplicationUpdaterUI;
//그분 모셔오기

var exampleUpdater:ApplicationUpdaterUI = new ApplicationUpdaterUI();
// 업데이트 폼 객체 생성
var configFile:File = new File("app:/update-config.xml");
// 설정 정보를 담은 xml파일을 File 객체로 생성 

exampleUpdater.configurationFile = configFile;
// xml에 담긴 설정 정보를 업데이트 폼 객체에 적용
exampleUpdater.initialize();
//설정 정보에 맞춰 업데이트 폼 객체의 초기화





 업데이트 설정 정보를 담은 update-config.xml는 AIR  패키지를 생성할 때 함께 추가되어 배포될 것입니다. 이 xml 파일은 사용자의 컴퓨터에 설치되어 해당 어플리케이션이 업데이트 정보를 어떻게 확인하고 어디서 확인하는지에 대한 정보를 담고 있습니다. XML 구조는 아래와 같습니다.

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://ns.adobe.com/air/framework/update/configuration/1.0" >
   <url>'update-descriptor.xml'이 있는 경로</url>
   <!-- 최신 업데이트가 있는지 확인할 수 있는 서버측 xml //-->
   <delay>1</delay>
   <defaultUI>
       <dialog name="checkForUpdate" visible="true" />
       <dialog name="downloadUpdate" visible="true" />
       <dialog name="downloadProgress" visible="true" />
       <dialog name="installUpdate" visible="true" />   
       <dialog name="fileUpdate" visible="true" />   
       <dialog name="unexpectedError" visible="true" />
       <!-- 상기 설정에 관한 자세한 정보는 검색을 이용 | 일단 모두 true 설정 //-->
   </defaultUI>
</configuration>



 이렇게 사용자 컴퓨터는 이 xml 설정 정보를 이용해 최신 업데이트가 있는지 확인합니다. 하지만 최신 업데이트가 있는지 확인할려면 서버측에도 업데이트 정보를 가지고 있어야겠지요? 이 역활을 해주는 것이 update-descriptor.xml입니다. 내용은 아래와 같습니다.

<?xml version="1.0" encoding="utf-8"?>
<update xmlns="http://ns.adobe.com/air/framework/update/description/1.0">
    <version>1.0</version>
    // 버전 설정 | 사용자 컴퓨터는 이 버전의 숫자로 파일의 버전을 식별
    <url>최신 업데이트용 패치 파일 *.air</url>
    <description><![CDATA[
        업데이트 내용을 서술하는 곳 | 릴리즈 정보로 나오게 됨
    ]]></description>
</update>



 이제 업데이트 구현을 위한 기본적인 구색은 갖춰졌습니다만 한가지 문제가 있습니다. 서버측에서 최신 버전을 확인하기 위해선 checkNow()라는 함수를 사용하는데 이것을 사용할 때는 initialize() 함수를 실행한 후 서버측 요청이 끝나야 사용가능하다는 것입니다. 쉽게 설명드리자면...

exampleUpdater.initialize();
exampleUpdater.checkNow();



 이렇게 하면 작동이 안된다는 것이지요. 이 문제를 해결하기 위해서는

  1. [업데이트 확인]이라는 버튼을 따로 만들어서 이 버튼을 클릭할 경우에 checkNow()를 실행시키거나 (이 버튼을 클릭할 때에는 이미 업데이트 객체의 initialize가 완료되어 있으므로)
  2. Timer객체를 이용하여 일정 시간 이후에 실행되거나

 둘중 하나를 선택해야할 것입니다.


 저 같은 경우엔 1분 간격으로 서버의 update-descriptor.xml에서 version정보를 주기적으로 읽어들여 사용자 컴퓨터의 버전 정보와 비교 후 같으면 checkNow() 함수가 실행되게 해놨습니다. 자세한건 설명드리 않겠습니다.(나도 먹고 살아야지;;) 한가지 힌트를 드리자면...

 NativeApplication.nativeApplication.applicationDescriptor를 이용해서 해당 어플리케이션의 버전과 이름 정보를 xml로 return 받을 수 있습니다. 여기서 버전 정보를 추출해 서버측 update-descriptor.xml의 버전 정보를 비교하면 되는 것이지요.

 건투를 빕니다.


참고 자료 : http://www.adobe.com/devnet/air/flash/quickstart/update_framework.html

저작자 표시 비영리 변경 금지
Posted by 정 영진

트랙백 주소 : http://www.weblind.com/trackback/101 관련글 쓰기

  1. Subject : 정영진의 생각

    Tracked from buckard's me2DAY 2009/07/21 14:57  삭제

    플래시 AIR 어플 자동 업데이트 기술 개발 완료~ 핵심 기술은 단돈 9원에 팝니다. “5원짜리 한개와 1원짜리 네개를 구하는 정성만 있으면 오픈”

댓글을 달아 주세요

↑ 메인화면 (영문)

↑ 목록 화면 (중문)

↑ 상세 화면

↑ 지도보기 화면

↑ 지도보기 선택화면

↑ 이메일 주소 입력기 화면

 전체적인 UI 수준은 제가 기대한 것 이하입니다. 개발 업무량을 잘못 선정하여 시간이 촉박한 상황 속에서 UI설계를 고민할 수 있는 시간적 여유가 부족했기 때문입니다. 지속적인 업데이트가 꾸준히 이루어질 예정이기 때문에 이후를 기대해주세요. 물론 저는 죽어나겠지만요. ㅋㅋ

 키오스크의 시연 동영상은 이곳을 참조하시길 바랍니다.
저작자 표시 비영리 변경 금지
Posted by 정 영진

트랙백 주소 : http://www.weblind.com/trackback/92 관련글 쓰기

댓글을 달아 주세요


 경주 관광안내 도우미(T.I.S)는 경주시의 다양한 관광지들과 문화재, 숙박시설, 음식점들의 정보를 손가락으로 화면을 누르며 확인할 수 있는 터치스크린(touch screen) 시스템입니다. 이 시스템이 제공하는 서비스는 아래와 같습니다.
  1. 분류 검색 서비스를 제공합니다. 사용자들은 이 서비스를 통해 자신이 원하는 형태의 관광자원만 정리해서 확인할 수 있습니다.

  2. 지도 검색 서비스를 제공합니다. 사용자들은 이 서비스를 통해 검색 대상의 대략적인 위치를 확인할 수 있고 주변의 여러 관광자원들의 위치도 파악할 수 있게 됩니다.

  3. 여행카트 서비스를 제공합니다. 모든 관광자원들은 여행카트에 담을 수 있고 사용자들은 이 여행카트에 담긴 관광자원들을 이용해 간단한 여행 일정표를 만들 수 있습니다.

  4. 4개국 언어환경 서비스를 제공합니다. 경주를 찾아 온 외국인들도 한국 사람들과 동일한 서비스를 제공 받습니다.

  5. 그외 각종 다양한 서비스들을 제공합니다. 경주시의 각종 행사 일정을 확인할 수 있을 뿐만 아니라 오늘의 날씨, 공공시설 위치 등 여행자들이 원하는 수많은 정보들을 제공합니다.

 이 시스템은 경주역과 안압지 입구에서 이용할 수 있습니다.


<여행도우미(키오스크) 조작화면>

 이번 키오스크 프로젝트는 저에게는 정말 큰 경험이었습니다. 웹 어플리케이션을 제작할 때 플래시를 사용해본 경험이 있으니 데스크탑 어플리케이션(플래시 AIR)도 쉽게 가능할 것이라 단정하고 이번 프로젝트에 임한 것은 정말 큰 실수였습니다. 생각해야할 것들이 너무 많았지요. 또한, 명확한 설계서 없이 진행되고 프로젝트 내내 새로운 컨텐츠가 추가되다보니 시간에 쫓기고 UX는 엉망이 되었 의도한대로 만들 수 없었습니다. 개인적으로는 최악의 프로젝트 중 하나로 기억될듯 합니다.

  1. 자원관리 : 데스크탑 어플리케이션은 웹환경과 달리 자원 관리가 굉장히 중요한 요소입니다. 포인트를 일일히 지정해서 메모르를 관리해야하는 C언어와 틀리게 플래시 플레이어의 가비지 컬렉션이라는 인공지능 모듈이 알아서 메모리를 관리해줍니다. Adobe측에선 이 기능을 대대적으로 홍보하고 있지만 실제 이 기능은 빚좋은 개살구나 마찬가지입니다. 가비지 컬렉션의 동작을 유도하는 것은 쉬운 일이 아니며 개발자 스스로가 메모리 관리를 할 방법도 없기 때문입니다. (이것에 대해선 차후에 다시 한번 포스팅할 예정입니다)

  2. 문서 : 프로젝트 도중에 수정사항이 들어오면 코딩은 산으로 가기 시작합니다. UX 설계는 말할 것도 없구요. 개발 전에 이루어지는 문서 정리 과정의 소중함을 다시 깨닫게 된 계기가 되었습니다.

  3. 설계 : TIMER객체를 이용한 옵저버 패턴으로 대부분의 이벤트를 처리했는데 이것이 코딩의 양이 방대해지니 문제를 일으키더군요. 각 리스너는 0.1초에 한번씩 이벤트를 살펴보는 구조로 되고 이런 구조는 소규모 어플리케이션에서는 안전하지만 대규모 어플리케이션에는 반드시 문제를 일으킵니다. (코딩의 양을 계산해보니 대략 7000줄 쯤 되는 것 같더군요) 그렇다고 TIMER객체의 시간 설정을 0.1초가 아니라 0.01초로 더욱 민감하게 만들어 놓으면 CPU 점유율이 올라갑니다. 진퇴양난입니다.;; 다른 개발자 분들은 어떻게 하시는지 모르겠지만 TIMER객체로 이벤트를 감시하는 구조는 가능한 자제하십시오.

  4. 컴포넌트 : 이번 키오스크는 터치스크린 구조입니다. 터치스크린은 손가락으로 조작하기 때문에 일반적인 마우스 조작과는 다른 환경입니다. 이 때문에 플래시에서 제공하는 우수한 UI컴포넌트들을 모두 버리고 직접 제작해야했습니다. ㅡㅡ;; UI컴포넌트를 사용할 수 있느냐 없느냐에 따라 프로젝트의 전체 일정도 상당한 차이를 일으키더군요. 일정이 자꾸 밀리기 시작했고 이 때문에 근 2달간 새벽에 퇴근해야했습니다.

 AS3.0 / 플래시로 데스크탑 어플리케이션을 제작할 때는 웹 어플리케이션 제작 일정의 2배로 잡아야 안전할 것입니다. 플래시 AIR를 제작하는 개발자 분들께 참조가 되었으면 좋겠군요.

저작자 표시 비영리 변경 금지
Posted by 정 영진

트랙백 주소 : http://www.weblind.com/trackback/91 관련글 쓰기

댓글을 달아 주세요

 경주 관광 포털 사이트의 핵심 서비스 중에 하나인 여행카트 서비스는 사용자들이 웹서핑 중에 마음에 드는 여행지가 있으면 상품 카트처럼 여행지들을 카트에 담을 수 있는 서비스입니다. 사용자들은 이렇게 카트에 모은 여행지들을 정리해서 여행 일정표를 작성하거나 출력할 수 있습니다.



이번 여행카트 디자인과 설계의 특징은 대략 아래와 같습니다.
  1. 전체적인 UI디자인은 회색계통의 무채색을 사용했습니다.그래픽툴, 개발툴, 웹브라우저까지 총 망라한... 우리가 접하는 수많은 UI들이 회색을 사용하고 있습니다. 회색이 정보를 표현하는데 가장 명확하고 공정한 색이기 때문이지요. 이번 여행카트 디자인에는 다양한 형태의 관광지 사진이 들어가는데 이 다채로운 색상의 이미지들을 모두 받아내는 UI색상은 역시 회색 밖에 없다고 생각했습니다. 사용자들의 눈에 들어와야하는 정보는 UI디자인이 아니라 관광지 이미지니까요. (자세한 설명은 예전의 기사를 참고 하시길 바랍니다.)

  2. UI에서 큰 아이콘은 검정색으로 처리했습니다. 아이콘이 UI와 같이 회색이면 주목성이 떨어지고 유채색을 사용할 경우엔 정보객체(관광지 사진)의 주목성을 떨어지기 때문입니다. 아이콘이 작을 경우에는 유채색이어도 정보객체의 주목성을 떨어뜨리지 않기 때문에 적절히 사용해도 상관없습니다.

  3. 우측의 버튼으로 카트의 내용을 보여줄 수도 있고 숨길 수도 있게 했습니다. 커다란 카트가 항상 열려 있으면 사용하는데 무척 걸리적 거리겠지요?

  4. 플래시가 제공하는 기본컴포넌트의 디자인을 그대로 사용했습니다. 이런 디자인들은 가급적 손을 대지 않는게 좋습니다. 왜냐하면 이미 사용자들은 이러한 UI디자인에 오랜 기간 숙달되고 익숙하기 때문입니다. 새로운 디자인이 아무리 훌륭하고 아름다워도 사용자들이 그 디자인에서 "기능(Function)"을 빠르게 유추해내지 못하면 쓸모가 없는 것이지요. 그러므로 UI디자이너들은 가급적 기본 컴포넌트에 어울리게 UI를 디자인을 하는 것이 좋습니다.

  5. 여행지들의 이동과정을 유추할 수 있도록 디자인 했습니다. 한 화면에 관광지를 3개 밖에 넣을 수 없어 조금 아쉬웠지만 상단의 여행코스 탭의 괄호() 안에 여행지 갯수를 넣고 카트 좌우측에 < > 버튼과 여행정보 객체 사이에 → 버튼을 넣어 '여행 카트에 더 많은 여행지들이 숨어 있다.'는 사실을 사용자들이 유추해낼수 있게 했습니다. (할만큼 했는데 조금 아쉽네요)

  6. 상세목록 탭을 클릭하면 해당 여행 경로가 목록으로 나옵니다. 앞서 설명한 여행코스 탭에서 한 화면에 다 담지 못한 여행객체들을 도표로 한눈에 볼수 있게 했습니다. 그리고 우측에 간략히 정리된 문서형 정보가 나오기 때문에 도표를 잘 이용하는 사용자들에 큰 도움이 될 것입니다.

  7. 여행 정보객체들을 드래그해서 위치를 바꿀 수 있게 했습니다. 아마 대부분의 사용자들은 이 기능을 잘 몰라서 사용하지 않을 것입니다. 아직까지 인터넷 세상에서 드래그앤드랍 기능을 사용해볼 기회는 그렇게 많지 않으니까요.


각 여행지 객체에는 롤오버시 작은 메뉴가 나옵니다.
이 메뉴의 삭제 버튼과 드래그 등을 통해 여행 일정을 조정할 수 있습니다.
모든 이미지는 도트로 명확하게 표현했고 텍스트도 안티엘리어싱이 없습니다.


달력 컴포넌트입니다.
플래시CS3는 자체적으로 달력 컴포넌트를 제공하지 않아 만들어 써야 했습니다.
어설픈 컴포넌트 하나 만드느라 약간 애를 먹었네요.



도표의 사용빈도는 의외로 높습니다.
참신한 기획력과 디자인, 기술을 입힌 컨텐츠도 좋지만
다소 투박하더라도 이런 도표 컨텐츠를 추가로 넣어두면 웹카트의 사용성은 더욱 높아집니다.
(시간과 비용이 허락하는 선에서 말이죠)


(출처 : 조석 블로그)

 이번 경주 관광 포털의 여행카트는 쇼핑몰의 상품카트와 여행포털의 일정표 서비스의 장점들을 합친 서비스입니다. 다소 생소한 서비스지만 웹카트는 쇼핑몰 등을 통해 워낙 많이 접해본 서비스이니 첫 사용자들이 겪게 되는 사용성 스트레스는 그리 크지 않을 것입니다.
저작자 표시 비영리 변경 금지
Posted by 정 영진

트랙백 주소 : http://www.weblind.com/trackback/88 관련글 쓰기

댓글을 달아 주세요