xml数据存储的最佳方法

发布于 2024-11-15 10:00:11 字数 539 浏览 0 评论 0 原文

我是一名学习 android 的 php/mysql 开发人员。我正在创建一个 Android 应用程序,它从我的 php 应用程序接收信息,以创建不同产品的列表视图,这将打开该产品详细信息的 Web 视图。

目前我的 php cms Web 应用程序为 iphone 应用程序输出 xml 列表....(也单独输出 html)。我可以完全控制 php 应用程序,因此如果有更好的方法来输出 Android 应用程序的数据,请告诉我。

我创建了从 Web 读取 xml 并创建列表视图的代码。该列表可以每天刷新,因此不需要每次应用程序启动时都从在线xml中读取数据。

因此,我正在考虑存储本地检索的数据以提高我的应用程序的响应能力。在任何给定时间,最多可能有 500 个产品描述存储在最多 30 个不同的 xml 列表中。我开始开发一个包含大约 30 种产品的 xml 列表。

为了获得最佳性能,我应该将产品信息存储在 sqlLite 数据库中,还是应该将实际的 xml 文件存储在缓存/数据库中或其他一些方法(例如应用程序缓存)中。

我还考虑将数据更新创建为服务,这是一个好主意吗?

I am a php/mysql developer learning android. I am creating an android app that receives info from my php app to create list views of different products which will open a web view of that product's detail.

Currently my php cms web application outputs xml lists for an iphone app.... (also, separately outputs html). I have full control of the php app so if there is a better way to output the data for the android app please let me know.

I have created code that reads the xml from the web and creates the list view. The list can be refreshed daily, so the data does not need to be read from the online xml every time the app starts.

So I was thinking to store the data retrieved locally to improve my apps responsiveness. there may be up to 500 product descriptions to be stored at any given time in up to 30 different xml lists. I am starting development with one xml list with about 30 products.

For best performance should i store the product info in a sqlLite db or should i store the actual xml file in the cache/db or some other method like application cache.

I also was think to create the update of the data as a service, would this be a good idea?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

鲜肉鲜肉永远不皱 2024-11-22 10:00:11

存储数据最有效的方式是 RAM。但如果你想缓存它,那么最有效的方法就是数据库。

我建议您将数据存储在 sqlite android 数据库中。

您还可以考虑压缩 xml 以加快网络传输速度,并通过 java.util.zip 包类进行解压缩。您甚至可以考虑使用数据输入/输出流,使用更简单的格式来传输数据,比 xml 更简洁。
(我在我的应用程序中这样做,效果很好)

以下是有关数据输入/输出流方法的一些详细信息:

  • 想象一下您的数据的专有协议,只有您需要的。没有标签,没有属性,只有按顺序排列的原始值。
  • 在客户端,使用 URL.getContent() 获取数据的输入流并将其投射到输入流中。
  • 仍然在客户端,构建一个封装套接字输入流的数据输入流并按顺序读取数据。使用 readInt、readDouble、readUTF 等。
  • 在客户端,从 php 开始,您需要找到一种方法来以与客户端期望的数据格式兼容的格式保存数据。我对PHP了解不多,我只使用java编程。

这种技术的优点是可以节省带宽,因为只有数据,没有 xml 带来的详细装饰。您应该阅读有关 java 规范的内容,以了解如何在数据输出流中写入 double、int、string。但使用两种语言来获取正确的数据可能很困难。

如果php不能以合适的方式保存格式,使用xml,会简单得多。首先尝试使用纯 xml,然后尝试使用 zip、tarball 或 xml 文件。

但这一切都是关于网络连接期间的速度增益。

您要做的第二部分是将列表的每一行存储在 SQL 表中。然后,您可以使用列表视图的 CursorAdapter 快速检索它(它破坏了迷人的 MVC 模型,但速度相当快!)。

The most efficient way to store data is RAM. But if you want to cache it, then the most efficient way is Database.

I recommend you store your data in sqlite android database.

You could also consider zipping you xml for faster network transfer and unzipping through java.util.zip package classes. You could even consider a simpler format for transmitting data, less verbose than xml, using a datainput/outputstream.
(I do that in of my apps and it works great)

Here are some details on data input / output stream method :

  • imagine a proprietary protocol for your data, only what you need. No tags, no attributes, just raw values in order.
  • on the client side, get an input stream on your data using URL.getContent() and cast it in input stream.
  • on the client side still, build a data input stream encapsulating your socket input stream and read data in order. Use readInt, readDouble, readUTF, and so on.
  • on the client side, from php, you need to find a way to save your data in a format that is compatible with the data format expected by the client. I can't tell much about PHP, I only program using java.

The advantage of this technique is that you save bandwith as there is only data and no verbose decoration due to xml. You should read about java specs to understand how double, int, strings are written in data output stream. But it can be hard using two languages to get the data right.

If php can't save format in a suitable way, use xml, it will be much simpler. First try with just plain xml, then give a try using a zip or tarball or xml file.

But all this is about speed gain during network connection.

The second part of what you have to do is to store each row of your list in a SQL table. Then you can retrieve it pretty fast using a CursorAdapter for your list view (it breaks the charming MVC model but it is quite fast !).

梅窗月明清似水 2024-11-22 10:00:11

对此感到抱歉,但作为评论写起来太长了。这并不是要回答你的问题,因为在我看来,Stéphane 回答得很好。最好的解决方案确实是将数据存储在 sqlite 数据库中。然后您需要创建用作数据、数据库和应用程序之间的连接的类。我不想把这里所说的归功于我(我也投了赞成票)。

我关心其他建议(使用低级原始流进行数据操作,该答案的列表步骤)。我强烈建议您避免创建自己的专有协议。它是这样的:

  • 我需要交换数据。
  • 我不想处理将外部 API 集成到我的代码中的麻烦。
  • 我知道我可以编写两个 5 分钟的例程来来回读写数据。
  • 因此,我只是创建了自己的专有格式来交换数据!

每当我需要处理未知的、晦涩的和任意的数据块序列时,它都会让我哭泣。记住为什么我们不应该使用未知格式总是好的:

  • 重新发明轮子会适得其反。看起来不是,但从中期来看是这样。您可以轻松地将您的项目适应其他媒介(服务器端、其他平台)。
  • 使用现成的组件可以帮助您稍后扩展代码。
  • 每当您需要使您的解决方案适应其他技术和媒介时,您的工作速度都会更快。否则,您可能最终会得到无法(轻松)扩展和互操作的临时代码解决方案。
  • 使用现成的组件使您能够利用该特定技术的进步。当您使用 Android API 时,这一点尤其重要,因为它们经常会在以后针对性能进行优化(请参阅 Android 的 为性能而设计)。制定自己的标准可能会导致性能下降。
  • 除非您记录了您的协议​​,否则很容易忘记您自己创建的协议。只要给它足够的时间,它就会发生:你需要重新学习/记住。如果你记录下来,那么你只是在浪费大脑的计算时间。
  • 您认为您不需要扩展您的工作,但大多数时候您很可能会这样做。
  • 当您这样做时,您会希望自己已经学会了如何轻松、无缝地集成众所周知的格式。
  • 无论如何,学习曲线是需要的。根据我的经验,当您学习时,您实际上会比想象自己的做事方式更快地集成众所周知的格式。
  • 最后,将您的数据托付给天才,他们会毕生致力于创建有凝聚力的智能标准。他们更了解这一点!

最后,如果目的是避免 XML 典型的冗长,无论出于何种原因,您都有多种选择。现在我可以想到 CSV,但我不是数据存储方面的专家,所以如果您对它不满意,我相信您可以找到很好的替代品,并提供大量现成的 API。

祝你好运!

Sorry about this, but it became too long to write as a comment. This is not intended to be an answer to your question, because in my opinion Stéphane answered very well. The best solution is indeed to store the data in an sqlite database. Then you need to create the class to be used as a connection between the data, the database and the app. I don't want to take credit for what is said here already (I, too, voted it up).

I'm concerned with the other suggestion (use of low level raw streams for data manipulation, the list steps on that answer). I strongly recommend you to avoid creating your own proprietary protocol. It goes like this:

  • I need to exchange data.
  • I don't want to deal with the hassle of integrating external APIs into my code.
  • I know I can write two 5 minute routines to read and write the data back and forth.
  • Therefore, I just created my own proprietary format for exchanging data!

It makes me cry whenever I need to deal with unknown, obscure and arbitrary sequence of data blobs. It's always good to remember why we should not use unknown formats:

  • Reinventing the wheel is counter-productive. It seems not, but on the middle term it is. You can adapt your project to other mediums (server-side, other platforms) easily.
  • Using off-the-shelf components help you scale your code later.
  • Whenever you need to adapt your solution to other technologies and mediums, you'll work faster. Otherwise, you would probably end up with ad hoc code solutions that are not (easily) extensible and interoperable.
  • Using off the shelf components enables you to leverage advances in that particular technology. That's particularly important when you are using Android APIs, as they are frequently optimized for performance later down the road (See Android's Designing for Performance). Rolling your own standards may result in a performance penalty.
  • Unless you document your protocol, it's extremely easy to forget the protocol you created yourself. Just give it enough time and it will happen: you'll need to relearn/remember. If you document, then you are just wasting the computational time of your brain.
  • You think you don't need to scale your work, but chances are you will most of the time.
  • When you do, you will wish you had learned how to easily and seamlessly integrate well known formats.
  • The learning curve is needed anyway. In my experience, when you learn, you actually integrate well known formats faster than imagining your own way of doing things.
  • Finally, trust your data to geniuses that take their lives into creating cohesive and intelligent standards. They know it better!

Finally, if the purpose is to avoid the typical verbosity of XML, for whatever reasons, you have several options. Right now I can think of CSV, but I'm no expert in data storage, so if you're not confortable with it, I'm sure you can find good alternatives with plenty of ready to use APIs.

Good luck!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文