GetApplication () vs. getApplicationContext ()

No pude encontrar una respuesta satisfactoria a esto, así que aquí vamos: ¿cuál es el trato con Activity/Service.getApplication() y Context.getApplicationContext() ?

En nuestra aplicación, ambos devuelven el mismo objeto. Sin embargo, en un ActivityTestCase , burlarse de la aplicación hará que getApplication() vuelva con el simulacro, pero getApplicationContext todavía devolverá una instancia de contexto diferente (una inyectada por Android). ¿Eso es un error? ¿Es a propósito?

Ni siquiera entiendo la diferencia en primer lugar. ¿Hay casos fuera de una suite de pruebas donde ambas llamadas pueden volver con objetos diferentes? ¿Cuándo y por qué? Además, ¿por qué se define getApplication en Activity y Service , pero no en Context ? ¿No debería existir siempre una instancia de aplicación válida disponible desde cualquier lugar ?

Pregunta muy interesante. Creo que es principalmente un significado semántico, y también puede ser debido a razones históricas.

Aunque en las implementaciones actuales de la actividad y el servicio de Android, getApplication() y getApplicationContext() devuelven el mismo objeto, no hay garantía de que siempre será así (por ejemplo, en una implementación de proveedor específica).

Por lo tanto, si desea que la clase de aplicación se registre en el manifiesto, nunca debe llamar a getApplicationContext() y getApplicationContext() a su aplicación, ya que puede no ser la instancia de aplicación (que obviamente experimentó con el framework de prueba).

¿Por qué existe getApplicationContext() en primer lugar?

getApplication() sólo está disponible en la clase Activity y en la clase Service, mientras que se getApplicationContext() en la clase Context.

Eso realmente significa una cosa: al escribir código en un receptor de difusión, que no es un contexto, sino que se le da un contexto en su método onReceive, sólo puede llamar a getApplicationContext() . Lo que también significa que no se garantiza el acceso a su aplicación en un BroadcastReceiver.

Al mirar el código de Android, verá que cuando se adjunta, una actividad recibe un contexto base y una aplicación, y esos son parámetros diferentes. getApplicationContext() delega su llamada a baseContext.getApplicationContext() .

Una cosa más: la documentación dice que la mayoría de los casos, no debería necesitar subclase Aplicación:

Normalmente no es necesario subclasificar la Application . En la mayoría de las situaciones, los singletons estáticos pueden proporcionar la misma funcionalidad de una manera más modular. Si su singleton necesita un contexto global (por ejemplo, para registrar receptores de radiodifusión), la función para recuperarla se puede dar un Context que utiliza internamente Context.getApplicationContext() al construir primero el singleton.

Sé que esta no es una respuesta exacta y precisa, pero aún así, ¿responde su pregunta?

Comparar getApplication() y getApplicationContext() .

getApplication devuelve un objeto Application que le permitirá administrar su estado de aplicación global y responder a algunas situaciones de dispositivo como onLowMemory() y onConfigurationChanged() .

getApplicationContext devuelve el contexto de la aplicación global: la diferencia con respecto a otros contextos es que, por ejemplo, un contexto de actividad puede ser destruido (o de otro modo no disponible) por Android cuando termina su actividad. El contexto de la Aplicación permanece disponible todo el tiempo en que existe el objeto Aplicación (que no está vinculado a una Activity específica) para que pueda utilizar esto para cosas como Notificaciones que requieren un contexto que estará disponible por periodos más largos e independiente de los objetos UI transitorios.

Supongo que depende de lo que su código está haciendo si estos pueden o no ser los mismos – aunque en uso normal, esperaría que sean diferentes.

Parece tener que ver con el ajuste de contexto. La mayoría de las clases derivadas de Context son en realidad un ContextWrapper , que esencialmente delega a otro contexto, posiblemente con cambios por el envoltorio.

El contexto es una abstracción general que apoya la burla y la representación. Dado que muchos contextos están vinculados a un objeto de duración limitada como una Activity , debe existir una forma de obtener un contexto de vida más prolongada, con el fin de registrarse en futuras notificaciones. Esto se logra mediante Context.getApplicationContext() . Una implementación lógica es devolver el objeto Application global, pero nada impide que una implementación de contexto devuelva un wrapper o proxy con una vida útil adecuada.

Las actividades y los servicios se asocian más específicamente con un objeto Application . La utilidad de esto, creo, es que puede crear y registrar en el manifiesto una clase personalizada derivada de la Application y estar seguro de que Activity.getApplication() o Service.getApplication() devolverá ese objeto específico de ese tipo específico, que Puede emitir a su clase de Application derivada y utilizar para cualquier propósito personalizado.

En otras palabras, getApplication() está garantizado para devolver un objeto de Application , mientras que getApplicationContext() es libre de devolver un proxy en su lugar.

Para responder a la pregunta, getApplication () devuelve un objeto Application y getApplicationContext () devuelve un objeto Context. Basándome en sus propias observaciones, asumiría que el Contexto de ambos es idéntico (es decir, detrás de las escenas que la clase de Aplicación llama a la última función para poblar la porción de Contexto de la clase base o se produce alguna acción equivalente). Realmente no debería importar la función a la que llame si solo necesita un Contexto.

  • Transmisión local desde Servicio no recibido por Actividad
  • Cómo ejecutar un servicio de arranque en Android 2.3 (Gingerbread) sin chocar
  • Cómo actualizar la interfaz de usuario desde el servicio de Android utilizando RxJava / RxAndroid
  • Comunicación entre servicios y actividades de Android
  • La instancia de actividad sigue existiendo incluso después de que onDestroy () se llame
  • Android PendingIntent FLAG_NO_CREATE no devuelve null
  • Cómo utilizar HdmiControlService
  • Servicio de fondo con oyente de localización en android
  • Iniciar VPNService desde dentro de widget android
  • ¿Cómo dirigir la queja de la pelusa del android sobre las implementaciones exportadas del servicio de la mensajería de Firebase?
  • Cómo se registra una aplicación de Android en el sistema operativo
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.