So far, we've looked at two ways to post information from our app

either to the screen or to the log.

Now, we're going to go even further and learn how to monitor our app in real time.

Our Android tools included debugging tool called the Dalvik Debug Monitor Server or

DDMS for short.

DDMS provides a ton of insight into how a connected device or emulator is running.

And we're going to see how to use it to debug our code line by line.

Instead of just running our app like we have been,

we now need to run our app with the debugger attached.

But the first thing we need to do is set a breakpoint in our code.

A breakpoint is a point in our code where the debugger will break out of the normal

computation and then wait for instructions from us on how to proceed.

Its a stopping point where we can take out time to look at the current

state of our app.

Then, if we want, we can continue processing the codes step by step or

presume running the app.

Let's start at the beginning of onCreate.

Now technically, there's some code that runs before we get to our onCreate method,

but we're not worried about that code.

Let's set our first breakpoint on the first line of onCreate.

We can add breakpoints in a few different ways.

First, let's click on the line where we want to add a breakpoint.

Then click on the Run menu, And select Toggle Line Breakpoint.

Notice that a little red circle representing the breakpoint appears to

the left of this line of code.

This area is known as the gutter.

To delete a breakpoint make sure that line is still selected, and

then select Run, Toggle Line Breakpoint to toggle it back off.

We can also click in the gutter next to a line of code to add or

delete a breakpoint like this.

We can add breakpoints all over our code to stop anywhere we like, but

let's start with just this one.

Now to run our app with the debugger, we want to use the debug button at the top.

Which is just to the right of the run button and

looks like a little bug with a play button on it, click it.

Then choose to run the app.

And once they have starts, it should stop at this breakpoint and

open the debug perspective.

Check it out, we now have a new debug view at the bottom of our screen.

And the line where we inserted our breakpoint is now highlighted with blue

to show where the apps stop.

Our app is in a pause state at this point.

If we switch to the emulator, we'll it's just a blank screen.

That's because we still haven't run any of the code that sets up our layout.

While it's paused, we can look at all sorts of things about our code.

We can hover over variables to see their values.

Let's scroll up and see what's in our factBook.

And then from this little pop-up, we can click the + sign to take a further look.

And look, our factBook has already been loaded and has all of our facts in it.

Since these variables are part of the class, they get created first,

even before the onCreate method.

But let's take a look at what happens if we look at these variables that are after

the current line where we stopped.

Nothing happens if we hover over fact or color.

That's because these variables haven't been initialized yet.

They get initialized here in the onClickListener, but we haven't gotten to

that point of the execution yet, we're still up here at the blue line.

All right, now let's step through this line by line.

There's a toolbar down here in the lower left, and

it contains controls on how to debug.

Let's quickly go over each one.

The first one is the resume button, which resumes normal execution of the code.

If there are any further breakpoints in the code,

then it will run until it gets to the next breakpoint.

Then there are pause and stop buttons, which are pretty self-explanatory.

Notice that pause is currently grayed out because we're already paused.

The next one down here with the multiple circles

shows all the breakpoints we currently have in the app.

This can be especially useful when we're debugging more complex tasks.

Now let's jump over here to these buttons at the top.

These control how we walkthrough the code.

The first one takes us to the current line of execution.

So if we had opened up a different class like color wheel,

we could use this button to get back to where we were paused.

These next ones are used to step through the code in different ways.

The first one is called step over.

Followed by two different step into buttons, and then a step out button.

Step over, the first one, will step to the next line to be

executed after this current line is all done, which for me is line 24.

Clicking on this step over button would process everything in

the super.onCreate method, and then it would pause again right here.

Step into means that we will step into the current method call,

provided there is one on the current line.

In this case, clicking step into means that we would take the debugger into

the onCreate method of the superclass, and we would continue debugging from there.

Eventually, we'd end up back here, just like if we clicked step over, but

that could be 1 or 1,000 lines later.

The last button, step out, means that we'll automatically process all

the code until the end of the current method, which in this case is OnCreate.

All right, let's step through our OnCreate code using the step over button.

Click it twice to get down here to where we initialize factTextView.

Now this line hasn't been executed yet, so we still can't look at factTextView.

Let's hit step over again, and now that that line is done,

we can hover over factTextView and see a little pop up like we've seen before.

Hitting the + sign, let us see a lot more information about it.

And if we scroll down to mText, there's our fun fact.

Also, in the debug pane, if we expand this which is our fun facts activity,

we can see that factTextView now has a value.

Whereas, showFactButton and relativeLayout are still null.

But if we step over two more times, Now all three views have been initialized.

Finally, if we hit the resume button, we can skip the rest of the code, and

if we switch to our emulator, our app is up and running.

And if we click the button, it just continues as normal.

Now if we add a new breakpoint here, In the onClickListener,

then go back to the app and

click the button, We're brought right back into the debugger, awesome.

This should be enough to get you started.

You can use the debugger to troubleshoot or

also just understand how your program is running.

It's a super useful tool.