User Tools

Site Tools


android-labs-s14:class-04

Class 04

In this class, we'll be learning about

  • Command line tools - ADB, Emulator
  • Debugging - in Eclipse, via Logging
  • Managing UI on different devices

Command Line Tools

Let's explore some useful command line tools.

ADB (Android Debug Bridge)

Android Debug Bridge (adb) is a versatile command line tool that enables you to control Android devices (and emulators) connected to your computer. To use adb, open Terminal application on your desktop machine, and go to <adt-bundle-directory>/sdk/platform-tools directory.

adb devices

You can view the devices currently connected to your computer by using the devices option with adb.

~$ adb devices

If there is an emulator and a device attached to your machine, you should get an output of the above command as something like below:

List of devices attached
HT07YPY09335 device
emulator-5554 device

By default, when you use the adb command, it assumes that currently there is only one connected device/emulator. If more than one device is connected, the adb command returns an error message:

error: more than one device and emulator

To access any specific device/emulator, use -s <DEVICE_NAME> option with adb. For example, use ~$ adb -s emulator-5554 logcat to get logs for this particular emulator.

If you have just one device connected to your machine, you use -d option with adb before using any other option. For example:

~$ adb -d logcat

Similarly, if you have just one emulator launched on your machine, you can use -e option with adb.

adb kill-server/start-server

Sometimes ADB will fail (when too many AVDs are opened at the same time; you will notice that you can no longer deploy applications from Eclipse onto your real devices or emulators). In this case, you need to kill the server and then restart it:

~$ adb kill-server
~$ adb start-server

adb logcat

The Android logging system provides a mechanism for collecting and viewing system debug output. Logs from various applications and portions of the system are collected in a series of circular buffers, which then can be viewed and filtered by the logcat command. So, you just need to execute:

~$ adb logcat

Use -c option with logcat to flush entire logs:

~$ adb logcat -c

adb shell

You can even create a shell connection to your device/emulator using the command:

~$ adb shell

If you have sufficient permisisons, you can then access the file system of your device/emulator using regular shell commands like cd and ls.

Emulator

To use emulator, open Terminal application on your desktop machine, and go to <adt-bundle-directory>/sdk/tools directory.

To launch an emulator from command line, type in:

~$ emulator -avd <AVD_NAME>

Debugging

Eclipse

In this section, we'll use debugging in Eclipse to better understand the Activity lifecycle in Android.

  • Let's start by creating a default Hello World App (as done in Class-01).
  • Now, add lifecycle methods - onResume(), onPause(), onStart(), onStop(), onDestroy() - with the function definition as mentioned below: (Just replace <lifecycle-method> by the lifecycle method name.)
	protected void <lifecycle-method>()
	{
		super.<lifecycle-method>();
 
		/* Rest of the code goes here. */
	}
  • Before launching our app, let's set breakpoints inside all of the recently implemented lifecycle methods.
  • Click on the button highlighted below to launch your application in debugging mode.

If you have not defined any breakpoints, this will run your program as normal. To debug the program you need to define breakpoints.

  • If you start the debugger, Eclipse asks you if you want to switch to the Debug perspective once a stop point is reached. Answer 'Yes' in the corresponding dialog.

  • Now you should be seeing a window something like the screenshot below:

  • Now, observe the order in which the debugger will hit the breakpoints.

Logging

  • Think of it as a printf, cout, or System.out.print(), which prints out information on 'adb logcat' console instead.
  • Let's continue with the project that we recently built. Insert following code in each of the lifecycle methods: (Just replace <lifecycle-method> by the lifecycle method name.)
  Log.d("HelloWorld", "<lifecycle-method> called.");

You might need to import android.util.Log; before your class definition. (Or, just use Ctrl+Shift+O, remember?)

  • Now, open Terminal App, go to <adt-bundle-directory>/sdk/platform-tools directory.
  • Clear pervious logs by executing ~$ adb logcat -c.
  • To get new logs about your 'HelloWorld' App, execute ~$ adb logcat | grep -i “HelloWorld”.
  • Now, when you'll launch your Application, you should see some of the logs as shown below:
D/HelloWorld(  394): onCreate called.
D/HelloWorld(  394): onStart called.
D/HelloWorld(  394): onResume called.

Following are the descriptions about different Logging options:

Log Option Signify Use-case
Log.d Debug Use this for debugging purposes. If you want to print out a bunch of messages so you can log the exact flow of your program, use this. If you want to keep a log of variable values, use this.
Log.e Error This is for when bad stuff happens. Use this tag in places like inside a catch statment. You know and error has occurred and therefore you're logging an error.
Log.w Warning Use this to log stuff you didn't expect to happen but isn't necessarily an error. Kind of like a “hey, this happened, and it's weird, we should look into it.”
Log.i Info Use this to post useful information to the log. For example: that you have successfully connected to a server. Basically use it to report successes.
Log.v Verbose Use this when you want to go absolutely nuts with your logging. If for some reason you've decided to log every little thing in a particular part of your app, use the Log.v tag.
Log.wtf What a Terrible Failure Use this when stuff goes absolutely, horribly wrong.

Toast Messages

  • Consider Toast message as a print in GUI.
  • Try inserting following code in each of the recently implemented lifecycle methods:
  Toast.makeText(this, "<lifecycle-method> called.", Toast.LENGTH_SHORT).show();
  • Now, launch your application.

Managing UI on different devices

Using Configuration qualifiers

To use a configuration qualifier:

  • Create a new directory in your project's res/ directory and name it using the format: <resources_name>-<qualifier>
    • <resources_name> is the standard resource name (such as drawable or layout).
    • <qualifier> is a configuration qualifier from the table below, specifying the screen configuration for which these resources are to be used (such as hdpi or xlarge).
  • You can use more than one <qualifier> at a time—simply separate each qualifier with a dash. Example: layout-xlarge-land
  • Save the appropriate configuration-specific resources in this new directory. The resource files must be named exactly the same as the default resource files.

For example, xlarge is a configuration qualifier for extra large screens. When you append this string to a resource directory name (such as layout-xlarge), it indicates to the system that these resources are to be used on devices that have an extra large screen.

Screen characteristic Qualifier Description
Size small Resources for small size screens.
normal Resources for normal size screens. (This is the baseline size.)
large Resources for large size screens.
xlarge Resources for extra large size screens.
Density ldpi Resources for low-density (ldpi) screens (~120dpi).
mdpi Resources for medium-density (mdpi) screens (~160dpi). (This is the baseline density.)
hdpi Resources for high-density (hdpi) screens (~240dpi).
xhdpi Resources for extra high-density (xhdpi) screens (~320dpi).
Orientationland Resources for screens in the landscape orientation (wide aspect ratio).
port Resources for screens in the portrait orientation (tall aspect ratio).

Using new size qualifiers (introduced in Android 3.2)

Screen configuration Qualifier values Description
smallestWidth sw<N>dp Examples: sw600dp, sw720dp The fundamental size of a screen, as indicated by the shortest dimension of the available screen area. Specifically, the device's smallestWidth is the shortest of the screen's available height and width (you may also think of it as the “smallest possible width” for the screen). You can use this qualifier to ensure that, regardless of the screen's current orientation, your application's has at least <N> dps of width available for it UI.

Exercise

Build an Android app with only one screen. That screen should have one button. The text string on the button should be different on tablet (7inch-WSVGA) and phone (Nexus4) emulator.

android-labs-s14/class-04.txt · Last modified: 2014/02/18 20:57 by prakhar