3

Hi all!

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?

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.

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.

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.

Any thoughts are greatly appreciated. The application is yet on a planning stage, so, now is the time to make fundamental changes.

dbm
  • 10,376
  • 6
  • 44
  • 56

1 Answers1

1

Dbm,

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.

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.

Frank

Frank C.
  • 7,758
  • 4
  • 35
  • 45
  • Thanks for the quick answer. I find the idea with putting the `ContentProvider` in an APK of its own a bit brave, yet I can't discard it right away (it's something intriguing with the idea, it keeps my attention like spellbound) :-) Is there anything to gain in putting it in its very own APK? I see some concerns if the CP APK isn't present on the target. Then I migh have to implement some sort of "graceful degradation" concepts in the clients (the Admin- and User APKs). – dbm Jan 30 '11 at 10:15
  • @dbm I threw it into the stew as it did appear to be a third option. Unless you want to have extreme flexibility in build->release segmentation I don't know (haven't thought of) what a 3rd APK would get you. The CP interface can be exposed no matter where it resides. If the DB/CP was a collection of information for general use that would require regular updates I would opt to making it it's own APK for deployment reasons. – Frank C. Jan 31 '11 at 09:52
  • @dbm No problemo... curious to know which way you turned in your decision? – Frank C. Feb 01 '11 at 05:24
  • I think I will experiment a bit on both solutions. But as of now I find the "two-APKs-only" solution a bit more attractive. This way I see a reduction of dependencies (none of the two applications depend on a preinstalled ContentProvider APK) and a much cleaner cut between the admin- and user application, which, after all, is the holy Grail in this case :-) – dbm Feb 01 '11 at 07:07