teaching machines

SENG 440: Lecture 4 – Task Scheduling and Activity Lifecycle

February 28, 2019 by . Filed under lectures, semester1-2019, seng440.

Dear students,

Last time we saw how activities and layouts get married and make the screens of our apps. Today, we extend our discussion of both of these big ideas as write an app that shows the time in two different places on Earth. We’ll look at ConstraintLayout, updating the user interface without user interaction, and handling interruptions from other apps.

Before we forget, here’s your TODO list for next time:

Let’s start by creating our user interface.

UI

Our TwoTimer app will show the current time in two different timezones. We’ll follow the same project setup that we did last time. However, let’s go with a ConstraintLayout this time. This layout is the current darling of the various layout managers. Widgets can be anchored to their parent or one another through various mathematical constraints. It supercedes several older layout managers, like RelativeLayout.

Let’s communicate with the user via four TextViews. Two will show the current time, and two will show the time zone. We’ll take these steps to specify the layout:

We’re going to do things a little differently for our Activity this time. To set the content of the TextViews, we’ll write this helper method:

private fun syncTimes() {
  val formatter = SimpleDateFormat("d MMMM HH:mm")
  val today = Calendar.getInstance()

  var timeZone = TimeZone.getDefault()
  formatter.timeZone = timeZone
  zone1.text = timeZone.displayName
  time1.text = formatter.format(today.time)

  timeZone = TimeZone.getTimeZone("America/Chicago")
  formatter.timeZone = timeZone
  zone2.text = timeZone.displayName
  time2.text = formatter.format(today.time)
}

For this code to work, we need our TextViews to be instance variables. Let’s try declaring them and initializing them in onCreate:

private var time1: TextView
private var time2: TextView
private var zone1: TextView
private var zone2: TextView

override fun onCreate(savedInstanceState: Bundle?) {
  super.onCreate(savedInstanceState)
  setContentView(R.layout.activity_main)

  time1 = findViewById(R.id.time1)
  zone1 = findViewById(R.id.zone1)
  time2 = findViewById(R.id.time2)
  zone2 = findViewById(R.id.zone2)
}

This code does not compile. In Kotlin, our variables cannot be declared without also being initialized at either the declaration site or in the constructor. We don’t know how to initialize them until after setContentView, and we don’t really have a constructor.

Maybe we should just set them to null? That’s a very Java-ish idea, but Kotlin discourages the use of null. We’d have to use the nullable type TextView? instead of TextView, and we’d have to use various null-safe operators everytime we invoked anything on our TextViews. A better solution is to use Kotlin’s special lateinit modifier:

private lateinit var time1: TextView
private lateinit var time2: TextView
private lateinit var zone1: TextView
private lateinit var zone2: TextView

As the name implies, we can now initialize these variables later. If we try to read from them before initialization has happened, we get an exception.

Now we just throw in a syncTimes call at the end of onCreate:

override fun onCreate(savedInstanceState: Bundle?) {
  ...
  syncTimes()
}

Scheduling Tasks

This works okay. But the times only get set once, when the app first runs. It should probably get updated more frequently. We could ask the user to force-quit the app and open it again, but we’ll certainly get some bad reviews. Instead, let’s schedule some updates on the event loop that drives our app.

Internally, each app is a sandboxed in a separate Linux process, and each process has a special thread for handling events. This is called the main thread or the UI thread—because many events are driven by the user interface. Internally, this thread follows this sort of event loop:

queue = []
forever
  task = q.dequeue 
  dispatch task

This algorithm is provided by the Looper class, but this is all managed behind the scenes. To get tasks into the queue, we use the Handler class, which talks to Looper for us. We can feed it Runnables to execute immediately or at some future time. Let’s add a Handler and a Runnable that syncs the times and schedules itself to run again:

private lateinit var handler: Handler
private lateinit var updateTask: Runnable

override fun onCreate(savedInstanceState: Bundle?) {
  ...

  handler = Handler()

  updateTask = Runnable {
    syncTimes()
    handler.postDelayed(updateTask, 1000 * 10)
  }

  handler.post(updateTask)
}

The clock will now update every 10 seconds. It’d be smarter to delay our updates by however many seconds are left in the minute, but this is lecture code.

Lifecycle

Suppose that we sync the clock more frequently, like every half-second. And let’s throw this log statement in syncTimes:

Log.d("FOO", "Updating!")

We run the code, and we see a stream of “Updating!”. Suppose now we go to the home screen. What should happen? What actually does happen? The log messages keep streaming. Our app keeps updating its user interface even though it isn’t visible. We broke Edict #2 of the Charter of Mobile Development in Verse, which is:

Do not update a UI that has said goodbye.
Do not freshen a view that has bid you adieu.
Do nothing to a screen that cannot be seen.

Why does this rule exist? Because our mobile devices have limited resources. In particular, we don’t want to run the battery down.

To fix this, we need to carefully schedule and unschedule our updating according our activity’s lifecycle. We’ve already seen one event of this lifecycle: onCreate, which gets called when our app is first run. There are many other events—too many to introduce all at once, in fact. We’ll start with two:

We move our scheduling to onStart in this manner:

override fun onStart() {
  super.onStart()
  handler.post(updateTask)
}

We also remove our post call from onCreate—it happens here instead. Note the call to the superclass method. Most of Android’s lifecycle methods force you to invoke the superclass method. If you don’t, you’ll get an exception.

override fun onStop() {
  super.onStop()
  handler.removeCallbacks(updateTask)
}

Now our app is a team player.

Spinner

If we have time, we’ll talk about one more feature: the Spinner for presenting the user with a list of options. It’s much like select in HTML. We can use it to allow the user to choose the time zones instead of hardcoding them. Let’s also distribute the views out in two spaced chunks rather than crammed at the top of the screen. We start by changing the layout as follows:

Then in onCreate, we populate the spinners with the help of an ArrayAdapter, which we will talk about more later:

val timeZones = TimeZone.getAvailableIDs()
val adapter = ArrayAdapter<String>(this, android.R.layout.simple_dropdown_item_1line, timeZones)
picker1.adapter = adapter
picker2.adapter = adapter

Our syncTimes method needs to pull the time zones from these spinners:

...
var timeZone = TimeZone.getTimeZone(picker1.selectedItem.toString())
...
timeZone = TimeZone.getTimeZone(picker2.selectedItem.toString())
...

Setting up a listener for Spinner is more complicated than listening for button clicks. This is because Spinner demands two callbacks, and a lambda by definition is only a single function. Instead, we create an object that implements the AdapterView.OnItemSelectListener. The syntax is a little idiomatic and looks like this:

val listener = object: AdapterView.OnItemSelectedListener {
  override fun onNothingSelected(p0: AdapterView<*>?) {
    syncTimes()
  }

  override fun onItemSelected(p0: AdapterView<*>?, p1: View?, p2: Int, p3: Long) {
    syncTimes()
  }
}

picker1.onItemSelectedListener = listener
picker2.onItemSelectedListener = listener

This object syntax is the Kotlin equivalent of new AdapterView.OnItemSelectedListener() { ... } in Java.

When we change timezones, we now see the clocks update. Some usability issues remain: there are a lot of timezones to scroll through, and the app doesn’t remember our previous selections. For testing purposes, we can pre-select our timezones:

picker1.setSelection(timeZones.indexOf("Pacific/Auckland"))
picker2.setSelection(timeZones.indexOf("America/Chicago"))

That’s enough for today, however. See you next time!

Sincerely,

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

When the sun goes dark
Will we still need to wear clothes?
Maybe to keep warm