태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

'Air'에 해당되는 글 5건

  1. 2009.01.11 개인을 위한 AIR인증서, 더 저렴하게 구입해보세요 (1)
  2. 2008.11.27 AIR 한글 삭제문제 해결하기 (20)
  3. 2008.10.27 개발자의 시각으로 살펴본 RIA서비스 - 픽짜(Piczza) (10)
  4. 2008.10.17 검쉰님께서 책을 선물해주셨습니다 > < (12)
  5. 2008.10.11 [FLEX/AIR] 현재까지 발견된 한글처리 문제 (15)

개인을 위한 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 In Action을 소개하신글에 농담조로 '지르고 싶지만 총알이 문제네요ㅠ' 라고 농담조로 댓글을 남겼는데, 어랏! 검쉰님께서, 책을 선물해 주신다고 하시더군요.. +ㅁ+

책이 한권 더있으시거나, 보시던 책을 선물해주시는줄 알았는데,
죄송하게도 책을 한권 구입하셔서 보내주셨네요.. 흐억..!

사용자 삽입 이미지
ㅠㅠ Yes24에서 직접 구매하셔서,
오늘 도착했습니다.!
(중요한 부분은 모자이크처리 ㅎㅎ)
사용자 삽입 이미지
검쉰님의 멋진 메세지 '열공하세요! ;)'
넵!! 주신메모, 그리고 AIR IN Action
가보로 간직하고 열공하겠습니다.. ㅎㅎ 감사합니다!
사용자 삽입 이미지
인터넷으로만 봤던 책이 이렇게!!
AIR를 들고계시는 배불뚝이 아저씨의 뭔가 심오한 표정!!!
뭔가 모르게 AIR의 이미지를 한눈에 알아보는듯한 느낌이네요.. ㅎㅎ
(뭔가 중후하면서 심오한 데스크탑 애플리케이션 이라는 느낌인가!)

이야 ㅠㅠ 검쉰님 정말 감사합니다!
전, 농담조로 남긴 댓글이었는데, 이렇게까지 선물로 보내주시고... 흑흑흑..

괜히 실례가 되었는게 아닌지.. ㅠㅠ

정말 열심히 잘 읽겠습니다.
그리고 멋진 AIR 애플리케이션 많이 선보일수 있도록 노력할게요.

감사합니다 : )
신고
트랙백 0 Comment 12

[FLEX/AIR] 현재까지 발견된 한글처리 문제

어도비 플렉스가 국내 시장에 활발히 도입된지도 근 3년이 되어가고 있습니다. 지금 이시간에도 많은곳에서 플렉스를 도입하여 프로젝트를 진행하고 있습니다.

매크로미디어(현 어도비)에서 RIA 즉, '똑똑한 인터넷'이라고 제안한지도 약 5년이 되어갑니다. 그동안 정말 많은 변화를 겪었습니다. 또 올해엔 Flash Player 10(astro)가 출시를 예고 하고 있고, 내년엔 Flex 4도 정식으로 출시될 예정입니다.

하지만, 한국에선 아쉽게도 '똑똑한 인터넷'이 제 힘을 발휘하고 있지 못합니다. 한글조차 제대로 처리하지 못하고 있기 때문입니다. 한글을 사용하고 또 사랑하는 한국인으로써 제일 화가 나고 짜증나는 부분이기도 합니다. 많은 개발자들이 Flex 2부터 어도비에 수정을 요구했던 부분이지만 아직까지도 수정이 되고 있지 않습니다.

어도비에 빠른 수정을 바라면서, 현재까지 발견된 문제점과 해결법에 대해서 다루어 보고자 합니다.

우선 지금까지, 약 4가지의 문제가 알려져있습니다.

  1. 한글을 입력할때 영어나 숫자를 입력할때 보다 지연되는 현상이 있습니다.
  2. 텍스트 블록을 벗어날때 까지 해당 텍스트가 인식되지 않는 문제가 있습니다.
  3. wmode가 transparent일때 IE를 제외한 브라우저에서 한글이 입력되지 않는 현상이 있습니다. (FP-479)
  4. AIR 1.1에서 한글을 삭제할때, 자소 처리에 문제가 있습니다.

1번문제

플렉스에는 Textinput, TextArea, 또 전혀 Rich하지 않은 RichTextEditor컴포넌트를 통해 텍스트를 입력할 수 있습니다. 하지만, 이들 컴포넌트에는 한글 입력시, 영문이나 숫자보다 한글이 다소 지연되어서 입력되는 문제가 있습니다.

이런 문제가 플렉스 챔피언이신 신호승님에 의해 의외로 간단히(?) 해결되었는데, TextField의 alwaysShowSelection 프로퍼티의 값을 true로 바꿔주게 되면, 한글 입력 지연현상이 말끔히 사라집니다.

TextField의 alwaysShowSelection 프로퍼티를 true로 설정하게 되면 텍스트필드에 포커스가 없는경우, 선택영역이 회색으로 강조표시가 됩니다. 어째서 이렇게 해결이 되는지 저도 많이 궁금하네요.. ㅋㅋ

TextInput, TextArea, RichTextEditor의 TextField에는 바로 접근할수 없기 때문에, 별도로 mxml 컴포넌트나 as컴포넌트를 만들어서 해결해야 합니다.
 


하지만 위의 해결 방법은 문제점이 있습니다. 근본적으로 AlwaysShowSelection이 TextField의 강조표시와 관련된 프로퍼티이기 때문에, 여러개의 입력 컴포넌트를 사용하게 될경우 각 입력컴포넌트에 텍스트블록 잔상이 남게 됩니다.

무엇보다 이런 문제가 Flex 2 부터 제기되어온 문제인 만큼, Flex 3.2, Flex 4(Gumbo)에서는 꼭 해결될수 있길 바랍니다.
 

2번문제

이 문제는 앞서 설명드린 Flex의 입력컴포넌트 Textinput, Textarea, Richtexteditor에서 발생하는 문제입니다.
이들 입력컴포넌트에는 text 프로퍼티로, 해당 입력컴포넌트에 입력된 plain text를 받아올 수 있습니다.

하지만, 2byte 문자열을 입력하게 될경우 해당 문자가 텍스트블록에서 벗어나거나, 입력컴포넌트가 포커스 아웃 될때까지 text 프로퍼티에 정상적으로 인식되지 않는 문제가 있습니다.



예를들어 가방이라는 문자열을 입력할경우, "ㄱ", "가", "갑"의 경우 아직 텍스트블록에서 벗어나지 않았기 때문에 입력컴포넌트의 text프로퍼티의 값은 공백으로 인식됩니다.

물론 이들 입력컴포넌트는 다른 UIComponent를 클릭할때 포커스아웃이 되기 때문에, 버튼을 눌러서 정보를 보낼때에는 문제가 없지만, 입력컴포넌트의 입력값의 변화를 비 동기적으로 서버와 주고받아야 할 경우 문제가 발생하게 됩니다.
(예를들어, 구글의 검색어 제안이나, 우편번호 검색 등등..)

이 문제의 경우 TextField의 text 프로퍼티를 불러오게 될경우 정상적으로 해결 됩니다.
TextField는 각 입력컴포넌트에서 직접 사용할수 없기 때문에 mxml 컴포넌트나 as 컴포넌트를 만들어서 불러와야 합니다.




위의 예는 두개의 입력 컴포넌트에 keyup 이벤트를 걸어둔 예시입니다.

두 입력컴포넌트 모두, 한글자씩 입력할때 마다, 정상적으로 keyup 이벤트가 발생하지만, 첫번째 입력컴포넌트의 경우 text프로퍼티로 불러와서 해당 텍스트블록을 벗어날때까지 텍스트가 인식되지 않지만, 두번째 입력컴포넌트의 경우 위에서 정의해둔 ktext 프로퍼티로 textfield의 text를 불러오기 때문에 텍스트블록을 벗어나지 않더라도 한글자씩 정상적으로 인식이 됩니다.


3번문제

Flash Player의 embed, object에 넣을수 있는 프로퍼티중 wmode라는 프로퍼티가 있습니다. wmode는 삽입될 Flash의 투명정도, 계층정도, 배치정보등을 설정할 수 있습니다.

그중 transparent 설정이 있는데, flash 배경을 투명으로 설정해두면 뒤의 HTML 배경이 해당 flash에 빚추어서 보이게됩니다.

하지만 wmode 프로퍼티가 아직 완벽히 브라우저, 플랫폼을 지원하지 않기 때문에, 일부브라우저에서는 제대로 지원되고 있지 않습니다. wmode 프로퍼티의 transparent 설정과 관련된 문제는 Flex Bug and Issue Management System의 단골 과제가 되어버렸습니다.

특히 wmode프로퍼티에 transparent를 지정하게 될경우 인터넷익스플로러(IE)외의 브라우저에서는 2byte의 문자열이 정상적으로 입력되지 않는 문제가 있습니다.

이 문제를 해결할만한 꼼수는 아쉽게도 아직 없습니다. IE이외의 브라우저에서 한글 입력이 반드시 필요하시다면, wmode 프로퍼티에 transparent를 지정하는것을 피하시는게 좋겠습니다.

이 문제와 관련된 꾸준한 버그 리포팅이 올라와서, Flash Player 10에는 수정될것으로 기대 되었습니다만, 지금 현재까지 출시된 Flash Player 10 Beta에선 수정되고 있진 않습니다.


4번문제

이 문제는 아주 최근(2008년 6월 16일)에 AIR1.1이 릴리즈 되면서 발견된 문제입니다.
AIR1.1의 입력컴포넌트중 Textinput, TextArea, RichTextEditor에서 한글을 삭제할때 마지막 글자의 자음이 남게됩니다.


Flex에선 텍스트블록이 검정색으로 표시되고 backspace(←)로 삭제하게 될경우 모두 제거가 되지만,


AIR1.1에서는 텍스트 블록이 노란색으로 표시되어 있고, 또 프롬프트도 입력된 글자 이전에 위치해 있습니다.
이상태에서 해당 글자를 backspace(←)로 삭제하게 되면, 제일 마지막 글자의 자음이 남게 됩니다.

이 문제에 있어서 아직 마땅한 해결 방법은 없습니다.
또, 아이러니 하게도 바로 전 버전의 런타임인 AIR1.0에서는 이런 문제가 없습니다.

이 문제가 AIR1.1 릴리즈 이전에 제대로된 로컬라이징 테스트 부족으로 발생한 문제이기 때문에, 곧 릴리즈 되는 AIR 1.5에서는 반드시 고쳐지길 바랍니다.



우리나라는 타 국가에 비해 많은 분야에서 Flex/AIR를 통한 프로젝트가 활성화가 되어있습니다.
하지만, 아직 몇몇부분에서 한국어 조차 제대로 처리하지 못하고 있는 사실이 아쉽습니다.

곧 릴리즈 되는 Flex 3.2, Flex4에서는 반드시 이런 문제가 해결될수 있길 바랍니다.
신고
트랙백 0 Comment 15
prev 1 next