Выбор хранилища и кеширования - PullRequest
1 голос
/ 09 января 2012

Надеюсь, название выбрано достаточно хорошо, чтобы задать этот вопрос.

Не стесняйтесь редактировать, если нет, и примите мои извинения.

Я сейчас выкладываю приложение, которое взаимодействует с сетью.

Объяснение основного потока программы:

Пользователь вводит идентификатор пользователя в мою программу, который затем используется для доступа к нескольким XML-файлам через Интернет:

http://example.org/user/userid/?xml=1

Этот файл содержит несколько идентификаторов продуктов, которыми владеет пользователь в DRM-системе. Этот список затем используется для доступа к статистике и информации о взаимодействии пользователей с продуктом:

http://example.org/user/appid/stats/?xml=1

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

Вот тут и начинается ужас, по крайней мере для меня: D.

1.) Как сохранить эту информацию на ПК пользователя?

Я думал об использовании каталога для идентификатора пользователя, а затем вложенных папок с appid для кэширования изображений и XML-файлов для их загрузки по требованию. Я также подумал об использовании zipfile при использовании той же структуры.

Или лучше использовать для этого локальную базу данных, подобную sqlite?

Среднее количество приложений может составлять ~ 100-300, а статистика и изображения для приложения в основном составляют 5-700.

2.) Когда мне обновить содержимое?

Плохо то, что веб-сайт, с которого загружаются эти данные, или, точнее, xmls, не содержит отметок времени, когда они обновлялись / изменялись в последний раз. Поэтому мне нужно было бы хэшировать все файлы и сравнивать их в тот момент, когда пользователь обращается к этим данным, что может занимать много времени, поскольку они доступны через Интернет. Хорошо, есть тайм-ауты, но мне нужно будет заблокировать доступ к контенту до тех пор, пока данные не будут либо загружены и обработаны, либо не истечет тайм-аут. В обоих случаях приложение не будет доступно в течение короткого или, может быть, даже долгого времени, и я хочу избежать этого. Я мог бы позволить пользователю выполнить обновление вручную, когда ему это нужно, но потом я надеялся, что для этого есть более эффективные методы.

Особенно с указанным количеством приложений и прочего.

Спасибо за чтение и все такое, и, пожалуйста, не стесняйтесь спрашивать, если я забыл что-то объяснить.

1 Ответ

0 голосов
/ 09 января 2012
  1. Вероятно, стоит использовать БД, поскольку это избавляет вас от необходимости возиться с форматами файлов для структурированных данных. Не забывайте время от времени удалять и перестраивать его (или убедитесь, что старый материал тщательно удаляется и время от времени уплотняйте его, но, вероятно, его легче начать заново, поскольку это всего лишь кэш).

  2. Если веб-служба не дает подсказок, когда следует перезагрузить компьютер, вам просто нужно решить за себя, но обязательно проверьте заголовки HTTP на предмет любых инструкций кэширования, а также данных XML [* ]. Определите разумную устаревание данных (количество времени, которое пользователь тратит на просмотр результатов, составляет абсолютный минимум , поскольку они будут видеть результаты, которые устаревают независимо от того, что вы делаете). Всякий раз, когда вы загружаете что-либо, запишите, в какую дату / время вы его загрузили. Сбросить старые данные из кеша.

Чтобы предотвратить длительные задержки обновления данных, вы можете:

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

Или какая-то комбинация тактики.

[*] Если подумать, если веб-сервер предоставляет разумные инструкции по кешированию, то может быть проще всего забыть о каком-либо типе хранилища или кеширования в вашем приложении. Просто возьмите файлы XML и отобразите их, но получите через кеширующий веб-прокси, который вы интегрировали в свое приложение. Я не знаю, какие прокси делают это проще - вы можете скомпилировать Squid самостоятельно (конечно), но я не знаю, можете ли вы связать его с другим приложением, не изменяя его самостоятельно.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...