Android : 이진 데이터를 위한 데이터 저장

이진 데이터를 위한 데이터 저장
안드로이드 SDK 문서는 컨텐트 프로바이더가 비트맵이나 음악 클립 같은 바이너리 데이터를 저장할 때 데이터는 데이터베이스 외부에 파일로 저장돼야만 하고, 컨텐트 프로바이더는 파일을 가리키는 데이터베이스의 content:// URI를 저장하라고 제안한다. 클라이언트 애플리케이션은 컨텐트 프로바이더에 content:// URI를 찾기위해 질의를 하고, URI가 가리키는 파일에서 실제의 바이트 스트림을 추출할 것이다.
이런 간접 방식을 사용하는 이유는 다음 몇 가지 사항을 살펴보면 이해하기 쉽다. 파일시스템은 SQLite blob를 다루는 것보다 훨씬 빠르고 다재다능하기 때문에, SQL blob보다 유닉스 파일시스템을 사용하는 편이 더 낫다. 그러나 안드로이드 애플리케이션은 다른 애플리케이션이 만든 파일을 읽고 쓸 수 없기 때문에 데이터를 접근하는 데 컨텐트 프로바이더를 사용해야만 한다. 그러므로 첫 번째 컨텐트 프로바이더가 데이터를 포함한 파일을 가리키는 포인터를 리턴할 때 그 포인터는 유닉스 파일이름 대신에 content:// URI형태여야만 한다. content:// URI 사용은 파일에 접근할 권리가 없는 클라이언트 애플리케이션이 그 파일을 소유한 컨텐트 프로바이더의 권한 아래에서 그 파일을 열고 읽기를 가능하게 한다.

CREAT TABLE user ( _id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, password TEXT, picture BLOB };

이런 방식의 파일 접근을 구현하기 위해서 위와 같은 사용자 테이블을 만드는 대신 안드로이드 SDK 문서에서는 다음처럼 두 개의 테이블을 제안한다.

CREATE TABLE user ( _id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, password TEXT, picture TEXT ); CREATE TABLE userPicture ( _id INTEGER PRIMARY KEY AUTOINCREMENT, _data TEXT );

user 테이블의 picture열은 userPicture 테이블의 행을 가리키는 content:// URI를 저장한다. userPicture 테이블의 _data 열은 안드로이드 파일시스템의 실제 파일을 가리킨다.
파일의 path가 user 테이블에 바로 저장된다면, 클라이언트는 그 path를 가져올 수는 있지만 실제로 파일을 열지는 못한다. 파일은 컨텐트, 프로바이더를 제공하는 애플리케이션의 소유고 클라이언트는 파일을 읽은 권한이 없기 때문이다. 그러나 아래 방식에서는 파일로의 접근이 ContentResolver 클래스에 의해 제어될 수 있다.
ContentResolver 클래스는 요청을 처리할 때 _data 열을 찾는다. _data열이 가리키는 파일을 찾으면 클래스의 openOutputStream 메소드는 파일을 열고 java.io.OutputStream을 클라이언트에 리턴한다. java.io.OutputStream은 클라이언트가 파일을 직접 열 겨우 리턴되는 객체와 동일한 객체다. ContentResolver 클래스는 컨텐트 프로바이더가 속한 애플리케이션에 속하기 때문에 클라이언트가 열지 못하는 파일도 열 수 있다.