30 KM/s

Today I went to Coding Lab to troubleshoot the logic roadblocks I was having with last weeks homework. Vince helped walk me through how @State & @Bindings were working in the Mobile Lab Game Kit.

We specifically walked through how avatarPosition was working across views since its needed across all layers. He mentioned how part of the magic that SwiftUI allows us with this system is that when the code goes to $avatarPosition to update the state it won’t get stuck in an infinite / recursive loop.

We then took a look at my app concept of navigating over clouds to reveal cloud names. he suggested approaching it in 3 steps:

1.  collisionObject 
   1. that you would need to change the let to a var to allow for flexibility in the target size / shape. With the change from the finite let to the versatile var, we can now target that the size variable would need to become 2 different variables: sizeHeight & sizeWidth since in the example the trigger is a square and only needed one dimension repeated twice.
2. contentView 
   1. Vince then walked me through the simple logic to toggle the background (shifting the color), and that the logic would be the same for switching out images. He created a helper function that is an if/else statement and then called it in the view.  He also reiterated how you cannot declare a function inside a view, that view only wants to deal with things that make instant changes to the canvas. So where calling a function in view would shift the canvas, the process of declaring it doesn’t return anything, therefore would return an error if in view.
3. Thinking about restrictions in position ( >&< ) logic to create rollovers  
   1. that in the example we did in coding lab, we only restricted in 1 direction, in order to achieve a rollover would need to restrict in all directions

This week we were to review the Cheat Sheet made by Nien & Sebastian. As well as create 1 controller that outputs a signal and 1 visualizer that processes the signal. “You can think of the controller as something with buttons, knobs, etc. and the visualizer will be like a processing sketch which updates based on the signal.”

Inspired by things like this:

Code Examples: 

The signal will have 3 components contained in a struct. Note the allowed ranges:

struct Signal {
    // Range: 0 - 10
    var intValue: Int    // Range: 0 - 1.0
    var floatValue: Float    // True or False
    var toggleValue: Bool
}

The Main Tester code will look somethings like this:

import SwiftUIstruct Signal {
    // Range: 0 - 10
    var intValue: Int    // Range: 0 - 1.0
    var floatValue: Float    // True or False
    var toggleValue: Bool
}struct ContentView: View {
    @State var signal = Signal(intValue: 0, floatValue: 0, toggleValue: false)    var body: some View {
        VStack {
            NiensController(signal: $signal)            Spacer()            NiensVisualizer(signal: signal)
        }
        .frame(height: 700)
    }
}

Deliverables: 

Before the start of next class, please Slack Sebastian and I directly with your 2 files and any required assets. We will take everyone’s controller and visualizer and wire it up to a master app allowing us to mix and match everyone’s components.

A controller file with your name. e.g. NiensController.swift

struct NiensController: View {
    @Binding var signal: Signal    var body: some View {
        //
        // Add your buttons, knobs, etc. here.
        // Update signal appropriately.
        //        Text("Controller")
    }
}

A visualizer file with your name. e.g. NiensVisualizer.swift

struct NiensVisualizer: View {
    var signal: Signal    var body: some View {
        //
        // Create visuals/animations here.
        //        Text("Visualizer")
    }
}

• Views should be no larger than 400×400
• If your views require image/audio/video assets, please send those along as well.
• Be creative with your design. Think about how standard buttons and sliders can be mapped in fun and novel ways.
• Consider using a timer and/or randomizer to modulate the signal over time.
• You may or may not require some internal @State for your component views based on their complexity.

Cheat Sheet Concepts