getApplication () 대 getApplicationContext ()

거래는 무엇입니다 : 우리가 간다, 그래서 여기에이에게 만족 대답을 찾을 수 없습니다 Activity/Service.getApplication()와 Context.getApplicationContext()?

우리의 응용 프로그램에서 둘 다 동일한 객체를 반환합니다. 에서 ActivityTestCase그러나, 응용 프로그램을 조롱하는 것 getApplication()모의로 돌아와,하지만 getApplicationContext여전히 다른 컨텍스트 인스턴스 (안드로이드 주입 한)을 반환합니다. 그게 버그 야? 의도적인가요?

나는 처음부터 차이점을 이해하지 못합니다. 테스트 스위트 외부에서 두 통화가 다른 객체로 돌아올 수있는 경우가 있습니까? 언제 그리고 왜? 또한, 왜 getApplication정의 Activity하고 Service, 그러나에 Context? 언제 어디서나 유효한 응용 프로그램 인스턴스가 없어야 합니까?

매우 흥미로운 질문입니다. 나는 이것이 의미 론적 의미라고 생각하며 역사적인 이유 때문일 수도 있습니다.

현재 안드로이드 활동 및 서비스 구현에, 비록 getApplication()와 getApplicationContext()같은 개체를 반환이 항상 (특정 공급 업체의 구현, 예를 들어)의 경우가 될 것이라는 보장은 없습니다.

따라서 매니페스트에 등록한 응용 프로그램 클래스를 원한다면 응용 프로그램 인스턴스 (테스트 프레임 워크에서 분명히 경험 한 응용 프로그램 인스턴스)가 아닐 수 있으므로 응용 프로그램을 호출 하여 응용 프로그램에 캐스트 해서는 안됩니다getApplicationContext() .

왜 getApplicationContext()처음에 존재합니까?

getApplication()getApplicationContext()Context 클래스에서 선언되는 반면 Activity 클래스와 Service 클래스에서만 사용할 수 있습니다 .

그것은 실제로 한 가지 의미입니다. 브로드 캐스트 리시버에서 코드를 작성할 때 컨텍스트가 아니지만 onReceive 메소드에 컨텍스트가 제공되는 경우에만 호출 할 수 있습니다 getApplicationContext(). 또한 BroadcastReceiver에서 응용 프로그램에 액세스 할 수있는 것은 아닙니다.

Android 코드를 보면 첨부 할 때 활동에 기본 컨텍스트 및 애플리케이션이 수신되고 서로 다른 매개 변수라는 것을 알 수 있습니다. getApplicationContext()에 전화를 위임합니다 baseContext.getApplicationContext().

한 가지 더 : 설명서에는 대부분의 경우 Application을 서브 클래스 화 할 필요가 없다고 말합니다.

일반적으로 서브 클래스가 필요하지 않습니다 Application. 대부분의 상황에서 정적 싱글 톤은보다 기능적인 방식으로 동일한 기능을 제공 할 수 있습니다. 싱글 톤에 글로벌 컨텍스트가 필요한 경우 (예 : 브로드 캐스트 리시버 등록) 싱글 톤을 처음 구성 할 때 Context내부적으로 사용 하는 기능을 검색 할 수 있습니다 Context.getApplicationContext().

나는 이것이 정확하고 정확한 답변이 아니라는 것을 알고 있지만 여전히 귀하의 질문에 대답합니까?

getApplication()와 비교하십시오 getApplicationContext().

getApplicationApplication전역 응용 프로그램 상태를 관리하고 onLowMemory()및과 같은 일부 장치 상황에 응답 할 수 있는 객체를 반환합니다 onConfigurationChanged().

getApplicationContext전역 응용 프로그램 컨텍스트를 반환합니다. 다른 컨텍스트와의 차이점은 예를 들어 활동이 종료되면 Android에서 활동 컨텍스트가 파괴되거나 사용 불가능하게 될 수 있다는 것입니다. Application 컨텍스트는 Application 객체가 존재하는 동안 계속 사용할 수 Activity있으므로 ( 특정에 묶이지 않음 ) 장기간 사용할 수 있고 일시적인 UI 객체와 무관하게 컨텍스트를 필요로하는 알림 과 같은 경우에이를 사용할 수 있습니다.

나는 그것이 동일한 지 아닌지에 관계없이 코드가 무엇을하고 있는지에 달려 있다고 생각합니다. 그러나 정상적인 사용에서는 코드가 다를 것으로 기대합니다.

컨텍스트 랩핑과 관련이있는 것 같습니다. 에서 파생 된 대부분의 클래스 Context는 실제로 ContextWrapper는 래퍼에 의해 변경 될 수있는 본질적으로 다른 컨텍스트에 위임됩니다.

컨텍스트는 조롱 및 프록시를 지원하는 일반적인 추상화입니다. 많은 컨텍스트가과 같은 수명이 제한된 개체에 바인딩되어 있기 때문에 Activity향후 알림 등록과 같은 목적으로 수명이 긴 컨텍스트를 얻는 방법이 필요합니다. 에 의해 달성됩니다 Context.getApplicationContext(). 논리적 구현은 전역 Application객체 를 반환하는 것이지만 컨텍스트 구현이 대신 적절한 수명을 가진 래퍼 또는 프록시를 반환하는 것을 막는 것은 없습니다.

활동 및 서비스는보다 구체적으로 Application객체 와 연관됩니다 . 이것의 유용성은, 저는 믿습니다, 당신이 만들어에서 파생 된 매니페스트 사용자 정의 클래스에 등록 할 수 있다는 Application그 확신 할 수 Activity.getApplication()또는 Service.getApplication()당신이 당신의 파생으로 캐스팅 할 수있는 특정 유형의 특정 오브젝트 돌아갑니다 Application무엇을위한 클래스와 사용 사용자 정의 목적.

즉, getApplication()반환 보장 Application하면서, 객체를 getApplicationContext()대신 프록시를 반환 무료입니다.

질문에 대답하기 위해 getApplication ()은 Application 객체를 반환하고 getApplicationContext ()는 Context 객체를 반환합니다. 본인의 관찰에 따라 두 컨텍스트가 동일하다고 가정합니다 (즉, Application 클래스가 후자의 함수를 호출하여 기본 클래스의 컨텍스트 부분을 채우거나 동등한 조치가 발생하는 장면 뒤). 컨텍스트가 필요한 경우 어떤 함수를 호출하는지는 중요하지 않습니다.