使用 Android 从云端检索数据
我正在编写一个社交网络 Android 应用程序。我已经在 Microsoft Azure 上创建了一个带有数据库的 .Net Web 服务，我计划调用该 Web 服务从云中获取数据并将其显示给用户。类似于脸书。
现在，我想到了两种方法，但不确定要实施哪一种。方法如下：
- “每次加载活动时，调用 Web 服务并重新加载所有数据。” 当然，这是最简单的方法，但它是正确的吗？我的意思是，我有大约 30 个活动，其中一半加载数据，另一半发布数据。据我所知，这种方法可能是一个问题，因为它可能会减慢应用程序的速度。如此多的请求还会增加我的云费用。而且不知道每次都重新加载是否正确。
- “每 10 分钟调用一次 Web 服务，并将所有数据存储在 SQLite 数据库中，只有超过 10 分钟才更新数据，甚至可能有一个刷新按钮。” 这种方法可能是更好，但我不确定是否值得编写这么多代码。
我需要你的建议来决定正确的技术。第 2 号看起来不错，但是如果有什么我不知道的东西，并且我无缘无故地编写了所有额外的代码怎么办？
请帮我一下。如果有更好的方法，请告诉我。
I am writing a social networking android application. I have create a .Net webservice with a database on Microsoft Azure, and I plan to call that web service to get data from the cloud and display it to the user. Similar to Facebook.
Now, I have two approaches in mind, and I'm not sure which one to implement. The approaches follow:
- "Every time an activity loads, call the web service and reload all the data." This, of course, is the easiest approach, but is it right? I mean, I have around 30 activities, and half of them load data, while the other half post. As far as I see, this approach can be a problem, because it might slow down the application. It can also increase my cloud bill with so many requests. And I don't know if it's right to reload everytime.
- "Call the webservice every 10 minutes, and store all the data in a SQLite database, and only update the data if it's been over 10 minutes, or possibly even have a refresh button." This approach is probably the better one, but I'm not sure if it is even worth writing so much code.
I need you advice in deciding on the right technique. Number 2 looks good, but what if there is something I don't know, and I'm writing all that extra code for no reason.
Please help me out here. If there is even a better approach, please do tell me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这实际上取决于数据的类型、数据需要什么样的延迟以及数据的数量。此外，随着复杂性的增加，项目的规模和您从实施中获得的好处也会增加。如需更准确的答案，请提供更多信息。
在这种情况下，本地缓存可能是一个非常好的主意。这是相当常见的做法，并且可以使用多种机制。根据从 Web 服务检索的数据的格式，
数据库中。
文件，如果您正在使用 xml 或 json 等格式化数据，有时很有用，因为您可以维护结构。您可以使用原生 Android 缓存 来协助管理存储。
当数据是简单类型（和字符串）并且数据不多时的首选项。
本地缓存将减少带宽消耗（最终会节省用户的钱，这一直很受欢迎），并且如果正确实施，则会减少内存和处理消耗。可能最重要的是（取决于数据），它可以在用户没有连接时有效地使用应用程序。
顺便说一句，30 个活动听起来很多，您确实应该考虑通过跨活动共享功能来减少活动，这应该会改善导航、代码量和内存占用。
来自评论的更新
根据有关您的项目的有限信息，我建议使用数据库作为您的数据存储（如果有），因为您不想在文件中缓存完整的 SOAP 消息以及数量40 多个记录可能会使首选项存储难以管理。
但是，正如我之前提到的，您需要考虑复杂性。使用数据库时，您必须创建一种与 SOAP 对象的反序列化分开的构造方法（可能是某种 ORM），因为从技术上讲，您将使用 2 种独立的持久数据格式。
我无法得到明确的答案，因为信息仍然非常有限，但您需要评估在项目中添加此类功能的成本以及您将获得的好处。
在考虑这种缓存时，我没有其他值得一提的事情。
It really depends on the sort of data, what sort of latency is required for the data and the quantity of data. Also the size of the project and benefit you will get from implementation as complexity will be increased. For a more precise answer provide further information.
Local caching can be a very good idea in this sort of situation. It is fairly common practice and there are multiple mechanisms which could be used. Depending on the format of data retrieved from your web service, you can store in a
Database, when data needs to processed (searched, queried etc) or there is a lot of data.
File(s), sometimes useful if you are working with formatted data such as xml or json as you can maintain the structure. You can use the native android caching to assist in managing the storage.
Preferences, when data is simple types (and strings) and there isn't much of it.
Local caching will reduce bandwidth consumption (will end up saving the user money which is always popular) and if implemented correctly memory and processing consumption. Possibly most important (depending on the data) it could allow for the effective use of the application when the user doesn't have connectivity.
By the way 30 activities sounds like a lot, you should really look at reducing that by sharing functionality across activities, this should improve navigation, code bulk and memory foot print.
UPDATE from comments
From the limited information available about your project I would suggest using the database as your data store (if any) as you don't want to be caching complete SOAP messages in files, and the quantity 40+ records may make preference storage difficult to manage.
However, as I have mentioned previously you need to consider complexity. When using the database you will have to create a method of construction (perhaps some sort of ORM) separate to your de-serialisation of SOAP objects because technically you will 2 separate persisted data formats.
I am not able to get a definitive answer because there is still very limited information but you need to evaluate the cost of adding such a feature to your project and the benefits you will receive.
I few other things worth mentioning when considering this sort of caching.