两个内容提供商访问非常相同的数据库 [英] Two content providers accessing the very same database

问题描述

大家好！

我不知道是否有一个普遍preferred实现范式尊重如果一个人想的两个完全不同的Andr​​oid应用程序访问和操作同一个数据库吗？它是推荐的，甚至在技术上可能做到这一点呢？将这样的结构是什么样子的？

I wonder if there is a generally preferred implementation paradigm to respect if one want's two completely different Android applications to access and operate on the same database? Is it recommended or even technically possible to do this at all? What would such an architecture look like?

截至目前我正在考虑让两个应用程序实现自己的的ContentProvider S（两个的ContentProvider 取值将访问同一个数据库，同时保证永远，虽然）。我也想过建立一个共同的内容提供商，让这两个应用程序使用访问数据库的时候之一。我preFER第一个例子，但还没有完全丢弃后

As of now I'm considering to let the two applications implement their own ContentProviders (both ContentProviders will access the same database, guaranteed never simultaneously, though). I have also thought of building one common content provider and let both applications use that one when accessing the database. I prefer the first example but haven't completely discarded the later.

理由：的

我有一个需要访问一个公共数据库的两个应用程序。数据库本身存储数据，而且还描​​述了数据行之间的关系，典型地描述了一套形式，其中的形式的内容;如文本框，按钮和各种列表的UI元素，是可定制的。这两个应用程序使用描述数据中的数据库运行时产生相应的应用程​​序UI的部分。

RATIONALE:
I have two applications which need to access a common database. The database itself stores data but also describes the relationship between the data rows, typically describing a set of "forms" where the form content; UI elements like text boxes, buttons and different kinds of lists, is customizable. Both applications use this "description data" in the database to generate parts of the respective application UI during runtime.

因此​​，有两个应用程序的两个方面：一是行政方面（管理数据行之间的数据结构和关系）和一个普通用户的一面（读取/修改实际的数据值）。这是一个深思熟虑的选择，以在不同的应用这两个方面分开。

Hence, there are two aspects of the two applications: one "administrative" aspect (managing the data structure and relationship between the data rows) and one "generic user" aspect (reading/modifying the actual data values). It's a deliberate choice to separate these two aspects in separate applications.

注<！/ em>的数据值从数据结构分离，即<青霉>值的被存储在一个单独的表，并在结构的描述在另一个表。这意味着两个应用程序将主要修改两个不同的表在同一数据库中，他们将永远不会改变其他表，可以这么说。

NOTE! The data values are separated from the data structure, i.e. the values are stored in one separate table and the structure is described in another table. This means that the two applications will essentially modify two different tables in the same database and they will never modify "the other table", so to speak.

的任何想法是极大的AP preciated。该应用程序是没有在规划阶段，因此，现在是做出根本性的变化的时间。的

推荐答案

DBM

是的，它被接受，鼓励和可能在Android上做。你有一个3选项（这无疑会得到我一些燃烧的解说），这就是把ContentProvider的（1）在所有APK它自己的。但是，考虑到你只有2种，可以翻转其APK它是由主办的四分之一。我会选择管理应用程序，但是这是我的一部分是主观的。

Yes, it is accepted, encouraged and possible to do on Android. You do have a 3rd option (that will no doubt get me some burning commentary) and that's to put the ContentProvider (1) in an APK all of it's own. But, given that you only have 2 types, you can flip a quarter over which apk it is hosted by. I would choose the admin app, but that is subjective on my part.

什么样的​​，每个可以操作的数据。如果您要创建两个应用程序的麻烦，那么你有什么每个行为将做先验知识，。因此我认为一个CP接口，只是限制了每个应用拨打电话给你所描述的行为。

If you are going to the trouble of creating two applications then you have "a priori" knowledge of what the behavior of each will do, and what kind of data that each can operate. Therefore I would conclude a single CP interface and just constrain what each app calls given the behavior you've described.

弗兰克

这篇关于两个内容提供商访问非常相同的数据库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！