Android Context의 이해

안드로이드 앱도 짜지만, 삼성에서 프레임웍 부분만 거의 담당을 하다 보니

앱에서 쓰는 여러가지 기법들이 프레임웍단에서 상당히 복잡하게 구현이 된다는

것을 알았다.

사실 대부분 AOSP에 소스를 따라가며 보는게 블로그에 정리된 내용을 보는 것보다

앱 개발자들에게는 훨씬 도움이 된다. 아리송했던 부분 다른 것에 빗대지 않고 한번에

RAW 소스를 보며 이해하는 것이 좋다.

왜냐면 Concept이 있긴 하지만 구현하면서 바뀌는 부분, 많은 사람들이 동시 코딩을

하는 부분 때문에 절대적으로 맞는 구석이 없고 그런 부분까지 앱 개발자가 알 필요는

없는 것이다.

 회사에서도 개인적으로 로컬 빌드를 해서 쓸 요량으로 프레임웍 수정을 해 본 경험을 보면

AOSP에 분석이 힘든 부분은 메시지 큐를 구현한 부분 외엔 없다.

메시지 큐 구현 부분은 연결 소스가 끊어져 있어서 정말 분석이 힘들다. 언젠가 다룰 날이

있겠지 하며...(이 부분은 알아도 시간이 지나면 또 잊혀질 것 같다.)

Context에 대해서 물어오는 사람을 위해서 말을하면,

우선 상대가 프레임웍 개발자라면 그냥 소스 보라고 하고,

앱 개발 자라면 Object Class 같이 void 형 포인터라고 보면 된다.

화면 구성단위가 꼭 Activity는 아니지만 일반적으로 Activity로 구현을 하고 있으며

그 Activity를 가르키는 포인터(자바에서는 인스턴스라고 하지)보다 더 큰 개념이

Context다. 사실 모든 포인터의 짱은 Object라서 Object에 담아도 되지만 안드로이드

개념이 그렇다.

Context에 맞는 인스턴스(포인터) 종류는 실행되는 앱, 액티비티, BR, CP, 서비스다.

BroadcastReceiver, Content Provider까지 비슷한 구조라고 보면 되겠다.

앱에 대한 Context를 얻어 올 때는 getapplicationContext()로 계속 쓰는게 좋다.

왜냐면 Context에서

    /**
     * Return a class loader you can use to retrieve classes in this package.
     */
    public abstract ClassLoader getClassLoader();

    /** Return the name of this application's package. */
    public abstract String getPackageName();

    /** Return the full application info for this context's package. */
    public abstract ApplicationInfo getApplicationInfo();

요런 애들은 안 바뀌겠지만,

    /**
     * Return the Theme object associated with this Context.
     */
    public abstract Resources.Theme getTheme();


요런 애들은 바뀔수도 있으니까...(제일 좋은 건 Context에 어떤 멤버변수들이

있는지 한번 확인해 보는 것)

포스팅이란게 쓰다보면 자꾸 쓰게 되어서...

한줄로 요약하면

Context는 앱, 액티비티, BR, CP, 서비스를 담는 포인터다.

자바식으로 표현하면

Context는 앱, 액티비티, BR, CP, 서비스의 객체 상태를 담을 수 있는 싱글톤 클레스이다.


-----------------------------------------------
배터리] 리튬 이온 배터리

리튬 이온 배터리는 자주자주 충전하는게 좋다고 한다.

아이팟 터치 2년 쓴 사람이 그러넹.

아이폰 자주자주 충전해야징.