SENG 440: Lecture 4 – Task Scheduling and Activity Lifecycle
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:
- Read Understand the Activity Lifecycle.
- Create a new Android Studio project for your term 1 project and push it to your remote repository. Follow these instructions to connect your local project to your remote repository, but use your personal remote URL:
https://eng-git.canterbury.ac.nz/seng440-2019/USERID
If you run into trouble, which is likely, please report it on#general. - On a quarter sheet of paper to be turned in at the beginning of the next class, draw your own version of the activity lifecycle state machine, using your own words to describe the system events or user actions that trigger each transition.
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:
- Add four
TextViews. Name themtime1,zone1,time2, andzone2. - Increase the font size for the times by setting
textSizeto36sp. - Increase the font size for the zones by setting
textSizeto24sp. - Constrain each text view to the left and right margins of the parent.
- Constrain the top of
time1to the parent’s top. - Constrain the top of
zone1to the bottom oftime1. - Constrain the top of
time2to the bottom ofzone1. - Constrain the top of
zone2to the bottom oftime2. - Push the second pair of labels down a bit by adding a bias of 64 on the
time2–zone1constraint.
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:
onStop, which gets called right before an activity becomes invisible. In this method we persist data and turn off any view-dependent recurring actions.onStart, which gets called right before an activity becomes visible. The UI will already have been laid out by some past call toonCreate. Here we schedule any view-dependent recurring actions.
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:
- Delete the time zone
TextViews. - Insert two
Spinners in their place. - Insert two guidelines at 33% and 66%.
- Constrain the widgets to the guidelines.
- Initialize instance variables in the activity.
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!
P.S. It’s time for a haiku!
When the sun goes dark
Will we still need to wear clothes?
Maybe to keep warm