Android开发笔记-ch3.3 Debugging

3.3 Debugging

3.3.1 Logging

Log.d("myTag", e.getLocalizedMessage());

Toast.makeText(getContext(), "My message", Toast.LENGTH_LONG).show();

A messageBox method could be like this:

private void messageBox(String from, String message)

{

AlertDialog.Builder builder = new AlertDialog.Builder(thisActivity);

builder.setTitle(from)

.setMessage(message)

.setCancelable(false)

.setNeutralButton("OK", null)

.show();

}

Alternatively, use positive button: .setPositiveButton("OK", new DialogInterface.OnClickListener(){ public void onClick(DialogInterface dialog, int id) { /*do things*/ }});

Also, alternatively, do not call builder.show(), instead, do: AlertDialog alert = builder.create(); alert.show();

3.3.2 Exception handing

Refer to this howto and this code for handling uncaughted exception.

Checked exceptions are exceptions that must be declared in the throws clause of a method. They extend Exception and are intended to be an “in your face” type of exceptions. Java wants you to handle them because they somehow are dependent on external factors outside your program. A checked exception indicates an expected problem that can occur during normal system operation. Mostly these exception happen when you try to use external systems over network or in file system. Mostly, the correct response to a checked exception should be to try again later, or to prompt the user to modify his input.

Unchecked exceptions are exceptions that do not need to be declared in a throws clause. JVM simply doesn’t force you to handle them as they are mostly generated at runtime due to programmatic errors. They extend RuntimeException. The most common example is a NullPointerException [Quite scary.. Isn’t it?]. An unchecked exception probably shouldn’t be retried, and the correct action should be usually to do nothing, and let it come out of your method and through the execution stack. At a high level of execution, this type of exceptions should be logged.

Errors are serious runtime environment problems that are almost certainly not recoverable. Some examples are OutOfMemoryError, LinkageError, and StackOverflowError. They generally crash you program or part of program. Only a good logging practice will help you in determining the exact causes of errors.

Best practices you must consider and follow

• Never swallow the exception in catch block

• Declare the specific checked exceptions that your method can throw

• Do not catch the Exception class rather catch specific sub classes

• Never catch Throwable class

• Always correctly wrap the exceptions in custom exceptions so that stack trace is not lost

• Either log the exception or throw it but never do the both

• Never throw any exception from finally block

• Always catch only those exceptions that you can actually handle

• Don't use printStackTrace() statement or similar methods

• Use finally blocks instead of catch blocks if you are not going to handle exception

• Remember "Throw early catch late" principle

• Always clean up after handling the exception

• Throw only relevant exception from a method

• Never use exceptions for flow control in your program

• Validate user input to catch adverse conditions very early in request processing

• Always include all information about an exception in single log message

• Pass all relevant information to exceptions to make them informative as much as possible

• Always terminate the thread which it is interrupted

• Use template methods for repeated try-catch

• Document all exceptions in your application in javadoc

3.3.3 Troubleshooting

Error: “Activity xxx.xxx.xxx has leaked window com.android.internal.policy.impl.PhoneWindow$DecorView”

Refer to this SO. The error is raised when trying to show a view while the Activity was already destroyed, because of other issue. So need to check other error happened early to root cause.

Runtime error with external Jar: “java.lang.ClassNotFoundException: Didn't find class xxx”: In the "Order and Export" tab of Build Path, check the box for the missing jar and move the jar above the src.

3.3.4 ADB

Refer this for setting up adb. On Ubuntu, need to add a udev rules file: /etc/udev/rules.d/51-android.rules.

Use this format to add each vendor to the file: SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", GROUP="plugdev". Then run: chmod a+r /etc/udev/rules.d/51-android.rules

Refer to this SO for enable ADB through WIFI.

From device side, to enable: su => setprop service.adb.tcp.port 5555 => stop adbd => start adbd

To disable: setprop service.adb.tcp.port -1 => stop adbd => start adbd

From host PC side: adb tcpip 5555 => adb connect 192.168.1.34:5555