3

I have a complex app that has background threads (that could be in a service) which, when they receive data from the internet, need to notify my main display activity (to update on of several status indicators). All run in the same process (I see no reason to do otherwise).

However, in some circumstances, these events are frequent - 5 per second. Also, the events may occur when the activity is not-visible or even destroyed. I think the only thing novel about this question is the issue of efficiency. I still target the G1, for example.

There are a number of methods mentioned in this thread, but I don't know which of these are efficient enough, and will work if the activity is destroyed. Those methods are the "Android way" which I would prefer to follow.

I have three ugly anti-Android ways that work, but they also have drawbacks:

  1. Have a thread in the activity that is waits on a semaphore, and when released, does the update. Disadvantages: extra thread, how to handle several event types
  2. Like #1, but use a concurrent blocking queue object. Disadvantages: extra thread, same type of event may end up in the queue multiple times (not good)
  3. Keep a static reference to a handler on the activity, and use that to run an updater. Disadvantages: (a) may leak a reference to the activity? (b) what happens when the activity changes state? (c) multiple runnables could end up there when only one is needed.
Community
  • 1
  • 1
Mesocyclone
  • 881
  • 1
  • 10
  • 19

1 Answers1

3

Also, the events may occur when the activity is not-visible or even destroyed.

If your activity is destroyed, there is nothing to update. If and when the user elects to re-visit that activity, the activity can get the current information in onResume() for display.

If your activity is in the background, there is nothing that needs to be updated, either. Again, if and when the user elects to re-visit that activity, the activity can get the current information in onResume() for display.

The ONLY time you need an activity to be notified of events in real time is if that activity is in the foreground. In that case, any of the solutions I outlined in the answer you linked to could work. The binding option or Messenger are probably the lightest-weight solutions.

I have a complex app that has background threads (that could be in a service)

Not "could be" -- "must be", if they are to live beyond the scope of any given activity instance.

I have three ugly anti-Android ways that work

None of those work without potential memory leaks.

Community
  • 1
  • 1
CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thanks. Obviously there's no need to update the activity when it isn't visible. Does this solution require having the activity disconnect from the service whenever it is hidden? – Mesocyclone Jul 09 '11 at 17:52
  • @Mesocyclone: For the binding pattern, you should unbind by `onDestroy()`, possibly earlier -- that would depend on your business logic. Don't forget to deal with the binding itself as state as you deal with configuration changes though. – CommonsWare Jul 09 '11 at 18:13