Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Android BroadcastReceiver o método simple de devolución de llamada?

En mis proyectos estoy utilizando BroadcastReceiver s como una devolución de llamada de un hilo largo de ejecución (por ejemplo, notificar la actividad que una descarga fue terminada y enviar algunos datos de respuesta de un Thread trabajo para que la actividad puede mostrar el mensaje adecuado para el usuario. ). Para usar BroadcastReceiver s tengo que tener cuidado de registrar y anular el registro del receptor de difusión cada vez que lo estoy utilizando y también tengo que cuidar de qué mensajes enviar a esspecialy cuando estoy usando este método para acciones más diferentes (como descargar, hacer llamadas WebService Etc.). Y también para enviar objetos personalizados a través de la intención de Broadcast también necesito hacer los objetos Parcelable .

A diferencia de este enfoque, he visto también el enfoque de métodos de devolución de llamada que parece ser más simple que el método que utilizo. Los métodos de devolución de llamada son sencillos implementación de métodos de interfaz que se puede utilizar para lograr el mismo efecto como el BroadcastRecaiver en la mensajería de aplicaciones. Este enfoque no necesita implementación parcelable para devolver objetos complejos y no utiliza claves como BroadcastReceiver .. Creo que la parte mala es que tengo que comprobar el objeto de devolución de llamada para el valor nulo antes de que quiera llamar a un método de devolución de llamada. Y también para asegurarse de que estoy ejecutando el código de la implementación en el hilo de interfaz de usuario para que pueda actualizar la interfaz de usuario sin errores.

  • Selector requiere atributo dibujable?
  • Android TableRow se estira verticalmente para llenar la pantalla
  • ¿Cómo encontrar el documento gradint lintOptions para android?
  • Posicionamiento de MediaController sobre VideoView
  • ¿Qué atributos de tema necesito anular para cambiar el color de resaltado azul de mis cuadros de diálogo?
  • ¿Cómo puedo eliminar automáticamente la salida logcat antes de cada ejecución en Android Studio?
  • Ok, espero que entendió lo que quería decir :).

    Ahora la pregunta es ¿crees que el método de devolución de llamada es mejor (más ligero, más limpio, más rápido ..) que el enfoque BroadcastReceiver cuando se utilizan sólo dentro de una sola aplicación? (Tenga en cuenta que no estoy usando el Service Android para el trabajo de fondo .. sólo AsyncTask y Thread s)

    ¡Gracias!

  • ¿Qué es un "lote" en una aplicación de Android?
  • Cómo configurar mi propio icono de marcadores en clúster en Google Maps
  • TileProvider utilizando azulejos locales
  • Android fusiona dos imágenes
  • Eliminar fila en la tabla de la base de datos dado un valor de columna - que es una cadena
  • Se esperaba que GoogleApiClient.connect () 'fuera del tipo interface, pero se encontró que era virtual
  • 5 Solutions collect form web for “Android BroadcastReceiver o método simple de devolución de llamada?”

    Esta es una pregunta muy interesante y me encontré con el mismo problema. En mi opinión, ambos mecanismos pueden ser utilizados en conjunto y el enfoque correcto de usar depende de su caso de uso. Éstos son algunos puntos a tener en cuenta antes de decidir.

    El uso del mecanismo de devolución de llamada tiene algunos beneficios, pero también hay limitaciones:

    PRO

    • Es simple y sencillo de implementar.
    • Obtiene seguridad de tipo entre los componentes que interactúan entre sí.
    • Puede devolver objetos arbitrarios.
    • Simplifica las pruebas, ya que sólo tiene que inyectar un mock-callback (por ejemplo, generado a través de mockito o algo similar) en las pruebas de unidad.

    CONTRA

    • Tienes que cambiar al hilo principal para hacer manipulaciones de interfaz de usuario.
    • Sólo puede tener una relación 1-a-1. Una relación 1-a-n (patrón de observador) no es realizable sin más trabajo. En este caso prefiero el mecanismo Observer / Observable Android.
    • Como ya ha dicho, siempre tiene que buscar null antes de invocar funciones de devolución de llamada si la devolución de llamada puede ser opcional.
    • Si su componente debe ofrecer un tipo de API de servicio con diferentes funciones de servicio y no desea tener una interfaz de devolución de llamada con sólo unas pocas funciones de devolución de llamada genéricas, debe decidir si proporciona una interfaz de devolución de llamada especial para cada función de servicio o si Proporcionan una sola interfaz de devolución de llamada con muchas funciones de devolución de llamada. En el caso posterior todos los clientes de devolución de llamada utilizados para las llamadas de servicio a su API tienen que implementar la interfaz completa de devolución de llamada aunque la mayoría de los cuerpos del método estarán vacíos. Puede solucionar esto implementando un stub con cuerpos vacíos y hacer que su cliente de devolución de llamada hereda de ese stub, pero esto no es posible si ya hereda de otra clase base. Tal vez usted puede utilizar algún tipo de devolución de llamada de proxy dinámico (ver http://developer.android.com/reference/java/lang/reflect/Proxy.html ), pero entonces se vuelve muy complejo y me gustaría pensar en utilizar otro mecanismo.
    • El cliente para las llamadas de devolución de llamada tiene que propagarse a través de varios métodos / componentes si no es directamente accesible por el llamador del servicio.

    Algunos puntos con respecto al BroadcastReceiver -approach:

    PRO

    • Usted consigue un acoplamiento flojo entre sus componentes.
    • Puede tener una relación 1 a n (incluyendo 1 a 0).
    • El método onReceive() siempre se ejecuta en el subproceso principal.
    • Usted puede notificar componentes en su aplicación entera, así que los componentes que comunican no tienen que "ver" el uno al otro.

    CONTRA

    • Este es un enfoque muy genérico, por lo que organizar y desmarchar los datos transportados por el Intent es una fuente de error adicional.
    • Tienes que hacer que las acciones de tu Intent únicas (por ejemplo, prefijando el nombre del paquete) si deseas eliminar correlaciones con otras aplicaciones, ya que su propósito original es hacer transmisiones entre aplicaciones.
    • Tienes que administrar el BroadcastReceiver-registro y desregistro. Si desea hacerlo de una manera más cómoda, puede implementar una anotación personalizada para anotar su Actividad con las acciones que deben registrarse e implementar una clase de Activity base que IntentFilter registro y la IntentFilter registro con IntentFilter s en su onResume() resp. onPause() .
    • Como ya dijiste, los datos que se envían con la Intent tienen que implementar la interfaz Parcelable , pero además hay una limitación de tamaño estricta y causará problemas de rendimiento si transportas una gran cantidad de datos con tu Intent . Consulte http://code.google.com/p/android/issues/detail?id=5878 para una discusión sobre eso. Por lo tanto, si desea enviar imágenes por ejemplo, tiene que almacenarlas temporalmente en un repositorio y enviar una ID o URL correspondiente para acceder a la imagen desde el receptor de su Intent que lo elimina del repositorio después del uso. Esto conduce a problemas adicionales si hay varios receptores (¿cuándo se debe eliminar la imagen del repositorio y quién debería hacerlo?).
    • Si sobreutiliza este tipo de mecanismo de notificación, el flujo de control de su aplicación puede quedar oculto y al depurar terminará dibujando gráficos con secuencias de Intent para comprender qué ha provocado un error específico o por qué esta cadena de notificaciones se ha interrumpido en algún momento.

    En mi opinión, incluso una aplicación móvil debería tener una base de arquitectura en al menos dos capas: la capa de interfaz de usuario y la capa de núcleo (con lógica de negocio, etc.). En general, las tareas de ejecución larga se ejecutan en un propio hilo (tal vez a través de AsyncTask o HandlerThread si se utiliza MessageQueue s) dentro de la capa núcleo y la interfaz de usuario debe actualizarse una vez que esta tarea se ha terminado. En general, con las devoluciones de llamada se logra un acoplamiento estrecho entre sus componentes, por lo que preferiría usar este enfoque sólo dentro de una capa y no para la comunicación a través de los límites de la capa. Para la transmisión de mensajes entre UI y core-layer usaría el BroadcastReceiver -approach que le permite desacoplar su capa de interfaz de usuario de la capa lógica.

    No veo lo que obtienes usando BroadcastReceiver en tu caso. Las devoluciones de llamada o, mejor dicho, los Handlers serían la forma de hacerlo. BroadcastReceiver es bueno cuando no sabes quiénes son los suscriptores.

    Solo añadiré otra opción a las otras grandes respuestas que ya recibiste …

    No es necesario crear un receptor de difusión para recibir Intents. En tu archivo de manifiesto de Android puedes registrar cualquier actividad para recibir intenciones:

     <activity android:name=".MyActivity"> <intent-filter > <action android:name="intent.you.want.to.receive" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> .... </activity> 

    A continuación, anule el onNewIntent(Intent) en su actividad para recibirlo.

    Para enviar el intento, utilice el Context.startActivity(Intent) . Lo más probable es que desee agregar el indicador FLAG_ACTIVITY_SINGLE_TOP a su Intención para que no cree una nueva instancia de su actividad si ya se está ejecutando.

    EDIT: Acabo de notar que se está ejecutando en una sola aplicación. Por lo tanto, una devolución de llamada simple es probablemente mejor. La solución anterior funciona en una sola aplicación, pero es más apropiada para diferentes aplicaciones. Dejaré esto aquí por si ayuda a alguien. ¡Buena suerte!

    Broadcastreceivers debe utilizarse Si necesita enviar transmisiones a través de aplicaciones, mientras que las devoluciones de llamada (o los manejadores como lo sugiere Alex) son mejores para usar en su situación.

    Si desea utilizar otro que estos dos, considere utilizar Observer (interfaz incluida en android) y delegar.

    Para el delegado por favor considere este post SO.

    Espero que esto solucione tu problema

    No está seguro de cuál es el objetivo, pero si desea mantener la misma idea de usar la intención y broadcastReceiver, y desea un mejor rendimiento y seguridad que normal broadcastReceivers, puede probar esta demo, disponible en la biblioteca de soporte de Android:

    http://developer.android.com/resources/samples/Support4Demos/src/com/example/android/supportv4/content/LocalServiceBroadcaster.html

    Si no, siempre se puede utilizar asyncTask, servicio, manejadores, etc …

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.