1. Students will gain experience navigating the App Inventor interface.
2. Students will gain knowledge of sprite and button components, and will practice implementing them
It is assumed that students are working with basic knowledge of variables and loops. Some students will require review of these basic concepts, which the teacher should provide while students are implementing the code on their own.
The teacher should interact with the students at their desks, if possible, when they are coding. The teacher should look for common misconceptions, and model good coding practice for students when needed (just in time).
App Inventor uses object oriented coding concepts. It is important to draw this concept out for students to recognize. Every component a student adds in the App Inventor design mode is an Object, which is a bundle or package of three things: properties, methods and events. Every time you add one of those objects in design mode, it comes with that whole bundle.
Properties (green) - might be boolean values, numerical values, strings, etc. All properties come with a Get function to retrieve its value and a Set function to change its value. You can access and change object properties in the Blocks view through Get (light green) and Set (dark green) functions for the object, or by setting the initial values in the right side panel in the Designer view. We may sometimes refer to object properties as object data (mostly out of habit, and because the author is tired and has grown sloppy).
Methods (purple) - these are useful functions that are used to manipulate the object in more complex ways. They depend a lot on what the object is, and common things that are done with that object. For example with an image sprite component, you might want to move it to a location. To do so, you invoke the MoveTo function and provide the function with the X and Y coordinates you want to move the sprite to. The X and Y coordinates are the parameters of the method function.
Events (brown) - these follow the form WHEN a trigger event happens to the object, DO one ore more functions. This allows, for example, a button object to "WHEN clicked DO start the game" for example. We say the event is "triggered" when it is activated by the action specified, in this case clicked. Other events we will consider are WHEN sprites collide with each other, WHEN sprites run into the edge of the screen, WHEN a sprite is touched, and WHEN a sprite is swiped (flung). Students should be familiar with the concept of events WHEN-THEN from lesson 6.
Often times we will rename Objects so we can keep track of them better in the code, so instead of Image1 we might have "FemaleStudent1." When we are referencing the data, methods or events about that specific object we might use a "." to connect them, so for example when we want to reference the image touch event (called "Touch") for the FemaleStudent1 we will might refer to that as FemaleStudent1.Touch. When we are referencing the X Position property (data) of that image we might refer to that as FemaleStudent1.XPosition.
In this section we will teach students technical concepts, with strong coding focus to enable them to perform new and more diverse actions within their game. The goal of each section is to provide a small coding example to give the students access to some new events, like "flinging sprites" or "collision detection," etc. and then allow the students time to integrate these events into their game. The teacher should have at least one example of each event ready to show students (examples are provided), and then provide the remainder of the class time to work with students on integrating this function into their game.
Alternatively, the teacher may want to "front load" the students by showing them a few new functions during a single class, and then allowing students to integrate those functions into their game over the next couple of days. Whichever method is preferred, the teacher should allocate 3-5 days total, to introduce the functionality we specify in this section.
Each Event (WHEN) should have an associated outcome (DO). For example, if a question is answered correctly, instead of a clapping sound they may want an explosion image to show on the screen. There are so many possible consequences that the students might want to implement, that we cannot provide examples for all of them. We will teach them how to program the WHEN part of the Event, and provide an example of the DO part (for example, an applause sound), but if they want it to explode, they (with the teachers support) will have to figure out how to accomplish that.
The most difficult aspect of teaching students to code in this way will be to teach them to think critically about what they want to have happen, and then understand and implement the code that accomplishes this goal. With coding, it is important to teach students that they will be able to do more and more as they gain experience (teachers new to coding should remember this too!). Perseverance and openness to collaborative learning are important characteristics for students wanting to code. Students should be encouraged to use the internet to research how to look up and code something they want to achieve.
Teachers should not be discouraged if they don't know how to code every possible outcome students may want to see; it is impossible to anticipate everything a student might want to code. Instead, these should be viewed as learning moments for both the teacher and student; the more experience the teacher gains, the easier this becomes.
The first step students usually take is to exactly copy examples they are given into their program, and hope it works. Almost always this is done with an at best superficial understanding of the code. Often it does not work and students are left to figure out why. When copied code does not work as expected, or at all, these are natural learning moments for students to understand the deeper principles of coding. Why isn't it working, and what has to be changed to get it to work? Debugging and testing are powerful tools in the coders toolkit. Students must be encouraged to make thoughtful changes to their code, to see what happens as a result, and to try to identify the underlying patterns. Again, grit and perseverance are important qualities to emphasize.
Activity 4.7.1 (Budget 15 minutes)
Students learn to navigate the App Inventor interface and create an App Inventor account.
1. Present the App Inventor Interface PowerPoint up to slide 3. Facilitate discussion on the differences between the EarSketch and App Inventor interfaces in slides 4 and 5.
2. Have students create an App Inventor account. When they Google and click on the App Inventor link, they will automatically be asked for a Google account.
App Inventor Interface PPT (Teacher Resource)