4

I use UrbanAirship (UA) for push notification.

The UA push service is configured in the Manifest file as follows:

    <service android:name="com.urbanairship.push.PushService"
     android:process=":com.urbanairship.push.process" />

Where android:process is optional, but recommended in their documentation.

When I use a single process and close all my activities, I can see that my single process consumes ~3mb of memory

When I use a two processes (one for the app and one for the service) and close all my activities, I can see that both processes are alive, each consumes ~3mb of memory.

So my question is: whats the point?

Donato Szilagyi
  • 4,279
  • 4
  • 36
  • 53
Asaf Pinhassi
  • 15,177
  • 12
  • 106
  • 130
  • I would also like to know. Looks like the Push model is different from the one used in iOS which receiving the notification is handled at the OS level and then handed off to the app. – tapi Jan 13 '12 at 13:50
  • Ranking up the question would help... – Asaf Pinhassi Jan 13 '12 at 14:50

1 Answers1

1

My guess is that UA recommended this so that their own code will face less contention/disruption. For example if your app crashes but UA code is running in a separate process, then theirs could probably keep running without interruption (and avoid the possible data corruption that might occur if the process hosting them gets abruptly killed).

For another clue, see this SO question: Starting an Android notification at startup. As you can see, some developers are reporting that general Android notifications sometimes fail to show up depending on the life cycle of their app's components. By putting the UA PushService into a separate process, this might mitigate this problem. I'm going to test this out because my UA notifications are sometimes not persisting after reboot.

By the way, it seems the latest UA documentation is no longer recommending to declare the Service with its own separate process.

Community
  • 1
  • 1
Jo Jo
  • 7,245
  • 5
  • 34
  • 49