Управление обратными вызовами удаленного обслуживания

У меня есть ситуация, когда я чувствую, что собираюсь изобретать колесо или ходить по домам, обрабатывать то, что уже есть «дизайн» – так что прежде чем я это сделаю, я надеялся, что смогу получить второе мнение, пожалуйста ,

У меня есть удаленный сервис. Это постоянное обслуживание переднего плана из-за необычной природы / функциональности самого приложения.

Я пишу библиотеку, чтобы сторонние приложения могли связываться с сервисом и использовать API, которые я раскрываю. Поскольку я обрабатываю потоки самостоятельно, и большинство обратных вызовов будут иметь асинхронный характер, я использую подход AIDL с настраиваемыми классами, которые «отгружены» для предоставления необходимых параметров Сервису. Все до сих пор работает отлично.

Конструкция моего кода службы очень похожа на пример API RemoteService , поэтому я буду ссылаться на это, поскольку публикация моего конкретного кода не изменяет вопрос.

Как и в примере , интерфейс каждого запроса, который я сохраняю в RemoteCallbackList , который, по-видимому, является удобным решением для некоторых других основ.

Однако моя служба не предоставляет такую ​​же информацию группе «ожидающих приемников», как показывает следующий фрагмент:

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(); 

Вместо этого запросы имеют разные типы, поэтому мне нужно отслеживать, какой именно объект интерфейса я должен отправить обратно. Каждый индивидуальный запрос может включать в себя дальнейшие асинхронные веб-запросы и / или обработку и необходимость передавать объект обратного вызова каждому из них (либо через конструктор, либо только параметр метода), где я чувствую, что я собираюсь сделать что-то очень утомительное и С длинными ветвями, чтобы решить проблему, которую я могу упростить по другому пути?

Задача была бы упрощена, если бы я мог гарантировать, что первый запрос в, был бы первым результатом и поэтому просто использовал бы заказ в RemoteCallbackList перед удалением ссылки на них, но это не так, из-за различного времени обработки Различных типов запросов.

Изменить. Кажется, RemoteCallbackList поддерживается ArrayMap, и поэтому я считаю, что в любом случае не заказал?

Я не могу найти документального способа сужения, когда возникла обратная связь в RemoteCallbackList, хотя, даже если бы я мог, я бы, конечно, все же нуждался в каком-то постоянном идентификаторе, чтобы знать, что я искал … Stumped.

Спасибо за то, что вы читаете это, любые идеи приветствуются.

Изменить – для псевдо-примера. Представьте, что запросы API связаны с книгами.

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

Как вы можете видеть из вышеизложенного, при прочих равных условиях, удаленный запрос на меньшую книгу или наличие книги может завершить и быть готовым ответить до запроса более длинной книги, даже если она была запрошена после. Здесь мне нужно отслеживать «реквестер» и это дизайн, который мне нужен.

Solutions Collecting From Web of "Управление обратными вызовами удаленного обслуживания"

Если я правильно понял, все, что вам нужно сделать, это ответить на ваши запросы из RemoteCallbackList, используя тот же интерфейс, но с различными структурами данных ответа.

Я думаю, самый простой способ – сделать запросы, чтобы донести вам информацию о том, какая возвращаемая структура данных им нужна. Самый очевидный (может быть, даже глупый) способ – отправить вам имя класса, которое вы должны создать и заполнить. Более сложным способом вы можете просто создать некоторое перечисление, имя которого должно быть подано по запросу и которое определит правильное Класс структуры данных, который должен быть создан и возвращен.

Второй способ состоит в том, чтобы иметь какой-то ответный ответчик – некоторая логика, которая будет определять, какие данные может потребоваться запросу. Но ИМХО выглядит слишком двусмысленно, довольно сложно и не очень удобно поддерживать.

В любом случае – весьма сомнительно, что вы найдете универсальное решение для такого случая, потому что оно не является общим.

Надеюсь это поможет.