여러분께서 생각하시는 AIR의 막강한 장점은 무엇이라고 생각하시는지요? 웹킷엔진, 로컬데이터베이스 탑재 등 여러 장점이 있지만, 저는 로컬파일을 제어 할 수 있는 점을 가장 큰 장점이라고 생각합니다.
AIR가 아폴로(Apollo)라는 코드네임으로 처음 공개 되었을 때, Flash Player는 파일을 업로드하고 내려 받는 정도의 제어만 할 수 있었고, 웹 상의 데이터를 Loader등의 클래스로 내려 받아 Bytearray로 읽어서 파일을 읽는정도의 제어 할 수 있었습니다.
하지만, 아폴로에서는 Flash Player와는 별도의 여러 Native API들이 추가되어, 로컬의 파일 목록을 읽어 올 수 있었고 심지어 파일을 쓰거나, 디렉토리를 만들고, 제거하고, 읽는 등 거의 모든 파일 제어까지 가능했습니다.
지금은 Flash Player에서도 사용자의 직접적인 인터렉션이 취해진다면, 로컬에 파일을 쓰거나 읽어올 수 있지만 당시엔 정말 놀라운 일이었죠.
AIR가 1.5.2까지 릴리즈 된 현재, 파일 제어기능이 더욱 강화 되었고, 파일 제어와 관련된 샌드박스 또한 명세화되었습니다. 이번 글에서는, AIR의 파일제어 샌드박스에 대해 간단히 알아봅시다.
사용자 저장소(file:)
사용자 저장소는, 말 그대로 로컬의 모든 저장공간 즉 하드 전체라고 이해하시면 됩니다. 루트는 URL스킴으로, file:///로 나타낼 수 있습니다. file:///은 현재 사용자 하드의 모든 저장 공간을 통체적으로 나타내는 경로로, 파티션에 따른 드라이브 레이블도 아래와 같이 반드시 명시해주어야 합니다.
사용자 저장소를 유용하게 사용하기 위해 File 클래스에서는 데스크탑의 디렉토리, 사용자 디렉토리, 사용자 문서 디렉토리의 경로를 나타내는 프로퍼티가 있습니다. 아래의 소스코드는 사용자문서 디렉토리에 test.txt라는 파일을 쓰는 예입니다.
이처럼, AIR 에서는 거의 모든 사용자 저장소를 제어할 수 있지만, 사용자의 시스템과 직접적으로 영향을 미치는 디렉토리나 파일
은 제어할 수 없습니다. 아래의 소스코드는, 위의 예제처럼 Program File 디렉토리에 test.txt를 만드는 프로그램입니다.
위의 프로그램을 실행하게 되면, 아래의 스크린샷과 같이 File I/O Error가 발생하게 됩니다. 따라서, AIR 애플리케이션을 개발할 때에는 사용자의 시스템과 관련된 파일이나 디렉토리는 제어하지 않는 것이 좋습니다.
시스템 관련 이외의 파일들은, 파일을 읽거나, 쓰는 등의 모든 제어가 가능합니다.
리소스 저장소(app:)
리소스 저장소는 AIR 애플리케이션이 저장된 위치를 이르는 저장소를 뜻합니다. AIR 애플리케이션에서 사용된 에셋파일, 디스크립터 파일도 AIR 애플리케이션이 설치 된 후 이곳에 저장됩니다.
사용자 저장소에서 알아본 것처럼, AIR 애플리케이션은 시스템과 직접적인 연관이 있는 파일은 제어할 수 없기 때문에, URL 스킴은 app: 로 시작되며, 실제 이 디렉토리의 경로는 URL 스킴에 포함되지 않습니다.
리소스 저장소에 접근할 때, 한가지 주의해야 할 점은 File 클래스에서 desktopDirectory로 접근하지 말고, 반드시 applicationDirecory로 접근하여야 합니다. AJAX 기반의 개발자는 리소스를 불러올 때, app: 와 같이 URL 스킴으로 접근 하면 됩니다.
한가지 더 주의할 점은, 응용프로그램 저장소는 패키징된 파일을 읽을 수 있으나, 파일을 쓰거나 업데이트 하는 등의 제어는 할 수 없다는 점입니다.
위와 같이, 응용프로그램 저장소에 파일을 쓰게 될 경우에도, I/O Error가 발생하게 됩니다.
(개발 과정 중, ADL이나, ADT를 통해 테스트 하게 될 경우엔, 조금 다른 에러가 나올 것입니다. ^^;;)
응용프로그램 저장소(app-storage:)
응용프로그램 저장소는 AIR 애플리케이션에 별도로 마련된 저장공간으로, 어도비에서는 AIR 애플리케이션과 관련된 중요한 파일(로컬데이터베이스, 업데이트 파일)은 이 곳에 저장할 것을 추천하고 있습니다.
응용프로그램 저장소의 URL 스킴은 app-storage: 로 시작되며, 이 디렉토리의 경로는 URL 스킴에 포함되지 않습니다. 또한, 이 저장소는 앞서 리소스저장소처럼 applicationStorageDirectory로 접근하여야 합니다.
응용프로그램 저장소라고 하니, 저장될 위치가 감이 안 잡히는 분들도 있을 것 같습니다. 운영체제마다 다르지만, 보통은 아래의 경로에 저장됩니다.
응용프로그램 저장소는 파일을 읽고, 쓰고, 업데이트 하는등의 모든 제어가 가능합니다. 다만, AIR 애플리케이션에서 응용프로그램 저장소를 삭제 할 수는 없고, 사용자가 응용프로그램 저장소를 직접 삭제할 경우에도, AIR 애플리케이션을 다시 실행하면, 저장소가 다시 생성됩니다.
또, ADL과 ADT에서 AIR 애플리케이션을 실행할 때에도, 이 공간을 사용할 수 있는데, 다만 주의할 점은 AIR 애플리케이션이 아직 패키징 되지 않은 상태이기 때문에, 저장소 폴더명은 디스크립터 파일에서 정의된 애플리케이션ID만 사용되게 됩니다. 따라서, 패키징 후 AIR 애플리케이션이 설치 된 경우라도, ADL, ADT에서 사용한 응용프로그램 저장소 데이터는 엑세스 할 수 없습니다.
이 공간은 잘 활용하면, 꽤 유용한 AIR 애플리케이션을 개발 할 수 있는데, 대표적으로 AIR의 업데이트 프레임워크도 이 공간을 사용하여, 업데이트 관리 및 진행을 하게 됩니다.
그럼, 이 공간을 사용해야 하는 경우에 대해 생각해봅시다. AIR로 스케쥴 관리를 하는 애플리케이션을 만들었을 때, 웹을 통해 동기화 하는 기능과는 별도로 오프라인 상태에서도 사용자가 스케쥴이 가능하도록, 로컬에 데이터베이스를 구상하게 되었습니다.
하지만, 로컬데이터베이스 파일을 만들 때, 데스크탑 디렉토리나, 문서 디렉토리와 같이 비교적 사용자의 접근이 잦은 디렉토리에 생성하게 될 경우, 사용자가 이 파일을 삭제하여 AIR 애플리케이션이 정상적으로 동작하지 않는 경우가 발생하게 됩니다. 따라서, 사용자가 접근할 일이 거의 없는 응용프로그램 저장소에서 관리하는 것이 좋습니다.
이 처럼, 어도비에서는 AIR 애플리케이션과 관련된 직접적인 파일들은 반드시 응용프로그램 저장소에 쓸 것을 권장하고 있습니다. 다만, 이 공간 또한 사용자가 직접 파일을 쓰거나 지우는 등의 제어가 가능하기 때문에, 드물게 AIR 애플리케이션이 정상적으로 동작하지 않을 수 있습니다.
암호화된 로컬 저장소(EncryptedLocalStore)
암호화된 로컬 저장소는 그 동안, 알아봤던 여러 저장소들 처럼, 파일이나 디렉토리 개념이 아닌 데이터베이스 개념으로 봐야합니다. 따라서, File, FileStream 클래스로 제어할 수 없고, 별도의 클래스인 EncryptedLocalStore를 사용하여야 합니다.
암호화된 로컬 저장소 저장소는 AES-CBC라는 128비트 암호알고리즘을 사용하며, 다른 응용프로그램에서 이 데이터를 쓰거나, 업데이트 하는 등의 제어를 할 수 없습니다.
위의 예제는, 암호화된 로컬 저장소에 데이터를 쓰고, 읽고, 지우는 예제입니다. 암호화된 로컬 저장소에 데이터를 쓰거나 읽을 경우엔, 반드시 ByteArray를 사용하여야 합니다.
다만, 특수 저장소도 응용프로그램 저장소처럼, 드물지만 사용자가 직접 파일을 삭제할 수 있습니다. 그리고, 특수 저장소를 많이 활용할 수록, AIR 애플리케이션의 속도가 느려지기 때문에, 권장 하지는 않습니다.
