好的。我开始为我们的企业 Web 应用程序开发一个 Android 应用程序。刚刚开始登录屏幕活动设计。
这个应用程序完全由 RESTFul API 驱动。
我想了解如何在应用程序中开发登录/注销功能。据我了解，应用程序世界中没有 Session 概念。此外，对于 API，我们需要在每个请求中发送用户名和密码（基本身份验证）。显然，我们需要将登录凭据保存在本地存储中的某个位置，以便与每个请求一起发送。
这是我从我的基本Android知识中了解到的。
当用户输入登录信息并按下按钮时，我们将启动对 API 的 HTTP 调用。如果登录凭据有效，那么我们必须将凭据存储在本地。选项是
还有其他选择吗？
我想确保我遵循最佳实践，同时不牺牲性能和架构的角度。
对于注销，我想我只需要清除本地存储的凭据并显示登录活动即可。
有没有不同的更好的方法？
我建议使用 Android帐户功能。
这个博客有一个关于你需要放在一起的所有位的非常好的分步指南。
一般的想法是您向AccountManager提供用户的用户名/密码，并将其留给 AccountManager 来安全地存储它们。
当你需要一个身份验证令牌时，你向 AccountManager 请求一个，它会返回一个缓存的令牌，或者回调你的代码（传递用户名/密码），然后你调用你的身份验证服务来获取一个新的令牌.
通常，您可以通过三种方式在 Android 中持久化数据：SQLite、.SharedPreferences以及通过 Java I/O 读取/写入文件。SQLite 是关系数据的最佳选择，但因为您只需要存储用户的凭据，我建议您使用 SharedPreferences。在我看来，这就像一个简单的键值数据模型。
SharedPreferences基本上只是对直接文件 I/O 的一种封装——也就是说，底层的实现仍然是文件读写，只是针对键值对进行了简化。我对加密知之甚少，但在将密码存储在SharedPreferences对象中之前，您可能必须自己处理（也请考虑 JaiSoni 的建议：改用访问令牌）。不过请放心，如果您创建SharedPreferences并将其设置为MODE_PRIVATE，其他应用程序将无法访问共享的 prefs 文件。
我相信这几乎是一个标准的实现。如果您查看此页面，您可以做的只有这么多：http: //developer.android.com/guide/topics/data/data-storage.html
我还需要指出，直接文件 I/O 的复杂性之一是您必须决定要将文件存储在哪里——内部或外部存储器（例如，SD 卡）——并因此检查它的可用性（并非所有设备都有 SD 卡插槽，有时内部存储器被注册为设备的外部存储器）。因此，只需使用共享首选项即可。
对于注销，这可能很有用：删除共享首选项
我认为在应用程序中存储密码是个坏主意，更好的方法是在用户登录时第一次使用用户凭据发出请求，服务器返回访问令牌保存此访问令牌以SharedPreferences用于其他目的，例如获取用户详细信息在请求中使用令牌.
会话：创建自己的类来维护会话。Hackbook就是一个很好的例子。
为什么需要将登录凭据保存在文件或数据库中？你想在你的应用重启后自动登录吗？如果不需要持久性，您可以将凭据放入静态 java 成员中。