Ich habe eine Situation, in der ich das Rad neu erfinden oder um die Häuser herumgehen möchte, um mit etwas fertig zu werden, für das es schon einen "Entwurf" gibt - also habe ich vorher gehofft, ich könnte einen bekommen zweite Meinung bitte.
Ich habe einen Fernservice. Es ist ein permanenter Vordergrunddienst aufgrund der ungewöhnlichen Art / Funktionalität der Anwendung selbst.
Ich schreibe eine Bibliothek, damit Anwendungen von Drittanbietern an den Dienst gebunden werden und die von mir bereitgestellten APIs verwenden können. Da ich das Threading selbst bearbeite und die meisten Callbacks asynchron sind, verwende ich einen AIDL-Ansatz mit benutzerdefinierten Klassen, die "parzelliert" sind, um dem Service die notwendigen Parameter zu liefern. Alles bis jetzt funktioniert perfekt.
Das Konstrukt meines Service-Codes ist dem RemoteService API-Beispiel , also werde ich mich darauf beziehen, da das Posten meines spezifischen Codes die Frage nicht ändert.
Als Mit dem Beispiel , das Interface jeder Anfrage, speichere ich in eine RemoteCallbackList , welche scheint eine handliche Lösung für einige andere Grundlagen zu sein.
Mein Service bietet jedoch nicht die gleichen Informationen für eine Gruppe von "wartenden Empfängern", wie die Verwendung des folgenden Snippets zeigt:
%Vor%Stattdessen sind die Anfragen von vielen verschiedenen Typen und deshalb muss ich verfolgen, an welches genaue Interface-Objekt ich die Ergebnisse zurücksenden soll. Jede einzelne Anfrage kann weitere asynchrone Web-Anfragen und / oder eine Verarbeitung beinhalten und das Callback-Objekt an jedes von diesen übergeben (entweder über einen Konstruktor oder nur einen Methodenparameter) ist, wo ich fühle, dass ich etwas sehr langweiliges tun werde langatmig, um ein Problem zu lösen, das ich vielleicht vereinfachend anders erreichen kann?
Die Aufgabe wäre leicht gemacht, wenn ich garantieren könnte, dass die erste Anfrage in, wäre das erste Ergebnis aus und daher einfach die Reihenfolge in der RemoteCallbackList vor dem Entfernen Verweis auf sie, aber dies ist nicht der Fall, aufgrund der unterschiedliche Bearbeitungszeiten der verschiedenen Anfragearten.
Bearbeiten - Es erscheint die RemoteCallbackList wird von einer ArrayMap unterstützt und ich glaube nicht trotzdem bestellt?
Ich kann keine dokumentierte Möglichkeit finden, den Callback in der RemoteCallbackList einzugrenzen, obwohl ich natürlich auch noch eine persistente Kennung benötigen würde, um zu wissen, wonach ich suchte .... Stumped.
Danke, dass Sie soweit gelesen haben, Ideen sind willkommen.
Bearbeiten - Zum Zweck eines Pseudo-Beispiels. Stellen Sie sich vor, die API-Anfragen betreffen Bücher.
%Vor%Wie Sie oben sehen können, können alle Dinge gleich sein, eine entfernte Anfrage für ein kleineres Buch oder die Existenz eines Buches, und es könnte fertig sein, vor einer Anfrage nach einem längeren Buch zu antworten, selbst wenn es so wäre danach gefragt. Dies ist, wo ich den "Anforderer" verfolgen muss und das Design ist, nach dem ich bin.
Wenn ich Sie richtig verstanden habe, müssen Sie lediglich auf Ihre Anfragen von der RemoteCallbackList antworten, die die gleiche Schnittstelle verwenden, aber mit unterschiedlichen antwortenden Datenstrukturen.
Ich denke, der einfachste Weg besteht darin, die Anfragen zu stellen, um Ihnen Informationen zu geben, welche Art von wiederkehrenden Datenstrukturen sie wollen. Der offensichtlichste (vielleicht sogar dumme) Weg ist es, Ihnen den Namen der Klasse zu schicken, die Sie instanziieren und ausfüllen müssen. Auf raffiniertere Weise können Sie einfach eine Aufzählung erstellen, welcher Elementname auf Anfrage mitgebracht werden soll und welches das richtige definieren soll Datenstrukturklasse, die instanziiert und zurückgegeben werden soll.
Der zweite Weg ist eine Art Response Resolver - eine Logik, die erkennt, welche Art von Daten die Anfrage haben soll. Aber IMHO sieht es zu zweideutig aus, ziemlich kompliziert und nicht sehr praktisch, um es zu unterstützen.
Wie auch immer - es ist ziemlich zweifelhaft, dass Sie eine universelle Lösung für solch einen Fall finden werden, weil es kein gewöhnlicher ist.
Hoffe, das hilft.