Warning: Outdated Content
This lab is from a previous version of CS 125. Click here to access the latest version.
Debugging and More Android Setup
Today’s lab begins teaching you to debug and completes preparing you to work on this semester’s Android-based MPs. You’ll start by completing some in-lab homework problems that help you learn to debug problems with your code. Next you’ll finish preparing your Android development environment by installing and using Android emulators to run and debug your Android code.
1. Learning How to Debug (60 Minutes Total)
Programmers never stop making mistakes. I’ve been doing this for almost 20 years and I make many, many programming mistakes every day. What you do get better at is fixing them, quickly, so that they don’t slow you down and you can get on with your business of changing the world.
Our first lab homework assignment today is designed to help you learn to do that. This knowledge will come in handy in all of your future programming tasks—but definitely during your CS 125 CBTF quizzes this semester, where you may small mistakes and be pressed for time.
Oh, and in case you’re wondering, programmers have long referred to fixing mistakes in their code as debugging, a term attributed at least in part to computer science pioneer Grace Hopper 1.
1.1. Understanding Your Program’s Output (20 Minutes)
A key part of learning to debug effectively is understanding the various kinds of output that your program produces. You can just stare at your code and try to figure out what’s wrong—that might work, eventually, maybe. But it’s slow. Frequently a much faster route is to use the output that the computer provides when testing your code to help you fix it.
Note that this is not just an artifact of how we do things in CS 125. Every large tech company has sophisticated systems for testing their code before it is released to users or to the public. This is because mistakes can be both embarrassing and expensive, so it’s better to test things first rather than try to clean up the mess later. Before modifications get made to widely-used pieces of software like, say, the Chrome browser, those changes go through extensive automated testing along with multiple rounds of review by other human developers. So increasingly one of the many things that computers are helping automate is the process of testing changes to their own code!
When you submit your program for grading in CS 125 the following steps take place.
1.1.1. Code Format Checking
First, we test the format of your code using
checkstyle
,
a program that checks it against a set of rules about how Java code should be
formatted.
We do this because writing readable code is as important as writing correct
code.
For example, the following code has a checkstyle
error—can you spot what
it is?
if (x>0) {
System.out.println("x is positive");
}
checkstyle
produces error messages that look like this (note that this is
not for the snippet above):
[ERROR] /base/src/main/java/Question.java:3:10: 'else' is not preceded with whitespace.
[ERROR] /base/src/main/java/Question.java:3:10: '}' is not followed by whitespace.
Note that the error message identifies the line number (3) where the error occurs, along with a brief human-readable description of the problem. Given the error message above, can you come up with a snippet that could have produced this error?
1.1.2. Compilation
Second, we try to compile your code using the Java compiler. This is step that we’ll discuss more soon in class, but certain kinds of mistakes can be caught at this point. We sometimes refer to errors identified at this stage as compiler errors or syntax errors. Note that if the Java compiler can’t compile your code we can’t run it and continue with testing, so we stop at this point.
For example, the following code will produce a compiler error—can you spot it?
double latitude = 80.98274;
if (latitute > 0) {
System.out.println("You're in the northern hemisphere");
}
The Java compiler can produce all kinds of error messages depending on what you
did wrong.
Understanding how to interpret them will greatly improve your ability to fix
errors and perform well on the homework, quizzes, and MPs.
Here are a few examples of common mistakes.
Note that, like the checkstyle
errors above, each identifies the line number
where the error took place and provide some information about the problem that
was encountered.
For each, see if you can determine a piece of code that could produce that
error.
/base/src/main/java/Question.java:2: error: cannot find symbol
if (currenttime > 10000000) {
^
symbol: variable currenttime
location: class Question
1 error
/base/src/main/java/Question.java:4: error: reached end of file while parsing
}
^
1 error
/base/src/main/java/Question.java:2: error: ';' expected
System.out.println("Smaller")
^
1 error
1.1.3. Testing
Finally, we run your code using a test suite.
At that point your program will run, but it might not be correct.
For example, we may have asked you to add x
and y
but if your code instead
computes x * y
, then it doesn’t match our specification.
Our test suite will try and determine this and, if your code doesn’t behave
correctly, we’ll provide some information about what went wrong.
Usually how we do this is to compare the behavior of your program to what we had
expected.
For example, let’s say that we instructed you to write a snippet of code that
printed North Pole
at the appropriate latitude
and longitude
and not print
anything otherwise.
You submitted the following code:
if (latitude == 0.0) {
System.out.println("North Pole");
} else {
System.out.println("Not at North Pole");
}
What we would do is test your code with different values of latitude
.
First we’d say, let’s see if it’s right if latitude
is equal to 0.0
.
In that case it does print North Pole
, so that’s good.
OK, now what happens if we set latitude
to 1.0
?
We didn’t tell you to not print anything otherwise, but you printed Not at
North Pole
.
So you might get an error message something like this:
java.lang.AssertionError: expected [] but found [North Pole]
These error messages might look different depending on the problem you are working on. But in general they describe a mismatch between our expectations of how your code should behave based on our instructions and the reality of how it worked when we ran it.
1.2. Practice Debugging (40 Minutes)
Next, you should the next 40 minutes on our in-lab homework. You will only be able to access this homework beginning 20 minutes after your lab starts and ending 40 minutes later. So if your lab starts at 9AM, you can start the homework at 9:20AM and should complete it by 10AM sharp. And if you are in the wrong lab you will not be able to complete the lab homework assignment—please attend the right lab next time.
Please feel free to work with a partner or in a small group on the lab homework. But every student must submit their own answers to receive credit.
Note that the best way to approach these debugging problems is not to just resubmit your solution over and over again. In fact, we’ve disable cut and paste on these problems to prevent you from doing that. Instead, first run the code, then use the output to identify the errors, and then fix them by modifying the code that is in front of you. All of these errors can be fixed with only a few keystrokes.
2. Building and Running Android Apps (Remaining Time)
Next, let’s return to the Android Studio tutorial and complete an additional portion of the tutorial. To work on our CS 125 MPs, you will need either an Android device or a working emulator—even if it runs a bit slowly. Again, work with the course staff to try and complete this portion of the lab.
Note that if you have an Android device you should use it for Android development. Even an old and slow Android device can provide a more enjoyable development environment than using the emulator.
2.1. You’re a Hacker Now
Note that we are definitely throwing you into the deep end today. As you work your way through the Android "Hello, World!" tutorial you will definitely encounter code and concepts that are new and unfamiliar to you. That’s normal.
CS 125 is designed to introduce you to two sides of programming and computer science. In lectures and on our homework problems and quizzes you’ll be working on clean, simple, isolated problems. Our goal is to prepare you to think and solve problems like a computer scientist.
But building real things also requires a different set of skills and mindset, sometimes referred to as hacking. Hacking involves learning how to work with large, complicated systems. It means spending more time learning about how other things work than building your own things. It requires that you get comfortable not necessarily understanding how every part of your program works—at least not right away.
You’ll get lots of practice at this on our labs and MPs, starting today. Our advice: be brave and unafraid. Try things, experiment, and have fun. You aren’t going to break anything important, and even if you get a mess and get stuck we’ll be able to help bail you out. And the rewards are huge. Once you can hack together Android apps, you can distribute them to billions of users all over the world. When we said "change the world", we meant it.
2.2. Modifying "Hello, World"
Once you have the "Hello, world!" app running, try to make the following modifications:
-
Change the text that is shown to "Hello, CS 125!"
-
Change the size of the text
-
Change the position of the text
-
Add some other element to the user interface
Your goal today should be to get at least to the "Build a simple user interface" portion of the tutorial. You don’t need to get farther than that—we’ll continue with this tutorial in future labs.
3. Before You Leave
Don’t leave lab until:
-
You’ve reviewed our debugging instructions and completed our first in-lab homework.
-
You’ve built and run your first Android app on either an emulated device or your own Android device.
If you need more help completing the tasks above please come to office hours or post on the forum.