Best practices re error messages

[RhinoCan]

Is there any well-accepted documentation that details the best practices with regard to how to handle various kinds of errors in Android? If so, can someone kindly point me to it?

As seasoned developers know, there are many kinds of errors that an app can experience and there are many ways to handle those errors. Errors can be as minor as typos that need to be brought to the user's attention for them to correct or as major as indications that some key part of Android is not working properly. The app itself might detect a typo and simply display a Toast or Alert Dialog to the user telling them about the problem and asking the user for the correct information. Other errors might require logging to a specific log or sending notifications to someone or maybe sending emails or texts to a specific individual.

I have to believe that developers have been thinking about these issues as long as Android has existed (probably inspired by their experiences with previous environments!) but I don't know where to find their collective wisdom on error handling.

 

[Deleted User]

The 'best practice' is to do whatever is necessary for the app you're developing. Data errors - and by that I mean anything which fails validation, or doesn't conform to specified inputs, are generally communicated to the user through alert dialogs, or Toast messages.
Another technique is to try and steer the user into doing the correct thing, often by disabling certain components on the UI, which aren't applicable in a specific context. Or somehow design your workflows to only accept the relevant information.
Unexpected errors i.e. bugs, are another thing entirely. The only way to handle those is to get your app to provide good diagnostic information, or get in there and debug the code.

 

[RhinoCan]

The 'best practice' is to do whatever is necessary for the app you're developing. Data errors - and by that I mean anything which fails validation, or doesn't conform to specified inputs, are generally communicated to the user through alert dialogs, or Toast messages.
Another technique is to try and steer the user into doing the correct thing, often by disabling certain components on the UI, which aren't applicable in a specific context. Or somehow design your workflows to only accept the relevant information.
Unexpected errors i.e. bugs, are another thing entirely. The only way to handle those is to get your app to provide good diagnostic information, or get in there and debug the code.

I'm basically fine with everything you've said here but want to quibble a bit and then drill down a bit for some details.

First, I'm surprised to hear that data errors are best handled with Alert Dialogs or Toast messages. I distinctly remember reading advice on one of the Android design sites steering people *away* from Alert Dialogs in most cases because they "interrupt" the user and alter his workflow. I say most cases because they obviously see *some* need for them, otherwise they might well have omitted Alert Dialogs from Android altogether. I'm not clear though on exactly when they think Alert Dialogs are warranted. I'm also a bit surprised to hear that Toast messages are okay in a production program. They are certainly convenient during development but I was really expecting to find that some kind of message area - a fixed location, perhaps the bottom or top of the screen - that showed messages was better. That was the prevailing design for many years in various languages I've used. But hey, if everyone nowadays thinks Toast messages are sufficiently professional for production code, that's fine by me I'm currently developing and/or designing some apps for my own use but I'm giving serious thought to using them as the basis for tutorials and maybe to put in a portfolio of my work which I can show prospective employers so I'm just trying to avoid people dismissing me for using "unprofessional" techniques.

That was the quibbling part ;-)

As for drilling down, I *am* concerned about dealing with bugs. Obviously, a developer needs to test their code as thoroughly as possible during development so that as few bugs as possible are released to the eventual "live" users of the program (as opposed to developers and beta testers). But I don't think anyone has ever released totally bug-free code so clearly their needs to be some attention on handling those bugs in production. Is there any general agreement on what sorts of errors should be logged, what sorts should result in notifications or texts to developers, etc?

For instance, one of the "live" users of your app throws an Exception when they run the program. That may be caused by a situation the developer didn't anticipate, like a virus messing with one of the system facilities or whatnot. What should your app do with Exceptions in a live environment?

 

[Deleted User]

I'm also a bit surprised to hear that Toast messages are okay in a production program

Why would you think that there's no place for a Toast message in a production app? Toast is just a way of displaying a transient message to the user. It's there for a few seconds, then it's gone. It uses no dedicated screen space (see below). You might want to use a Toast in response to a long press event on something, to give the user some guide on what to do.
People sometimes use Toast as a debugging tool during development. To me that's an inefficient way of going about debugging. Run the app in debug mode, and use breakpoints.

I was really expecting to find that some kind of message area - a fixed location, perhaps the bottom or top of the screen - that showed messages was better.

Remember that screen space on a mobile device is limited, and its use should be considered carefully. You probably don't want an area of the screen which is permanently reserved for messages, which may only appear briefly, or not at all.
This of course depends on the nature of the app though, and there may be reasons why you want to do this. But I still say that you want to be thinking carefully about how you use the screen space, and avoid wasting it.

What should your app do with Exceptions in a live environment?

You create a crash report, which includes the stack trace, and send it to the developer.

 

[RhinoCan]

First of all, sorry for the delay in responding. I've been on a coding tear and didn't want to lose my momentum!

I appreciate your answer and agree that it's better to debug the program than to simply fill it up with Toasts that tell you the status of your variables at various points. I'm happy to say that I have a good working knowledge of the debugger in Android Studio and it has been instrumental in helping me get to the root of several problems in a timely fashion. I also appreciate that screen space *is* limited on phones and tablets and perhaps justifies popping up messages with Toast rather than writing to a message area on the screen.

Can you point me to any code that creates a crash report and sends it to the developer that I could use as a starting point for my own efforts? I'm very curious to see exactly what you include in it and how you get it to the developer. I'll need to do something like this when my own app is completely so that I can share it with my colleagues and then get information back from them if Bad Things Happen while they execute it....