On Wed, Nov 10, 2010 at 6:41 PM, William Ferguson <[email protected]> wrote: > 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 > wouldn't rely upon the failed process to send that data.
Your strategy only makes sense if you feel that your "failed process" will be able to successfully do IPC to start a service to report the exception and *not* successfully be able to report the exception itself. I am dubious that this is the case. If your process truly is failed, neither will work. I think both will work, in which case why add the overhead and complexity? In the end, though, this isn't a huge deal...*if* your proposed crash-reporting service isn't running all of the time. Saying there's a 2nd process briefly is one thing -- having a long-lived service chewing up a 2nd process is another matter entirely. We still have too many devices with too little RAM to be using that sort of technique today. -- 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
