Волейбол или Сервис с загрузчиком курсора

Ответ 1

Традиционная арка

Лично, в прошлом я обнаружил, что использование службы было громоздким для реализации, но в конце дня было хорошо структурировано и было хорошим последовательным опытом. Но производительность потоковой передачи... трудно справиться.

Сервис запрос → загрузка базы данных → уведомление

Пользовательский интерфейс инициировать запрос и загрузку курсора → обновить ui.

Только волейбол

С volley возникает соблазн пропустить весь компонент, который ранее обрабатывался в службе и базе данных.

Пользовательский интерфейс Запрос волейбола → Реакция волейбола → обновление ui

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

• отображаемые данные не полностью описаны одним и тем же URL (например, страницами).

Пользователь может прокручивать вниз и тянуть больше страниц. Однако, когда пользователь возвращается к активности или даже просто поворачивается, вызов Volley будет возвращать результат только для начальной страницы, если вы не запомните все остальные запросы, содержащиеся в этой странице. Это становится большой работой для архитектуры, которая должна быть более удобной. Или даже немного отличающаяся страница, это может быть непоследовательным для пользователя, если все, что они делали, это поворот телефона.

• данные должны быть изменены

Легче применять изменения локально, а затем применять к серверу всякий раз. Только с волейболом вам придется выполнять обновление REST и запрос (всех предыдущих запросов) синхронно.

• Скорость и настойчивость

Волейбол очень быстрый. Тем не менее, он не имеет никакой стойкости, кроме кеш-хитов, где доступно, что может зависеть от сервера, на который вы запрашиваете. Агрессивное кэширование может даже нанести ущерб вашему приложению с устаревшими данными. Выгрузка из локальной базы данных обеспечивает последовательный и быстрый опыт при навигации по нескольким действиям, которые могут фактически ссылаться на данные в прошлых запросах. Для чистого опыта волейбола вам может потребоваться запросить данные, которые у вас есть в техническом отношении уже из предыдущих запросов, но у них нет центрального хранилища данных для получения этих данных.

Гибридный волейбол и курсоры

В эти дни я фактически пропускаю часть сервиса, но все остальное остается от традиционной арки

UI инициировать запрос волейбола и загрузку курсора → обновить ui

Запрос волейбола → обновить базу данных → уведомить

Кроме того, нет ничего, что помешало бы вам получить услугу ui ping, а затем услуга использует залп... Это будет выглядеть более традиционным, может быть, значение перемещает больше логики управления куда-то более централизованно, но тот факт, что он запускается из-за "услуги" фактически не предлагает технического преимущества.

Резюме

Надеюсь, это поможет. В принципе, не пытайтесь идти только волейбол, я пытался, и это было бы очень конкретное и простое приложение, если бы это сработало для вас и, надеюсь, я определил основные подводные камни.

Кроме того, я нашел те же подводные камни с robospice, несмотря на то, что он был на службе... Но... YMMV

Ответ 2

Volley - это просто вспомогательный уровень для общения с сервером, который управляет потоками и другими. Да, он уже реализует красивое кэширование потоков и прочее. Но вы не должны использовать его в своей деятельности. Я бы даже сказал, что не стоит. Мы все знаем, что услуга на самом деле является местом для любой фоновой сетевой работы. Он предназначен для сохранения изменений конфигурации и является естественным способом для вашего приложения заявить, что он работает в фоновом режиме и должен быть принят с особой тщательностью системой.

Представьте себе, что волейбол не было. Что бы вы сделали? Готов поспорить, что вы воспользуетесь поддержкой потоков в службе, правильно (все мы знаем, что службы работают в основном потоке)? Это может быть так же просто, как IntentService, который является единственным статическим рабочим потоком и обработчиком для него. Или вы можете подумать и использовать ExecutorService для создания пула потоков. Или вы можете сходить с ума и начинать new Thread() каждый раз в onStartCommand(). Независимо от ваших потребностей и вкуса.

Поэтому я предпочитаю смотреть на Volley как на еще один способ решения этих задач. На этот раз вам не нужно выполнять какую-либо работу с потоками самостоятельно, вы просто должны сделать Volley для вас.

Таким образом, в нижней строке используется использование волейбола и сервиса.

Ответ 3

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

В основном у меня есть CompleteRequest, который вернет:

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

Запрос выглядит так:

public class SampleRequest extends CompleteRequest<Object> {

    public SampleRequest(int method, String url, ResponseListener<Object> responseListener, Response.ErrorListener errorListener) {
        super(method, url, responseListener, errorListener);
    }

    @Override
    protected Object getLocalResponse() {
        // query your local database for example
        // return the result or null if there is no result from database
        return new Object();
    }

    @Override
    public void saveNetworkResponseToLocal(Object response) {
        // save the network response to the local database
        // next time the request is performed the local response will return the result faster than the network request
    }

    @Override
    protected BallResponse<Object> parseBallNetworkResponse(NetworkResponse response) {
        // parse the result from the network request, in the same way than with volley
        return Response.success(new Object());
    }
}

И вы выполняете такой запрос, с прослушивателем ответа, который включает в себя промежуточный и окончательный ответ:

mRequestQue.add(new SampleRequest(Request.Method.GET, "http://some.url", new ResponseListener<Object>() {
    @Override
    public void onIntermediateResponse(Object response, BallResponse.ResponseSource responseSource) {
        // intermediate response, such as from local database or soft cached network response
    }

    @Override
    public void onFinalResponse(Object response, BallResponse.ResponseSource responseSource) {
        // final response, which is the network response
    }

    @Override
    public void onFinalResponseIdenticalToIntermediate(BallResponse.ResponseSource responseSource) {
        // final response is identical to intermediate one
        // happens when intermediate is from soft cache and network response is identical (not modified)
    }

}, new Response.ErrorListener() {
    @Override
    public void onErrorResponse(VolleyError error) {
        // network response is an error, in the same way than with volley
    }
}
));

Он все еще находится на ранней стадии разработки, но я использую его в нескольких приложениях, и он работает хорошо. Я написал быстрый пример с примерами, и есть пример проекта, который может помочь.

Вы можете проверить это на https://github.com/lukaspili/Volley-Ball

Ответ 4

Всегда используйте залп для загрузки материала. Если вам дополнительно нужно хранить данные в db, вы все равно можете его использовать. Просто переосмыслите свою архитектуру. Volley - это сетевой инструмент, не более того.

Oh и volley не используют AsyncTasks.

Ответ 5

Volley предназначен для предоставления более удобного способа асинхронного выполнения сетевых запросов. Это не требует от вас подкласса Service или AsyncTask, и его синтаксис очень прост для любого опытного разработчика.

Как указано выше, это вполне удобно. Если у вас есть механизм, который хорошо работает, тогда обязательно используйте его. Если вы постоянно переписываете код, который следует за вашей существующей моделью, вы можете захотеть заглянуть в библиотеку многократного использования, такую ​​как Volley или droidQuery.

Нет правильного или неправильного ответа. Однако может быть лучший или худший фактор. Основное сравнение здесь - скорость. Volley может похвастаться быстрыми скоростями и вскоре планирует поддерживать OKHTTP, а также стать частью Android SDK (или пакета совместимости), продолжая расти с платформы Android. Если эти вещи важны для вас, то, возможно, вам следует переключиться на будущие приложения (если у вас нет заметного запаздывания в текущих приложениях, я бы изо всех сил пытался понять, что нужно изменить рабочий код).