File, File Path, SharedPreferences

안드로이드는 내장 메모리 공간을 가진다. 이 공간은 리눅스 파일 시스템으로 되어 있으며 시스템 파일, 설치한 앱 파일 등이 이곳에 저장 된다. 앱이 설치 되었을때 그 앱이 사용할 수 있는 공간을 할당받게 되는데, 이 공간을 앱 홈 폴더라고 부른다.

앱의 홈폴더

data

data

패키지명(com.회사명.서비스명) -> 앱의 홈폴더

cache

files

Memo.obj

lib

위와 같은 구조로 구성 되어 있다.

이 앱의 홈 폴더 내부에 있는 디렉토리,파일의 path를 가져오기 위해서는 Context클래스의 함수를 사용하면 된다.

Context.getFileDir() -> 빨간색

Context.getFileStreamPath() -> 파란색

Context.getCacheDir() -> 캐시 파일들이 저장되는 경로

Context.getDatabasePath(파일명) -> 특정 데이터베이스 파일 경로를 얻어 온다.

외장 메모리 경로 참조

Environment.getExternalStorageDirectory()

-> 외장 메모리 루트 경로를 가져온다.

이렇게 외장 메모리의 경로를 함수를 통해 가져오는 이유는 단말기 제조사마다 외장 메모리의 경로가 다르기 때문이다.

외장 메모리는 PC와 휴대폰을 usb로 연결했을때 이동식 디스크로 인식되어 쉽게 데이터를 넣고 뺼수 있다. 그렇기 떄문에 보안이 취약할수밖에 없고, 중요한 데이터는 외장 메모리에 저장하지 않는것이 좋다.

외장 메모리에 파일을 읽고/쓰기 위해서는 AndroidManifest.xml에 권한을 추가해야 한다.

<uses-permission

android:name="android.permission.WRITE_EXTERNAL_STORAGE"

android:name="android.permission.READ_EXTERNAL_STORAGE"/>

이렇게 Manifest에 권한을 추가하게 되면, 사용자가 구글 플레이스토어 등에서 앱을 다운로드 받아서 실행시켰을때

이 애플리케이션을 설치할까요?

이 애플리케이션은 외장 메모리 수정/삭제를 수행합니다.

yes/no

와 같은 메세지를 띄운다. 즉, Manifest에 이러이러한 권한을 사용하겠다고 명시만 하고, 이 권한을 사용해도 문제가 발생할지 안할지는 앱을 설치하는 사용자가 선택하게끔 하는것이다.

FileInputStraem이나 FileOutputStream 클래스에서 사용하는 SD카드 외장메모리 경로를 구할때는 다음과 같이 해야 한다.

Environment.getExternalStorageDirectory().geAbsolutePath() + "저장할 파일명"

ex)

FileInputStream fis = new FileInputStream(Environment.getExternalStorageDirectory().geAbsolutePath() + "/Memo.obj");

fis를 통해서 Memo.obj에 적힌 텍스트를 바이트 형태로 읽어 올 수 있다.

공유 프레퍼런스

앱을 사용 하다보면, 앱의 설정 정보를 저장해야 할 필요가 있다. 이 설정 정보를 저장해 놓아야 나중에 다시 앱을 켰을때 그 설정 정보대로 동작 할 수 있다. 하지만, 이 설정 정보를 내장 또는 외장 메모리에 저장하기 위해서는 파일 입출력을 하는 코드를 짜야 하기 떄문에 여간 귀찮은게 아니다. 그리하여 편리하게 설정정보등을 저장하게 끔 하기 위해서 SharedPreferences라는 클래스를 안드로이드에서 제공한다.

이 클래스는 HashMap을 사용하여 데이터를 간편하게 입/출력 한다.

공유 프레퍼런스에 데이터 입출력 하는 예시

SharedPreferences mPref = new SharedPreferences("SharedPreferences명",Context.MODE_PRIVATE);

SharedPreferences.Editor editor = mPref.edit();

editor.putBoolean(key,value);

editor.commit() or editor.apply();

commit() vs apply()

커밋은 동기적으로 동작하는 함수이다. 즉, 공유 프레퍼런스가 완벽히 업데이트될때까지 블락 되기 떄문에 아주 약간이나마 성능 저하를 일으 킬 수 있다.

apply는 비동기적으로 동작하는 함수이다. 별도의 쓰레드에 공유 프레퍼런스의 업데이트 내용을 업데이트 하게끔 전달하고, 바로 리턴한다. 

그렇기 때문에 commit()대신 apply()를 쓰는것이 더 좋다.

Context.MODE_PRIVATE -> 이 앱 내부에서만 공유 프레퍼런스를 사용하겠다는 의미.

현재 안드로이드 버전에서는 MODE_PRIVATE모드만 허용한다. 이 앱의 SharedPreferences등을 다른 앱에 제공하기 위해서는 Content Provider를 구현하는 방식으로만 가능하게 변경 되었다.

SharedPreferences는 마찬가지로 앱 홈 폴더 내부에 XML 형태로 저장된다.

data

data

앱 홈 폴더(패키지명)

shared_prefs

Setting.xml -> 공유 프레퍼런스

이런 형태로 저장 된다. getSharedPreferences()를 통해서 처음에 공유 프레퍼런스를 읽어 올때 XML파일의 내용을 HashMap형태의 자료구조로 변환 해야 하기 떄문에 속도가 조금 걸릴 수 있다. 하지만, 이 공유 프레퍼런스를 읽어 오는 시점이 앱이 로딩 될때 읽어오게끔 하면, 충분히 사용자가 참을만한 시간이다. 처음에 공유 프레퍼런스를 get을 통해 읽어올때만 시간이 좀 걸리고 그 이후에는 공유 프레퍼런스가 메모리 위에 올라가있으므로 참조하는것은 굉장히 빠르게 일어난다.

프레퍼런스가 느리기때문에 사용하지 말라고 하는 사람들이 있는데, 이 사람들은 commit()함수를 사용했을 가능성이 있다.

대량의 데이터를 다루기 위해서는 데이터베이스를 사용해야 한다. 공유 프레퍼런스는 앱의 설정 정보같은 단순하고 양이 얼마 되지 않는 데이터를 손쉽게 입출력하기 위해서만 사용하는것이 좋다. 공유 프레퍼런스의 크기가 커지게 되면 느려질수 있기 때문이다.

출처 : http://callmansoft.tistory.com/entry/%ED%8C%8C%EC%9D%BC-%EA%B3%B5%EC%9C%A0%EC%8B%9C-Setting

http://blog.naver.com/PostView.nhn?blogId=huewu&logNo=110084637531

-> MediaStore에 대한것과 content:// file:/// 스키마에 대해