android - studio - snackbar material design

Gestionando los objetos View y Class<?> Actuales

Question

Tengo una AppUtils de clase de utilidad para toda la aplicación, donde puedo publicar información relevante de la aplicación a cualquier velocidad:

1. ya sea como SnackBar, cuando estoy en la aplicación
2. o por medio del administrador de notificaciones

Por ejemplo, cuando los volúmenes están yendo como un Snackbar, necesito la pista del contenedor de visualización actual para usarlo en Snackbar.make(view, text, length); Cuando deseo publicar ese mensaje por medio de NotificationManager.notify(int, Builder); y necesito la firma de la clase aquí

Intent resultIntent = new Intent(this, ResultActivity.class);

Por lo tanto, tengo en mi AppUtils:

public static void setCurrentViewAndClass(View v, Class<?> c)
{
    view = v; // view is static
    cls = c;  // cls is static
}

donde puedo recordar de todas partes de mi proyecto la vista actual (para el parámetro Snackbar) y cls (para intención de notificación).

Más adelante, borro esos parámetros, por ejemplo, cuando dejo la aplicación en segundo plano:

public static void clearCurrentViewAndClass()
{
    view = null;
    cls = null;
}

R. Cuando esos parámetros NO son nulos , sé que mi aplicación tiene el foco con la vista correspondiente y puedo mostrar el mensaje relevante como una Barra de Snack. B. Cuando estos parámetros son nulos , sé que mi aplicación está en segundo plano y quiero mostrar el mensaje relevante como una Notificación

Entonces, cada vez que se crea o se reanuda un Fragmento / Actividad, llamo a setClassAndview() en cada onResume() para recordar los parámetros.

¿Hay una forma más elegante de hacer un seguimiento de la actividad actual o de la clase activa?

Answer 1

Como ejemplo ... cree una clase de aplicación (MyApp) que esté registrada en AndroidManifest:

<application
        android:name=".MyApp"
        ...>

En la clase de aplicación MyApp .onCreate () establecido:

registerActivityLifecycleCallbacks(new MyAppActivityLifecycleCallbacks());

En MyApp, cree un campo estático que contenga un recuento de Actividades visibles y un método para determinar si la aplicación está en primer plano o no:

private static int mActivityCount = 0;

public static boolean isAppInForeground() {
    return mActivityCount != 0;
}

Y finalmente configure su clase ActivityLifecycleCallbacks para mantener el recuento de las actividades visibles:

private static final class MyAppActivityLifecycleCallbacks implements ActivityLifecycleCallbacks {

        public void onActivityCreated(Activity activity, Bundle bundle) {
            // No operations
        }

        public void onActivityDestroyed(Activity activity) {
            // No operations
        }

        public void onActivityPaused(Activity activity) {
            // No operations
        }

        public void onActivityResumed(Activity activity) {
            // No operations
        }

        public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
            // No operations
        }

        public void onActivityStarted(Activity activity) {
            mActivityCount++;
        }

        public void onActivityStopped(Activity activity) {
            mActivityCount--;
        }
    }

Y ahora debería poder llamar a MyApp.isAppInForeground () para determinar si alguna de sus actividades está actualmente en primer plano. Si necesita una referencia a la Actividad visible actual, puede manejar eso aquí también.

Answer 2

Esto no es precisamente lo que solicitó, pero puede mejorar enormemente el mantenimiento de su código actual mediante el uso de un patrón de bus de eventos . Suscribirse a eventos específicos en Vistas, Actividades, Servicios, etc. interesados ​​le permitirá manejar cualquier cantidad de notificaciones sin hacer un seguimiento explícito de sus receptores.

Esto funciona así:

1. Usted se suscribe a los eventos en cada componente interesado después de que esté completamente inicializado.
2. Reciba y administre el evento, opcionalmente cancele el evento, si el componente piensa, que otros componentes no lo necesitan.
3. Anular la suscripción cuando el componente ya no necesita eventos (la Vista está oculta / separada, el Fragmento se destruye, la Actividad se cierra / se minimiza).

La belleza de este enfoque radica en la flexibilidad: siempre puede agregar más lógica alrededor de cada evento sin afectar a otros componentes, que se suscriben a él. Además, puede elegir el mejor momento para suscribirse / cancelar la suscripción de forma independiente para cada componente (por ejemplo, las notificaciones pueden emitirse en cualquier momento, pero las barras de refrigerios solo se deben mostrar cuando la Actividad esté visible y reanudada).

Existen múltiples buenas opciones para implementar un bus de eventos en su aplicación:

1. Transmisiones globales de Android : se adapta mejor cuando tiene múltiples componentes de alto orden (Actividades, Servicios, Receptores de difusión), interesados ​​en eventos comunes. Puede usar las prioridades del filtro de intención y las transmisiones ordenadas para cancelar el manejo de eventos a mitad de camino.
2. LocalBroadcastManager. Muerto simple, algunas características, pero también fácil de usar con API familiar.
3. Varias bibliotecas de autobuses de eventos especializados , elige tu favorito.
4. Varias API, que pueden usarse como buses de eventos, incluso si este no es su objetivo principal: RxJava (recomiendo leer este artículo ), PendingIntents, ContentResolver.notifyUri, etc.

Answer 3

Puede usar ActivityManager para obtener actividad actual.

Este enlace explica cómo.

Sin embargo, no puedes obtener el Fragmento actual ya que puede haber múltiples fragmentos simultáneamente. Puede encontrar un fragmento actual en un grupo de vista específico utilizando FragmentManager.

getActivity().getFragmentManager().findFragmentById(R.id.fragment_container);