We have growing interest in our App Dev program. At the moment, I have 33 students learning App Dev in my capstone class and another 27+ working with us outside of school. It's pretty cool. At the moment, I have more students wanting to learn than I have MacBooks available.
It's amazing what happens when you give students authentic problems to solve. They are learning App Dev through working on real projects for our school and community. We are still using the Everyone Can Code materials Intro to App Dev with Swift and App Dev with Swift. I'm pretty excited.
0 Comments
For the last couple of years, I have been incorporating iOS App Dev in with my capstone engineering class. There are two tangible goals for doing this. 1) I want my students to be comfortable with and have a strong foundation in programming. 2) I want my students to also spend more time focusing on the end user experience. These two goals are very important for future engineers in any field. I use Swift for all of the reasons I have stated before. This summer, I got an email from one of my students who just graduated a few weeks earlier. He had landed an internship with a software development company out of Houston. Austin lives in the Dallas area. Not only did they hire him to work in their iOS department, but they let him work remotely from home. He was super excited. Here's a part of the email from him. "Anyways, I can't thank you enough for helping me grow throughout this year and making swift mandatory. I honestly couldn't have done it without you. This is a huge opportunity that I wouldn't have even imagined a year ago." Needless to say, I am super excited and proud of what Austin accomplished. He developed several features for a specific app the company developed. He learned several new APIs and iPhone features such as Touch ID. He said it was a real challenge, but he was up to it.
The Everyone Can Code curriculum along with Swift make it possible for teachers to provide the ability to take advantage of opportunities like this when they arrive. I can't promise any of my students what opportunities will come their way. All I do is give them the tools to be able to take advantage of the opportunities that present themselves. I get asked by students and others all the time why I chose to go with iOS App Development in our engineering program. The answer lies in how well Apple has embedded crucial conversations into the process. I can't do a mediocre job, much less good job, of teaching iOS App Dev without putting time and effort into important topics such as accessibility, privacy, and security. The very nature of iOS and Swift require these conversations. All too often, we see these issues come up in the news and conversations. Privacy and security are major concerns for everyone. Accessibility should be as well. It is too easy to develop for other platforms and languages and never talk about it. I've read stories about how coding bootcamps do a great job of teaching coding skills, but never talk about these issues. Consequently, new programmers leave huge holes in their applications without realizing it. As a high school technology teacher, I feel it is my duty to teach about all three: Accessibility, safety, and privacy. These topics bring up great conversations. When we discuss them, it really makes the students think and look at the world through a different lens. We have the opportunity to see the doors that accessibility opens up for people. It may be the first time my students really thought about it. On the issues of safety and privacy, my students get a look at what it takes to make our services secure and the responsibilities that get overlooked all too often. I can't control what my students do when they leave, but I can make sure they have thought about these very important topics in their lives. I know that these discussions and my work with iOS App Development makes a difference. I see it in my students' work. They are now putting subtitles and clearer dialog in their videos. They are using better color palettes in their designs. And even bigger, they are taking on projects that open up doors to others in our community. I have a student working on an app to help our special education department. It is a communication aid to help students better communicate what activities they want to do. I have another group of students taking on a project to make announcements and other verbal events more accessible to those that are hearing impaired. As a teacher, I cannot choose the route my students will take when they leave my room. All I can control is the opportunities for discussion, learning, and exploration while they are in it. Making sure that accessibility, safety, and privacy are part of that conversation is critical to helping students becoming successful adults in the 21st century. The Unit 2 project is an app called Apple Pie. It is a friendlier version of hangman where no one dies. The project itself is a guided project that leads learners to a basic, working iPad app. I am giving minimum acceptable credit for learners completing the project. In it, there are some new skills being learned. For more credit, learners have to customize and improve the UI and gameplay code. The challenge has been accepted by them. I have seen some really great things. Most exciting of all is that the learners have pushed into new ground to get their app done. We have multi-screen apps with multiple levels, adjustable lighting (light/dark schemes), challenging point schemes, and a whole host of new graphics. It has been fun to watch them push the boundaries of what they know in pursuit of making a better game instead of chasing a game. I'm behind in my blogging. That's all my own doing though. I have set the pace for my students, but I am allowing them to make mistakes. The main mistake is not paying attention to their time management. I am letting the pressure of the closing semester and their parents hammering on them be the punishment. I am not using grades as a disciple tool. See my blog post in the STEM Toolkit Blog for more on that.
Anyway, I have been doing a lot of going back and assessing old assignments and fixing the grade book and such. It is keeping me busy. But, I believe it is right. Anyway, enough about that. Here is where we are at right now. We are about halfway through Unit 2. Things are getting hard. Interestingly enough, my students thought they were being creative and it is starting to catch up with them. You see, I have all of the assignments in Schoology. They turn them in and I assess from there. I don't check every page of the labs. Only some key pages. to catch up since they are behind, many of the students are only doing the pages I am checking online. When we got to Unit 2 Lesson 3, I started checking the actual code on their computer. I also asked some questions and looked at other pages. I am still not requiring them to do everything, but I am asking about it and pointing things out. 2.3 gets into structs (structures) and making custom types. I had them turn in a screenshot of page 10. But they had to have the lab checked by me in person. Pretty much from here out, they have to talk to me. I have questions and want to be able to help them with small things. Page 10 deals with static variables and static functions. It creates great conversations that are better held in small groups or individually. I also flip over to page 7 and look at the property observers. Most of the students haven't done it. I have been making sure that everyone is aware that I am not going to count off or require them to do it, but... I did point out how property observers are part of good coding and makes their lives easier. The last several days have been a succession of 1-on-1 conversations as they work to understand it. I love it. They are on their way to becoming self-motivated learners. It is keeping me busy, but that's the way I designed it. We did the Unit 1 guided project, Light, today. I had a blast. The students did as well. Several are working to get it on their phone. I am making them work through how to do it on their own. The goal is that they get familiar with looking up developer things like that. If they are going to take the initiative here, then they are more likely to make their own app and see it through to the end.
As always, I brought up a student to "drive". I was able to move around the room and help out people who needed it. The first thing that way too many people needed was for me to read their code and figure out where they messed up in typing it. They were trying to be too lazy to even look at the iBook guide. That didn't last long. I showed them all how to use the multiple desktops and move between them to make it easier to look at both the book and Xcode. Sadly, most of them had previously turned in their school iPad and it is biting them back now. The consistent errors by students were:
All of these gave us great opportunities to work on our debugging skills. When they came up, I worked with the student who was stumped to learn what the editor was telling them. Then I had my student at the presentation station recreate the error. We went through how to read and understand what they were looking at and why. I was really excited because my 6th period class wanted to try some things out along they way. They wanted the app to start out black instead of white. This led us to great discussions. It also gave me the opportunity to point out how they can change up the projects as they wish as long as they demonstrate the core concepts the project or lab is getting at. I'm all for them doing things differently as long as they learn it and can explain it. We finished up Unit 1 yesterday. It was a lot of fun getting into Xcode and doing "stuff". Again, I brought up one of the learners to drive on the overhead. This gave me the freedom to move around the room and help people out.
The last lesson, Lesson 8 went over the basics of Xcode. We had fun with it. We explored the Xcode IDE more and put in a button. They were having a lot of fun with adjusting colors. Several questions came up organically. Things like the "!" at the end of the @IBOutlet line, lining up objects on the storyboard, why it crashed when they deleted and reentered an outlet or action, and why the button didn't line up correctly in the simulator. It was great. Everyone had a really good time getting into Xcode and seeing an app come alive. They are all starting to get the hang of Swift and the syntax. They are loving autocomplete and the Interface Builder features were a hit. Last year, they had to create, configure, and arrange any buttons or objects all in code. Now, they can focus more on logic and making better applications. Monday, we do the Light project. We moved quickly today. In class today, we covered Lessons 1.5, 1.6, and 1.7. It wasn't by design. The lesson just went that way. I started in on Lesson 1.5. This was the first time we were doing a lot on Xcode and Playgrounds so I started in with letting the learners drive. Up to now, I was only showing quick snippets straight out of the iBook. It was all in a playground and very simple. These were demos and gave us the ability to compare Swift to Processing (which they learned last year). Today, we got to go deeper and start exploring. I brought up a student and had them plug their MacBook into the projector. The reasoning is that I know the material better than they do at this point. I will just naturally go faster than them. This isn't fair to learners just getting started. by brining up a student to drive, the pace is naturally slowed down to the pace of the class. I can't go faster. I'm not driving. Lesson 1.5 gives an overview of Xcode. The class was a bit overwhelmed at first. There is a lot going on. I explained some of the important things and showed them the things they needed now, like how to open and close panes. I also introduces them to some of the file types they will deal with. All to just give them some bearings to the environment. All of it is in lesson 5. I even had them change to presentation mode so can get more comfortable with controlling their environment. After a little explaining on what they were looking at in the ViewController.swift file, we played with the array error example from Lesson 5. About halfway through, I wanted them to see it in a playground. I messed up and just had them open a new playground file from the drop-down menu. (I'll explain how I messed up later). We did the example where the array constant is built with 2 elements. Then the .removeFirst() method is called on it 3 times. In the middle, we also printed to the console. I wanted them to understand what was really going on in each line. It seemed to work. The concept of the array and calling the method seemed to work. We closed the file and went back to Xcode. We put the same array exercise in and looked at how the errors worked in full Xcode. It crashed like it should have. I used this moment to show them how the debugging tools are just like LabVIEW. They were happy to use learning that they had gained in prior years. We put in a breakpoint and stepped through the code to the error so they could at least see that support is there. I'm quite sure they will all forget about it tomorrow. But, hey, they are teenagers. That's why we have lessons that build and spiral. When we deleted the code and tried to run the simulator again, it still crashed. Turns out that the code we put in the playground ended up finding it's way into the AppDelegate.swift file. That's my mess up I mentioned earlier. I tried several times to recreate it at home, but could not. Never mind the fact that it happened two classes in a row today. In this, we did some looking at the debugging window and the clues it gives us on errors. This doesn't come till Lesson 6, but we were on a roll. We did some more digging around what was being given in the basic template. We ran the simulator and talked about the million dollar flashlight app from the first iPhone. Then we talked a little about the two functions that showed up. I jumped to lesson 7 this time without a pause. We started looking at the documentation a little. We made comparisons to LabVIEW this time. They liked having the help right there at there at their fingertips. When I went back to the iBook, I realized that we had jumped right through lessons 5, 6 and 7. So I just went for it. I brought up a new student to drive and we did the Lesson 6 Lab together. It gave us great discussions on the errors, memory management, and how Xcode is set up. We finished up a few details from Lesson 7. I turned them loose on completing the Lessons 1-5 assignments that we didn't do together. Thursday, we move into Lesson 8. We should be doing the Light project on Monday. Today we moved to 1.4 and dealing with control flow. Talking about IF-ELSE statements. They liked that it was so much simpler and more expressive than other languages. We also delved into switch-cases. My java programmers were noting how they didn't have to "break out" of the case when it ran. Swift is so nice.
I have also been hammering on some who are behind. Today, we started something new - Mandatory Tutoring. Those behind will have to come in twice a week before school to work until they are caught up and no longer behind. I don't want them to hope they catch up and never get there. By putting in specific days and times that they have to be in, along with a plan and order for materials, we will get there together. After this announcement, I got a lot of late work in. Yay! Tuesday we do our first app in Lesson 1.5 We did Lesson 1.3 today. I was planning on moving to 1.4 today as well. Unfortunately, many of the students were not making use of their time and had gotten behind. I've been notifying their parents on it. I give students four days to make up late work with no penalty. I want them to learn the material more than I am concerned with grades. To that end, I decided to let them use the last half of class today to get caught up. Most of them made good use of the time. Many have moved ahead to lesson 1.4 on their own. Yay.
|
About this blog pageThis is my blog covering the activities and results from my work teaching App Dev with Swift. Archives
February 2021
Categories |