CODEWITHSUNDEEP
androidprocessandroid-contentprovider
Android Developer
Android Developer

Reputation: 9643

Content Provider vs SharedUserId vs Global Process for sharing data across applications

I found three ways to share data across applications.

1.Content Provider

2.SharedUserId-When you declare the same shared user id for more than one application, they can reach each other's resources (data fields, views, etc.). provided applications are signed with same certificate.

3.Global Process-Put a component of one application in separate process by using android:process attribute and naming process starting with lowercase letter and another component of another appication in separate process with same name as the separate process of first application.Now these components can share data.

I am confused what to use when or which is more efficient?

Upvotes: 0

Views: 693

Answers (1)

CommonsWare
CommonsWare

Reputation: 1006604

I found three ways to share data across applications.

#2 and #3 are the same, insofar as #3 (shared process) requires #2 (sharedUserId).

You also missed all other forms of standard Android IPC, including:

  • starting activities
  • starting services
  • binding to services
  • sending broadcasts

I am confused what to use when

Ordinary app developers should use #1 (ContentProvider) or one of the other standard Android IPC mechanisms that I outlined above. You have no control over when users update apps, and using formal IPC enforces a clear separation between the apps, forcing you to think through things like API contracts, API versioning, and related concerns.

sharedUserId and shared processes are really there for device manufacturers, where apps are pre-installed and then updated in unison via a firmware update. Personally, I recommend to device manufacturers that they too use standard IPC, for most scenarios. For example, if App A modifies App B's files directly, how does App B find out? What if App B then overwrites App A's changes, because App B did not know about those changes? In many other areas of computer programming, we have gotten away from having multiple processes from multiple apps work with each others files directly.

which is more efficient?

Efficiency should not be an issue in this case, as you should be using any of these techniques infrequently. If you have two apps that need to communicate with each other frequently, then you really have one app, and you should implement it that way.

Upvotes: 4

Related Questions