Demo

If you remember, the last studio included a demo of a Bluetooth controlled smart lamp. An App was used to control a variety of features:

  • Set the lamp to a specific color
  • Set the lamp to cycle through a color pattern (and set the speed it changes)
  • Schedule alarms (turn the lamp on/off at specific times)

Objectives

The objectives of today’s Studio are:

  • Continue to refine your understanding of User Interface (UI) development
    • Learn about common aspects User Interface “lifecycle”
  • Improve your JavaScript development skills
  • Work with specific JavaScript Concepts
    • Interact with the DOM
    • Work with Events
    • Practice JavaScript debugging techniques

1. Studio Setup

1.1. Find a Group

Today’s studio will require groups of four. If you don’t already have someone to work with, introduce yourself to those near you.

Special Circumstances: Groups of three

Groups of three will be allowed if:

  • You plan to work with someone who is absent and all members of the group agree to work as a group of three for this studio.
  • There aren’t enough people present to form groups of four.

In groups of three the Manager must also take on the responsibilities of the Spokesperson.

1.2. Role Assignment

Each member of the group should pick a specific role (Manager, Technician, Recorder, Spokesperson) and the role should be different than the role selected last Studio. Each role has some specific responsibilities for the work, but everyone is expected to contribute to discussions and exploration of concepts.

When you get your role, read it over and make sure you are aware of your responsibilities.

1.3. Studio Distribution

As in the previous studios, all group members will need to be in a GitHub group (and repository)

  • The group’s Manager should create the repository. The GitHub group name should include the surnames of all group members.
  • All other members should join the group.

The link for this studio is: https://classroom.github.com/g/Oo9UM2PN

Today both the Recorder and Technician will want to be able to work with the repository (i.e., it should be on at least two computers). The Technician will be working with JavaScript (and HTML+CSS). Chrome and Firefox have developer tools that are slightly better than Safari’s for today’s Studio, so the Technician should probably have access to Chrome/Firefox.

1.4. Recorder

The Recorder should update process/Roles.md to record everyone’s roles for this studio (use full names). In addition, the Recorder should take notes about the interaction of the overall session.

1.4. Prep Debrief

The Technician should read the questions in process/Debrief.md to the group, the group should come to a consensus for each, and the Technician should enter the summary for each question.

2. Studio: JavaScript and UI Behavior

Today’s studio uses Google’s Material Design Lite (MDL)for styling. MDL was chosen because:

  • It’s responsive and mobile friendly
  • It has a contemprary look and feel
  • It’s open source

Today’s Spokesperson should open the page for Material Design Lite and review it with the group.

Material design just provides CSS styles, it doesn’t help manage the behavior of the user interface.

Outside libraries, such as Angular, React, and Vue, are often used to help manage all of the complexity of user interface’s behavior. Use of such libraries isn’t needed for this course, but today’s exercise may give you some insight into a few of the details often handled by such libraries.

2.1 Understanding UI Lifecycle Events

Applications, including user interfaces, have a “life cycle”. For example, if you’re interested in developing an iOS app, you may use elements of the View Controller Lifecycle to ensure your app is always handeling displayed data correctly.

This class works with relatively simple types of applications and the life cycle elements of interest are often just:

  • Things to do when the application (as a whole) starts
  • Things to do for each screen:
    • Set it up before it is displayed
    • React to changes while the screen is displayed
    • Tear it down when leaving the screen (save values or pass them to other screens)
  • Things to do when the application (as a whole) is done

Use your web browser to open the mainLightUI.html file and examine its user interface. You may notice that you can interact with a few of the UI elements, but that the overall behavior is incomplete.

2.2 App Description

Note that the App is divided into two tabs.

2.2.1 Basic Tab Behavior

The Basic tab provide basic controls for the app.

  • It will allow users to see the current color of the light (in a small blue rectangle to the right of the “Current Color” label).
  • It will allow users to slide the slider bars to pick different colors. As the bars are moved, the combination of the three colors wil be shown in the box with the “Target Color” label, which is red initially. Sliding the bars also updates labels to the right of each slider with values from 0-100 indicating the amount of the color to be shown. Note that this is a convenience for regular users, but internally the light uses RGB values, which range from 0-255. Consequently, the value from the slider must be scaled.
  • It will allow users to set the color via the Set Color button, which will transfer the target color to the light.

Complete README.md Q1.1-1.2

2.2.2 Settings Tab Behavior

The Settings tab will allow users to enable and disable the lights ability to automatically turn off as well as configure the time until it turns off.

  • Like the sliders for color, the value of the slider is shown to its right. In this case it also includes a unit (s for seconds)
  • If the Auto-off feature is disabled, the slider will also be disabled. When the Auto-off is enabled, the slider should be enabled.

Complete README.md Q1.3

2.3 App Behavior Investigation

Review the source code provided in lightBehavior.js, but do not reload the page or test it.

Complete README.md Q2.1-2.3 prior to proceeding

2.4 Load and test the page

Try the page out. If you notice any problems or errors, use some common JavaScript debugging techniques:

  • Open the developer console in your browser. It is usually the best place to identify syntax errors that may undermine page loads.
  • Other syntax errors, like bad variable names, often only show up when the relevant code is run. Keep the console open and test out the completed portions. Fix any run-time errors that show up.
  • You can dynamically interact with variables in the JavaScript console. For example, this code uses a variable named redSlider and redLabel. Try typing the following into the console:
    • console.dir(redLabel) and then expand the details to see all the fields of the redLabel element. console.dir isn’t completely stanardized, but in most developer tools it will allow you to examine the details of an element.
      Developer Console dir()
      Then:
      Developer Console dir()
    • The JavaScript console will often also help you autocomplete, which can help you spot a correct field value. Try typing redLabel. and review the list of suggested options.
    • console.log() can be used in much the same way as println() and System.out.println() for log-based debugging. It can help you understand the execution of your code.

2.5 Fixing the Prototype

For the remainder of this Studio you need to modify and complete the JavaScript. (You should NOT modify the HTML in any way. All behaviors and initial values should be handled by JavaScript alone)

Complete the prototype so it:

  • Supports the behaviors described above (there are some TODO notes in the JavaScript that provide some guidance)
  • All values of all screens are consistent when the page first loads

Review your code and try to simplify and consolidate it as much as possible.

3. In-Class Checkout

Commit your work to GitHub:

  • The Recorder should complete changes, save them, commit them locally, then push to GitHub using GitHub desktop.
  • The Technician should save any changes, commit them locally, use GitHub desktop to Pull and merge any changes to the repo, and finally Commit/Push the additions back to GitHub.
  • Verify your commits from both Technician and Recorder on GitHub
  • Show a TA your progress

4. Post-Class Checkout

Complete any unfinished work and commit it to your repo by 11:59pm Sunday.