I presume you're setting this up in the Application, right? Indeed,
passing in the application at that point is just what I was about to
suggest.

Actually, I see nothing at all wrong with doing this. Just post it to
the main thread's Handler, and do everything except interception
there.

Just make sure that your code that runs in the main thread is bullet-
proof. (And anything it then passes off to other threads). That's just
a matter of having a catch (Throwable ex) {...} and logging, but not
passing on, any errors that occur.

I've done this sort of thing in a number of environments. I would even
go so far as to term this a cross-platform "best practice".

In terms of thread handling and communication, this is no different
than anything else you'd do in another thread. When you have something
to do in the normal context, you post it.

The one thing that CAN get tricky, is trying to recover from failures.

Another possibility is to set up your own Handler in your own thread.
Then you can do things like post Toast notifications, etc. while
leaving the main thread alone.

I've done this, and it worked, but then decided I didn't have any good
reason for it. However, this could be useful if the main thread is
stuck in a loop. But if you do it right, you can start off going to
the main thread, and switch to this later.

On Feb 15, 12:20 pm, laphroaig15 <laphroai...@gmail.com> wrote:
> Didn't eat my wheaties this morning.  I can simply pass in the
> reference during the construction of the handler.
>
> Mark, thanks for the feedback.  I agree that broadcasting through an
> excepted context is a little dicey, but it seems to work for now.  I
> can't think of a better alternative context-less thread -> android
> communication short of something horribly inefficient like file
> polling, but I'm open to suggestions.  I am building a "whatever" app
> to report exceptions, so using Flurry or DroidDrop would defeat the
> purpose.  You are right in that, tragically, "whatever" cannot self-
> reference its own automated exception reporting capabilities.  ;)
>
> thanks for the input,
>
> -Jess
>
> On Feb 15, 2:01 pm, Mark Murphy <mmur...@commonsware.com> wrote:
>
>
>
> > laphroaig15 wrote:
> > > Is there some way to interact with the android packages to
> > > retrieve a context in a static manner?
>
> > Not really. The Application object is a singleton, as is any Service you
> > have running, but I am not aware of ways to obtain those from a static
> > method.
>
> > Moreover, please do not try binding to a service from an exception
> > handler. Broadcasting an Intent may be safe, but I'm not completely
> > confident of that, either.
>
> > Even simpler is just to use Flurry or DroidDrop or whatever to report
> > your exceptions.
>
> > Trying to have an Android component respond to an exception may prove
> > troublesome, particularly if the exception is thrown from the Android
> > component in question.
>
> > --
> > Mark Murphy (a Commons 
> > Guy)http://commonsware.com|http://twitter.com/commonsguy
>
> > Android Development Wiki:http://wiki.andmob.org

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

Reply via email to