2

Beginner in android, so please bear with me...

According to the docs, you should never start an activity from a broadcast receiver:

"(...)Never start an Activity in response to an incoming broadcast Intent."

http://developer.android.com/training/run-background-service/report-status.html

(last line of the docs).

So, here's my question: since I need to show the activity chooser from a background service and since I should never start an activity from a broadcast receiver, then how can I solve my problem?

Richard Le Mesurier
  • 29,432
  • 22
  • 140
  • 255
Luis Abreu
  • 4,008
  • 9
  • 34
  • 63
  • If you need to alert the user about anything, you send a Notification. If it is important, user will click on notification, that will open the activity. – Sundeep Jun 04 '14 at 09:08

1 Answers1

2

Your exact situation needs more clarification. Exactly what are you trying to do?

In the meantime, here is the background explanation that should help you to understand when this rule applies, and if you should break it in your app.

"(...)Never start an Activity in response to an incoming broadcast Intent."

This has to do with the idea of giving Notification to the user by using the notification bar. The idea is that you should never interrupt the user from what they are trying to do at the time.

Android appreciates that the user knows what they want to do at any time, and the OS has no right to interrupt the user. This is in direct contrast to other systems that use popups to alert the user of incoming event.

So the idea behind your quote, is that you should never pull a user's attention out of his current activity, by launching your own activity over it.

This could be terrible, imagine you are in the middle of a game, and suddenly Luis's activity shows in front of the game.

However, there are exceptions to the rule:

1

If the user is already using your app, and you receive the Intent, then your BroadcastReceiver should launch your own activity.

When the user is not using your app, then post the Notification instead.

You can see this type of behaviour in apps like Whatsapp. If you are in the app, you don't get the notification, instead the app just shows the new message. If you are out of the app, you get the notification.

2

Sometimes starting an activity like this is expected behaviour, it makes sense.

One obvious example is a phone app. It must launch when the phone rings, and we have come to accept that.

Here is another legitimate use-case of starting an activity from a receiver. It is a clock app that is designed to launch when the phone is put on charge:

Community
  • 1
  • 1
Richard Le Mesurier
  • 29,432
  • 22
  • 140
  • 255
  • Hello Richard. Thanks for the quick answer. In my app, I'm using a service for exporting data. here's the typical scenario: 1. user taps Export option in the action bar 2. an intent service is started for handling the generation of a csv file 3. a local broadcast intent is generated from the service 4. that broadcast is treated by a receiver which is responsible for letting the user decide how the csv file will be sent (Intent.ACTION_SEND) Is there a better way of doing this than using service+broadcast receiver without blocking the main thread of the app? – Luis Abreu Jun 04 '14 at 13:49
  • Hello again. ok, I've ended up removing the broadcast receiver from the equation because it's possible to start an activity from a service by using the FLAG_ACTIVITY_NEW_TASK flag... – Luis Abreu Jun 04 '14 at 14:38
  • @LuisAbreu yes, that's probably a simpler method for what you are trying to do. In a more complex situation, you may want to use `android.os.Message` and `android.os.Messenger` with a `Handler` to communicate back. I just mention this so you know it exists, and can google for it if you need it as you learn more. Good luck. – Richard Le Mesurier Jun 04 '14 at 17:08
  • 1
    Hello again Richard. Yes, I've seen it. however, in this case, it seemed more complex than necessary :) – Luis Abreu Jun 04 '14 at 20:39
  • @LuisAbreu it is definitely. Just thought I'd put it on your radar for future. – Richard Le Mesurier Jun 05 '14 at 06:16