title: Two content providers accessing the very same database
body: <p><strong>Hi all!</strong></p>
  
  <p>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?</p>
  
  <p>As of now I'm considering to let the two applications implement their own <code>ContentProvider</code>s (both <code>ContentProvider</code>s 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.</p>
  
  <p><strong><em>RATIONALE:</em></strong><br />
  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.</p>
  
  <p>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.</p>
  
  <p><em>NOTE!</em> The data values are separated from the data structure, i.e. the <em>values</em> are stored in one separate table and the <em>structure</em> 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.</p>
  
  <p><em>Any thoughts are greatly appreciated. The application is yet on a planning stage, so, now is the time to make fundamental changes.</em></p>