Student Instructions

You do not need to watch this video to understand or complete this lesson - it is merely here if you are interested in getting a general overview.

In this lesson to get started we will only use a few of the features depicted.

Student Instructions

Welcome to Design Mode

In App Lab "Design Mode" lets you drag and drop User Interface (UI) elements into the app and then add code to respond when a user interacts with those elements. It's kind of two-step process, but we'll learn all about it in this lesson.

To start let's just look at Design Mode and add a single UI element (a button) to our app. We'll add code later on.

Vocabulary

User Interface (UI) - The "User Interface" or UI of an app refers to how a person (user) interacts with the computer or app. There are common patterns to user interfaces that you probably know about just from experience:

• UI Elements or objects, like buttons, images, text boxes, pull down menus, screens and so on.
• UI Events or controls, like click, scroll, move mouse, type keyboard key, etc.

Student Instructions

Design Mode

You Try it: Add a large red button to your app using Design Mode.

• Switch to Design Mode
• Drag a button onto the app screen
• Change the text to say "Click Me!"
• Make the color of the button red.

Student Instructions

Event-driven programming

App Lab apps work by adding code to respond to certain events that occur in a program. It's App Lab's way of saying "Hey! something just happened!". Your code can then respond to each of these events.

Collectively, the coding tasks involved in making your app respond to events by triggering functions are called Event Handling.

In App Lab all event handling starts by adding a special block of code called onEvent. Here is how to do it:

A small example - move turtle forward on "click"

It's important to understand in Event-Driven programming that:

• Users trigger events - Events occur when users click a button, tap the screen, move the mouse, type a key on the keyboard, etc.
• Events trigger code - When an event occurs or "fires" it can be used to trigger a particular javascript function.

App Lab's onEvent block is a type of event-handling function called an Event Listener. It wraps all of the setup up you need to do event handling into one command that has several parts. Here is an example with everything labeled:

You'll try this next!

Student Instructions

onEvent

You try it! - Make the turtle move forward when the button is clicked.

• Add an onEvent block
• Set the id of your button

• Add moveForward to the function definition

• Run the program to make sure it works.

• Try changing the event type to something like "mouseover" and see what happens. Not all event types will work with buttons but it's fun to play a little bit.

Once you've got the program responding to some event, congratulations! You've just made your first interactive app.

Click Finish to move on to the next problem.

Student Instructions

Practice! Add another button

Now that you know the pattern try it out. Add a 2nd button to the screen that turns the turtle to the left when clicked. The finished product should look similar to the image shown here.

Remember the steps:

1. Design Mode: drag another button onto the screen
2. Switch to Code Mode: add an onEvent block to the code
3. Add code inside the function to make the turtle turn left
4. Run. Test. Debug

Student Instructions

Event-Driven Programming Patterns

Now you're getting the hang of it!

What you have just done once will become a familiar pattern to you. When making event-driven apps in App Lab you usually go through the following steps:

Step 1 - Design Mode

Add a UI element (or a few) in Design Mode

Step 2 - Add onEvent to Code

Set the id and event type to listen for some event on that element.

Step 3 - Write the code for the event handling function

The code describes what you want the app to do WHEN the specified type of event happens on the specified ID.

Step 4 - Run. Test. Debug.

If the program doesn't work at first (this is very common) try-try again

Debugging

We haven't had a ton of practice with debugging yet. But if you have ever written any code and it threw an error, or didn't work for any other reason and you dug in and figured out why and fixed it, you were debugging.

We'll do some debugging practice later on.

The next tip we'll learn about will help make debugging easier for you later on.

Don't Worry!

Even for professionals, it's very common to go through several cycles of run-test-debug to get it right even for very small programs or pieces of code. It's the nature of the business.

In the next few levels we'll practice this pattern of creating event-driven programs and also debugging.

Student Instructions

Choosing Good IDs

Good IDs are meaningful and descriptive.

Just like good names for functions, you will want an ID to describe the intended purpose of the element.

For example, if you have many buttons in your program, you will want to give each an ID that describes what the button does.

So, instead of this:

• button1 and button2

You might make IDs that convey not only that it's a button but what you intend the button to be used for, like:

• forwardButton and leftButton or
• fwdBtn and leftBtn or
• forwardBtn and leftBtn
• it's up to you!

Rules About IDs

In making descriptive and meaningful IDs there are some rules about IDs you need to know. IDs...

• are case-sensitive
• cannot contain spaces.
• must begin with a letter (A-Z or a-z) and may be followed by any number of digits and letters.
• can contain hyphens ("-"), underscores ("_"), colons (":"), or periods (".").

Why no spaces?

Many computer systems do not allow function names and IDs to contain spaces. We typically use camelcase in our lessons.

You've already seen several examples like this: moveForward, onEvent, turnLeft, etc. It's important to realize that camelcase is a style convention, not a hard and fast rule of JavaScript.

Case-sensitive?

This means there is a difference between LeftBtn and leftBtn (notice the Capital L on the first one).

These differences seem annoying at first, but you get used to it, and actually learn to appreciate the fact that the computer requires such precision.

There are a few common styles for capitalizing and spelling multi-word IDs:

• "Camelcase" -- aCamelcaseNameMightLookLikeThis
• Underscores -- Some_people_like_to_use_underscores_to_separate_words
• dashes -- Others-like-to-use-hyphens-or-dashes

Whatever you choose is up to you. It's your style. It just helps to be consistent.

Student Instructions

Descriptive IDs

You try it - give your buttons descriptive and meaningful IDs rather than the default button1, button2 and so forth.

After you change the ID in Design Mode remember to:

• Change the event handler code so that it correctly references the new IDs of the buttons
• Run - Test - Debug the program to make sure it works, and debug any problems.

Student Instructions

Play with different event types

If you haven't yet, you should experiment with different event types with your onEvent blocks. The ones that will work best here are mouse-related ones such as: * click * mousemove * mousedown * mouseup * mouseover

There are some events that capture keystrokes from the keyboard. These are interesting, but they do not work easily with buttons. We'll stick to mouse events for now, and get to keys later.

Be sure to experiment with each of the ones that start with "mouse...".

Once you've have played a little bit, click Finish to move on.

Student Instructions

Learning How to Debug Programs

Debugging is a skill and an art. With practice you learn how to write relatively bug-free code and more importantly you learn about yourself and the kinds of errors you typically make.

But learning how to debug takes some time and getting used to, and you will learn about the different kinds of things that can go wrong when you write programs.

It bears repeating:

Debugging is part of the problem-solving process of programming.

• Rarely does code work exactly the way you want the first time.
• If you write some code and need to work out a few bugs that does not mean you are bad programmer - actually the opposite might be true.

Be a Pro! Even professionals do not expect to write bug-free code on the first

• Instead they get in the habit of running their code, checking their assumptions, and making changes as needed. Programming isn't a fixed set of steps.
• It's a creative and continuous cycle of writing, testing, and improving code.

Don't Worry! We'll Practice.

• With practice you eventually stop making certain kinds of errors that beginners run into, but there's always something around the corner that needs to be worked out.

Common Types of Errors

In the next few levels we'll practice debugging a few common types of errors. They generally fall in two categories:

Syntax errors

• Things you misspelled or wrote in such a way the computer doesn't understand what you're trying to say
• Usually the computer spits out an error message of some kind that is a clue about what it can't understand
• Fix these with careful reading of the lines that have errors

Logic errors

• The program runs but doesn't do what you think it should.
• Can be tricky to fix because there might not be an error message
• Fix by retracing your steps, being humble, and trying to understand why the computer is interpreting what you wrote the way it is.

Click Continue to start practicing

Student Instructions

Debugging Event-Driven Programs: IDs

You Try it: Checking IDs -- Your first debugging task will be to verify that the button IDs match the event-handlers. You'll also see error messages in the "Debug Console"

1. Run the program and inspect the error messages in the Debug Console.
2. NOTE: an error message only indicates where the computer ran into trouble. It doesn't tell you the root cause of the problem, necessarily.
3. Investigate -- Use the error message as a clue to investigate the possible problem.
4. Fix it -- Make a change that you think will fix the problem.
5. Run the program and verify that not only are there no error messages but the program works as intended (turtle moves forward on button click).
6. Didn't work? - repeat the steps above. And stick with it! You'll get it eventually.

Remember: You can see the ID of a UI element by just hovering your mouse over it.

Student Instructions

Debugging Event-Driven Programs: IDs

Try another one! -- This one is trickier, but very common.

1. Run the program and inspect the messages in the Debug Console for clues.
2. Investigate - track down what the root of the problem might be.
3. Fix it the program and correct the errors so that it works as intended.
4. Run the program and verify that both buttons have the intended functionality.
5. Repeat as necessary until the program works as intended

Student Instructions

Debugging Unexpected Behavior

Predict - Observe - Reflect

To understand a new piece of code good programmers often try to first make a prediction about what will happen before running the program.

By forcing yourself to make a prediction (it doesn't matter if you're right or not) you are immediately alerted to any unusual or unexpected behavior and you can ask yourself, "Huh? why did it do that? Was that supposed to happen?" It might not be an error, but you gain invaluable insight and actually learn faster.

Predict: For the code that is here, what will happen when the "Click Me" button is clicked?

• Study the code - This program has two event handlers listening for events on the same button?
• Force yourself to make a prediction! - "I don't know" is not a prediction!.

Here are some options to think about:

• There will be an error in the console immediately after hitting run
• There will be an error in the console but not until you hit the button
• Program does nothing
• turtle only moves forward
• turtle only turns left
• turtle move forward then turn left
• turtle turn left then move forward?
• something else?

Observe: Once you've made a prediction, close these instructions and run the program to observe what happens.

Reflect: Was your prediction correct? If not what about your mental model might need to change? Talk about it with a classmate and experiment with the code to make sure you understand what is happening.

Student Instructions

Debugging Logical Errors

Sometimes you can write a program that generates no errors but still does not work as intended.

This is the result of logical errors in your code, and making a prediction can help find these nasty little buggers too.

Once again we've introduced an error or two (a logical error this time) for you to debug.

1. Investigate the code and make a prediction - What should happen here?
2. Run the program and experiment to see what's wrong.
3. Reflect - were you right? Why or why not?
4. Fix it - make it work as intended.
5. Repeat as necessary

Student Instructions

Goodbye, Turtle!

Using the turtle as a form of output was helpful as we learned about UI elements and event handlers.

But it's time to move on. Goodbye, fair turtle! We'll miss you.

Typically when you handle an event your code makes changes to UI elements to make a computation or update the app display in some way. Since we only have one UI element right now, we'll just add code to change it every time we click it.

setPosition and Screen Dimensions

The setPosition command (now added to the Toolbox) lets you move UI elements to an arbitrary position on the screen (and optionally set the size at the same time). Here is the generic form which shows that: for a given UI id, you can explicitly set the x,y location on the screen as well as the width and height.

The little arrow on the right side mean that some of the parameters are optional. You can click the arrows to collapse or expand the available parameters.

You (perhaps obviously) need to plug actual numbers into these parameters of setPosition for it to have any effect. The numbers for setPosition x and y coordinates of the screen. This is similar to the turtle's moveTo(x,y) command.

Remember:

• 0,0 is the top left corner.
• Specify a location by how many pixels from the left and down from the top of the screen it is.
• The screen is 320 by 450 pixels.
• You can hover over the screen to see the x,y coordinate of any point.

Student Instructions

Using setPosition

Now you try it - use setPosition to move the button to the middle of the screen when clicked.

We've set up a small project for you with a button (id: moveBtn) already added in design mode.

1. Add an onEvent block
2. Drag a setPosition command into the event handler function
3. Set the x,y coordinate so that the button ends up in the middle of the screen.
4. You'll need to experiment a little bit to find coordinates that work for you.
5. Hover over the screen to find a good starting point.

Tip: when you see a command that is linked like this: setPosition click it! -- it will show you other hints.

Once you've got the button moving to the middle of the screen click Finish to move on to the next challenge.

Student Instructions

Using setPosition and randomNumber

Now you try it - instead of using a fixed value, you use randomNumber to set the x and y coordinates for setPosition. Now you'll have to chase the button all over the screen!

• Make it so that the button could jump anywhere on the visible screen each time it's clicked.
• Extend it: if you want to get really nuts, you could add back in the width and height parameters of setPosition and make the size of the button also change randomly with each click!

Once you've got the button jumping around the screen. Click Finish to move onto the next level.

Student Instructions

Design Mode: Add a label

Well, now we have the beginnings of a little game! Time to go back to design mode to start embellishing our program.

You try it: - Add a text label that says "Try to Catch the Button!"

• Switch back to design mode
• Drag a label on the screen
• Set the text to be something like "Try to Catch the Button!"
• Set any other properties or styles of the text label that you want.

Student Instructions

How to Add Images in Design Mode

Adding an image UI element in design mode is relatively simple. But you have three options for how to get the image you want.

Enter a URL of an image on the web

There are several ways to get the URL of an image.

A common technique (shown at right) is to find an image you like on a web page and then right-click (or ctrl-click) and choose an option that says something like "Copy Image Address" then you can paste it into the text box in App Lab.

If you're unsure, you can also choose an option like "Open Image in New Tab" which isolate the image by itself and the URL will show in the address bar, which you can copy/paste into App Lab.

Common Mistake: Using the URL of an image search web site rather than a URL of the image itself.

• Make sure you get the path to an actual image file - something that ends with .jpg, .gif or .png.
• A URL that starts like this: https://www.google.com/search?q=cat&espv=2&biw=1497.... is probably wrong.

Upload your own images

If you have saved images on your computer you can upload them into app lab's asset manager. Just click Upload File and follow the dialogs on screen.

For images the file must be of type: .jpg, .png, or .gif

Once you've uploaded the image then you need to Choose it to set the image to that file. If you add multiple images you'll see them all listed every time you upload a file and you can choose to use any file that you've already uploaded.

Use a Pre-Loaded Icon

App Lab comes with a set of handy single color icons (black icon, white/transparent background) that you can use for buttons or graphics, whatever you like. You can also change the color of the icon after you add it to the app.

The trickiest part is that you need to find and click on the "Icons" tab once the asset manager pops up.

Click Continue to try it!

Student Instructions

Add an Image and Make a Chaser Game!

Now You Try it - add an image to your app and modify the code so that the image jumps around the screen rather than the button. Your little game should have:

• Text on the top of the screen with a title or instructions for what to do.
• An image that "runs away" (moves randomly) based on some mouse event.

Tips: * Hint - the easy way to do this is to simply change the IDs in onEvent and setPosition to respond to the image instead of the button. * Remove the button from the app after the image is working. We don't need it anymore. * Change the label text so that the instructions make sense for your game. * The game is even more fun if you use the mouseover event instead of click

Optional Extensions: * Make the background interesting * Add another image that runs away. * See what happens with the commands hideElement and showElement * Have two UI elements where interacting with one controls or does something to the other.

Finalize your "Chaser Game v.1" and click Finish.

• Note: We'll revisit this game in the next lesson where you can improve it. This is just version 1

Student Instructions