태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

'adobe air'에 해당되는 글 6건

  1. 2009.01.14 멀티터치의 시대 곧 열리나? (5)
  2. 2009.01.11 AIR개발자라면 피해야할 실수 - Custom Chrome의 잘못된 활용 (7)
  3. 2009.01.11 개인을 위한 AIR인증서, 더 저렴하게 구입해보세요 (1)
  4. 2008.11.27 AIR 한글 삭제문제 해결하기 (20)
  5. 2008.10.27 개발자의 시각으로 살펴본 RIA서비스 - 픽짜(Piczza) (10)
  6. 2008.10.08 개발자없는 AIR 어플리케이션 (6)

멀티터치의 시대 곧 열리나?

몇년전까지만 해도 터치스크린은 고가의 장비였지만, 요즈음 저가형 터치스크린의 등장으로, 여러 기기들에 속속 도입되고 있습니다. 금융권 예금 입출금기를 비롯해, 병원의 키오스크와 같이 사용자의 직접적인 동작으로 정보를 안내해주는 기기도 있고,  PDA, 게임기 등에서도 도입하는 만큼 그 사용폭은 점차 넓어져 가고 있는데요.

닌텐도에서는 자사의 게임기에 터치스크린을 도입하여, 많은 매니아로 부터 호평을 받고 있다고 하네요.. ^^

사실 터치스크린의 가장 큰 장점은 사용자가 입력한 위치 정보가 사실상 마우스의 포인터 위치와 처리가 같기 때문에, 개발자가 터치스크린용 애플리케이션을 개발하는데 있어 큰 학습이 필요하지 않지만, 사용자에게는 꽤나 직관적인 경험을 할 수 있다는 점이 있죠.

사용자 삽입 이미지
 
이젠 단순한 터치스크린을 뛰어넘어, 요즘은 멀티터치를 지원하는 터치스크린도 속속 나오고 있습니다. 사실 기존 터치스크린은 하나의 포인트 밖에 인식을 못했지만, 멀티터치는 하나 이상의 포인트도 인식할 수 있다는 점인데요.

이러한 멀티터치는 애플의 맥북에서 가장 먼저 선을 보였습니다.

맥북의 트랙패드는 멀티터치를 지원하는데, 한개의 손가락을 올려놓으면 포인트 이동이 되지만, 두개 이상의 손가락을 올려놓으면 애플리케이션의 여러 기능들을 수행할 수 있습니다. 예를들어 두개의 손가락을 올려놓고 아래로 내려 놓으면 스크롤이 되는기능들이 있죠.
 
이후 애플에서는 아이폰, 아이팟과 같은 기기에서도 멀티터치를 선보여 큰 호평을 얻었습니다.
그리고 최근 마이크로소프트에서는 서피스 컴퓨팅이라는 멀티터치 컴퓨터를 발표한적이 있는데요. 한국에서는 디자인 올림픽 기간동안 국내에서 공개되어 큰 호평을 얻었다고 하네요.. ^^

사용자 삽입 이미지

그리고 얼마전 유럽 어도비MAX에서도 멀티터치 시스템이 탑재된 컴퓨팅 서비스를 공개한적이 있습니다. 바로, IntuiFace(http://www.intuiface.com/)라는 회사에서 만든 시스템 인데요.

회사 홈페이지를 들어가니 소프트웨어 개발 회사라고 하는데, 특히 요즘엔 멀티터치 스크린 관련 기술에 대해 관심이 많은 곳인가 보네요.. ^^


위의 동영상은 Adobe MAX에서 공개된 멀티터치 서비스 컴퓨팅을 시연하는 동영상인데요. 재미있는 점은 위의 서비스 컴퓨팅에서 사용중인 소프트웨어는 AIR 기반으로 개발되었다고 하네요.

물론 하드웨어적으로 멀티터치를 지원해야 겠지만 다만 아쉬운점은 Flash Player와 AIR런타임에서는 아직 멀티터치를 지원하지 않습니다. 따라서, 위의 서비스 컴퓨팅처럼 멀티터치를 구현하려면 별도의 애플리케이션의 도움을 받아 AIR 애플리케이션과 터치 정보를 주고 받아야 합니다.

아직 가격이 높아 대중화를 가늠하긴 힘든 시기지만, 애플과 MS에서도 멀티터치에 눈독을 들이는 만큼, 멀티터치도 이제 하나의 대세로 자리매김 해 나가는것 같습니다.

멀티터치가 대중화 되는 시대가 오면, 정말 마우스가 필요없는 세상이 오게 되는걸까요? ㅎㅎ

신고
트랙백 0 Comment 5

AIR개발자라면 피해야할 실수 - Custom Chrome의 잘못된 활용

AIR가 정식적으로 출시된지 약 1년이 지났습니다. 그간 AIR는 이베이, 나스닥, 파인툰등 외국기업들을 비롯해 국내에서는  GS이숍, 엠비안, 아이에스비엔샵 등이 속속 도입하면서 그 입지를 굳혀가고 있습니다. 전세계적으로AIR로 개발된 애플리케이션이 약 천만개에 이를정도로 그 파급력은 대단한데요.

Adobe AIR는 Flash Player에서 더 나아가 웹킷 엔진을 채용함으로써, 실제적으로 액션스크립트를 모르는 자바스크립트 개발자도 애플리케이션을 쉽게 개발할 수 있고, 추후 Alchemy를 활용해 C/C++ 컴포넌트를 그대로 AIR개발에 활용할 수 있는 만큼, 개발 언어의 폭도 상당히 넓은 편입니다.

그만큼, 보안적인 이슈를 비롯해 주의해야할 많은 이슈들이 존재하고 있으며, 그 이슈들이 사용자에겐 치명적인 결함이 되기도 합니다. 그와 관련된 이슈는 아래의 문서를 살펴보세요.
AIR개발자들이 공통적으로 하는 10가지 실수 - David Tucker

저는 위의 이슈들에 덧 붙여서, AIR개발자들이 반복적으로 하기 쉬운 실수들에 대해 연속적으로 다루어 보고자 합니다. 실제로 그런 실수는 매우 간단하게 수정할 수 있고, 또 예방할 수 있습니다.

여러분들은 어떠한 운영체제를 사용하고 계신지요? 국내에선 90%이상이 윈도우라고 대답하겠지요 ㅎㅎ 운영체제의 종류는 크게 윈도우/리눅스/유닉스 등이 있으며, 현재 대표적으로 많이 쓰이고 있는것이 윈도우XP와 MAC OS입니다.

그래픽유저인터페이스(GUI)라는 개념이 도입된 이후로, 사용자의 입력을 담당하는 마우스포인터가 생겼고, 또 여러 애플리케이션이 멀티태스킹 할 수 있도록, 창(Window)이라는 개념도 새롭게 생겨나게 되었습니다.

하지만, 운영체제를 장기간 사용하다 보면 다소 단조로운 UI에 질려서, 사용자가 스스로 디자인을 커스트마이징 하는 사례들도 늘어나고 있습니다. 윈도우 제품군에서는 이를 '테마'라고 해서 지원하고 있습니다. 이런 '테마'를 손쉽게 만들어서 배포할 수도 있습니다.

AIR에서도 GUI환경에서 하나의 애플리케이션의 실행공간인 창(Window)을 꾸밀수 있도록 아래의 세가지 방법으로 제공하고 있습니다.


System Chrome


시스템크롬(System Chrome)는 AIR개발시 기본사항으로써, 사용자의 운영체제의 UI를 그대로 불러와서 사용합니다. 따라서, 윈도우나 리눅스, 맥OS등에서도 모두 기본 UI가 적용되게 됩니다.

위 System Chrome의 가장 큰 장점은 바로 사용자에게 가장 친숙한 인터페이스를 제공한다는 점입니다. 해당 애플리케이션을 제일 처음 실행하는 사람이더라도, 익숙하게 사용할 수 있습니다.

하지만 단점으로는, 애플리케이션이 실행중인 창 전체의 인터페이스는 개발자가 변경 할 수 없다는 점입니다. 즉, 해당 애플리케이션이 실행중인 창 안의 인터페이스만 개발 할 수 있습니다.


Flex Chrome


Flex Chrome는 플렉스에서 개발중일때, System Chrome를 해제하게 되면 활성화 되게 됩니다. 어도비에서 기본적으로 제공하는 윈도우 템플릿인 Flex Chrome은 위의 System Chrome와는 달리 모든 운영체제에서 같은 UI로 보이게 됩니다.

다만, Flex Chrome는 System Chrome와 마찬가지로 애픙리케이션이 실행중인 창의 UI는 변경할 수 없고, 디자인의 자율성이 낮기 때문에 추천해 드리고 싶진 않습니다.


Custom Chrome


Custom Chrome는 영문 뜻 그대로, 애플리케이션이 실행중인 창 전체의 인터페이스도 커스트마이징 하는것을 의미합니다. 일반적으로 Flex에서 개발할땐, System Chrome와, Flex Chrome의 속성을 모두 해제하게 될경우, Custom Chrome로 설정되게 됩니다.


Custom Chrome으로 개발하려면(Flex 기준), 우선 [project-name]-app.xml 파일에서 systemChrome의 주석을 해제한후 none를 입력하고, [project-name].mxml파일에서 WindowedApplication에 showFlexChrome프로퍼티를 추가해 false로 지정해두면 됩니다.

사용자 삽입 이미지

그렇게 제일 처음 실행하게 되면 청옥색의 배경 위에 애플리케이션이 떠있는것을 볼 수 있는데, Flex에서 기본적으로 배경 색상은 청옥생이기 때문에 배경의 투명도를 주지 않게 되면, 위의 화면처럼 출력되게 됩니다. 투명도는 [project-name]-app.xml파일에서, transparent 프로퍼티의 주석을 해제한후 true 지정할 수 있습니다.

이러한 Custom Chrome는 애플리케이션 내부 뿐만 아니라 창 전체의 인터페이스도 완전히 커스트마이징 할 수 있고, 또 각 OS마다 새롭게 커스트마이징한 인터페이스를 똑같이 구현할 수 있습니다.


Custom Chrome를 잘못 사용하면 어떤 문제점이 있을까?
하지만 Custom Chrome를 지나치게 활용하면 큰 문제점이 있습니다. 위에서 설명드린것과 같이 System Chrome와는 달리 Custom Chrome는 창의 유저인터페이스 까지 커스트마이징 해버리기 때문에, 각 운영체제별로 똑같은 유저인터페이스가 적용되게 됩니다.

위의 점이 장점으로 보일수 있겠지만, 아래를 살펴보게 되면 그 단점에 대해 이해할 수 있을것입니다.
사용자 삽입 이미지
바로,  각 운영체제별 기본적으로 제공하는 사용자 인터페이스가 다릅니다. 우선 MAC OS X는 각 기능버튼이 왼쪽에 있는 반면, Windows Platform은 각 기능버튼이 오른쪽에 위치해 있습니다.

각 기능버튼이 세개지만 기능버튼의 배열 순서도 다릅니다. 우선 MAC OS X 는 각 기능버튼을 색깔별로 배열했지만, Windows Platform은 아이콘으로 배열되어 있고, 또 각 위치별 기능도 다릅니다.

또한, 각 창을 더블클릭했을때에도 MAC OS X는 창이 담기는 반면, Windows Platform은 창이 최대화되게 됩니다.

이것이 뭐 그리 대수냐고 생각할 수 있지만, 개발자가 자신이 사용하고 있는 운영체제에만 맞춰서 인터페이스를 구상하게 되면, 명백히 말해서 타 운영체제를 사용하는 사용자의 경험(UX)에 반하는 유저인터페이스를 제공하게 되는것입니다.

일단 대부분의 GUI기반 운영체제는 기본적으로 창이라는 단위에서 해당 애플리케이션이 실행되게됩니다. 하지만 MAC OS X를 사용하는 사용자에게 Windows Platform을 기반으로 구현된 인터페이스를 제공하면 어떨까요? 반대의 경우도 어떨까요? 이 경우 해당 애플리케이션을 사용하는 사용자에겐 큰 혼란을 일으킬 수도 있습니다.


그 문제점을 해결하는 방법은?
위의 문제는 해당 애플리케이션에 기능상으론 큰 문제를 일으키진 않지만, 사용자의 경험 측면에선 상당히 커다란 문제를 일으키게 됩니다.

AIR는 현재 윈도우, 맥을 정식적으로 지원하고 있고 리눅스는 현재 베타버전이 배포되어 있습니다. 추후, AIR2.0과 Flash Lite와 AMC의 결합형인 AIR "Stratos"가 나오는 만큼 AIR는 이제 크로싱 운영체제가 아닌 크로싱 디바이스로 까지 변모를 추진하고 있습니다.

그렇기 때문에, 가급적이면 System Chrome를 사용하여, 해당 애플리케이션이 실행중인 창의 UI는 변경하지 않는것을 권고하고 있습니다.

하지만 불가피하게 Custom Chrome를 이용하여 개발하는 경우엔 아래의 방법으로 위의 문제점을 해결 할 수 있습니다.

1. 다양한 OS의 UI를 파악한후, 디자인할것
우선 AIR가 지원되는 OS의 UI의 특징점등을 파악하는것이 중요합니다. 윈도우와 맥, 그리고 리눅스는 큰 차이가 있습니다. 특히 리눅스는 OS가 많고, GUI환경을 지원하는 애플리케이션이 많기 때문에, 통상적으로 윈도우,맥을 기반으로 디자인하는것이 바람직 합니다.
사용자 삽입 이미지
이렇게 각 운영체제의 UI와 기능들을 파악한후, 본격적으로 Custom Chrome도 각 OS에 맞게 디자인 하면 됩니다.

2. 애플리케이션 초기화시 사용자의 OS를 파악하여 인터페이스를 꾸밀것

이렇게 디자인된 각 UI들을 Flex에서는 ViewStack로 잘 분류해서 배치한 다음, 애플리케이션이 초기화될때, 사용자의 OS를 파악하여 적절한 UI를 선택하면 됩니다.

아래는 그 예입니다.




위의 예시는 해당 애플리케이션이 모두 초기화 될때 detectOS()를 호출해 사용자의 os를 확인한후, ViewStack를 전환하여 운영체제별로 다른 사용자 인터페이스를 제공하고 있습니다.


무엇보다 위의 방법은 이후 AIR가 더 많은 플랫폼을 지원할 경우 애플리케이션의 코드량이 더 많이 증가할 수 있기 때문에, 가급적 사용을 권장하지 않으며, 가장 좋은 방법은 사용자에게 가장 친숙한 경험을 제공할 수 있는 System Chrome를 활용하여 개발하는것이 좋습니다.
신고
트랙백 0 Comment 7

개인을 위한 AIR인증서, 더 저렴하게 구입해보세요

일전에 개발자없는 AIR 어플리케이션 라는 글에서, AIR인증서에 대해 소개해 드린적이 있습니다.

Adobe AIR는 플레이어인 Flash Player와는 달리, 데스크탑에서 돌아가는 런타임의 일종이기 때문에, 로컬의 많은 자원들을 경유할 수 있습니다. 따라서, 개발자가 마음만 먹으면 사용자의 주요 정보를 빼돌리거나 아니면 사용자의 컴퓨터에 해를 입힐 수도 있습니다.

사용자 삽입 이미지

그래서 Adobe에서는 공인된 서드파티 사로 부터 인증이 된 애플리케이션을 사용할 것을 사용자에게 권고하고 있습니다. 인증서를 개인적으로 생성할 수는 있지만, 사용자가 설치시엔 이런 경고를 표시하게 됩니다.

AIR 인증서를 발급해주는 서드파티사에는 Thawte나 VeriSign과 같은 회사가 있는데, 비싼 인증서 비용에도 문제가 있지만, 개인적인 용도로 개발하고 있는 사람은 이런 서드파티 사로 부터 인증서를 취득할수 없습니다.

사용자 삽입 이미지

그리고 얼마전, ChosenSecurity라는 회사에서도 AIR 애플리케이션용 인증서를 제공하기 시작하였습니다.

위 사의 인증서는 Thawte, VeriSign과는 달리 개인적인 용도로 발급이 가능하며, 인증서도 타사에 비해 100달러 저렴한 199달러(1년)입니다.

ChosenSecurity에서 AIR인증서를 발급받고 싶으신 분들은 아래의 페이지를 참고하세요.
TC Publisher ID Adobe AIR

지금 현재 환율을 고려하면 20만원대 중반으로 여전히, 개인적으로 구입은 부담스럽겠지만, 앞으로 더 많은 서드파티사들이 등장하게 되면, 조금 더 가격이 내려가지 않을까요? ㅎㅎ

앞으로 많은 애플리케이션에서 AIR 공인인증서가 활용될수 있는 날이 오길 바랍니다.
신고
트랙백 0 댓글 1

AIR 한글 삭제문제 해결하기

방문자수는 많고, 댓글은 적은 저의 블로그에 반가운 트랙백이 걸렸습니다. 바로 에어레네님께서 AIR에서 한글 삭제 문제를 해결한 방법에 대해 다룬 글이었는데요.
(AIR1.1 이후 한글 입력 버그 수정하기 - 에어레네)

사실 저도, 이와 관련된 버그리포팅도 많이 해봤고, AIR 1.5에서는 이런 문제가 고쳐지지 않을까 기대해 봤는데, 이번 릴리즈에 픽스가 되지 않아서 무척 아쉬웠습니다.

그럼 잠시, AIR1.1이후 발생한 한글 삭제 문제에 대해서 정리하도록 하겠습니다.

사용자 삽입 이미지

기존의 플렉스의 Textinput 컴포넌트에서는 한글 문자열을 백스페이스(←)를 눌러서 삭제하게 되면 깔끔하게 잘 삭제되었는데,

사용자 삽입 이미지

AIR 1.1이후 부터는 유독 한글문자열에서만 백스페이스(←)를 눌러 삭제하게 될경우 항상 가장 마지막 글자의 자음이 남게 되는 문제가 발생하게 되었습니다.

특히 이런 문제는 AIR1.0 에는 없던 문제였는데, AIR1.1이 출시된 이후 발생이 되어서 무척 실망스러웠습니다.

저도 이런 버그를 잡아 볼려고 많이 노력을 했는데, 역시 단무지(단순, 무식, 지....)인 저는 해결방법을 찾질 못하겠더라구요. 결국 고수님들의 따스한 은총을 기다리고 있었는데, 오늘 에어레네님께서 그와 관련된 해결방법을 남겨주셨네요.

에어레네님의 해결방법은, keyup이벤트가 송출될때마다, 벡스페이스가 눌러져 있으면, 이전의 문자열과 비교해서, 한글자가 남게 되면 삭제를 시켜주는 방법입니다.

앗 역시! 멋진 에어레네님 이다! 라고 감탄을 한번 하고,
저는 여기서 살짝 저의 생각을 더해, 한글 삭제 문제를 해결해보았습니다.


AIR1.1 이후버전에서는, 한글 삭제시 TextField의 포커스를 나타내는 EndIndex가 문자열보다 한글자 앞에 위치하는 문제가 있습니다. 따라서, 문자열을 삭제할때, 제일 마지막 문자의 자음이 남는 문제가 발생하게 됩니다.

이런 문제를 해결하기 위해, keydown 이벤트가 송출될때, 사용자가 누른 keycode를 체크해서 백스페이스(←)를 누르고 있을때, EndIndex를 1만큼 더해주면, 이런 문제가 말끔히 해결됩니다.

keydown 이벤트를 사용한 이유는, 사용자가 백스페이스(←) 키를 쭉 누르고 있을경우, keyup 이벤트는 한번 송출된것 밖에 안되기 때문에, 그런경우엔 제일 마지막 글자의 자음이 남게 됩니다.

위의 해결 방법으로 TextInput뿐만 아니라 TextArea에도 적용해서 AIR 1.1 이후 부터 발생한 한글삭제 문제를 해결할 수 잇을것이라고 생각합니다.

위의 컴포넌트는 어떤 용도에서든 사용하셔도 좋습니다.. ^^

무엇보다 근본적으로 이런 한글 입력 문제들이 많은 개발자분들의 버그리포트를 통해  빠른 시일 이내로 해결 될 수 있기를 간절히 희망합니다.

그런의미에서 지금까지 발견된 한글 입력문제들 보러가기!

(앗 그리고, 이 글은 제 블로그에 올리는 100번째 글이네요!! ㅋㅋ 축하축하 ㅋㅋ)

신고
트랙백 1 Comment 20

개발자의 시각으로 살펴본 RIA서비스 - 픽짜(Piczza)

안녕하세요. 주인장입니다 ^^;;
요즘 글이 많이 뜸했죠? ㅎㅎ 역시 유령블로그라 주인장의 안부는 아무도 안물어주시고!! ㅎㅎ

사실, 웹엡스콘 행사때문에, 여러가지로 많이 피곤해서 어제까지 뻗어있었습니다.
이제서야 겨우 정신을 차렸네요 @.@

앞으로 제 블로그에서 FP10과 CS4와 관련된 정보도 자주 다룰테니 앞으로도 많이 찾아와주시구요!
특히 블로그 방문자수가 하루에 300~400명정도 되는데 아무도 댓글을 안달아주셔서 살짝 삐쳐있습니다 ㅠㅠ
많이많이 달아주세요! 팍팍달어! 막막 달어!!


본론으로 들어가서, 현재 많은곳에서 RIA로 프로젝트를 진행하고 있고, 이런 서비스들이 많은 곳에서 활약하고 있습니다.
이번 웹엡스콘 행사의 런치패드에서도 RIA 기술로 개발된 곳이 5개사중 3곳이나 될정도로 RIA에 대한 열기가 후끈한데요!

그래서, 오늘부터 '개발자의 눈으로 살펴본 RIA서비스'를 연재할려고 합니다.
제 글은 아마 기획이나, 디자인쪽 보다는 '개발자'의 시각으로 살펴보기 때문에, 약간 난해하실 부분도 있을수 있겠지만, 이 서비스에 어떤부분에 RIA Technology가 반영되었고 그 효과는 어떤지, 많은 개발자 분들이 자세히 살펴보고 또 정보를 공유할수 있었으면 합니다.

오늘 처음으로 살펴볼 서비스는 바로 픽짜(Piczza)입니다!

사용자 삽입 이미지

픽짜는 엠비안에서 진행중인 프로젝트로, 얼마전 어도비플렉스 공식홈페이지 "Flex 구축사이트, '우리가 최고야'"에 선정되기도 했는데요.

픽짜는 파일배달시스템으로 백앤드 쪽에서는 ROR과 Mysql로 구현되어있고, 클라이언트 프로그램은 Adobe AIR로 구현되어 있습니다.

그럼 픽짜에는 어떤 RIA기술들이 활용되었는지 한번 살펴볼까요?


Custom Chrome(Adobe AIR)
Adobe AIR에서는 윈도우 창을 일반적으로 Chrome라고 부르며, 개발할 수 있는 Chrome은 총 3가지 종류가 있습니다.

일반적으로, 각 시스템별 윈도우창 템플릿을 사용하는것을 System Chrome, Adobe에서 별도로 만든 Chrome를 사용하는것을 Flex Chrome, 그리고 서비스별로 직접 새롭게 만드는것을 Custom Chrome라고 합니다.

System Chrome는 각 시스템 별로 윈도우디자인은 바뀌지만, 사용자에게 가장 익숙하다는 장점이 있으며, Flex Chrome, Custom Chrome는 운영체제가 다르더라도 보이는 윈도우 디자인은 모두 같습니다. 다만 Custom Chrome는 윈도우의 모든 기능, 디자인을 모두 직접 개발하여야 한다는 번거로움이 있습니다. 

사용자 삽입 이미지사용자 삽입 이미지

Piczza는 이런 Custom Chrome를 적절히 잘 활용하여 개발되었습니다. 사용자의 요구에 따라 창의 크기가 스르르 바뀌고, 또 윈도우의 오른쪽 공간을 넓혀 그 공간을 활용하여 회원가입을 할때도, 웹이 아니라 클라이언트에서도 바로 회원가입을 할 수 있습니다.

또 Piczza에서는 Custom Chrome에 들어가는 인터페이스들을 스킨화 해서 디자인을 바꿔볼수도 있고, 또 개발사가 아니더라도 사용자가 직접 스킨을 만들어 사용하고 배포할 수도 있습니다.


Native File Drag&Drop (Adobe AIR)
Flash/Flex의 AS3에는 DragManager라고 해서 각 UI객체들을 Drag&Drop하는것을 관리하는 API가 있습니다. Adobe AIR에서는 이 API를 좀더 확장하여 NativeDragManager가 추가되었습니다.

NativeDragManager은 DragManager과 마찬가지로, Drag&Drop을 제어하지만, Native Level의 Drag&Drop를 제어한다는 특징이 있습니다.

예를들어, 이 API를 활용하여 파일을 AIR 애플리케이션 내부로 드래그 할 수 있고, 또 AIR 애플리케이션 내부에서 애플리케이션 밖으로 내보낼 수 있습니다.
사용자 삽입 이미지사용자 삽입 이미지

보통 파일 업로더에서는 파일을 업로드 하기 전 우선 사용자가 업로드할 파일을 지정해서 업로드 하게 됩니다.
Piczza에서는 업로드될 파일을 추가할때, AIR의 NativeDragManager을 활용하여 사용자는 drag&drop로 간단히 추가할 수 있습니다.


Invoke Event (Adobe AIR)
여러 데스크탑 애플리케이션에서는 사용자의 편리성을 위해 .zip, .alz, .avi와 같이 특정 파일 확장자를 실행하게 되면, 연결프로그램 형식으로 해당 프로그램과 함께 실행됩니다.

Adobe AIR에서도 물론 연결프로그램 형태를 활용할 수 있습니다. 특정 파일을 애플리케이션과 함께 실행시킬때 발생하는 이벤트를 InvokeEvent라고 합니다. 이 이벤트를 걸어두면, 프로그램이 실행시 함께 Dispatch 됩니다.

사용자 삽입 이미지사용자 삽입 이미지
Piczza에서는 사용자의 편리성을 위해 Native Drag&Drop뿐 아니라, 해당 파일에서 오른쪽 클릭을 해서 파일을 전송목록에 추가하는 기능을 확장형 플러그인 형태로 배포하고 있습니다.

다만 아쉬운점은 해당 플러그인이 윈도우 기반으로 개발되었기 때문에, 윈도우환경에서만 작동을 한다는 점입니다.


대용량 파일의 안정적 전송
Flash/Flex에서 파일을 전송할 때엔, 파일 업로드와, 다운로드와 관련된 Filerefrence API를 활용합니다. 다만, 이 API는 HTTP로 전송되기 때문에, 대용량 파일을 전송할경우 Back-end계열에서 해당 파일의 데이터를 모두 받을때 까지 계속 실행되게 되어 부하를 주게 되기 때문에 대용량 파일의 안정적인 전송이 힘들다는 점이 있습니다.
사용자 삽입 이미지
Piczza는, 4GB의 대용량 파일까지 지원하게 되는데, 만약 이와같은 대용량 파일을 Filerefrence로 전송하게 되면, 해당 파일을 전송받게 되는 Back-end에서도 막대한 부담을 느끼게 되며, 파일의 안정적인 전송도 힘들어 질 것입니다.

사용자 삽입 이미지

하지만 Piczza에서는, 이런 대용량 파일을 전송하는데 있어서, Filerefrence를 활용하지 않고, 별도의 소켓통신을 활용하여, 파일을 전송하고 있습니다. (레퍼런스 참고)

Piczza의 사례와 같이, HTTP는 비동기적 전송 방식으로 한번에 모든 데이터를 전송해야 한다는 단점이 있지만, 소켓으로 데이터를 전송하게 될경우 동기적으로 서버와 연결을 할 수 있으며, 파일을 나눠서 전송할 수 있기 때문에, 보다 안정적으로 고속의 전송이 가능하다는 장점이 있습니다.

이런 대용량 파일의 안정적 전송을 Adobe AIR를 활용해서 구현했다는 점이 흥미로운데, Adobe AIR는 기존 FP9와 달리, 로컬 파일의 ByteArray를 읽어 올 수 있습니다. 따라서, 대용량 파일을 전송할때 기존과 달리 파일의 ByteArray를 나눠서 읽어오고, 동기적으로 서버에 보낼수 있었기 때문에 안정적 파일 전송이 가능했습니다.


지금까지 Piczza에서 사용중인 RIA Technology를 알아 보았습니다. 픽짜는 국내 대스크탑 상용 애플리케이션 중 최초로 멀티플랫폼을 지원하고 Adobe AIR 기반을 통해 개발되었습니다. 또, 애플리케이션 내에서도 AIR의 기능들이 속속 잘 어울러져 있습니다. 리눅스, 맥, 윈도우환경에서도 Piczza를 통해서 파일을 간단히 배달할수있다는점! 정말 매력적이지 않나요? ㅋㅋ

Piczza는 앞으로 오픈소스로도 진행될 예정이라고 하니, 저도 긴장 가득 하고 있겠습니다! 또 외국어 서비스로 오픈될 예정이라고도 하니, 외국시장에서도 한국 IT의 진면모를 보여주시길 바랍니다!!!

마지막으로 제가 Piczza에 제안하는 서비스를 하나 말씀드리면서, 이만 물러가겠습니다 (__)


그럼 이런서비스는 어떨까요? Piczza on Web
Piczza는 대용량 파일도 안정적으로 전송해야하기 때문에, Filerefrence를 사용하지 않고, 별도의 네트워크 기능들을 구현하여 사용하였습니다. 무엇보다 이 Filerefrence가 '파일 선택, 파일 업로드, 파일 다운로드'등의 제한적 기능만을 지원하기 때문에 Adobe AIR의 사용이 필수적이었을 것입니다.

그리고, 얼마전(10월 16일) Flash Player10이 출시되었습니다. 물론 갑자기 바뀐 보안 샌드박스 때문에 많은 개발자와 사용자들에게 원성을 사고 있지만, 3D이펙트 추가, 커스텀 필터, FTE, 사운드 제어 등 강력한 기능들이 추가되었습니다.

그중 Filerefrence API에서도, 변화가 있었는데 load()와 save() 메서드가 추가되었습니다.
(참고자료 - [FP10] Filerefrence는 어떻게 달라졌을까?)
이 메서드들은 그간 Filerefrence는 클라이언트의 파일은 선택하고, 업로드, 다운로드하는데 국한되었지만, Adobe AIR와 마찬가지로, 파일의 Bytearray를 불러오고, 또 파일을 저장할 수 도 있습니다.

Piczza에서는 별도의 소켓통신을 이용해, 파일을 ByteArray를 나눠서 동기적으로 전송하여, 대용량 파일에서도 안정적 전송이 가능했는데, 이젠 웹기반인 Flash Player 10에서도 파일의 ByteArray를 불러올수 있고, 위와 같은방법으로 안정적 전송이 가능해졌습니다.

따라서, Piczza에서도 기존 AIR에서 활용했던 네트워크 업로드 기술을 활용하여, 웹으로도 크로싱플랫폼 기반 안정적인 파일 전송 시스템을 구현해본다면!!! 크아! 정말 멋지겠죠? ㅎㅎ

신고
트랙백 0 Comment 10

개발자없는 AIR 어플리케이션

Adobe AIR가 정식 출시된지 약 8개월여가 다 되어가네요. 좀있으면 1년, AIR 돌잔치는 어디서할려나 ㅎㅎ 기대중입니다.

 AIR가 Apollo라는 코드네임을 가지고 등장할때 부터 많은 분들의 주목을 받았던걸로 기억합니다. 당시엔 RIA가 대세였는데, 이 RIA환경을 그대로 끌어서 데스크탑으로 이어준다는게 비지니스 적으로나 혹은 플랫폼적으로 얼마나 성공적인가에 대한 회의도 많았던걸로 알았습니다.

 하지만 발매 6개월 사이에 2천 5백만 종의 수도없이 많은 응용애플리케이션이 등장하였습니다.(참고) 또한, 우리나라에서 옥션과 G마켓의 자회사를 가진 ebay에서도 ebay desktop을 개발하여, 다운로드수가 100만에 돌파했다는 얘기도 있군요 ㅎㅎ

 

 이처럼 AIR는 발매 8개월 만에, 국내외적으로 자바 이후 가장 강력한 크로싱플렛폼 런타임으로 자리매김 해 나가고 있습니다. 국내에서도 현재 많은 AIR애플리케이션이 개발되고 있으며, piczzame2day 팀에서도 AIR를 통해서 서비스를 하고 있습니다.

 또한 올 가을중 AIR 1.5(cosmo)가 출시되어 많은 변화가 예고됩니다. 그동안 고질적인 문제가 수정되고, 몇몇 기능들이 추가되고 또 FP10의 API들을 지원하는등, 여러 새로운 변화가 많은데요. 그중 가장 놀라운것은 AIR1.5부터 리눅스를 정식적으로 지원한다는 점입니다.

  

조금 옆길로 새서, 필자가 AIR의 장점중 가장 꼽고싶은것은 바로 AIR Badge 입니다. Java 애플리케이션의 배포과정중 생기는 단점중하나는 Java 런타임이 없는경우 클라이언트에서 Java런타임을 직접 내려받아 설치해야하는데, AIR Badge를 활용하면, AIR런타임이 설치 되어 있지 않은 환경이라도 번거로운 절차 없이 어플리케이션과 AIR런타임까지 함께 설치됩니다.

 또 사용자는 Install now만 누르면, 바로 설치 동작으로 이어지기 때문에 다운로드 후 실행 그리고 설치라는 불필요한 절차가 사라지게 됩니다.

 

 실제 대부분의 AIR 어플리케이션은 AIR Badge를 통해 배포되고 있습니다. AIR Badge는 프로그램을 설명하는 이미지, AIR 파일, 프로그램 설명등 몇가지 필요한 부분만 swf 파라미터로 넘겨주면 바로 사용할 수 있습니다.

 기존의 AIR Badge의 디자인이 마음에 들지 않는다면, 새롭게 커스트마이징을 해볼수도 있습니다. (참고)

 

 하지만 AIR 애플리케이션을 설치하다 보면, 뜻하지 않게 찝찝한 부분을 만날수 있습니다. 바로 "이 어플리케이션을 설치할거니?" 라고 묻는 중대 기로에, "제작자가 정식으로 인증받은 사람이 아니야! 신뢰할수 있는것만 깔래?"와 같은 그 애플리케이션 개발자에겐 다소 섭섭한 메세지를 보여줍니다.

   

AIR 애플리케이션에는 디지털 사이닝이라는 그간 플렉스,플래시 개발자에겐 다소 생소한 개념이 도입되었습니다. 디지털 사이닝이 필요한 이유에 대해선 Todd Prekaski가 아래와 같이 설명을 했습니다.

When users install your application, they're trusting you that you're not going to do sucky things, like sniff their files for financial data to upload to some server in a third-world country, or to delete all your local images, or to send e-mails on behalf of all your friends. Users want to feel confident that the software they're installing comes from a reliable vendor (publisher), and that what they're installing hasn't been modified since that vendor released it. As a developer, you build a great application and release it to the world. After it's released, though, you don't really have any control over other people taking my application, modifying it, injecting some evil bits, and then distributing it on your behalf. Users should be aware that anything they install from the web could be tampered with or come from an unreliable malware vendor.

출처 : http://www.adobe.com/devnet/air/articles/signing_air_applications_print.html

 (사용자가 당신의 어플리케이션을 설치할때, 당신이 제 3세계(?)와 같은곳에 사용자의 자료를 업로드하는건지, 또는 로컬의 이미지를 모두 지워버리는지, 친구들에게 모두 메일을 보내버리는것과 같은 나쁜짓을 하는게 아닌지에 대해 당신을 신뢰하고 있습니다. 사용자들은, 그 소프트웨어에 대해 믿을수 있는 게시자인지 그리고 게시자가 릴리즈한 이후로 변경된 사항이 없는지에 대해 확실한 느낌을 받길 원합니다. 개발자로서, 당신은 멋진 애플리케이션을 만들고, 그걸 세계에 릴리즈 합니다. 애플리케이션을 릴리즈 한후, 그러나 당신은 다른사람들에게 나의 애플리케이션이 전파되었다면 더이상 컨트롤을 할수 없습니다. 그것이 수정되거나, 몇몇 나쁜것이 끼어들더라도 그것은 당신의 몫이 되어버립니다. 사용자들은 웹으로 부터 설치한 애플리케이션이 손상되었거나, 신뢰할수 없는 멀웨어 개발자로 부터 온 것이라고 생각하게 됩니다.

 결론은 "웹으로 부터 내려받으니, 너는 제대로된 컨트롤을 하고, 사용자는 너를 신뢰하게 만들기 위해 필요해!" 라고 하네요 ㅠㅠ

(부족한 콩글리쉬 때문에.. 잘못 해석된 부분이 있으면 리플로 달아주세요! ㅎㅎ)

 그래서 어떻게 사용자들에게 신뢰를 주어야 할까요?

The only way to instill confidence in the end user is by requiring developers to digitally sign their applications with a security certificate from a trusted third-party vendor, such as Thawte or VeriSign, called a certificate authority (CA).

(설치시 사용자에게 신뢰를 줄수 있는 유일한 방법은 개발자가 Thawte나 VeriSign과 같은(이들을 CA라고 부릅니다.) 믿을수 있는 서드파티 게시자로 부터 어플리케이션에 서명을 요구하는 것입니다.)

 

왠지 모를 슬픔이 밀려오는군요... ㅠ 내가 신뢰할수 있는 존제인지 아닌지에 대해 검증을 받아야 한다니..
(전... 불순세력이 아니에요..)

이와 관련된 AIR 애플리케이션 서명 인증기관은 앞서 본문과 같이 Thawate와 VeriSign이 있습니다. 

Verisign은 얼마전인 8월 19일, AIR사이닝 인증 코드를 출시한다고 밝혔습니다. (참고)
Thawate는 이미, 인증 서비스를 오픈했습니다. 1년에 299달러, 2년이면 549달러로 그리 가볍지 않은 가격이네요..

그래서 이 신뢰할수있는(-_-) 기관으로 부터 인증서를 받고, 그 인증서를 포함시켜 릴리즈 하게 되면, 설치시에 제작자 정보가 정상적으로 출력 됩니다.

 

 또한 제작자의 ID가 확인되었다고, 밑에서 알려주네요..

다만, 시스템 엑세스의 경우 해당 프로그램에서 로컬에 있는 데이터에 접근하거나, 인터넷에 엑세스 할때는 여전히 빨간 표시로 나오게 됩니다.

(아마 이 부분까지 문제가 없다면, 노란색이 아니라 초록색 체크로 나오겠죠? ㅎㅎ)

 
물론 사용자에게 신뢰를 줘야한고 또 앞으로 다양한 디바이스에서 사용되어야 하기 때문에 디지털 사이닝이 필요하다는 부분에 있어 Adobe가 많은 고민을 했고, 또 실제 도입한것에 대해선 긍정적으로 평가합니다. 아니 당연한 것이겠지요.

 하지만, 공인된 기관으로부터 사이닝을 받지 못한 프로그램의 경우 그 프로그램이 사용자의 컴퓨터에 해를 끼치지 않음에도 불구하고, 빨간색의 경고가 출력되고, 제작자 까지 표시할수 없다는점에 있어선 큰 아쉬움이 남네요..

(사실 아래의 제작자 ID 부분만 확인할수 없음으로 출력해도 될것 같은데..)

신고
트랙백 0 Comment 6
prev 1 next