Should I use android: process =":remote" in my receiver?

AndroidBroadcastreceiverAndroid Broadcast

Android Problem Overview


I have a BroadcastReceiver which is called every so often, and I have noticed many people use

android: process =":remote" 

in their receiver. Mine is used to check a few things and if the conditions match then activate an alarm. My question is should I use the line I had posted above in my manifest? And if so what are the benefits of doing so?

Android Solutions


Solution 1 - Android

By defining your receiver with android:process=":remote" you basically run your receiver in a different process (= VM). For typical use-cases, you don't need to run this in a different process, and whatever you want to do can probably run just fine locally (in your APK process).

The drawback of using android:process=":remote" is that you need additional resources for it to run (in this case a separate process). When doing so, you're basically dealing with 2 VMs, and some patterns like singletons, static fields can no longer be shared between your app and your remote service.

The benefit of using android:process=":remote" is that for some use-cases, it might be handy to start a service that will keep on running (in its own process) after you've shutdown your application, or if you want remote clients to be able to bind to your service. Your broadcast receiver will not block your applications main thread when running in a separate process upon calling the onReceive() method (however, there are other ways of implementing this).

I've found that most of the time, for most common use-cases, you can get away without using android:process=":remote".

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionJasonView Question on Stackoverflow
Solution 1 - AndroidddewaeleView Answer on Stackoverflow