Question

[argen666]

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

1. Запрос на сервер успешен, но требуется обновить существующие данные в бд и добавить новые.
2. Запрос на сервер завершился с ошибкой. Какие я вижу варианты:
3. В BaseLoader поставить метод onSuccess перед save, передать в него Response и сделать очистку данных, либо вообще вынести метод сохранения из базового класса в наследники, если логика сохранения в бд более сложная.
4. Доработать метод apiCall и в случае ошибки вернуть базовому лоадеру Response с данными из бд, в таком случае BaseLoader не заметит, что данные пришли не с сервера, либо сделать метод onError возвращающим Response и писать эту обработку в нем, что менее гибко, я считаю. Также, чтобы вернуть в BaseLoader результат из бд в рамках данной модели, придется делать примерно так:

List<Airport> airports=
AirportsTable.listFromCursor(getContext().getContentResolver().query(AirportsTable.URI, null, null, null, null));
return new AirportsResponse().setRequestResult(RequestResult.SUCCESS).setAnswer(airports); 

Не скажется ли такой подход (наполнять коллекцию из курсора) на производительности, при достаточно большом объеме данных? Спасибо!

[ArturVasilov]

Добрый вечер! Вопросы интересные, постараюсь ответить правильно :) В случае 1 проблем не вижу. Поведение при сохранении объекта Response в бд полностью определяете Вы. То есть Вы можете переопределить метод save таким образом, чтобы он вначале очищал базу, и только потом сохранял значения в нее. Поскольку все эти методы выполняются в бэкграунде, проблем не возникнет. Второй случай поинтереснее, но Ваше решение кажется мне достаточно хорошим. Наполнение коллекции из курсора - это не такой долгий процесс, собственно, почти вся локальная работа по длительности значительно быстрее запросов на сервер, так что этим можно пренебречь и проблем быть не должно. Если у Вас, конечно, 10+ Мб данных, то еще что-то можно ощутить, но не забывайте главное - все эти методы работают в фоне.

У меня была еще идея добавить объект Response в параметры метода onError, и в наследнике переопределить его таким образом, чтобы записать в него все данные из БД и изменить тип результата. Впрочем, суть одинаковая.

Опять же, у меня не было цели создать суперуниверсальную модель, которую можно использовать в любом приложении. Но я хотел создать базу, от которой каждый разработчик может отталкиваться и дорабатывать модель нужным образом. Впрочем, сам я использую именно такую модель, которую описал в статье :)

Надеюсь, я ответил. Я с удовольствием отвечу и на другие вопросы, но лучше пишите мне на почту vasilovartur@gmail.com . Спасибо.

Понедельник, 21 сентября 2015, 3:45 -07:00 от argen666 notifications@github.com:

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

1. Запрос на сервер успешен, но требуется обновить существующие данные в бд и добавить новые.
2. Запрос на сервер завершился с ошибкой. Какие я вижу варианты:
3. В BaseLoader поставить метод onSuccess перед save, передать в него Response и сделать очистку данных, либо вообще вынести метод сохранения из базового класса в наследники, если логика сохранения в бд более сложная.
4. Доработать метод apiCall и в случае ошибки вернуть базовому лоадеру Response с данными из бд, в таком случае BaseLoader не заметит, что данные пришли не с сервера, либо сделать метод onError возвращающим Response и писать эту обработку в нем, что менее гибко, я считаю. Также, чтобы вернуть в BaseLoader результат из бд в рамках данной модели, придется делать примерно так: List airports= AirportsTable.listFromCursor(getContext().getContentResolver().query(AirportsTable.URI, null, null, null, null)); return new AirportsResponse() .setRequestResult(RequestResult.SUCCESS) .setAnswer(airports); Не скажется ли такой подход (наполнять коллекцию из курсора) на производительности, при достаточно большом объеме данных? Спасибо! — Reply to this email directly or view it on GitHub .

С уважением, Артур Василов artur_8005@mail.ru