Identify WHERE the issue is happening
- Look at the logcat error to see if you can immediately identify the issue in the line of code
- Make sure to use Log.e(“tag”,”specific error note”) rather than in app toasts/popups. The UI execution thread can be blocked by other operations, but the log is written independent of execution.
- Always include e.printStackTrace(); in your try-catch blocks. Otherwise runtime exceptions fail silently.
- Isolate the last change that led to the issue (with code X it works but X+ doesn’t)
- Run through the code in your head (what should be executing/running/open)
Identify WHAT the issue is (get to a Google query)
- Look at stack Logcat errors/traces. Any errors? Any outputs that are not expected?
- Work your way down the call stack. Start with the first method (onCreate) and work your way to the last method viewing variables at runtime along the way to make sure they are what you'd expect.
- Watch inheritance
- A lot of pain has come from issues with overrides. For example I assume my code is using java.library.newclass when instead it’s using mycode.newclass or android.newclass.
Finding a solution
- Google it to see if is a common issue
- Answers usually come from stack overflow/api documentation.
- Beware so sub-optimal implementations. There is a strong temptation using stack overflow just to paste in a solution to see if it works, but if you don’t understand what is going on it will introduce issues for you in the future
- For example I added an animation sequence in android that overrode the onpause method. This caused an unhandled exception to fire every time I tried to call finish() or pause() or a user hit the home/back button. Huge pain to find and its not an issue that is immediately apparent (ie you’ll go 5-10 versions forward before discovering it. Then you need to backtrack).
- This is good practice.
- It is an opportunity to examine every line of code again to see if anything triggers an association with the trouble spot