Является ли поставщик контента единичным экземпляром блокировки?

У меня есть контент-провайдер, который может запрашивать несколько других поставщиков контента (через распознаватель контента) и делает некоторое слияние контактных данных.

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

cancelAllExistingTask();

proiverTest1 = new ProviderTask(getActivity, MyActivity.this.callBack).execute(SearchString, elementId1);
proiverTest2 = new ProviderTask(getActivity, MyActivity.this.callBack).execute(SearchString, elementId2);
proiverTest3 = new ProviderTask(getActivity, MyActivity.this.callBack).execute(SearchString, elementId3);
proiverTest4 = new ProviderTask(getActivity, MyActivity.this.callBack).execute(SearchString, elementId4);

Поэтому я создаю 4 экземпляра моей ProviderTask, как часть конструктора ProviderTask, передаю интерфейс, который реализован в моем экземпляре класса callBack.

class CallBackClass implements MyCallBackIF{}

ProviderTask во время doInBackground запускает ContentResolver.query() для поставщика ONE. Тот же провайдер используется всеми 4 Задачами. Но на основе elementId он возвращается в интерфейс через onPostExecute() w/elementId массива курсора, в который он должен быть помещен (см. Ниже).

ContentProvider анализирует URI, который передается и на основе URI отправляется и запрашивает 1 другой ContentProvider для данных. Это могут быть локальные данные или удаленные от сервера. Затем, в зависимости от источника, он может объединить его с другими данными (локальными) и вернуть обратно новый курсор с объединенными данными. Индивидуальный поставщик контента → Content Resolver → Content Provider → Content Resolver довольно быстр. И несколько полезно для обеспечения агрегирования поиска в нескольких различных приложениях, которые у нас есть. Поставщик фактически создает асинхронную загрузку данных поставщика удаленных данных, и есть синхронизированный блок, который ждет от него завершения обработки данных до того, как он вернется в Activity. Частично это связано с тем, что я могу пройти в ури, у которого есть несколько провайдеров, чтобы искать и объединять, где он запускает более одного запроса разрешения контента в свой собственный Merge Cursor. (Но прямо сейчас это Merge Cursor w/1, который запускается в Async Task).

** Я использую курсор слияния и курсор [], чтобы обновить представление списка на основе объединенных данных от разных разных поставщиков. Возможно, вы спрашиваете, почему бы не позволить поставщику контента просто делать это для нас? Мы попытались. Казалось, это не сработало для нас, но открыто для предложений.

Таким образом, если наши запросы MergeProvider - ContentProvider1, ContentProvider2, ContentProvider3, ContentProvider4 и говорят, что ContentProvider3 также должен запрашивать ContentProvider 1 для объединения некоторых данных. ContentProvider 3 и 4 являются удаленными (на сервере)

W/прогностический поиск мы хотим, чтобы результаты поиска возвращались назад быстрее всего, чтобы отображаться в первую очередь. И другие, которые будут просачиваться, когда они вернутся, если будет напечатано новое письмо, мы хотим сбросить весь набор результатов и дождаться нового запроса. Это то, что происходит, и кажется, что мы где-то заблокированы (мы попытались повысить приоритет потока AsyncTask, у нас есть ExecuteExecutor с нашим собственным Executor и пулом (повышение async-задачи max от 10 до 100) без результатов).

Так что кто-то печатает в письме "a" - Content Provider 1 и Content Provider 2, скажем, 0,050 секунд. Провайдер контента 4 возвращается примерно через 0.100 секунд. И Content Provider 3 возвращается через 5.00 секунд. (Задержка 5,00 связана с тестируемым сервером, на котором мы тестируем, но обнаружила проблему, которую мы видим с блокировкой).

теперь, если они продолжают печатать, а строка показывает "albert". Возможно, она выпустила новую AsyncTask для "al", которую некоторые возвращают быстро, а другие нет. Скажем, провайдер 3 все еще ждет ответа. код отбрасывает результаты, если предсказательный поиск изменился к моменту возвращения результатов. (что хорошо). поэтому он запускает еще один раунд альберта AsyncTasks. Теперь помните, что провайдер 3 по-прежнему отключен в 5-секундном ответе.

Мы добавили некоторые протоколирования как в AsyncTask, так и в методе Calling (обработчик). Мы видим, что AsyncTask создается, но мы не видим doInBackground(), чтобы начать, пока SearchProvider3 не вернет результаты (и они будут отброшены). Я совершенно смущен, почему это происходит. Но это в основном блокирует другие объекты AsyncTask. Не уверен, что вызвало бы doInBackground(), чтобы не вызываться до тех пор, пока другая AsyncTask не вернется, если это не из-за максимального предела в 10 AsyncTasks? W/наша собственная реализация ThreadPoolExecutor (и даже создание двух разных экземпляров ThreadPoolExecutor), мы по-прежнему видим ту же проблему.

Это ОЧЕНЬ видно, если в методе запроса нашего провайдера 3 мы добавим thread.sleep(60000). В принципе, похоже, что 5 задач Async вызываются, прежде чем они начнут блокировать. Наша цель состояла в том, чтобы быстрее получить результаты локального сопоставления, независимо от других длительных задач. Это было бы более очевидно в медленной (3g) сети.

Может быть, мы не должны использовать для этого задачи Async и просто использовать runnables?

Благодарю.