teaching machines

SENG 440: Lecture 24 – Finish

Dear students,

Today we wrap up our course. Let’s recount what happened this semester. In week 1 we examined Kotlin, a language that many of us hadn’t used before—myself included. It seemed like the right thing to do, and that decision was recently validated by Android chief advocate Chet Haase at Google I/O:

We’re announcing that the next big step that we’re taking is that we’re going Kotlin-first. We understand that not everybody is on Kotlin right now, but we believe that you should get there.

If you’re starting a new project, you should write it in Kotlin; code written in Kotlin often means much less code for you—less code to type, test, and maintain.

In week 2 we explored the cornerstone of interactive apps: the Activity class. In Moarse, an app to emit Morse code signals, we wired up our first buttons and lambda callbacks. In TwoTimer, an app for showing the time in two different timezones, we explored scheduling tasks with Handler and ways of making our activities aware of lifecycle events so that they don’t forget who they were before the screen rotated or the language changed.

In week 3 we saw how our apps reside in a large service-oriented ecosystem. In Connect440, we assembled our first list and used implicit intents to trigger other apps to email, call, or map a classmate. For your information, this was also the day that the projector kept flickering on me. In Kana-san, a flashcard app for learning the two Japanese phonetic alphabets, we built our first app with more than one screen, which we reached via an explicit intent.

In week 4 we had our first look at persistence. We wrote Is Kitten, a game that has the potential to model the entire world in a dichotomous key, which we wrote to internal storage. We also started our work on Lately, an app for showing the latest headlines. The headlines were fetched from the NewsAPI web service, giving us our first taste of connecting to the web. We saw that we can’t issue network requests on the main thread, so we conjured up an AsyncTask.

In week 5 we discussed a pillar of mobile platforms everywhere: the list view. Because our collections can grow large and have complicated views, we saw how lists can impose a view holder pattern separating allocation of views from the population of their content. We added a RecyclerView to Lately. Then, in order to implement a master+detail UI pattern, we explored fragments as a way to form reusable portions of user interface.

In week 6 we examined managing resources that were sensitive to a device’s screen size, orientation, and language. We put Lately to bed, thank goodness, and moved on to dealing with media. We built Rattler to let the user compose RTTTL ringtones and used MediaPlayer to play them.

In week 7 we looked at object-relational mapping tool Room to bridge between a database and Kotlin. We extended Rattler to persist a collection of songs to a local database. In our last meeting of term 1, we used the alarm and notification system to send periodic reminders to the user. We started building Backlog, an app for taking daily pictures.

Then we all went on break. I saw glow worms with my family. My youngest children got car sick. I had a crisis that caused me to restructure the lectures to be more about the code that you write.

In week 8 we acquired images from the camera and image gallery. We used FileProvider to deal with the security issues of sharing resources between apps. That rounded out our Backlog app—which I have been using when the notifications work.

In week 9, we sensed the world. We wrote Lonely Phone to cry for help when the gravity sensor says that gravity is up or down. We wrote Hideaway to pin a hidden message to a geographic location and located our device with GPS to determine if we could unlock it.

In week 10, we connected devices to one another in P2Piano. This app presented a shared piano to two users connected via Google Nearby. We also touched upon multitouch, writing Lots, an app for randomly choosing one of many possible fingers that are touching the screen.

In week 11, we explored scaling and panning the interface with gestures. In Recog, we gave the user an anagram to solve and then listened for their response using speech recogniton.

In week 12, we had our first look at the new CameraX API to write Two-Face, an app for taking split-screen images. We are probably one of the first mobile development courses in the world to have used CameraX. Because, my friends, this stuff moves fast.

Many of these lectures ended with apps in semi-broken states. This is a problem I have. My dreams continue to not fit in my allotted time. The good news is that working versions of all our apps are available on GitHub:

For our final exam, you will be asked to implement a collection of tasks common to Android app development. In particular, you will be given a video of me interacting with an app, and you will reverse engineer what you see as you recreate that app. I’d like to hear from you what you think every Android developer should be comfortable doing quickly and routinely. Together we will generate a list of features that you can expect to see on the exam.

Across our two terms together, we wrote apps that fit the culture of mobility that we described in the first lecture.

  • Our apps are casual, designed for informal and interruptible use.
  • Our apps are paranoid about getting disrupted, so we persisted our data.
  • Our apps are personal, managing our own data for daily living.
  • Our apps are social, connecting us to friends and those around us.

In what you would call year 6, my social studies teacher Mr. Schmidt told us that he teaches life skills, and that social studies is only his vehicle. I suppose my vehicle is computer science, but I’m not quite sure what I teach. If I had to settle on a single big idea that motivated my design of this course it would be this: build stuff for yourself.

This sounds selfish. Really, it’s a reaction to the capitalistic tendencies of our industry. Many of us will get jobs and work on business products. But business is only one dimension of our lives. We need apps that go with us when we tramp, to entertain us at bus stops, and to bind us to family and friends. Because our devices are with us and connected to us, it’s easier on mobile platforms to build software that reaches into the small parts of our day, to affect individual humans and their emotions.

I encourage you to use the skills that you’ve acquired in this course to make things for yourself and your communities.

See you at your demos!


P.S. It’s time for a haiku!

Not money, not stars
My app’s greatest achievement?
When Mom installed it


Leave a Reply

Your email address will not be published. Required fields are marked *