问题描述
请考虑以下情形.一家公司发布了许多应用程序.他们希望在所有这些应用程序之间共享一些数据.这些应用程序中的任何一个都可以创建或读取这些数据，就像普通的数据库一样.因此，公司决定创建一个实现此目的的android库.我搜索了几天，下面给出了我的分析.
-
SharedPreferences-不推荐使用，不建议使用.它也没有达到目的.所有其他应用程序都需要知道创建数据的应用程序的程序包名称才能创建PackageContext.在这里这是不切实际的，因为任何应用程序都可以创建/更新/读取数据，并且无法说出谁是谁.
-
ContentProviders-这不适用于我.每个应用程序中都必须存在ContentProviders之类的原因.设备中不能有两个具有相同名称的内容提供者.除此之外，ContentProviders基本上是为一个应用程序创建数据而其他应用程序使用Content_Uri订阅数据.
-
网络连接-我们不想在任何服务器上存储数据.
-
外部存储-这是剩余的唯一选项.我应该去吗?
有趣的是，还必须保护数据安全，任何存储选项均不支持该数据.
注意:对于iOS，我们使用钥匙串实现相同的功能
了解Android上的问题
具有讽刺意味的是，由于iOS上的沙盒过多，如果需要共享数据的应用程序全部由同一位开发人员提供，则有一种简单的方法可以在此实现(应用程序组).可能是因为Android在安全性方面更加灵活，但这实际上最终是一个更困难的问题.到目前为止，由于安全解决方案的安全性较低，Android团队不适合提供一种方便，安全的方式来专门共享此类数据.也就是说，有很多方法可以在不涉及云的情况下在应用程序之间共享数据.
SharedPreferences
原始问题指出不建议使用SharedPreferences.据我所知，这是不正确的，但是不赞成使用MODE_WORLD_READABLE和MODE_WORLD_WRITABLE上下文，这使这种方法将来无法使用.自Android 4.2(2012)起，此模式已弃用了相当长的时间.当前的Android文档中没有威胁表明他们实际上正在逐步淘汰它(有时弃用只是意味着这不是一个好主意"而不是将被删除").我怀疑在设置级别缺少用于应用程序数据共享的更安全的OS级直接替代可能是在过去5年中将其保存为弃用状态的原因.
文件访问
我知道在Android上的应用程序之间实现数据共享的最简单，最常见的方法是，简单地请求设备上的文件访问，并在外部存储中为该数据创建共享位置.(不要与外部存储"名称混淆-这只是Android引用共享数据的方式.它不一定引用SD卡.)为文件指定一个唯一的名称，然后将其存储在您的应用知道在哪里寻找它.获得该路径的最佳方法是:Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOCUMENTS)
明显的问题是安全性.虽然不被OS弃用，但它引入了与Android文档列表相同的问题，作为MODE_WORLD_ *被弃用的原因-它本质上是不安全的，并在您的应用程序中打开了潜在的漏洞利用之路.
- 您正在将信息放置在所有内容都可以随时访问的位置它.
- 您正在请求您的应用可能不需要的权限.
- 您正在读取无法验证其来源的文件.
如果您的应用程序未处理任何敏感数据，那么这对您(对您的用户)可能并不重要.如果打算从这些文件中读取数据，则应确保在解析之前为这些数据提供最大的验证.检查文件的大小，验证格式等.
创建自己的服务
您始终可以创建Service或IntentService.(两者之间有细微的差异，但是IntentService是Service的子类，它在Worker线程中运行，而Service中断主线程.IntentService还实现了Intent支持，可在Android上提供最直接的应用程序间通信.)
此服务具有其自己的私有存储，对其具有完全的读/写访问权限，但没有其他操作.然后，该服务提供了一个界面，用于从其他应用程序接收Intent，并将结果(作为Intent)返回给那些应用程序.这是在实现应用程序间数据同时最大程度地提高数据隐私性和数据安全性的一种极其友好的方式.如果外围应用大部分需要从中央应用中请求非常基本的信息，那么这是您的入门级选项.
实施BroadcastReceiver
同一行是BroadcastReceiver类.取决于您打算在应用程序之间共享哪种数据，以及这些应用程序对您的特定方法可能有多熟悉，这是另一种可能性.同样，您将在一个应用程序的私有存储下管理共享数据.通信是由Intents完成的，因此它类似于IntentService-区别在于应用程序可以通过发出系统范围的事件与BroadcastReceiver进行通信(也就是说，它们不需要与您的应用程序或服务进行显式通信-它们会大声喊叫一个信息世界，期待一个答案.)
创建ContentProvider
原始帖子似乎误解了ContentProvider是什么以及它如何工作.您必须像对待云解决方案一样考虑此类项目-即使它是设备本地的.每个应用都不需要ContentProvider，它们都需要与ContentProvider进行通信，并且ContentProvider可以维护，更新和返回数据.
对于该特定用例，这可能是最"Android-y"的解决方案，并且提供了最大的可扩展性.您实现了一个独立的过程来处理数据存储并响应其他应用程序.但是，这是一个更加发展的解决方案-因此，这可能是更具挑战性的工作.如果您需要真正的数据库服务，而不是相当简单的请求/响应类型服务，则ContentProvider似乎是最佳选择.
Consider the following scenario. A company releases many apps. And they want some data to be shared across all these apps. Any of these app can create or read these data, just like a common database. So company decided to create an android library which does this purpose. I searched for a few days and my analysis are given below.
SharedPreferences- not recommended and is deprecated. It does not serve the purpose too. All other apps need to know the package name of the app that created the data to create PackageContext. Here this is impractical as any app can create/update/read data and it is not possible to say who is who.
ContentProviders - This does not work for me. The reason being ContentProviders has to be present in each app. There can not be 2 content providers with same name in a device. In addition to that, ContentProviders are basically meant for one app creates data and other apps subscribe to it using Content_Uri.
Network connection - We do not want to do store data in any server.
External storage - This is the only option remaining. Should I go for this?
And interestingly the data has to be secured as well which is nowhere supported in any of the storage options.
Note: For iOS, we use keychain to implement the same functionality
Understanding the problem on Android
Ironically, due to the intense sandboxing on iOS, there's a straightforward way to make this happen there (App Groups) provided the apps that need to share data are all by the same developer. Likely because Android is more flexible on security, this actually ends up being a more difficult problem there. The Android team have so far not seen fit to provide a convenient and secure way to specifically share this kind of data because there's a low security workaround.
That said, there are plenty of ways to share data between applications without involving the cloud.
SharedPreferences
The original question states that SharedPreferences are deprecated. This isn't true, as far as I can tell, however the MODE_WORLD_READABLE and MODE_WORLD_WRITABLE contexts are deprecated which makes this approach subject to not working in the future. The mode has been deprecated for quite some time, though - since Android 4.2 (2012). There's no threat in the current Android docs to suggest they're actually phasing it out (sometimes deprecation just means "this isn't a great idea" not "this is going to be removed"). I suspect the lack of a more secure OS-level direct alternative for application data sharing at the settings level is probably the reason for preserving it in a state of deprecation for the last 5 years.
File Access
The simplest and most common way I'm aware of to implement data sharing between applications on Android is to simply request file access on the device and create a shared location on external storage for this data. (Don't be confused by the "external storage" designation - this is just how Android refers to shared data. It doesn't necessarily refer to an SD card.) You give the file a unique name, and you store it somewhere that your apps know where to look for it. Best way to get that path is something like: Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOCUMENTS)
The obvious problem with this is security. While not deprecated by the OS, it introduces the same problem that the Android docs list as the reason for deprecating MODE_WORLD_* - it's inherently insecure and opens up potential exploits in your application.
- You're placing your information where everything has ready access toit.
- You're asking for permissions that your app may not otherwise need.
- You're reading files that you can't verify the origin of.
If your application isn't handling any sensitive data, maybe this doesn't matter to you (it might to your users). If you're planning to read data from those files, you should ensure you're providing maximum validation for that data before parsing. Check the size of the file, validate the formatting, etc.
Creating your own service
You could always create a Service or an IntentService. (There are subtle differences between the two, but IntentService is a subclass of Service that runs in a Worker thread while Service interrupts the main thread. IntentService also implements Intent support which provides the most straightforward interapplication communication on Android).
This service has its own private storage, for which it has full read/write access, but nothing else does. This service then provides an interface to receive Intents from other apps, and to return results (as Intents) to those apps. This is an extremely friendly way to implement interapplication data while maximizing data privacy and security of that data. If outlying apps mostly need to request very basic information from a central application, this is your entry-level option.
Implementing a BroadcastReceiver
Along the same lines is the BroadcastReceiver class. Depending on what sort of data you're intending to share between applications, and how familiar those applications may be with your specific approach, this another possibility. Again, you'll be managing the shared data under one application's private storage. Communication is done by Intents, so it's similar to an IntentService - except that applications may communicate with a BroadcastReceiver by issuing systemwide events (that is, they don't need to be explicitly communicating with your app or service - they're shouting out the world for a piece of info, and expecting an answer.)
Creating a ContentProvider
The Original Post seems to misunderstand what a ContentProvider is and how it works. You have to think of this type of item like you would a cloud solution - even though it's local to your device. Every app doesn't need a ContentProvider - they all need to communicate with a ContentProvider, and that ContentProvider maintains, updates and returns data.
This is probably the most "Android-y" solution for this particular usecase and offers the greatest expandability. You implement an independent process that handles data storage and responds to other applications. It is, however, a more evolved solution - and as such may be more a more challenging endeavor. If you need a real database service, rather than a fairly simple request/response type service, ContentProvider seems to be the best choice.
这篇关于如何在Android中的一组应用程序之间共享数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！