лучший метод для хранения данных XML

Question

Я разработчик php / mysql для обучения Android. Я создаю приложение для Android, которое получает информацию из моего php-приложения для создания представлений списков различных продуктов, которые откроют веб-представление деталей этого продукта.

В настоящее время мое веб-приложение php cms выводит списки xml для приложения iphone .... (также отдельно выводит html). У меня есть полный контроль над приложением php, поэтому, если есть лучший способ вывести данные для приложения Android, пожалуйста, дайте мне знать.

Я создал код, который читает XML из Интернета и создает представление списка. Список можно обновлять ежедневно, поэтому нет необходимости читать данные из онлайн-XML каждый раз при запуске приложения.

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

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

Я также подумал, чтобы создать обновление данных в качестве службы, это было бы хорошей идеей?

Answer 1

Наиболее эффективным способом хранения данных является оперативная память.Но если вы хотите его кэшировать, то наиболее эффективным способом является база данных.

Я рекомендую хранить ваши данные в базе данных sqlite android.

Вы также можете рассмотреть возможность архивирования XML для ускорения передачи по сети.и разархивировать через классы пакетов java.util.zip.Вы могли бы даже рассмотреть более простой формат для передачи данных, менее подробный, чем xml, используя поток данных / outputtream.(Я делаю это в своих приложениях, и это прекрасно работает)

Вот некоторые подробности о методе потока ввода / вывода данных:

• представьте собственный протокол для ваших данных, только чтотебе нужно.Никаких тегов, никаких атрибутов, только необработанные значения в порядке.
• на стороне клиента, получите поток ввода для ваших данных с помощью URL.getContent () и приведите его во входной поток.
• на стороне клиента все же создайте поток ввода данных, инкапсулирующий поток ввода сокетов, и считывайте данные по порядку.Используйте readInt, readDouble, readUTF и т. Д.
• на стороне клиента, из php, вам нужно найти способ сохранить ваши данные в формате, совместимом с форматом данных, ожидаемым клиентом.Я не могу много рассказать о PHP, я программирую только с использованием Java.

Преимущество этого метода в том, что вы сохраняете пропускную способность, так как есть только данные и нет подробного оформления из-за xml.Вы должны прочитать о спецификациях java, чтобы понять, как строки double, int, string записываются в поток вывода данных.Но это может быть трудно, используя два языка, чтобы получить правильные данные.

Если php не может сохранить формат подходящим способом, используйте xml, это будет намного проще.Сначала попробуйте просто обычный xml, затем попробуйте использовать zip, tarball или xml файл.

Но все это связано с увеличением скорости при сетевом подключении.

Вторая часть того, что у вас естьчтобы сделать, это сохранить каждую строку вашего списка в таблице SQL.Затем вы можете получить его довольно быстро, используя CursorAdapter для представления списка (это ломает очаровательную модель MVC, но это довольно быстро!).

Answer 2

Извините за это, но писать в качестве комментария стало слишком долго.Это не является ответом на ваш вопрос, потому что, по моему мнению, Стефан ответил очень хорошо.Лучшее решение - хранить данные в базе данных sqlite.Затем вам нужно создать класс, который будет использоваться в качестве соединения между данными, базой данных и приложением.Я не хочу брать в расчет то, что здесь уже сказано (я тоже проголосовал за него).

Меня беспокоит другое предложение (использование низкоуровневых необработанных потоков для манипулирования данными,список шагов на этот ответ).Я настоятельно рекомендую вам избегать создания собственного проприетарного протокола.Это выглядит так:

• Мне нужно обмениваться данными.
• Я не хочу иметь дело с трудностями интеграции внешних API в мой код.
• Я знаю, что могу написать две 5-минутные процедуры для чтения и записи данных туда и обратно.
• Поэтому я просто создал свой собственный собственный формат для обмена данными!

Это заставляет меняплакать всякий раз, когда мне нужно иметь дело с неизвестной, непонятной и произвольной последовательностью больших двоичных объектов.Всегда хорошо помнить, почему мы должны , а не использовать неизвестные форматы:

• . Изобретать колесо непродуктивно.Кажется, нет, но в среднесрочной перспективе это так.Вы можете легко адаптировать свой проект к другим средам (на стороне сервера, на других платформах).
• Использование готовых компонентов поможет вам масштабировать ваш код позже.
• Всякий раз, когда вам нужно адаптировать вашРешение других технологий и сред, вы будете работать быстрее.В противном случае вы, вероятно, в конечном итоге получите кодовые решения ad hoc , которые (легко) не расширяемы и не совместимы.
• Использование готовых компонентов позволяет использовать преимущества этой конкретной технологии.Это особенно важно при использовании API-интерфейсов Android, так как они часто оптимизируются для повышения производительности в будущем (см. Designing for Performance * для Android ).Изменение ваших собственных стандартов может привести к снижению производительности.
• Если вы не задокументируете свой протокол, очень легко забыть созданный вами протокол.Просто дайте ему достаточно времени, и это произойдет: вам нужно будет переучиться / запомнить.Если вы документируете, то вы просто тратите время на вычисления вашего мозга.
• Вы думаете, что вам не нужно масштабировать свою работу, но скорее всего, вы будете делать это большую часть времени.
• Когда вы это сделаете, вы захотите, чтобы вы узнали, как легко и без проблем интегрировать хорошо известные форматы.
• Кривая обучения в любом случае необходима.По моему опыту, когда вы учитесь, вы на самом деле интегрируете известные форматы * на 1038 * быстрее , чем представляете себе собственный способ ведения дел.
• Наконец, доверьте свои данные гениям, которые отдают свои жизни на создание связногои интеллектуальные стандарты.Они знают это лучше!

Наконец, если цель состоит в том, чтобы избежать типичного многословия XML по каким-либо причинам, у вас есть несколько вариантов.Прямо сейчас я могу думать о CSV, но я не специалист по хранению данных, поэтому, если вам это неудобно, я уверен, что вы можете найти хорошие альтернативы с большим количеством готовых к использованию API.

Удачи!