我应该使用服务作为访问网络数据的方式吗？
我对 Android 开发有点陌生，我正在尝试构建一个非常简单的应用程序，它将浏览我的网络以查找 DLNA 服务器，并允许我将每个 DLNA 服务器作为目录浏览。这个想法非常简单：一个 Activity 显示网络上的所有 DLNA 服务器，用户选择一个，然后我们重定向到另一个浏览 DLNA 媒体服务器目录的 Activity。
我的问题非常基本：如何保留“所选服务器”、“当前目录”等信息以及其他类似信息？我只需要一种方法让我的应用程序的其余部分知道该做什么。我应该将这些数据构建到服务中吗？这似乎违反了对服务应该是什么的普遍理解。我/应该如何保留应用程序状态？
I'm somewhat new to Android development and I'm trying to build a very simple app which will browse my network for DLNA servers and allow me to browse each DLNA server as a directory. The thought is pretty simple: one activity displays all DLNA servers on the network, user selects one, then we redirect to another activity which browses the DLNA media server's directories.
My question is quite basic: how do I persist information like 'selected server', 'current directory' and other things like this? I just need a way for the rest of my application to know what to do. Should I build this data into a service? It seems like that violates the common understanding of what services should be. How can I/should I persist application state?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你有几个选择。我认为我最喜欢的一点是，您只需将这些值传递到从一个活动发送到下一个活动的 Intent 对象中即可。因此，浏览 DLNA 媒体服务器目录的活动会接收 Intent 中选定的服务器，如果该活动来自 DLNA 列表活动，那就太好了，但该 Intent 可能来自任何其他想要向 DLNA 媒体服务器目录显示的活动。用户。努力将功能封装在活动中，这样它就不需要依赖于应用程序的其余部分来获取数据。
当您确实需要跨应用程序提供数据时，请查看 SharedPreferences。这些可以向用户显示，以便他们可以做出在应用程序调用过程中持续存在的选择，并且应用程序中的任何活动都可以轻松读取首选项并保持最新状态。然而，并非所有首选项都需要可显示。您始终可以创建一个首选项编辑器来读取和写入您自己的首选项，而无需将其显示给用户。
其他几个选项是设置保存共享值的单例类，并且每个活动都可以引用该值，或者作为最后的手段，您可以扩展 Application 类，并创建 getter 和 setter 以使值在您的应用程序中可用。我说最后的手段是因为 Application 是 Android 中的一个重要类，最好不要管它，这样您现在或将来就不会意外地破坏某些东西。
要回答您的另一个问题，您不仅应该使用服务来进行网络访问，而且还需要创建线程。 Android 服务默认不包含后台线程，您需要自己执行此操作。您永远不应该从主（也称为 UI）线程进行网络调用。
You have a few options. The one that I think I like the best is that you simply pass these values in the Intent object that you're sending from one activity to the next. Therefore, the activity that browses the DLNA media server's directories receives the selected server in the intent, and if that came from the DLNA list activity, that's great, but the intent could come from any other activity that wants to show media server directories to the user. Try very hard to encapsulate functionality inside an activity so it doesn't need to depend on the rest of the application for data.
When there is data that you really do need across an application, take a look at SharedPreferences. These can be displayable to the user so they can make choices that persist across invocations of your application, and any activity in your application can easily read the preferences and keep current. Not all preferences need to be displayable however. You can always create a preferences editor to read and write your own preferences without ever showing them to a user.
A couple of other options are to setup singleton classes that hold your shared values, and that every activity can refer to, or as a last resort you can extend the Application class, and create getters and setters to make values available across your application. I say last resort because Application is a significant class in Android that's better left alone so you don't accidentally break something now or in the future.
To answer your other question, not only should you use services to do network accesses, but you need to create Threads as well. An Android service does not by default include a background thread, you need to do that yourself. You should never make network calls from the main (a.k.a. UI) thread.