ECS 189E: Android and iOS fundamentals

The ViewController lifecycle

Sam King

11/19/2019

Administrative

Last time: GCD

This time: ViewController lifecycle

Next week: ???

​

This is our last technical lecture where I will quiz you

Administrative

One quiz left, will be hard but count the same as the rest

• Expectation: you should be spending a lot of time on your project

​

Milestone 2 meetings on Thursday

• Turn in your sprint planning, we’ll use it to take a peek
• Make sure that you have answers to anything that I asked you to follow up, we’ll “close the loop” in that meeting

Administrative

Meetings with mentors -- are they happening?

• Networking is important!!!
• Don’t ask them for help debugging!
• Do build rapport
• Do get their perspective as practicing engineers

​

Please do switch with groups if you can

Administrative

Submitting to the app store, why you should do it

• Unique learning opportunity
• How often can you have family download an assignment!
• Extra help -- in class meetings on December 3rd reserved only for groups trying to submit to the app store

Developer licenses -- we have some available

• Just to be clear, there aren’t any groups signed up for this yet as far as I know
• Please reach out explicitly and setup a written plan by Thursday at the latest

Process abstraction vs the app abstraction

Process: once your code is running, you run forever

• Might run slow, but you can assume you are always running

​

App: the OS can and will kill your app

• When you are running you have nearly full access to all system resources, but you will get killed at some point

Why do mobile OSes do this?

Semantics on iOS vs Android are a bit different

iOS will keep all of your in memory state

Android will kill your memory state, but replay an “Intent” so that you can recreate / lookup again whatever you need

​

Many bugs on Android due to this, more flexible and efficient

iOS is a more natural way to think about it, I think it’s better

private class DownloadFilesTask extends AsyncTask<URL, Integer, Long> {

protected Long doInBackground(URL... urls) {

int count = urls.length;

long totalSize = 0;

for (int i = 0; i < count; i++) {

totalSize += Downloader.downloadFile(urls[i]);

publishProgress((int) ((i / (float) count) * 100));

// Escape early if cancel() is called

if (isCancelled()) break;

}

return totalSize;

}

… (continued on next page)

​

protected void onProgressUpdate(Integer... progress) {

setProgressPercent(progress[0]);

}

​

protected void onPostExecute(Long result) {

showDialog("Downloaded " + result + " bytes");

}

}

​

// here’s how to create an AsyncTask

new DownloadFilesTask().execute(url1, url2, url3);

Interesting story about AsyncTask

• Implementation started off with a single background thread for all AsyncTasks
• Semantics made no guarantees about the single thread
• Introduced multiple threads, hoped to get “free” performance
• Tons of bugs, people ended up programming to the implementation, often times without even knowing it
• Switched back to single thread