Lectures‎ > ‎Week 2: June 6-June 12‎ > ‎

01-Android Applications Structure and UI

Homework in preparation for this lecture

  1. Read 
    1. Chapter 3 in Hello Android, "Designing the User Interface"
    2. Read "Fundamentals" section in the Android Developer site
    3. Read "Activities" section in the Android Developer site
  2. Do (really do this)
    1. Starting from Eclipse "New Android Project"...
    2. Follow along the Sudoku example in Chapter 3 of Hello Android and implement all of it
    3. I will look at the code to make sure you don't "just cut and paste" it!
    4. Invent one or two additional 'features' or ideas and add those to your code
    5. Deliverable:
      1. Check your code into your Github repo
      2. Create a screencast with an audio/visual tour of your code, demoing it's operation and giving an oral tour of the interesting parts of the code.
  3. Continue working with the team from yesterday to finalize the design brief (2-5 pages)
    1. Group deliverable: Update the google doc for it, make all of us readers
    2. Group deliverable: Post a link to your design brief to the blog
    3. Group deliverable: 20+ stories in your pivotal tracker
  4. Complete PA-1
    1. Deliverable: Code in Github; link to code and the usual screencast in the homework log.
  5. For today's lecture
    1. Download activities.zip (at the end of this page) and load it into your editor so you can follow along
    2. Load it into Eclipse

Android Application Structure

  • It is what you download onto an Android device -- the .apk file
  • Contains everything that 'is' the application
  • Of course it has to 'marry' itself with what is already on the device
    • existing code
    • existing data
    • OS version
    • particulars of the device -- screen size, etc.
  • My simplistic view, an application is:
    • A set of activities
      • define logic dispatching between them
      • layouts and views controlling the appearance of the UI
      • code implementing the activity
  • Versioning and related issues
    • Your app will make some assumptions about the version of the sw in the Android
      • The system software
      • Also other software, e.g. from other vendors
      • Also data that may have been stored by the previous version
      • Also protocols used for talking to the server
    • Often edge-case and error handling are a lot of work!
  • Event Loop Issues
    • Android OS is in total control of the CPU
    • Your application is given control for specific reasons at specific times
    • Therefore in general you have to be careful about long running algorithms
  • Applications can have these kinds of components, each instantiated and controlled by Android - but implemented with your Java classes.
    • Activities
    • Services - kind of like an activity without a user interface, e.g.
    • Content Providers - generic repository - media, data, files, etc.
      • allowing data to be shared between applications (only way to do it!)
      • built in set includes, e.g. Contacts, System Settings and a few others, 
      • Homegrown ones are often a layer over a sqlite db or the file system
    • Broadcast Receiver - Notification handler
      • To receive notifications from system, e.g. Powering Off or Out of network connection

User Interface

Activity Lifecycle

  • At the crux of how you structure your application
  • Activities and Intents
    • Note: application != activity
    • Note2: process != activity
    • In fact, "activity' is a unique and specific Android concept
  • One APPLICATION may have multiple ACTIVITIES
  • Each ACTIVITY goes through a life cycle
  • Note the BACK button


Here's another diagram that may be easier to see:

And here's what the code looks like:

public class ExampleActivity extends Activity {
   
@Override
   
public void onCreate(Bundle savedInstanceState) {
       
super.onCreate(savedInstanceState);
       
// The activity is being created.
   
}
   
@Override
   
protected void onStart() {
       
super.onStart();
       
// The activity is about to become visible.
   
}
   
@Override
   
protected void onResume() {
       
super.onResume();
       
// The activity has become visible (it is now "resumed").
   
}
   
@Override
   
protected void onPause() {
       
super.onPause();
       
// Another activity is taking focus (this activity is about to be "paused").
   
}
   
@Override
   
protected void onStop() {
       
super.onStop();
       
// The activity is no longer visible (it is now "stopped")
   
}
   
@Override
   
protected void onDestroy() {
       
super.onDestroy();
       
// The activity is about to be destroyed.
   
}
}

Let's look at some code

  • Download activities.zip (below) and load it into your editor so you can follow along
  • First I will run it so we can look at it together
  • Now split up into teams of 2 students each and look at the code together. Note, please pair up with someone new so you can learn from each other. Take a few minutes. Here's a question for each group, in turn
    1. Look at AndroidManifest.xml: How many activities are there?
    2. Look at src/edu/brandeis/pitosalas/actvities. How many activities are there? Explain
    3. Identify the line of code which navigates from one Activity to the next
    4. Each activity shows a 'log' window in the bottom half. Is there a single log window View or one per activity?
    5. When I click a button and go to the other Activity, am I creating a new instance of the activity, or just activating the previous one?

RANT

  • Seeking and getting assistance from the community. PLEASE learn to do this. 
  • I was confused about the previous question and after studying the online documentation and two reference books I own, I posted this question on StackOverflow and within minutes my problem was solved: Question and answer on StackOverflow

Let's continue looking at the code

  • Continuing asking questions (last two student pairs)
    1. How would you modify the example that I gave so that the activity is not created over and over again. 
    2. How would you solve the issue that is mentioned: "To be clear, your activity may be restarted even if using the flags above. This would happen if your activity were destroyed in an attempt to free memory. In other words, you still need to make sure your activity can handle being restarted, taking the proper precautions in onPause andonSaveInstanceState.." 
      • Can you explain this? 
      • What line(s) of code needs to be changed?

Why activities are interesting

  • Why activity lifecycle is so important
    • Maintaining the user 'illusion'
  • Managing state - from one moment to the other
    • What can happen?
    • The back button
    • Why does state have to be managed?
    • Where is it stored?
  • New for 3.0: Fragments
    • I haven't used them yet
    • Sub-activity to support larger screens (tablets)
    • Sketch of Music player on white board. How it looks on a smart phone; how it might look on tablet

Afternoon Schedule

  • Speaker (1pm to 2pm)
  • Products (2pm to 4pm)
    • Each team summarize your design brief and show your paper prototype
    • Discuss the backlog so far. Re-prioritize
    • Discuss timeline between now and end of course. Initial decision on 'themes' for each sprint
    • Discuss Thursday specific goal
Č
ċ
Pito Salas,
May 9, 2011, 1:32 PM

Videos from Class