On Wed, Nov 10, 2010 at 6:38 PM, William Ferguson <[email protected]> wrote: > rather than relying on a process that is already in a bad state and is > trying to destroy itself.
The process is not in a bad state. Some piece of your code is in a bad state. > That way the process that is responsible for > sending the crash info can handle all the flows associated with a > remote connection without being constrained by immediate destruction > or UI responsiveness. The process will not be destroyed, because your code is running and no components have been destroyed. The UI is no more a factor for reporting an unhandled exception than it is for anything else. > Mark, as I noted above, the reason I think a remote process is a valid > solution here is to ensure that the > crash info is actually sent. I cannot disagree more. > I wouldn't rely upon the failed process to send that data. There is no failed process. -- 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.2 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
