android - tipos - ¿Por qué extender una clase de aplicación?
programacion android pdf 2018 (13)
¿Por qué extender una clase de Application
?
¿Que hay para mi?
¿Por qué harías eso?
Leí que se puede usar para variables globales, eso es todo, ¿hay otras aplicaciones?
Introducción:
- Si consideramos un archivo
apk
en nuestro móvil, se compone de múltiples bloques útiles como,Activity
s,Service
s y otros. - Estos componentes no se comunican entre sí con regularidad y no olvidan que tienen su propio ciclo de vida. que indican que pueden estar activos al mismo tiempo e inactivos en el otro momento.
Requisitos:
- A veces podemos requerir un escenario en el que necesitemos acceder a una variable y sus estados en toda la
Application
independientemente de laActivity
esté utilizando el usuario, - Un ejemplo es que un usuario puede necesitar acceder a una variable que contiene su información de personal (por ejemplo, nombre) a la que se debe acceder a través de la
Application
, - Podemos usar SQLite pero crear un
Cursor
y cerrarlo una y otra vez no es bueno para el rendimiento, - Podríamos usar
Intent
s para pasar los datos, pero es torpe y la actividad en sí misma puede no existir en un cierto escenario dependiendo de la disponibilidad de la memoria.
Usos de la clase de aplicación:
- Acceso a las variables en la
Application
, - Puede usar la
Application
para comenzar ciertas cosas, como análisis, etc., ya que la clase de aplicación se inicia antes de que se ejecuten lasActivity
o losServices
, - Hay un método reemplazado llamado onConfigurationChanged () que se activa cuando se cambia la configuración de la aplicación (horizontal a vertical y viceversa),
- También hay un evento llamado onLowMemory () que se activa cuando el dispositivo Android tiene poca memoria.
A simple vista, no puedo pensar en un escenario real en el que la extensión de la aplicación sea preferible a otro enfoque o sea necesaria para lograr algo. Si tiene un objeto caro y de uso frecuente, puede inicializarlo en un servicio de intendencia cuando detecte que el objeto no está presente actualmente. La aplicación en sí se ejecuta en el subproceso UI, mientras que IntentService se ejecuta en su propio subproceso.
Prefiero pasar datos de Actividad a Actividad con Intentos explícitos o usar Preferencias Compartidas. También hay formas de pasar datos de un Fragmento a su Actividad principal utilizando interfaces.
A veces desea almacenar datos, como variables globales a las que se debe acceder desde múltiples actividades, a veces en todas partes dentro de la aplicación. En este caso, el objeto Aplicación lo ayudará.
Por ejemplo, si desea obtener los datos de autenticación básicos para cada solicitud http , puede implementar los métodos para los datos de autenticación en el objeto de la aplicación.
Después de esto, puede obtener el nombre de usuario y la contraseña en cualquiera de las actividades como esta:
MyApplication mApplication = (MyApplication)getApplicationContext();
String username = mApplication.getUsername();
String password = mApplication.getPassword();
Y finalmente, recuerde usar el objeto Application como un objeto singleton:
public class MyApplication extends Application {
private static MyApplication xxx;
public MyApplication getInstance(){
return singleton;
}
@Override
public void onCreate() {
super.onCreate();
singleton = this;
}
}
Para más información. Por favor haga clic en este LINK
Comience por crear una clase que amplíe la aplicación android.app.aplication de Android. Android crea una instancia de esta clase cuando se inicia la aplicación, es decir, cuando se inicia un proceso de DVM para ejecutar su apk. Como un ejemplo de cómo funciona la aplicación, supongamos que estamos construyendo algún tipo de juego. Nuestra aplicación de juego tendrá varias pantallas, cada pantalla en este caso es una Actividad. Los jugadores del juego generan puntos en cada pantalla y su puntaje debe rastrearse a través de las muchas pantallas de nuestro juego hipotético. Para rastrear el puntaje del juego del usuario a través de las muchas actividades que componen el juego, necesitamos un lugar para almacenar el puntaje del juego durante la duración del juego, es decir, mientras se esté ejecutando el proceso de solicitud.
Creo que puede usar la clase de Aplicación para muchas cosas, pero todas están relacionadas con su necesidad de hacer algunas cosas ANTES de que se inicien cualquiera de sus Actividades o Servicios. Por ejemplo, en mi aplicación uso fuentes personalizadas. En lugar de llamar
Typeface.createFromAsset()
de cada actividad para obtener referencias para mis fuentes de la carpeta de activos (esto es malo porque dará como resultado la pérdida de memoria ya que mantiene una referencia a los activos cada vez que llama a ese método), esto lo hago desde el método onCreate()
en mi clase de aplicación:
private App appInstance;
Typeface quickSandRegular;
...
public void onCreate() {
super.onCreate();
appInstance = this;
quicksandRegular = Typeface.createFromAsset(getApplicationContext().getAssets(),
"fonts/Quicksand-Regular.otf");
...
}
Ahora, también tengo un método definido así:
public static App getAppInstance() {
return appInstance;
}
y esto:
public Typeface getQuickSandRegular() {
return quicksandRegular;
}
Entonces, desde cualquier lugar de mi aplicación, todo lo que tengo que hacer es:
App.getAppInstance().getQuickSandRegular()
Otro uso de la clase Application para mí es verificar si el dispositivo está conectado a Internet ANTES de que las actividades y servicios que requieren una conexión realmente comiencen y tomen las medidas necesarias.
El mejor uso de la clase de aplicación. Ejemplo: supongamos que necesita reiniciar su administrador de alarmas al finalizar el arranque.
public class BaseJuiceApplication extends Application implements BootListener {
public static BaseJuiceApplication instance = null;
public static Context getInstance() {
if (null == instance) {
instance = new BaseJuiceApplication();
}
return instance;
}
@Override
public void onCreate() {
super.onCreate();
}
@Override
public void onBootCompleted(Context context, Intent intent) {
new PushService().scheduleService(getInstance());
//startToNotify(context);
}
El uso de la aplicación de extensión solo hace que su aplicación sea segura para cualquier tipo de operación que desee durante el período de ejecución de la aplicación. Ahora puede ser cualquier tipo de variables y supongamos que si desea recuperar algunos datos del servidor, puede poner su asynctask en la aplicación para que pueda obtenerla continuamente y de forma continua, para que pueda obtener datos actualizados automáticamente. Utilice este enlace para más conocimiento ...
http://www.intridea.com/blog/2011/5/24/how-to-use-application-object-of-android
Fuente: https://github.com/codepath/android_guides/wiki/Understanding-the-Android-Application-Class
En muchas aplicaciones, no es necesario trabajar directamente con una clase de aplicación. Sin embargo, hay algunos usos aceptables de una clase de aplicación personalizada:
- Tareas especializadas que deben ejecutarse antes de la creación de su primera actividad
- Inicialización global que debe compartirse en todos los componentes (informe de fallos, persistencia)
- Métodos estáticos para acceder fácilmente a datos inmutables estáticos, como un objeto de cliente de red compartido
Nunca debe almacenar datos de instancias mutables dentro del objeto Aplicación porque si supone que sus datos permanecerán allí, su aplicación se bloqueará inevitablemente en algún momento con una NullPointerException. No se garantiza que el objeto de la aplicación permanezca en la memoria para siempre, será asesinado. Contrario a la creencia popular, la aplicación no se reiniciará desde cero. Android creará un nuevo objeto Aplicación e iniciará la actividad donde el usuario estaba antes para dar la ilusión de que la aplicación nunca se mató en primer lugar.
La clase de aplicación es el objeto que tiene el ciclo de vida completo de su aplicación. Es tu capa más alta como aplicación. Ejemplos de posibles usos:
- Puede agregar lo que necesita cuando se inicia la aplicación sobrescribiendo onCreate en la clase Application.
almacena variables globales que saltan de Actividad a Actividad. Como Asynctask.
etc
La clase de aplicación es un singleton al que puede acceder desde cualquier actividad o en cualquier otro lugar donde tenga un objeto Context.
También obtienes un poco de ciclo de vida.
Puede usar el método onCreate de la aplicación para crear instancias de objetos costosos, pero de uso frecuente, como un asistente de análisis. Entonces puedes acceder y usar esos objetos en todas partes.
No es una respuesta, sino una observación : tenga en cuenta que los datos en el objeto de aplicación extendido no deben vincularse a una instancia de una actividad, ya que es posible que tenga dos instancias de la misma actividad ejecutándose al mismo tiempo (una en el primer plano y el otro no visibles) .
Por ejemplo, comienza normalmente su actividad a través del iniciador y luego la "minimiza". A continuación, inicia otra aplicación (es decir, Tasker) que inicia otra instancia de su actividad, por ejemplo, para crear un acceso directo, porque su aplicación es compatible con android.intent.action.CREATE_SHORTCUT. Si luego se crea el acceso directo y esta invocación de creación de acceso directo de la actividad modificó los datos del objeto de la aplicación, la actividad que se ejecuta en segundo plano comenzará a utilizar este objeto de aplicación modificado una vez que vuelva al primer plano.
Puede acceder a las variables de cualquier clase sin crear objetos, si está extendido por la aplicación. Pueden llamarse globalmente y su estado se mantiene hasta que no se mata la aplicación.
Veo que a esta pregunta le falta una respuesta. Extiendo la Application
porque uso la implementación de Bill Pugh Singleton ( ver referencia ) y algunos de mis singletons necesitan contexto. La clase de Application
ve así:
public class MyApplication extends Application {
private static final String TAG = MyApplication.class.getSimpleName();
private static MyApplication sInstance;
@Contract(pure = true)
@Nullable
public static Context getAppContext() {
return sInstance;
}
@Override
public void onCreate() {
super.onCreate();
Log.d(TAG, "onCreate() called");
sInstance = this;
}
}
Y los singletons se ven así:
public class DataManager {
private static final String TAG = DataManager.class.getSimpleName();
@Contract(pure = true)
public static DataManager getInstance() {
return InstanceHolder.INSTANCE;
}
private DataManager() {
doStuffRequiringContext(MyApplication.getAppContext());
}
private static final class InstanceHolder {
@SuppressLint("StaticFieldLeak")
private static final DataManager INSTANCE = new DataManager();
}
}
De esta forma, no necesito tener un contexto cada vez que estoy usando un singleton y obtener una inicialización sincronizada perezosa con una cantidad mínima de código.
Sugerencia: la actualización de la plantilla singleton de Android Studio ahorra mucho tiempo.