Comunicación de Android entre dos servicios
Sé que una actividad puede comunicarse con un servicio local usando la interfaz de IBinder; Estoy tratando de encontrar una forma de comunicación entre dos servicios.
Específicamente, tengo mi servicio principal iniciando un IntentService para manejar las subidas de archivos. Quiero que este IntentService informe de nuevo al servicio principal una vez que se termine de cargar, y antes de que muera.
- Cómo evitar que el servicio se ejecute de nuevo si ya está ejecutando android
- Vincular servicio a la actividad en Android
- Cómo forzar el onServiceDisconnected () obtener llamado?
- ¿Cómo puedo enlazar este servicio en Android?
- Compruebe si el servicio se está ejecutando desde un receptor de difusión
¿Alguna idea acerca de cómo esto sucedería?
- Android Context.bindService devuelve siempre falso y el objeto ServiceConnection nunca se activa
- ¿Cómo iniciar y detener el servicio de Android desde una shell de anuncios?
- El servicio onCreate de Android se llama varias veces sin llamar a onDestroy
- Conectarse a través del nombre del servicio Bluetooth
- Android-Servicio matado con "ya no quieren" - cómo reiniciarlo?
- Descargar varios archivos utilizando un servicio en android
- Cómo comunicarse entre un receptor de difusión de Android y un RemoteService
- Priorizar la programación del reinicio del servicio androide bloqueado
Usted tiene que utilizar BroadcastReceiver para recibir intenciones, y cuando usted quiere comunicarse simplemente hace un intento con los valores apropiados.
De esta manera usted debe ser capaz de hacer una comunicación bidireccional entre cualquier componente.
En Android, hay una forma especial de completar tareas como la tuya. Mira AIDL (no está bien documentado en documentos oficiales, pero hay algunas fuentes adicionales en la web). Esta es una forma de implementar la comunicación bidireccional entre cualquier componente colocado en procesos separados. En comparación con BroadcastReceivers, usando esto obtendrían llamadas directas y callbacks, que estarían menos sucias que confiar en algo que vendría de algún lugar en BroadcastReceiver.
Para alcanzar el efecto necesario, tendrá que definir una interfaz para una devolución de llamada y una interfaz para realizar acciones (con una devolución de llamada suministrada o métodos de registro / anulación de registro). Después de recibir algún comando utilizando la segunda interfaz, debe realizar el trabajo y devolver el resultado a través de la devolución de llamada. Para llegar a la conclusión asíncrona, agregue una clave de trabajo "oneway" antes de la firma del método (tipo de retorno). Para separar los parámetros de entrada y salida (si es necesario), utilice las palabras clave "in", "out" y "inout" cerca de los parámetros.
Como se trata de restricciones, sólo primitivas, matrices y parcelables (y matrices parcelables) pueden ser transferidos entre procesos.
Para controlar el ciclo de vida de las devoluciones de llamada y la atomicidad de las operaciones, utilice RemoteCallbacksList para almacenar devoluciones de llamada registradas y notificar a los destinatarios utilizando el duplicado de su lista obtenido de beginBroadcast.
Si tienes algún problema, puedes preguntar aquí.