This set of slides introduces the reader to the concepts of Android Activities and Views. After presenting these two concepts in general terms, it continues with a detailed description of the activity lifecycle. It follows a discussion on how to structure the user interface in terms of View and ViewGroup objects. Finally, the presentation shows how to frame Android application development within the dictates of the Model-View-Controller (MVC) pattern.

1. Activities and Views
Ilio Catallo, Eleonora Ciceri – Politecnico di Milano
ilio.catallo@polimi.it, eleonora.ciceri@polimi.it
1

2. Androidinterface
2
Recent button
Jump instantly from
one task to another by
navigating a list of
recently opened apps
Home button
Visualize the Android
home screen
Back button
Move backward
through the history
of screens users
previously visited

3. Definitions
3

4. Activities and Views
¤ The activity is a single, focused thing that the user can do
¤ Each activity is associated with a window in which to draw
the user interface
¤ The view is the basic building block for user interface
components
¤ Responsible for drawing and event handling
¤ Examples: button, textbox
4

5. Applicationbuilding
blocks:UIcomponents
5
View
View
The Activity is the task
that can be
performed by
interacting with the
user interface

6. Analogy: web pages and activities
Website Application
6
Home
page
Main
activity
Navigation among
various pages
Navigation among
various activities

7. Activities and use case diagrams
¤ Roughly, each activity corresponds to a use case
¤ As such, the use case diagram could also serve as the
graph of connected activities
7
User
Use case 1
Use case 2
Use case 3
<includes>
Use case 4<includes>

8. Activity lifecycle
8

9. Activity lifecycle
¤ The activity lifecycle:
¤ Begins with instantiation
¤ Ends with destruction
¤ Includes many states in between
¤ Whenever a state change is required, the activity:
¤ is notified of the impending state change
¤ is allowed to execute the code in order to adapt itself to
that change
9

10. Activity lifecycle
¤ The state of each Activity is determined by its position on
the Activity stack
¤ The Activity stack is a last-in-first-out collection of all the
currently running activities
¤ When a new Activity starts, it becomes active and is moved
to the top of the stack
¤ If the user navigates back (using the Back button) or the
foreground Activity is closed, the next Activity down on the
stack moves up and becomes active
10

11. Activity lifecycle
¤ As Activities are created
and destroyed, they
transition through four
possible states:
¤ Active (running)
¤ Paused
¤ Stopped
¤ Inactive (destroyed)
11
FrontBack

12. Activity lifecycle
¤ Active (running) Activity
¤ Visible, focused,
foreground activity that
is receiving user input
¤ At the top of the stack
¤ Kept alive at all costs!
¤ If it does not have
the resources it
needs, other
Activities will be
killed
12
FrontBack

13. Activity lifecycle
¤ Paused Activity
¤ Visible but not focused
¤ This state is reached if a
transparent or non-full-
screen Activity is active
in front of it
¤ Treated as if it were
active, but without user
input events
13
FrontBack

14. Activity lifecycle
¤ Stopped Activity
¤ Not visible
¤ It remains in memory,
retaining all state
information
¤ It is a candidate for
termination when the
system requires memory
elsewhere
14
FrontBack

15. Activity lifecycle
¤ Inactive (destroyed)
Activity
¤ Removed from the
Activity stack
¤ Needs to be restarted
before it can be
displayed and used
15
FrontBack

16. Activitylifecycle
¤ The activity lifecycle is implemented as a collection
of methods the OS calls throughout the lifecycle of
an activity
16
onCreate()
onStart()
onResume()
onPause()
onResume()
onStop()
onRestart()
onStart()
onDestroy()

17. Activitylifecycle
¤ The activity lifecycle is implemented as a collection
of methods the OS calls throughout the lifecycle of
an activity
17
The activity does not
exist in memory

18. Activitylifecycle
¤ The activity lifecycle is implemented as a collection
of methods the OS calls throughout the lifecycle of
an activity
18
onCreate()
onStart()
onResume()
The activity is currently on
the screen and interacting
with the user
Create views, initialize variables
Actions performed at the end of
onCreate(), right before displaying
the activity
Start animations, listen from
GPS/camera updates

19. Activitylifecycle
¤ The activity lifecycle is implemented as a collection
of methods the OS calls throughout the lifecycle of
an activity
19
onPause()
The activity is not in focus
but still visible on the screen

20. Activitylifecycle
¤ The activity lifecycle is implemented as a collection
of methods the OS calls throughout the lifecycle of
an activity
20
onResume()
A paused activity is
resumed when it returns
visible on the screen

21. Activitylifecycle
¤ The activity lifecycle is implemented as a collection
of methods the OS calls throughout the lifecycle of
an activity
21
onStop()
The activity is not
visible but in
memory, waiting
for the user to
restart it soon

22. Activitylifecycle
¤ The activity lifecycle is implemented as a collection
of methods the OS calls throughout the lifecycle of
an activity
22
onRestart()
onStart()
When the user requires an
interaction with a stopped
activity, it is restarted

23. Activitylifecycle
¤ The activity lifecycle is implemented as a collection
of methods the OS calls throughout the lifecycle of
an activity
23
onDestroy()
A destroyed activity is no
longer in memory. Before
the activity is destroyed, it
can perform some actions

24. Differences between Home and Back
¤ When user presses Back
¤ The activity is destroyed
¤ Operations: onPause() – onStop() – onDestroy()
¤ When user presses Home
¤ The foreground activity is NOT destroyed
¤ Operations: onPause() – onStop()
¤ Note: the behavior in the emulator may differ
24

25. Configuration changes
¤ Configuration changes are rapid activity destruction/re-
creation cycles that occur when the configuration of an
activity changes
¤ Examples
¤ Device rotation: the activity needs to be rebuilt
¤ Keyboard is displayed: the activity is resized
25

26. Implementing lifecycle methods
¤ It is extremely important for the application developer to:
¤ analyze the requirements of each activity
¤ determine which methods need to be implemented
¤ Failure to do this can result in
¤ Application instability and crashes
¤ Resource bloat
¤ Underlying OS instability
¤ You should never call any lifecycle methods yourself!
26

27. TakeNotes v1:
ToDoListActivity.java
¤ Created as a default (blank) activity
¤ In Android Studio:
File > New > Other… > Android > Android Activity
27
public class ToDoListActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_to_do_list);
}
}
The file res/layout/activity_to_do_list.xml
defines the structure of the activity that is loaded
when the activity is created

28. Views and ViewGroups
28

29. User interface
¤ Each Activity in the app is associated with a user
interface (UI)
29
User interface
activity

30. User interface:
View and ViewGroup
¤ User interfaces are built using View’s and ViewGroup’s:
¤ A View is a widget that has an appearance on the screen
¤ A ViewGroup is a special View that contains other Views in
order to define the layout of the interface
¤ In other words, each ViewGroup is an invisible container
that organizes child Views, and Views are any widget
that draws some part of the UI
30

31. User interface:
View and ViewGroup
¤ The UI for each component of the app is defined using a
hierarchy of View and ViewGroup objects
31

32. User interface:
View and ViewGroup
¤ The UI for each component of the app is defined using a
hierarchy of View and ViewGroup objects
32

33. User interface layout
¤ Each subclass of ViewGroup defines the layout, i.e., the
arrangement, of its child views on the screen
33
LinearLayout RelativeLayout

34. User interface layout:
LinearLayout
¤ A LinearLayout
organizes its children
into:
¤ Either a single
horizontal row
¤ Or a single vertical
row
34

35. User interface layout:
RelativeLayout
¤ A RelativeLayout
enables you to
specify the location
of child objects:
¤ either relative to
each other
¤ or relative to the
parent
35

36. User interface:
View and ViewGroup
¤ Android provides a collection of View and ViewGroup
subclasses that cover most common situations:
¤ Views: input controls, e.g., TextView class, Button class,
CheckBox class
¤ ViewGroup: layout models, e.g., LinearLayout class,
RelativeLayout class
¤ However, if your app has unique need that is not
covered by the built-in views, it is possible to create a
custom View by extending the View class
36

37. LinearLayout ViewGroup
¤ The LinearLayout arranges views in a single column or a
single row
¤ Attributes
¤ layout_width: specifies the width of the ViewGroup
¤ layout_height: specifies the height of the ViewGroup
¤ orientation: vertical or horizontal
¤ Default values for attributes
¤ fill_parent: makes the component expand to match the
size of its parent view
¤ wrap_content: the width or height of the view is set to the
minimum size necessary to fit the content within that view
37

38. ScrollView ViewGroup
¤ The ScrollView enables users to scroll through a list of
views that occupy more space than the physical display
¤ You should place one child in it containing the entire
contents to scroll
¤ A child that is often used is LinearLayout, which in turn
contains some other views
¤ By doing so, the content of the LinearLayout will be
scrollable
38

39. ScrollView ViewGroup
39
Screen
ScrollView
width: fill_parent
height: fill_parent
LinearLayout
width: fill_parent
height: wrap_content
orientation: vertical

40. TakeNotes v1:
activity_to_do_list.xml
40
Add a static checkbox
to the checkbox list
A new string in the resource file specifies the content
of the default checkbox:
<string name="first_checkbox_text">
Conclude the implementation of TakeNotes
</string>
<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
tools:context=".ToDoListActivity">
<LinearLayout android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:orientation="vertical">
<CheckBox android:id="@+id/checkBox1"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:layout_marginTop="32dp"
android:text="@string/first_checkbox_text"/>
</LinearLayout>
</ScrollView>

41. TakeNotes v1: the result
41
Resource
@drawable/ic_launcher
Resource
@string/app_name
View
Checkbox
Resource
@string/first_checkbox_text
Activity
ToDoListActivity.jav
a

42. Android vs. MVC

43. Patterns
¤ Patterns are distilled commonality that you find in
programs
¤ They provide a general solution to a class of problems
¤ Patterns allow developers to deconstruct a complex
system into smaller, simpler parts
43

44. Architectural vs. design
patterns
¤ Software goes through a series of deconstruction at
different levels
¤ Architectural patterns pertain to the structural organization
of software system
¤ Design patterns are associated with code level
commonalities, and can be influenced by the specific
programming language at use
44

45. Model-View-Controller
pattern
¤ In the late seventies, software architects saw applications
as having three major parts:
¤ The part that manages the data (Model)
¤ The part that creates screens and reports (View)
¤ The part that handles interactions between the user and the
other subsystems (Controller)
45

46. Model-View-Controller
pattern
46
View
Controller
Model
State query
Change notification
State
change
View
SelectionUserinteraction
Event
Method
invocation

47. MVC is a concept
¤ Remember: there is no universal MVC pattern. MVC is a
concept rather than a solid pattern
¤ In fact, it is not even clear whether MVC is a design
pattern or an architectural pattern
47

48. Many MVC declinations
¤ As a rule of thumb, you are adopting the MVC pattern if
the application includes:
¤ A set of classes containing what to render (Model)
¤ A set of classes that know how to render those data (View)
¤ A set of classes that contains the interaction logic
(Controller)
48

49. Android vs. MVC
¤ Android does not explicitly embrace MVC
¤ Still, some developers prefer to frame Android app
development within the precepts of the MVC pattern
49

50. Android MVC declination
50
User input
View Controller
User interacts with
view object
View sends message to
controller
Model
controller updates
model objects
controller takes
from model
objects data
needed by the
views
controller updates
view with changes
in the model
objects

51. TakeNotesvs.MVC
51
TextView Button Checkbox
Checkbox
Checkbox
ToDoListActivity
Todo
Todo
Todo
Model
Controller
View
The model objects hold
the data and the
business logic of the
app
the controller responds to
the events triggered by
view objects and
manage the flow of data
to and from model
objects
View objects know how
to draw themselves on
the screen and how to
respond to user input

52. References
52

53. References
¤ Android API Guides, UI Overview
http://developer.android.com/guide/topics/ui/overview.
html
¤ Android API Guides,
Layoutshttp://developer.android.com/guide/topics/ui/d
eclaring-layout.html
¤ Google I/O 2013 - Structure in Android App Design
https://www.youtube.com/watch?v=XpqyiBR0lJ4
¤ The Big Nerd Ranch Guide to Android Programming, B.
Phillips, B. Hardy
53