Building Apps - Lesson 3: Building an Event-Driven Program
This lesson gives students time to familiarize themselves with the process of making event-driven programs before we move on to deeper content.
They will design and create a program on a topic of their choosing. There are some constraints on the project
to help guide students in their thinking. Students are also encouraged to do independent work, but alongside a
"coding buddy" or "thought partner" to be a help along the way.
Note: This activity is not intended to be a Practice PT but could be used similarly. The aim is to give students
an opportunity to get comfortable with the Quorum Game Engine and the structure of event-driven programming in a creative way. Another goal is to
intentionally build an environment of informal collaboration, even when doing individual work.
Students will be able to:
Develop and Design a plan for an event-driven program.
Collaborate with a "thought partner" during the implementation of a project.
Create an event-driven program using UI elements/objects and event handling.
This lesson is not heavy on new CS content. It is primarily
a time to reinforce programming skills while prototyping a simple event-driven
program. The lesson does, however, fall at the intersection of the Big Ideas
of Creativity and Programming. The fact that students will share ideas
before programming their projects and will provide feedback using a peer rubric
also mirrors some of the practices of collaboration that students can employ
on the Create Performance Task.
As for the project itself, it probably bears the closest
resemblance to creating a "computational artifact" as outlined in the
Explore Performance Task -- Creating something to communicate an idea
Today students will get a chance to make a program of their own design that uses objects and lets them practice using event handlers by programming some simple user interactions. We want to have students spend most of their time working on it, so let's get to it.
Distribute the Activity Guide.
Pair students with a "coding buddy" for this project.
Students will make a project independently, but have a partner with whom they can get instant and rapid feedback and help.
Refer to the first two lessons in this Unit which you might use as review and kickoff to the project.
In the last two lessons students looked at the Quorum Game Engine and Event-Driven Programming. This lesson is all about students getting a chance to use those new skills to make their own event-driven program. Encourage students to use their creativity and personal interests to make their program unique. Here are some steps to get students started:
Choose the theme of your program
Complete the Planning Guide
Share your plan with a classmate
Code your program/app
Give and receive feedback on programs.
Before having students embark on making their own program from scratch, recap these few important things:
When instantiating objects from a Class use names/IDs that are easily identifiable and include the appropriate "use" statement at the beginning of your program for the associated Class/Library.
Build your code section by section and use the "Run, Test, Debug!" concept throughout your coding process to ensure that everything is behaving as you would expect and/or catch anything that is not behvaing as you would expect early on.
Don't forget to add a KeyboardListener to "listen for" keyboard input from the user.
As you are about to embark on your first solo project we thought it would be a good time to give you some tips.
Have a "coding buddy" and/or "thought partner": working on your own doesn't mean working by yourself. It's very useful to have someone nearby who you can use as a "thought partner." Many professionals work at the same table or desk, even if they are working on completely different projects, because of the benefits of having someone nearby. There is a lot to remember and a lot to try to keep straight, so it's helpful to have someone nearby who can provide another perspective. Here are a few things that "Thought Partners" might do:
Bounce ideas off each other
Share insights or discoveries they've made through their own programming
Answer each other's questions in the moment
Help double-check code and provide a second pair of eyes for debugging
Persistence Pays off: When you are learning to program you will inevitably run into problems. Like anything else, over time you stop making the same mistakes you made as a novice. Remember:
Programs rarely work correctly the first time.
The whole point is to build something up in small increments.
You can't break anything. Add code, try it out. Doesn't work? Get rid of it and try something else.
Add. Run. Test. Debug.
You will be creating your own program which will give you practice
designing user interfaces and writing event-driven programs. Complete the Planning
Sheets and Peer Review before beginning to write your code. We have provided
the Quorum Game Engine template and a list of Audio files that you can Load to your
Audio objects to help you get started on programming your project.
Available Audio Files:
Create your own Event-Driven Program
Save this Project
Load a Project
Incorporate peer feedback
Give students a chance to respond to the feedback they receive on their program. They should pick at least one piece of feedback to implement in their program. This could be done outside of class, if desired.
Rubric: Use the provided rubric (in the Activity Guide) or one of your own creation, to assess students' submissions.
Extended Assessment: If you want to make the project more like a practice performance task you could have students write responses to applicable reflection prompts from the real Performance tasks.
You might modify these slightly for this context, but useful prompts are:
From Create PT:
2b. "Describe the incremental and iterative development process of your program, focusing on two distinct points in that process. Describe the difficulties and/or opportunities you encountered and how they were resolved or incorporated. In your description clearly indicate whether the development described was collaborative or independent. At least one of these points must refer to independent program development; the second could refer to either collaborative or independent program development. (Approximately 200 words)"
From Explore PT:
2b. "Describe your development process, explicitly identifying the computing tools and techniques you used to create your artifact. Your description must be detailed enough so that a person unfamiliar with those tools and techniques will understand your process. (Approximately 100 words)."