On Tue, Jun 22, 2010 at 8:06 AM, Steve <[email protected]> wrote:
> Are there any good design patterns to solve the following problem:
>
> How can I best implement a BroadcastReceiver that may need to
> "consume" the current broadcast (via abortBroadcast()), but it first
> needs to perform some non-trivial work to determine whether or not the
> broadcast should be consumed.

Oy.

> I'm developing an app that can consume some (but not all) inbound SMS
> messages.

Note that receiving SMS messages technically goes outside the bounds
of the SDK, opening you up to compatibility issues.

> Is that a viable approach?  If there are any better options I'd love
> to hear them ...

I truly dislike any plan that involves relying on Java threads to
behave. Therein lies madness.

8 seconds is quite a long time, particularly for a background
operation. Your users will be very unhappy when you ::bleep:: up their
real-time game while you chug away at calculations, for example. This
is also the sort of behavior that people point to when they say that
iOS4 has better multitasking, because it puts limits on what
background stuff can do and hence how much those background things can
impact CPU, battery, etc. I realize that you say that this occurs on
"rare occasions", but my guess is that your normal case is probably a
few seconds, which isn't much better.

I'd really rather focus on getting that 8 seconds down to, say, 250ms.
Then the problem of going past the 10-second limit falls away, and you
get a better user experience to boot. Can we brainstorm on ways that
you can more quickly identify messages as being "relevant to the app
or not"?

BTW, if the time variance is due to live Internet lookups, bear in
mind that it is very possible to receive text messages without having
Internet access on the device, as evidenced by my week in the back
woods of Georgia last week.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to Android Development_ Version 3.1
Available!

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to