Tonight we will meet in the boardroom in 25N.
This is our last working meeting of the 2017-2018 school year!
We will discuss our weather wear project and what the next steps should be, including deploying to azure and providing a web API endpoint to the Swift team.
We can also discuss plans for next year – schedule, meeting room, etc.
We will also continue with gadgets:
- Playing (i.e. shooting holographic bugs) with the Hololens
- Arduino projects
Tonight we will meet in the boardroom in 25N for more gadgets!
We will break into small groups:
- Playing (i.e. shooting holographic bugs) with the Hololens
- Arduino projects
April is ‘Gadget Month’!
Tonight we will kick off Gadget Month with a little Arduino programming as well as some fun with the Hololens. Tonight, we will play a little RoboRaid!
For Arduino programming, we can either use the online IDE or the desktop IDE – find them here: https://www.arduino.cc/en/Main/Software
We have a few Arduinos with added hardware, such as Snapino.
We also have two Awesome Shields. Here is a video of what is possible with the Awesome Shield:
Looking forward to our meeting tonight!
Tonight’s meeting will focus on continuing the development of the WeatherWear Web Service and the Swift app to consume the Web Service.
Notes on Swift String Interpolation Issue with Optional variables:
String Interpolation in Swift: the term “string interpolation” refers to creating a character string that pulls values out of one or more variables and combines those values with other characters to form a string. The entire expression is enclosed in double quotes and each variable within the string is preceded by a backslash and enclosed in parentheses. Example “Hello \(name)” will print “Hello Gandalf” if Gandalf is the value in the variable name.
Optional Variables in Swift: Swift is strongly typed and insists that if there is a possibility that a variable (or constant) may not have a value at some point when the program is running, then it must be declared as optional. The variable may then either contain a value of the declared type or may be nil. The purpose is to avoid the null reference errors that can occur in other languages when someone tries to use a variable without a value. Declare a variable as optional by putting a question mark at the end of the type such as our WeatherForecast:
var forecast: WeatherForecast?
When using the values in an optional variable, the variable needs to be “unwrapped”, like removing it from a box. Consider a cardboard box labelled “Weather Forecast”; you can open it up to find a forecast object or you can find nothing, so you can’t treat it as if there is always a value there. There are several ways to unwrap and to check what is in the box, but for this problem we will force unwrapping explicitly.
The Problem with String Interpolation with Optionals:
When we tried to display the temperature in either Fahrenheit or Celsius by drilling down through the many nested levels of objects in our WeatherForecast we were getting this warning and the text on screen was gibberish:
The fix is to explicitly unwrap the values at each object level by putting an exclamation point in place of the question mark in multiple places, i.e., after each object name within the long nested object:
Jellyvision Field Trip Debriefing
Last Friday, on a day off from school, 9 of our members enjoyed an amazing day at Jellyvision, getting an inside look at what it is like to work at this tech company in a very wide variety of different roles, technical, business, and creative. Many of the brilliant and talented people at Jellyvision gave their time to make this a very special event for all of us. Kate from Jellyvision will be attending our meeting this Friday and we will have an open discussion about the experience and insights gained. How were you inspired? What did you learn?
Continue Developing Web Service and Client
We will work in our Web Service and Swift teams to continue developing the Weather Wear Service and the Swift client app to send a request to the service and display results.
Some notes on what we have so far in our Swift Client:
Consuming a Web Service in Swift
We will meet at our usual time and place: 5:45 PM at 25N Coworking
Finalize Plans for our Jellyvision Field trip!
Continue working on our multi-component Weather Wear software :
Review overall solution architecture:
- Lucid Chart diagram by Robin
C#/Swift Tutorial: Learn/review some object-oriented concepts
- Classes and Objects: Properties (values) and Methods (behaviors defined in functions/procedures)
- How are they defined and used in C#? In Swift?
- Objects as Models for Data:
- What is the data model for the JSON returned from the Weather Underground API Request for the Forecast?
- What is the data model for the JSON returned from the API of the WeatherWear Web Service we are building?
- Can/should the WeatherWear data model inherit the Weather Underground Forecast data model?
Web Service Team:
- Merge Web API code with the GitHub Repo
- Continue work on algorithm and implementation of the WeatherWear Web Service and the console app to test it
- MVC: Model/View/Controller design pattern
- Model represents the data model defined in a class; we will create a model class for the Weather Forecast, and later for the WeatherWear API Response
- View is the Presentation Layer, i.e, the screen the user sees
- Controller: Code that handles the user input, talks to the model, handles interactions between Model and View. In Swift, we will define a Class for the controller; there will be a ViewController Class defined for each View
- Review/Learn how to connect UI elements to code. Elements in the UI designed on the storyboard need to be connected to code in the appropriate controller:
- @IBOutlet: in a code module, an Interface Builder Outlet is a variable that holds a reference to an element on the storyboard. Example: our screen has a label to display a city name and we need our code to be able to access it. We add this to our view controller:
@IBOutlet weak var cityLabel: UITextField!
- Start setting up the code to send the Web API Request for WeatherWear
- We will initially set up code to access the existing Weather Underground Forecast API
Take a look at our updated “Why” Page
Check out the updated list of summer opportunities and more….
Planning Session for multi-faceted solution
Tools: Depending on what components we decide to develop, we will identify which software tools are needed so that we can get everyone started on setting up their laptops as appropriate. Some of this configuration may need to be done later at home.
Setting up for iOS Development on a Mac with XCode/Swift:
Please bring your iPhones and/or iPads to the meeting along with their USB cables so we can connect it to the Mac to run Swift apps.
We will be coding in pairs or small groups so even if you don’t have your own Mac you will be able to do everything.
To Set Up a Mac:
- You will need an Apple ID, which you probably have if you have ever downloaded anything from the App Store
- You do not need a paid Apple Developer ID at this point; that will only be required if you want to put your apps in the store
- From the App Store download and install XCode
iOS Apps with Thunkable
We will take a deeper look at building apps with Thunkable, perhaps doing a simple prototype for part of the multi-project solution we are designing
Mobile Application Development Starts this Month!
Join us as we learn to build applications for our phones and tablets. We will be taking a look at all this over the next couple of months:
Tonight we will build apps for iOS mobile using Thunkable! So please bring your iPhone or iPad to the meeting.
First a little overview on Mobile App Building…
- Programming Languages depend on whether you are building the app for an iOS device or an Android device
- Native programming languages are the coding languages understood specifically by a target operating system
- Swift or Objective-C for Native iOS apps: requires a Mac to build and test; Objective-C is very old and Swift is much more widely used now
- Java for Native Android apps: can be developed on Windows or Mac
- Cross-Platform programming builds apps that work on both Android and iOS devices and more
- Xamarin provides developers with a full-featured IDE for building apps in C# that can run on Windows, iOS, and Android devices. The coding can be done in Visual Studio for Windows or for Mac but the iOS apps do require connection to a Mac for building
- Drag and Drop App Builders with coding blocks: Drag and drop UI components (buttons, images, text, etc.) onto a mockup of the phone’s screen; then use the blocks editor to build your program’s code by drag and drop as well. Behind the scenes the blocks are compiled into the native code that is understood by the target device.
- MIT App Inventor currently provides only Android builds but they are in the process of developing iOS capabilities too
- Thunkable allows you to choose either iOS or Android coding environments and that is what we will use today to make our apps!
Now Let’s THUNK!
Install Thunkable Live on your iPhone or iPad: go to Apple’s App Store and get the Thunkable Live app. You will use this to test your Thunkable apps as you are developing them
Start up Thunkable: Supported Browsers are Chrome, Firefox, and Safari. Go to Thunkable and get started by clicking the “Get your App Started” button; when prompted “I want to create apps for” select iOS
Logging into Thunkable: use your Google account to register and sign in
We will do the five introductory tutorials together to get familiar with the interface and some of the functionality:
Thunkable Hour of Code Tutorials
Build and modify a Weather Forecast Application!
In the Thunkable Documentation click the Sample Apps link and find the Weather app. Click “Copy the app source code” to create a copy of the app in your own Thunkable iOS projects.
The weather app is an example of using a Web Service; we will look at this in more detail and together will figure out how to modify the app to show the weather in our own location and perhaps to display additional information.
NOTE: Our December 1st meeting will be held at the St. Charles Public Library. We will meet at the usual time 5:45PM to 7:45PM
- Fix the Jelly Wobbly Gravity game! With the book’s original code, the character won’t move…the jellies are all dropping in the same line and splattering before hitting the floor…the character isn’t able to get sick from the jellies because the “collisions” have no effect. Let’s help The Dude enjoy (or not) his fill of jellies!
- Make your own changes to any part of the game and/or to your site’s home page
- We can do some changes as a group if there are suggestions and desire to do that
- We can help each other with updates to individual pages
- Click the “Raw” button when viewing the file
- Right-click and select “save as” to save it to your machine
Detailed notes for the debugging exercise and concepts:
A working version of the game: Jelly Gravity
Tonight’s meeting will be a feast of engaging presentations by:
- Our first tech talk of the year!: Erin Maresko, who designed our FVGCC branding, will give us her insights on technical design
- Our very own Hackathon team: Our members who participated very successfully in the Huskie Hackathon at Northern Illinois University will share their experiences and demo the results of their all-night programming efforts
- Our very own instructor: Robin will give us a mini-version of her presentation for Fox Valley Computing Professionals on Cross Platform Mobile Development with Xamarin