Mobile Programming

In this module, we will discover the fundamental design patterns of all android
applications. We will also learn about the different components of the android project which are
the src or source code, the auto generated codes and the included libraries. It is also in this
module that we will be demonstrating the “Hello World” program in android via video tutorial.

Objectives:

At the end of the session, the students should be able to:

1. Know the standard user layouts in an android application;

2. Understand the concept of Activity life cycle and its use in the android environment;

3. Test and run a simple android program in different screen sizes; and

4. Familiarize himself with the terms relevant to the topic;

USER INTERFACE 1
ARCHITECTURE
A. Standard View Layouts
A layout defines the visual structure for a user
interface (UI), such as the UI for an application or widget.
When designing layouts for Android, you’ll rarely want to
hardcode the value of button titles, labels, and other text
fields into the layout’s XML file. Instead, you define string
resources in a separate file and link to it from within the
layout. This extra layer of abstraction makes it possible to
reuse the same layout file with different string resources.
The advantage to declaring your UI in XML is that
it enables you to better separate the presentation of your
application from the code that controls its behaviour. Your
UI descriptions are external to your application code, which
means that you can modify or adapt it without having to
modify your source code and recompile.
In general, the XML vocabulary for declaring UI
elements closely follows the structure and naming of the
classes and methods, where element names correspond to
class names and attribute names correspond to methods. In
fact, the correspondence is often so direct that you can
guess what XML attribute corresponds to a class method,
or guess what class corresponds to a given XML element.
However, note that not all vocabulary is identical. In some
cases, there are slight naming differences.
Each layout file must contain exactly one root
element, which must be a View or ViewGroup object. Once
you've defined the root element, you can add additional
layout objects or widgets as child elements to gradually
build a View hierarchy that defines your layout.
 When you compile a project, Android automatically
generates a View instance from each of your XML layout
files. Like String resources, these are accessed via the
special R class under the static layout variable. For
example, if you wanted to access the View instance created
from a file called activity_main.xml. Although before we
start talking about Android’s built-in layout schemes, it’s
important to understand how to set the size and position of
UI elements within a particular layout. The next three
sections show you how to define the dimensions, padding,
and margin of a UI element using various XML properties.

To set the width (Size) of a particular UI element,

all you need to do is add an android:layout_width attribute
to that element in the XML layout file. Likewise, the
android:layout_height attribute defines the height of the
element. The value for either of these parameters must be
one of the following:
wrap_content – This constant makes the element
as big as it needs to be to contain its content.

match_parent – This constant makes the

element match the width and height of the parent element.

An explicit dimension – Explicit dimensions can

be measured in pixels (px), density-independent pixels
(dp), scaled pixels based on preferred font size (sp), inches
(in), or millimeters (mm). For example,
android:layout_width="120dp" will make the element 120
device-independent pixels wide.

nce to a resource – Dimension resources

let you abstract reusable values into a resource file, just like
we saw with strings.xml in the first chapter of this book.
Dimension resources can be accessed using the
@dimen/resource_id syntax, where resource_id is the
unique ID of the resource defined in dimens.xml.

Padding is the space between an element’s content

and its border. It can be defined via any of the following
attributes, all of which take an explicit dimension or a
reference to a resource:
android:padding – Sets a uniform value for all
sides of the element.

android:paddingTop – Sets the padding for the

top edge of the element.

android:paddingBottom – Sets the padding for

the bottom edge of the element.

android:paddingLeft – Sets the padding for the

left edge of the element.

android:paddingRight – Sets the padding for

the right edge of the element.

android:paddingStart – Sets the padding for the

start edge of the element.

android:paddingEnd – Sets the padding for the

end edge of the element.

Padding can be added to View or ViewGroup

elements. For the former, it defines the space between the
element’s contents and its border, and for the latter it
defines the space between the edge of the group and all of
its child elements.
 Margin is the space between its border and either
the surrounding elements or the edges of the parent
element. It can be specified for any View or ViewGroup
using the android:layout_margin element. And, like
android:padding, the top, bottom, left, right, start, and end
margins can be defined individually using
android:layout_marginTop, android:layout_marginBottom,
etc.

Common Layouts

Android provides three main ways to arrange UI

elements: linear layouts, relative layouts, and grid layouts.
The first two methods use classes called Linear Layout
and Relative Layout, respectively. These are subclasses of
View Group that have built-in functionality for setting the
position and size of their child View objects. Grid layouts
make it easy to display one- and two-dimensional data
structures to the user, and they are slightly more complex
than linear or relative layouts.

The Linear Layout class arranges all of the

contained UI elements either horizontally or vertically. It
displays each element in the same order it appears in the
XML file, making it a very simple way to create complex
layouts made up of many elements.

RelativeLayout is an alternative to LinearLayout

that lets you specify where each element should be placed
with respect to the other elements in the interface. Unlike
LinearLayout, the order of the elements in the rendered
interface of a RelativeLayout does not necessarily have to
match the underlying XML file. Instead, their positions are
defined by specifying a relationship to another element
(e.g., “place the button to the left of the text field” or “place
the button at the bottom of its parent”). The fact that
positions are defined relative to other elements makes this a
very powerful way to create pleasing UIs that expand and
contract based on the screen size.

When you want to create a user interface using

dynamic data, things get a little bit more complicated.
Data-driven layouts or Grid Layouts require three
components:

A subclass of Adapter for converting the data items

into View objects.

objects created by the Adapter

Before you can start configuring a data-driven

layout, you need some data to work with. For this section,
our data set will be a simple array of String objects, but
Android also provides many built-in classes for fetching
data from text files, databases, or web services. Next, you
need an Adapter to convert the data into View objects. For
example, the built-in ArrayAdapter takes an array of
objects, creates a TextView for each one, and sets its text
property to the toString() value of each object in the array.
These TextView instances are then sent to an AdapterView.
AdapterView is a ViewGroup subclass that replaces the
 LinearLayout and RelativeLayout classes from the previous
sections. Its job is to arrange the View objects provided by
the Adapter.

B. Activity Life Cycle

An Activity Life Cycle consists of the following six states:
Created: The activity has been created and is
ready to be displayed.

Started: The activity is visible, but the user

cannot interact with it yet. This state is typically followed
immediately by the resumed state.

Resumed: The activity is running in the

foreground and the user can interact with it.

Paused: The activity has been interrupted by a

phone call or dialog message (e.g., a low-battery alert).
This often leads immediately into the stopped state. The
activity is usually still visible while paused, but obscured
by a dialog so the user cannot interact with it.

Stopped: The activity has been moved to the

background and is no longer visible, but the instance still
exists in memory. An activity can be re-launched from this
state without re-creating it.

Destroyed: The activity has been released by the

system and no longer exists. This will happen automatically
when the Android operating system deems it necessary.

When an activity is being created, it passes through

the first three states, and when it is being destroyed, it
passes through the latter half of the states. However, this
rarely happens in a strictly linear fashion. The typical
application will switch between the started, resumed,
paused, and stopped state as the user interacts with the
other activities in your application and gets interrupted by
important alerts.

To manage the transitions between these states, the

Activity class provides several methods. To define custom
startup and teardown behavior, all you have to do is
override these methods in an Activity subclass. All of the
Activity transition methods are listed below, along with
common examples of when they should be used:

onCreate() – Called when the activity is entering

the created state. As we saw in the last chapter, this is
where you want to initialize UI elements and otherwise
prepare the activity for use.

onStart() – Called when the activity is entering

the started state. This is a good place to load data that
needs to be displayed to the user, though this can also be
done in onResume() depending on the type of data and how
you’re using it.

onResume() – Called when the activity is

entering the resumed state. This is the best place to
initialize sensor input (e.g., GPS, cameras) and begin any
animations required by your user interface.

onPause() – Called when the activity is entering

the paused state. This is where you should stop using
scarce system resources (e.g., animations, GPS, cameras) to
 maximize the device’s battery life and to reduce your
application’s memory footprint. This is the teardown
counterpart to the onResume() method.

onStop() – Called when the activity is entering

the stopped state. This is called right before the application
enters the background, so it’s a good place to save user data
that needs to be re-used later on (e.g., an email draft). Note
that onPause() can also be an appropriate time to do this, as
it is always called immediately before onStop(). Whether
you want to use onPause() or onStop() largely depends on
your specific application requirements. onStop() is the
teardown counterpart to the onStart() method.

onDestroy() – Called when the activity is

entering the destroyed state. This is the last chance you
have to clean up any resources that would otherwise leak
when your application is destroyed. This is the teardown
counterpart to the onCreate() method; however, the system
will automatically release class references when the activity
is destroyed, so you usually won’t need to implement
onDestroy() unless you started a background thread or
created a memory buffer in onCreate().

As you can see, there is a symmetry between the

above transition methods. Anything that happens in
onStart() should be undone in onStop(), and anything done
in onResume() should be undone in onPause().

C. Supporting Multiple Screen Sizes

 (Note: Please check the Module 5 video tutorial for
the demonstration of supporting multiple screen sizes in an
android application).

Reference:

Rahman K. (2013). Android Development Tools for

Eclipse. (1st ed.) Packt Publishing

Hodson R. (2014). Android Programming

Succinctly (1st ed.) www.syncfusion.com