Getting data between apps
from the CommonsWare Community archivesAt October 7, 2021, 4:49pm, Jan asked:
I have an app that needs to send some data to another app upon request from the other app. I looked at FileProvider but that seems overkill for a small piece of data (2 strings). This request might be made multiple times during the app’s lifecycle.
I’m looking at using Service. The app that needs the data would request the data from the service when it needed the data. The data needs to be come in fast so the app doesn’t wait a long time for the data.
I couldn’t find Service example in any of your books other than R which was a different type of Service.
Is there another approach I should look at other than Service?
The app with the service is unlikely to be active/running. Can the service get started by the other app?
Do I use IBinder to send the data back to the requesting app?
Most of the examples I’ve found through google were about local service which is not my use case.
At October 7, 2021, 5:22pm, mmurphy replied:
I am assuming that you mean that App B pulls data from App A (so App B initiates the data transfer), rather than App A pushing data to App B (so App A initiates the data transfer).
OTOH, if the data is constant or changes infrequently, this is probably the simplest solution.
In the second-generation books, I do not cover Service
much outside of specific scenarios like in Elements of Android R, as few developers need to write a service nowadays. However, there is a fair bit of material on Service
in The Busy Coder’s Guide to Android Development.
You could also do a custom ContentProvider
instead of FileProvider
. Or, you could use a pair of broadcasts: a request from App B to App A and a response from App A to App B.
When App B starts or binds to a service from App A, Android will fork a process for App A to use to fulfill the request. Basically, any Intent
-based IPC has that property.
If you are using a bound service, yes. Bound services are kind of a pain, such as needing some sort of API versioning, so that you can deal with API changes and a mixed pair of apps (e.g., App B is newer than App A).