Teaching Tip

Cards to Screens

To simplify the prototyping process, teams can think of each card that they created in the Paper Prototyping as a separate screen in the App Lab iteration of their app. In reality, screens that are very similar can often be developed as a single screen with content that changes based on user interaction. In the next lesson students will see some examples of how that could work, but it's not expected that they incorporated that kind of functionality in this project.

Teaching Tip

Catching Up

If students missed the previous lesson, or were unable to complete the home screen, you can have them import this completed version of the home screen https://studio.code.org/projects/applab/Y3yxoz85-vy5Hpq8R4qOTQ/. See the Screen Import Map for details.

Teaching Tip

Promoting Teamwork

The following levels will prepare teams to merge all of their separate screens into a single app. There are two potential stumbling blocks that teams may run into during the import process:

• Miscommunicated urls: The sharing URLS are long and complicated, so students will need a shared location where they can copy/paste their urls
• Conflicting screen IDs: Importing a screen with the same ID as an existing one will allow you to overwrite the existing screen. This is particularly troublesome when students leave the default screen ID "screen1"
• Conflicting element IDs: If students have properly namespaced all of their elements this shouldn't be an issue, but any elements that have the default ID or share an ID with an existing element will prevent a screen from importing

Once teams move to the programming phase of this project, it becomes much more difficult for students to collaborate on the same app. The design phase is the primary opportunity for all students to collaborate on the app - after this teams will still be working together, but each student will be working on their own copy of the app.

Teaching Tip

Just the Facts

There's a lot to consume here and many of the details about how events work in App Lab are not totally necessary to understand for our needs in this unit. If students are struggling with how programming works in App Lab, focus on these essentials:

• There is no draw loop that runs forever
• The onEvent() block specifies:
  • an element ID
  • an event (such as "click" or "mouseover")
  • code that should be run when the event occurs (this code is technically an anonymous callback function, represented by the green block)
• Code inside onEvent() blocks runs any time the specified event occurs

Compared to Game Lab

In Game Lab, we might use the following code to check if a sprite named "button" was clicked and do something about it:

function draw() {
    if (mousePressedOver(button)) {
        // Do something
    }
}

In App Lab, given a button with the ID "button", we could write the following code to achieve the same goal:

onEvent("button", "click", function () {
    // Do something
});

In the App Lab example, the function is just another argument passed to the onEvent function, it just so happens that the argument must be a function itself. We could also define the function separately and write this same program as follows:

function doSomething() {
    // Do something
}

onEvent("button", "click", doSomething);

In the second example, notice that when we pass the function doSomething to the onEvent function we don't include the parenthesis at the end. This is because we're actually passing the whole function as an object.

Teaching Tip

Limited Programming Required

The goal of this unit is to get students thinking about the role design plays in developing a product and to help them build empathy for end users. This is not a programming focused unit, and the extent to which students will be expected to program is represented in its entirety here. Students will get a chance to delve deeper into App Lab, and to learn more about how onEvent works, in unit 6.