This short note describes a programming lab for a CS1 class (CS180, Programming I) taught during the fall 2009 semester. The purpose of the lab was to reinforce student understanding of recent lectures on dynamic data structures and generics, as well as provide a review of threads (the course is taught using Java). To add interest to the lab, we used Google Android phones (specifically, the HTC ADP1).
While the Android phone has a comprehensive, well-documented Java-based API, it is also quite complex, especially for students in a CS1 course. Labs are two hours long from start to finish, so there is no time to learn new material. We decided to develop a lab-specific API that would be easy for the students to use without needing to learn the Android API.
The lab assignment was to develop a simple camera application.
It would feature a small “preview window” to see a live image of the camera and a second “display window” to browse through pictures that were already taken. Three buttons on the interface would control “take a picture”, and two directional controls to “scroll forward” and “scroll backward” through the set of pictures. The students would need to store the pictures in a dynamic data structure.
Two of the methods in the API were blocking methods:
waitForPicture() method waited for the user to press the shutter button; it compressed the picture and returned a reference to it as value. The
waitForButton() method waited for one of the two directional buttons to be pressed and returned “true” if the forward button was pressed, “false” if the backward button was pressed. Since the two methods were blocking methods and the student's program needed to handle whichever method happened to return first, it was natural to create two threads and have each call one of these methods.
The lab-specific API contained three other methods:
displayPicture() to display a picture as returned by
popupToast() to display transient message to the user, and
setText() to set a line of text on the screen at a pre-determined location.
The standard Android application development environment is to create a directory structure with a regular format: an Android manifest file and Ant build file at the top level, subdirectories for sources, binaries, generated files, resources, etc. To shield the students from this complexity, we allowed them to work with their source files in a simple directory that contained only a hidden Android-structured application directory. They used a special command,
pal (Purdue Android Loader), to build and test their application. The first time the
pal command was run, it initialized the hidden directory and copied a short skeleton file into the student's directory. The skeleton file was a working sample program that could take and display one picture. In addition, and on all subsequent uses, the pal command would copy their source files into the appropriate location into the hidden Android directory hierarchy and run ant to build the application file. If the build succeeded the command would also copy the application to the connected phone and start it.
Related resources and links:
pal(Purdue Android Loader) command.