[android-developers] Re: Local Service vs Remote Service
Yeah, in my personal apps I call the previously registered default uncaught exception handler from my own. That's why users still get the force close option. Doing a network call beforehand in the same process doesn't work well. If you wait you can get situations where there's an ANR as well as the pending force close and all sorts of bizarre stuff. If you do it in a different thread and don't wait, then the force close kills your thread before you send the majority of the time. I've tried both. There are a couple rare cases where I don't pass the exception on to the default handling. I hash the stack trace, compare it to a white list of known harmless exceptions, and don't pass the exception on if it matches one of them. This is only good with a very small subset of exceptions, however. I think I have like an exception or two from Quattro and Millennial Media ad Networks in there, for example. I hate using buggy ad networks, but they pay way more per click than AdMob. Most exceptions you can easily wrap in your own code anyway. These were getting thrown from threads I don't even start, I think. At a company where I work they exit the process and restart, but that adds all sorts of other complications, like restoring state on your own and making sure you don't get stuck in an endless loop if the app dies immediately again. If you are restarting over and over, then obviously it is time to use the original handler, but that's annoying to detect. use Thread.setDefaultUncaughtExceptionHandler() to eliminate the force-close dialog and deal with the unexpected exception myself, such as logging it to a server. This does not require a remote process. I definitely don't recommend trying to keep using the process for anything user facing after an unhandled exception in general. I've tried that and it just doesn't work reliably. Think about it, how is an activity or UI going to run if the exception killed the loop in the main UI thread that processes messages or something like that? Only ever eat the exception if it is something you've reproduced on your own machines and checked that the process isn't hosed. Most of the exceptions I get reported aren't something I can reproduce, unfortunately. I test on all the devices I can get my hands on and lots of emulator images. We're not talking about common exceptions here. If the user hits the report button, the crash information will be available through market feedback. The official Android reporting sucks. It is only on the latest versions and requires Market. It requires a double opt-in button press each time, so users hardly every do it, and yes I have numbers to prove that. It would have been much better to have an opt-out of sending stack traces when a user activates or upgrades to a new Android version that supports it, or when they install an app, and then an opt-in every time for sending additional, potentially more private information. Stack traces would still get sent if the user is lazy and hits force close and doesn't care either way. Something like that. What good is having all that information when hardly any users actually send it? It's fine if they don't send for privacy reasons, but they are not sending because the process is badly implemented and a pain in the ass for the user. Er... fix the force close in your app...? :p There are unfixable ones in the Android platform, unfortunately. One particular one thrown by ViewGroup.offsetRectBetweenParentAndChild can't even be wrapped by my code. See this thread: http://groups.google.com/group/android-developers/msg/d378a3dc1b467b44 There are also ones in libraries I use or used, like Millennial Media and Quattro advertising as mentioned above. I suppose I could decompile their libraries, fix their bugs, and recompile. Reporting the bugs to them was about as useful as reporting Android bugs on b.android.com, which we aren't even allowed to do for anything but the latest Android versions nowadays anyway, which shows how completely out of touch that process is with the bugs developers have to work around every day. There are also lots of issues that might not be worth fixing as well. All phones, but Droids especially, can get corrupt databases on upgrade even though my DB code matches the official tutorials, for example. Spending time to account for that might help so few users, however, that it would be better for me to write a feature that would help much more users instead. Too bad the platform is so unreliable that even stuff based on the official samples sucks when put out in production and gives your users force closes. On Nov 11, 4:14 am, Kostya Vasilyev kmans...@gmail.com wrote: The default Android force close dialog is displayed by the default uncaught exception handler. If you replace the uncaught exception handler, make sure to call the previous uncaught exception handler from yours, presumably after writing / sending the exception information. So you can have the best of
Re: [android-developers] Re: Local Service vs Remote Service
The default Android force close dialog is displayed by the default uncaught exception handler. If you replace the uncaught exception handler, make sure to call the previous uncaught exception handler from yours, presumably after writing / sending the exception information. So you can have the best of both everything: your own logging for uncaught exceptions, and still leave the user experience unchanged. Regarding corrupted process - in some languages that are executed directly by the CPU, it's pretty easy for application logic errors to produce heap corruption, such that allocating memory in the exception handler (for formatting the error message, for example) would crash again. Java is different, much safer, in this regard: you get exceptions (IndexOutOfBoundsException, NullPointerException) instead of a possibly corrupted heap. Therefore, there is a much better chance that the exception handler code can run from start to finish without crashing itself. -- Kostya 11.11.2010 3:17, William Ferguson пишет: Sorry, I may have muddled several concepts here .. I'll blame lack of sleep. I was thinking that a RuntimeException force closes an app and that there is limited opportunity to capture the failure (pre Froyo) before the app is destroyed. But if using Thread.setDefaultUncaughtExceptionHandler() actually stops the force close then there is opportunity to dispatch the crash report since the app won't be destroyed. Whether the crash dispatch happens in the app process or another process is irrelevant. And yes, I was only imagining having the 2nd process exist briefly. Something like an IntentService solely tasked with dispatching the crash and handling disconnection and other dispatch failures. But that doesn't seem as relevant now. Am I back on track? On Nov 11, 9:56 am, Mark Murphymmur...@commonsware.com wrote: 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/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.2 Available! -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- 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
Re: [android-developers] Re: Local Service vs Remote Service
On Thu, Nov 11, 2010 at 4:14 AM, Kostya Vasilyev kmans...@gmail.com wrote: The default Android force close dialog is displayed by the default uncaught exception handler. If you replace the uncaught exception handler, make sure to call the previous uncaught exception handler from yours, presumably after writing / sending the exception information. That's a good point -- I forgot about that trick. Thanks! -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android App Developer Books: http://commonsware.com/books -- 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
Re: [android-developers] Re: Local Service vs Remote Service
On Wed, Nov 10, 2010 at 1:25 AM, William Ferguson william.ferguson.au@ gmail.com wrote: Um, I think the point that Lance was trying to make was that he won't actually know about the force close UNLESS he uses the remote service. But sure, once he knows about, then he could fix it. If the user hits the report button, the crash information will be available through market feedback. If you are just catching the error to report it yourself, there wouldn't be a crash dialog, so no button for the user to press to kill the app before you are done. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
Re: [android-developers] Re: Local Service vs Remote Service
On Tue, Nov 9, 2010 at 11:33 PM, Lance Nanek lna...@gmail.com wrote: I can think of no scenarios in which you need a service to run in a separate process. I've run into a scenario. Force close kills your process. So if you want to do an internet call on unhandled exceptions, doing it in another thread isn't enough. Users often hit the button before your internet call can complete. A remote service doesn't get killed, though. Er... fix the force close in your app...? :p -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Local Service vs Remote Service
Um, I think the point that Lance was trying to make was that he won't actually know about the force close UNLESS he uses the remote service. But sure, once he knows about, then he could fix it. On Nov 10, 7:14 pm, Dianne Hackborn hack...@android.com wrote: On Tue, Nov 9, 2010 at 11:33 PM, Lance Nanek lna...@gmail.com wrote: I can think of no scenarios in which you need a service to run in a separate process. I've run into a scenario. Force close kills your process. So if you want to do an internet call on unhandled exceptions, doing it in another thread isn't enough. Users often hit the button before your internet call can complete. A remote service doesn't get killed, though. Er... fix the force close in your app...? :p -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
Re: [android-developers] Re: Local Service vs Remote Service
Personally, I would use Thread.setDefaultUncaughtExceptionHandler() to eliminate the force-close dialog and deal with the unexpected exception myself, such as logging it to a server. This does not require a remote process. On Wed, Nov 10, 2010 at 4:29 AM, Dianne Hackborn hack...@android.com wrote: On Wed, Nov 10, 2010 at 1:25 AM, William Ferguson william.ferguson...@gmail.com wrote: Um, I think the point that Lance was trying to make was that he won't actually know about the force close UNLESS he uses the remote service. But sure, once he knows about, then he could fix it. If the user hits the report button, the crash information will be available through market feedback. If you are just catching the error to report it yourself, there wouldn't be a crash dialog, so no button for the user to press to kill the app before you are done. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.0.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 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
[android-developers] Re: Local Service vs Remote Service
Forgive if I have this wrong, but I thought the report button only shows for Froyo and beyond. I certainly don't see it on 2.1 on my GalaxyS. If its for reporting the crash to oneself (as it seems to be - to handle all Android versions), then handing it off to another process to send the data to a remote site seems to be a practical solution, rather than relying on a process that is already in a bad state and is trying to destroy itself. 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. On Nov 10, 7:29 pm, Dianne Hackborn hack...@android.com wrote: On Wed, Nov 10, 2010 at 1:25 AM, William Ferguson william.ferguson.au@ gmail.com wrote: Um, I think the point that Lance was trying to make was that he won't actually know about the force close UNLESS he uses the remote service. But sure, once he knows about, then he could fix it. If the user hits the report button, the crash information will be available through market feedback. If you are just catching the error to report it yourself, there wouldn't be a crash dialog, so no button for the user to press to kill the app before you are done. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Local Service vs Remote Service
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. I presume that is what the Froyo Exception logging (to Market) does, but perhaps it just wings it. On Nov 10, 9:58 pm, Mark Murphy mmur...@commonsware.com wrote: Personally, I would use Thread.setDefaultUncaughtExceptionHandler() to eliminate the force-close dialog and deal with the unexpected exception myself, such as logging it to a server. This does not require a remote process. On Wed, Nov 10, 2010 at 4:29 AM, Dianne Hackborn hack...@android.com wrote: On Wed, Nov 10, 2010 at 1:25 AM, William Ferguson william.ferguson...@gmail.com wrote: Um, I think the point that Lance was trying to make was that he won't actually know about the force close UNLESS he uses the remote service. But sure, once he knows about, then he could fix it. If the user hits the report button, the crash information will be available through market feedback. If you are just catching the error to report it yourself, there wouldn't be a crash dialog, so no button for the user to press to kill the app before you are done. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.0.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 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
Re: [android-developers] Re: Local Service vs Remote Service
On Wed, Nov 10, 2010 at 6:38 PM, William Ferguson william.ferguson...@gmail.com 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 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
Re: [android-developers] Re: Local Service vs Remote Service
On Wed, Nov 10, 2010 at 6:41 PM, William Ferguson william.ferguson...@gmail.com 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 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
[android-developers] Re: Local Service vs Remote Service
Sorry, I may have muddled several concepts here .. I'll blame lack of sleep. I was thinking that a RuntimeException force closes an app and that there is limited opportunity to capture the failure (pre Froyo) before the app is destroyed. But if using Thread.setDefaultUncaughtExceptionHandler() actually stops the force close then there is opportunity to dispatch the crash report since the app won't be destroyed. Whether the crash dispatch happens in the app process or another process is irrelevant. And yes, I was only imagining having the 2nd process exist briefly. Something like an IntentService solely tasked with dispatching the crash and handling disconnection and other dispatch failures. But that doesn't seem as relevant now. Am I back on track? On Nov 11, 9:56 am, Mark Murphy mmur...@commonsware.com wrote: 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/commonsguyhttp://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 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
Re: [android-developers] Re: Local Service vs Remote Service
On Wed, Nov 10, 2010 at 7:17 PM, William Ferguson william.ferguson...@gmail.com wrote: But if using Thread.setDefaultUncaughtExceptionHandler() actually stops the force close then there is opportunity to dispatch the crash report since the app won't be destroyed. Whether the crash dispatch happens in the app process or another process is irrelevant. Correct. If you catch the unhandled exception yourself, none of the automated stuff (force close dialog, etc.) kicks in. It is up to you how to deal with it. I'd always try reporting it, assuming you're hooked up to a system to do that. After that, the strategy is up to you: just continue along, finish()/stopSelf() the offending component, System.exit() to blow away the process, etc. Similarly, it's up to you how you inform the user about what transpired (dialog, toast, nothing). And yes, I was only imagining having the 2nd process exist briefly. Something like an IntentService solely tasked with dispatching the crash and handling disconnection and other dispatch failures. But that doesn't seem as relevant now. Am I back on track? Yup. And you probably weren't all that far off the track originally -- I was overreacting. I too am short of sleep. My apologies. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.0.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 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
[android-developers] Re: Local Service vs Remote Service
I can think of no scenarios in which you need a service to run in a separate process. I've run into a scenario. Force close kills your process. So if you want to do an internet call on unhandled exceptions, doing it in another thread isn't enough. Users often hit the button before your internet call can complete. A remote service doesn't get killed, though. On Nov 9, 4:01 pm, Mark Murphy mmur...@commonsware.com wrote: On Tue, Nov 9, 2010 at 1:17 PM, prgmratlarge yossiele...@gmail.com wrote: I'm confused about whether I need to run my service in a separate process. You don't. I can think of no scenarios in which you need a service to run in a separate process. For reference I'm trying to create an App that uses a service to play [streaming] audio in the background. Do not use a remote process for this scenario. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android App Developer Books:http://commonsware.com/books -- 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
