In Android, should a contact sync adapter run in a separate process?

Question

In my app, I'm using a contact sync adapter, but it has a lot of information that it shares with the main app. There are settings that the adapter needs to work proplery (like login information and if the user changes any sync settings), so I currently have it running in the same process, and it communicates with the main ap using getApplicationContext(), and then I have some shared variables in the Application that the sync adapter is using during the sync process.

But in the training document, and a few tutorials online, the sample adapter is set up to run in its own process -- it's using android:process=":sync" in the manifest. Is that necessary? And if it does run in a separate process, how can I communicate back to the main app?

Answer 1

In our context, due to fast searching requirement, we are using remote service to hold a huge database in memory.

The reason we are using remote service, instead of local service is that, we believe running the service in separate process, will make us harder to hit maximum memory per process limitation (The limitation is vary based on different devices and OS version).

In our initial design, we are using AIDL. Later, we switch to Messenger. I cannot recall the reason behind. I will check back our source code history log to figure out why. But, I think it is mostly, Messenger is less complicated than AIDL, and we do not need the multi-thread capability provided by AIDL.

Answer 2

I think it should be separated, but it's not required.

In general, separating a Service process is well worth to consider if it may be used independently from system components or other applications. In this perspective, the lifecycle of the process should be managed independently from other components such as Activity in the same app, so Android can mark which process is currently used easily and precisely to decide which process to be killed in case of a memory shortage. Also the service can keep running even if the front activity crashed unexpectedly.

It's hard to maintain sharing data between separate processes. For login credentials and preferences, I guess you may go with a combination of SharedPreferences and OnSharedPreferenceChangeListener.

Answer 3

Running Service in its own process may be helpful

1) if you want your service to withstand your main app's process destruction (but START_STICKY is more than enough for that case),

2) if you'd like to designate this process for all "sync" tasks of your application (as stated in the tutorial),

3) if you want other apps to use your Service.

To communicate with the Service running in separate process, you use Bound Services.

However, running Service in separate process increases the complexity of communicating with it, so consider if any of cases mentioned above relates to your app purposes.

Answer 4

When the application starts, it may cache different things, in particular for the UI. By splitting the sync logic in a different process, you allow the UI process to be killed when the device is running low in memory, which will free these UI caches.

Hence, this technique is primarily of interest to apps that run services for a long time. Typical examples:

• the service that plays music in a music app
• the service that uploads the video in Youtube

However:

• this increases the complexity of the app
• if done incorrectly, it can actually increase the overall memory footprint of the app