Gestión de devoluciones de llamada del servicio remoto

Tengo una situación en la que siento que estoy a punto de reinventar la rueda o ir alrededor de las casas, para manejar algo que ya hay un "diseño" para – por lo que antes de hacerlo, esperaba poder obtener una segunda opinión por favor .

Tengo un servicio remoto. Se trata de un servicio de primer plano permanente debido a la naturaleza inusual / funcionalidad de la aplicación en sí.

Estoy escribiendo una biblioteca para que las aplicaciones de terceros puedan vincularse al servicio y usar las API que expongo. Como estoy manejando el subprocesamiento de mí mismo y la mayoría de las devoluciones de llamada serán de naturaleza asíncrona, estoy utilizando un enfoque AIDL, con clases personalizadas que son "Parceled up" para proporcionar los parámetros necesarios para el servicio. Todo hasta ahora, funciona perfectamente.

La construcción de mi código de servicio es muy similar al ejemplo de RemoteService API , por lo que me referiré a eso, ya que publicar mi código específico no altera la pregunta.

Como con el ejemplo , la interfaz de cada solicitud que guardo en una RemoteCallbackList , que parece ser una solución práctica para algunos otros fundamentos.

Sin embargo, mi Servicio no proporciona la misma información a un grupo de "receptores en espera" como demuestra el uso del siguiente fragmento:

int i = callbacks.beginBroadcast(); while (i > 0) { i--; try { callbacks.getBroadcastItem(i).somethingHappened(); } catch (RemoteException e) { // The RemoteCallbackList will take care of removing // the dead object for us. } } callbacks.finishBroadcast();

En su lugar, las solicitudes son de muchos tipos diferentes y, por lo tanto, necesito realizar un seguimiento de qué objeto de interfaz exacto debo enviar los resultados. Cada solicitud individual puede implicar más solicitudes asincrónicas en la web y / o procesar y tener que entregar el objeto de devolución de llamada a cada uno de ellos (ya sea a través de un constructor o simplemente un parámetro de método) es donde siento que estoy a punto de hacer algo muy tedioso y Largo de viento para resolver un problema que tal vez puede lograr de manera simplista de otra manera?

La tarea sería fácil si pudiera garantizar que la primera solicitud en, sería el primer resultado fuera y por lo tanto, simplemente utilizar el orden en el RemoteCallbackList antes de eliminar la referencia a ellos, pero esto no es el caso, debido a la variación de los tiempos de procesamiento De los diferentes tipos de solicitudes.

Edit – Parece que el RemoteCallbackList está respaldado por un ArrayMap y por lo que creo que no ordenó de todos modos?

No puedo encontrar ninguna forma documentada de reducir el origen de la devolución de llamada en el RemoteCallbackList, aunque incluso si pudiera, por supuesto, todavía necesito algún tipo de identificador persistente para saber lo que estaba buscando …. Stumped.

Gracias por leer hasta aquí, cualquier idea es bienvenida.

Editar – Con el propósito de pseudo ejemplo. Imagine que las solicitudes de API se refieren a libros.

 // requests bookExists(String title) bookContent(String title) // response bookExists(boolean exists) bookContent(ArrayList<String> words, int pageTotal)

Como se puede ver de lo anterior, todas las cosas son iguales, una solicitud remota para un libro más pequeño o la existencia de un libro, puede completar y estar listo para responder antes de una solicitud de un libro más largo, incluso si se solicitó después. Aquí es donde necesito rastrear el 'solicitante' y es el diseño que busco.

Si te entiendo bien, todo lo que tienes que hacer es responder a tus peticiones desde RemoteCallbackList utilizando la misma interfaz, pero con diferentes estructuras de datos de respuesta.

Supongo que, la forma más sencilla es hacer las peticiones para traerle información qué tipo de estructura de datos que regresan que quieren. La forma más obvia (tal vez incluso estúpida) es enviarle el nombre de la clase que tiene que instanciar y rellenar. De manera más sofisticada, puede crear una enumeración cuyo nombre debe ser presentado por solicitud y que definirá el Clase de estructura de datos para ser instanciada y devuelta.

La segunda forma es tener algún tipo de resolución de respuesta – alguna lógica que detecte qué tipo de datos la solicitud puede desear. Pero IMHO parece demasiado ambiguo, bastante complicado y no muy conveniente para apoyar.

De todos modos – es bastante dudoso que encontrará una solución universal para este caso, porque no es una común.

Espero que esto ayude.