Android 4: A Second Project

1

Android 4: A Second Project

Kirk Scott

2

3

Outline

• This unit will be divided into these sections:• 4.1 Introduction• 4.2 Views, layouts, and resources• 4.3 The activity_main.xml file• 4.4 The strings.xml file• 4.5 The R.java class• 4.6 The MainActivity.java file

4

4.1 Introduction

• The overall plan of all of the sets of overheads is to gradually grow some examples which illustrate how to do things

• It is not practical to cover each relevant topic in depth before applying it

• There are too many topics and they are too extensive

5

• Eventually, after covering enough examples, it will become possible to delve into individual topics in some depth

• Examples and background information are interspersed throughout the sets of overheads

• The background may help give context to previous examples and may provide a starting point for understanding future examples

6

• On the following overhead a screenshot is given of the example that will be pursued in this unit

• The goal is to develop an app that allows the user to enter text into a field and press a button to have the text echoed on the screen

• In other words, the goal is move one step beyond Hello World to a rock bottom simple echoing program

7

8

• These are some of the topics that will be covered in this unit in brief:

• Views in apps (the term View has a specific meaning in Android)

• XML and app layout• Graphical components of apps• The relationship between apps and resources• The specification of id’s for various components in apps• Adding functionality to apps

9

4.2 Views, Layouts, and Resources

10

Views and Layouts

• The logic of Android app layout has some similarities with the way layouts are accomplished in Java swing

• You may be reminded of how components are added to panels, for example, or how focus belongs to focus traversal groups

• However, there are major differences in the way things are accomplished in practice

11

• The layout of an Android app can be conceptualized as view groups and views

• View groups are overall containers for views or other view groups

• The term view refers to specific, individual graphical components like buttons, text fields, etc.

• Some of these individual items are known generically as widgets in Android

12

• In concrete terms, one of the most basic differences between Java applications and Android apps is that the layout of an app is stored in a separate .xml file

• To a certain extent, this is inconvenient, because as a developer you have to get used to having various things in different places and keeping track of their relationships

13

• In the long run, it is actually a very useful and practical way of managing the code for apps

• It’s sort of like taking the MVC pattern to the extreme

• The view is maintained completely separately from the model

14

• There are various advantages to this• For example, there are many different kinds of

mobile devices, with screens of different sizes and resolutions

• Defining layouts separately helps make it possible to support the same app in many different environments

15

Resources

• The same kind of logic applies to managing various resources, including things as simple as the strings that an app displays

• It may seem clumsy at first to have strings declared in a strings.xml file

• But separating strings from the logic of the code also has advantages

16

• For example, not only do apps run on different devices, they may also be internationalized

• Keeping strings separate from program logic makes it reasonably easy to substitute strings in one language for strings in another, or make other substitutions as necessary

17

• The purpose of this section was to give some vocabulary—views and layouts

• It was also to give a brief preview of the concrete example that will be pursued—MyEchoApp

• The organization and presentation of the following sections directly depends on the idea that various parts of an Android app are stored in different files

18

• The overall goal of the following sections is to trace through the contents of MyEchoApp

• This is done by examining the contents of the files related to the app one after the other in the order listed on the following overhead

19

• activity_main.xml (layout)• strings.xml (string resources)• R.java (the resources automatically generated

when the Java code is built)• MainActivity.java (the application source code)

20

4.3 The activity_main.xml File

21

• The activity_main.xml file contains the formatting for an app

• Information concerning this file will be presented in this way:

• A. A review of what the file contained for MyFirstApp• B. A presentation of the complete file for MyEchoApp• C. A line-by-line discussion of the contents of the file

for MyEchoApp

22

Layout for MyFirstApp

• The screenshot on the following overhead shows the Graphical Layout view of the activity_main.xml file for MyFirstApp

• This just serves as a reminder of what you saw in a previous unit

23

24

• The layout of MyFirstApp was based on what is known as RelativeLayout

• What the layout contained was known as a TextView

• These terms show up when you start looking at the XML for the layout

• The screenshot on the following overhead shows the editor view of the activity_main.xml file for MyFirstApp

25

26

• The complete activity_main.xml code for MyFirstApp is shown on the following overhead

27

• <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"

• xmlns:tools="http://schemas.android.com/tools"• android:layout_width="match_parent"• android:layout_height="match_parent"• tools:context=".MainActivity" >

• <TextView• android:layout_width="wrap_content"• android:layout_height="wrap_content"• android:layout_centerHorizontal="true"• android:layout_centerVertical="true"• android:text="@string/hello_world" />

• </RelativeLayout>

28

• Most of the details of importance will be discussed when going through the activity_main.xml file for MyEchoApp

• That will be done immediately after this summary review of the layout for MyFirstApp

29

• As noted above, MyFirstApp uses a RelativeLayout

• The RelativeLayout is a so-called root view• It contains a TextView• The TextView is a so-called child view• The idea is straightforward• The layout root organizes the child views that

it contains

30

• The TextView contains this:• android:text="@string/hello_world"• This is a reference to the resource defined in

strings.xml• This is the actual text that’s displayed in the

TextView

31

Layout for MyEchoApp

• The layout of MyEchoApp is based on the same organizing principles as MyFirstApp, but the layout is different and it contains more views

• The screenshot on the following overhead shows the Graphical Layout view of the activity_main.xml file for MyEchoApp

32

33

• The screenshot on the following overhead shows the editor view of the activity_main.xml file for MyEchoApp

34

35

• The complete activity_main.xml code for MyEchoApp is shown on the following overhead

36

• <?xml version="1.0" encoding="utf-8"?>• • <LinearLayout• xmlns:android="http://schemas.android.com/apk/res/android"• xmlns:tools="http://schemas.android.com/tools"• android:layout_width="match_parent"• android:layout_height="match_parent"• android:orientation="vertical" >• <EditText• android:layout_height="wrap_content"• android:layout_width="wrap_content"• android:hint="@string/text_message"• android:id="@+id/edit_message" />• <Button• android:layout_height="wrap_content"• android:layout_width="wrap_content"• android:text="@string/button_echo"• android:onClick="sendMessage" /> • <TextView• android:layout_height="wrap_content"• android:layout_width="wrap_content"• android:text="@string/echo_placeholder"• android:id="@+id/echo_message" />• </LinearLayout>

37

The activity_main.xml Code for MyEchoApp Line-by-Line

• The following overheads will go through the XML code for MyEchoApp line-by-line

• The goal is not to cover XML in detail• The goal is to get an initial idea of the connection

between the XML and the appearance of the application

• The goal is also to get an idea of how the connection is made between the XML components and what will be the functionality of the application

38

• It is worth noting again that the Graphical Layout view has a palette you can use to drag and drop components into a layout

• The first items in the palette are Form Widgets, Text Fields, Layouts

• You could create a layout by dragging and dropping• You were invited to try this at the end of the last

set of overheads• It will come up again in the future

39

• The point now is to look at the XML• It’s helpful to have some familiarity with the XML

that is generated in order to later become an intelligent user of the tools in the palette

• Generating the graphical components is pretty mechanical

• The important part will be the connection between them and the functionality of the application

40

Line-By-Line Starts Now

• The first line of activity_main.xml gives the version

• <?xml version="1.0" encoding="utf-8"?>

• The second line illustrates the form of a comment in XML

• 

41

• The third line declares the kind of layout that is being created for the app

• The LinearLayout is sort of like the FlowLayout in swing

• Another parameter will be given lower down which clarifies how LinearLayout works

• <LinearLayout

42

• For the time being we can just copy and carry the following lines without needing to know the details

• It is worth noting that in these lines, xmlns stands for XML name space

• xmlns:android=http://schemas.android.com/apk/res/android• xmlns:tools="http://schemas.android.com/tools"

43

• The LinearLayout is in effect a child of the device it’s running on

• The following two lines specify that the LinearLayout should take up the full space of the display of its parent

• android:layout_width="match_parent"• android:layout_height="match_parent"

44

• The next line sets a parameter relevant to how the LinearLayout is displayed

• LinearLayout presents views (components) in order as they’re added

• The orientation of the added items can be horizontal or vertical

• android:orientation=“vertical">

45

• Following the declarations related to the overall layout come the three child views that it contains

• They are:• EditText—this will allow data input• Button—this will have an action• TextView—this will show the output

46

The EditText View

• This is the complete code for EditText, the first child view in the LinearLayout of the app:

• <EditText• android:layout_height="wrap_content"• android:layout_width="wrap_content"• android:hint="@string/text_message"• android:id="@+id/edit_message" />

47

EditText Line-by-Line

• This line introduces the first child/view/graphical component that belongs to the LinearLayout, the editable text field

• <EditText

48

• These lines state that the size of the text field will be defined by the height and width of the string that it contains

• android:layout_height="wrap_content"• android:layout_width="wrap_content"

49

• This next line specifies a string resource associated with the text field

• android:hint="@string/text_message" />

• android:hint tells you the role that this string will play in the app

• The hint is the thing that is displayed in the text field by default

50

• android:hint="@string/text_message" />

• Quotation marks and @string are the syntax for designating a string resource

• text_message is the symbolic name of the string• The actual definition of the string is done in the

strings.xml file, here: /res/values/strings.xml• Referring back to the app screenshot, you can see

that the value of this string is “Enter a string”

51

• The activity_main.xml file won’t compile successfully until text_message has been included in the strings.xml file

• After a successful compilation of the code with the string declaration shown above a line like this one will appear in R.java

• public static final int text_message=0x7f040001;

52

• The next line is the most significant of the lines of code in EditText

• android:id="@+id/edit_message"

• This line of code assigns an id to the EditText view that is being created

• The view can be referred to by this id in the Java code for the app

53

• This is the syntax of the line:• It is defining an android id• The use of @ in general indicates a reference to a

resource• The + is the syntax that makes it possible to assign an

id to something at the same time it is initially being declared and defined

• In the previous line, + wasn’t necessary because we were referring to a string that had already been defined and given a name in strings.xml

54

• The point is this:• You are creating a handle which can be used later

on in MainActivity.java code to refer to this view, the EditText element of the layout

• Layouts contain views and can refer to strings by id

• Code can refer to views by id• Using references, code ultimately displays layouts

containing strings

55

• After successful compilation of a project containing this line:

• android:id="@+id/edit_message"

• A line like this one will appear in R.java

• public static final int edit_message=0x7f070000;

56

• At a system level, an id is a unique integer identifier (like a hashcode) for a resource

• The id’s, as they appear in R, are the handles for resources which can be referred to in ActivityMain.java, the Java source file for the app

• When using this handle, the edit_message identifier for the EditText view will be referred to in this way:

• R.id.edit_message

57

• In summary, this is what we just looked at, line-by-line

• <EditText• android:layout_height="wrap_content"• android:layout_width="wrap_content"• android:hint="@string/text_message"• android:id="@+id/edit_message" />

• The EditText component’s display characteristics are defined, its string is defined, and its id is defined

58

The Button View

• This is the complete code for Button, the second child view in the LinearLayout of the app:

• <Button• android:layout_height="wrap_content"• android:layout_width="wrap_content"• android:text="@string/button_echo"• android:onClick="sendMessage" />

59

Line-by-Line

• This line introduces the second child/view/graphical component that belongs to the LinearLayout, the button

• <Button

60

• The button will contain a label• These lines state that the size of the button

will be defined by the height and width of that label


61

• This line specifies a string resource associated with the button

• android:text="@string/button_echo" />

• @string is the way of designating this• button_echo is the symbolic name of the string• The actual definition of the string is done in the strings.xml file,

here: /res/values/strings.xml• The activity_main.xml file won’t compile successfully until

button_echo has been included in the strings.xml file

62

• This line is the most significant of the lines of code in Button

• android:onClick="sendMessage" />

• This line of code gives the name of the method, sendMessage(), that will be called when the app is running and the button is clicked

63

• The sendMessage() method is java code which will be implemented in the MainActivity.java file

• The name and purpose (event handling) of the method are predetermined

64

• In summary, this is what we just looked at line-by-line

• <Button• android:layout_height="wrap_content"• android:layout_width="wrap_content"• android:text="@string/button_echo"• android:onClick="sendMessage" />

• The component’s display characteristics are defined, its string is defined, and it is associated with an action

65

The TextView

• This is the complete code for TextView, the third child view in the LinearLayout of the app:

• <TextView• android:layout_height="wrap_content"• android:layout_width="wrap_content"• android:text="@string/echo_placeholder"• android:id="@+id/echo_message" />

66

Line-by-Line

• This line introduces the third child/view/graphical component that belongs to the LinearLayout, the text view

• A TextView simply displays a string

• <TextView

67

• These lines state that the size of the text view will be defined by the height and width of the string that it contains


68

• This line specifies a string resource associated with the text field

• android:text="@string/echo_placeholder"

• The resource, named echo_placeholder, would have to be defined in strings.xml

• Looking at the screenshot of the app, you see that this string is defined to have this value: “Your input will be echoed here.”

69

• This line defines another id of this text view

• android:id="@+id/echo_message" />

• This works the same way as explained for the edit text component

• It will result in this id appearing in R:

• R.id.echo_message

70

• The edit text and text view components are the input and output parts of the echoing

• The sendMessage() method is the functionality

• In the code for sendMessage() the id’s of the input and output components will be referred to in order to make the app work

71

• In summary, this is what we just looked at line-by-line

• <TextView• android:layout_height="wrap_content"• android:layout_width="wrap_content"• android:text="@string/echo_placeholder"• android:id="@+id/echo_message" />

• The component’s display characteristics are defined, its string is defined, and its id is defined

72

Ending the Layout

• This line ends the definition of the LinearLayout

• </LinearLayout>

73

A Side Note on Names of Resources and Scope

• XML code similar to the code we just looked at is given on the following overhead

• Note that the id at the top and the string at the bottom have the same name

• You may run across example code written by other programmers with this characteristic

74

• <EditText• android:id="@+id/edit_message"• android:layout_height="wrap_content"• android:layout_width="0dp"• android:layout_weight="1"• android:hint="@string/edit_message" />

75

• It is possible for two things to have the same name because id’s and strings are two distinct kinds of things

• In the R.java (resource) file, the reference identifiers for id’s and strings are in different sets of braces, so they can be distinguished

76

• Even though it’s possible to have different things with the same name, I think it’s a bad idea that will lead to confusion

• I will give everything different names even if they are of different types

77

4.4 The strings.xml File

78

• The screenshot on the following overhead shows the editor view of the strings.xml file for MyEchoApp

79

80

Here is the XML Code:• <?xml version="1.0" encoding="utf-8"?>• <resources>• <string name="app_name">My Echo App</string>• <string name="menu_settings">Settings</string>• <string name="title_activity_main">MainActivity</string>• <string name="text_message">Enter a string</string>• <string name="button_echo">Echo</string>• <string name="echo_placeholder">Your input will be echoed

here.</string> • </resources>

81

• It is not necessary to examine strings.xml line by line on separate overheads

• It is apparent that the first 3 lines in the file consist of overall app related strings which are supplied by the system

82

• The last 3 lines in strings.xml are the strings associated with the views in the app

• The XML syntax for naming the string and giving it a value is apparent

• As noted earlier, you won’t get a clean compilation unless the strings mentioned in activity_main.xml are defined in this way in strings.xml

83

4.5 The R.java Class

84

• The screenshot on the following overhead shows the editor view of the R.java file for MyEchoApp

85

86

• The code from the top of the R.java file is given on the following overheads

• All resources have automatically generated identifiers in R.java as a result of successful compilation

87

• These resources can be strings from strings.xml, id’s from activity_main.xml, or other resources

• The app’s Java code refers to its resources through the R.java file

88

Here is the Code for R.java• /* AUTO-GENERATED FILE. DO NOT MODIFY.• *• * This class was automatically generated by the• * aapt tool from the resource data it found. It• * should not be modified by hand.• */

• package com.example.myechoapp;

• public final class R {• public static final class attr {• }• public static final class drawable {• public static final int ic_launcher=0x7f020000;• }•

89

• public static final class id {• public static final int echo_message=0x7f070001;• public static final int edit_message=0x7f070000;• public static final int menu_settings=0x7f070002;• }

• public static final class layout {• public static final int activity_main=0x7f030000;• }

• public static final class menu {• public static final int activity_main=0x7f060000;• }

90

• public static final class string {• public static final int app_name=0x7f040000;• public static final int button_echo=0x7f040002;• public static final int echo_placeholder=0x7f040005;• public static final int menu_settings=0x7f040003;• public static final int text_message=0x7f040001;• public static final int title_activity_main=0x7f040004;• }

91

4.6 The MainActivity.java File

92

• The screenshot on the following overhead shows the editor view of the MainActivity.java file for MyEchoApp

93

94

Here is the Java Code:

• The complete code for MainActivity.java is considered section-by-section beginning on the following overhead

95

Package and Imports• If you use the development environment it

will automatically put your app into a package


• Here are the general imports for the app

• import android.os.Bundle;• import android.app.Activity;• import android.view.Menu;

96

• You need to import the view classes in order to work with them in your code

• These are the Android classes that correspond to the views in the layout in activity_main.xml

• import android.view.View;• import android.widget.EditText;• import android.widget.TextView;

97

The App Class

• This is the class of the app as provided by the system

• public class MainActivity extends Activity {

98

The Standard Provided Methods

• The onCreate() method is the moral equivalent of a main() method

• It’s provided by the system if you use the development environment

• @Override• protected void onCreate(Bundle savedInstanceState) {

• super.onCreate(savedInstanceState);• setContentView(R.layout.activity_main);• }

99

• The onCreateOptionsMenu() method is also system provided

• Until we develop an app with a menu, we don’t have to worry about it

• @Override• public boolean onCreateOptionsMenu(Menu menu) {• // Inflate the menu; this adds items to the action bar

if it is present.• getMenuInflater().inflate(R.menu.activity_main, menu);• return true;• }

100

The sendMessage() Method

• The sendMessage() method is needed in the Java code for the app

• This method is specified in activity_main.xml as the method to be called when the button in the layout which belongs to the app is clicked

101

• If it’s specified in the layout but not implemented in ActivityMain.java, you won’t get a clean compile

• In other words, you don’t inherit this from Activity

• Not all apps have buttons, so not all apps have a sendMessage() method

• You have to supply one if your app does have a button

102

The Signature and Explicit Parameter of the sendMessage() Method

• Here is the signature of the method:

• public void sendMessage(View view) {

• Remember that in layout terms, the button is a view• The view that comes in as a parameter to the method

when the button is clicked is a reference to the button• In the code for the method you don’t have to acquire

a reference to the button separately

103

A Preliminary Description of the Body and the Implicit Parameter of the sendMessage()

Method

• The body of the sendMessage() method will come next

• Obviously it’s important because this is where the echoing logic of the app is implemented

• It’s also important because in this code you see how you can acquire references to the views in the layout belonging to the app

104

• The reference to the button comes in as the explicit parameter

• You have to call methods in order to access the input, EditText, and output, TextView, views

• You will see that the method calls are floating in space

• These calls to acquire references to the views are made on the implicit parameter

105

• Speaking concisely, the implicit parameter is the MainActivity that is currently being executed

• This is an important topic• In the example in the next set of overheads, it

will be necessary to pass the MainActivity around as an explicit parameter so that calls such as these can be made on it elsewhere

106

• Activities will be explained in greater detail in a future set of overheads

• In the current example we can simply accept that calls can be made on activities in order to acquire references to the views that belong to them

107

The Body of the sendMessage() Method

• The process of echoing in the app consists of 4 steps:• 1. Acquire a reference to the input, EditText, view• 2. Acquire the string from the input view• 3. Acquire a reference to the output, TextView, view• 4. Put the string into that view• The complete code is shown on the following

overhead• After that, the code is examined line-by-line

108

• EditText editText = (EditText) findViewById(R.id.edit_message);

• String message = editText.getText().toString();

• TextView echoText = (TextView) findViewById(R.id.echo_message);

• echoText.setText(message);• }• }

109

• The calls to get and set the text string are straightforward

• The calls to acquire the references have two critical elements:

• 1. You specify the view you want a handle on by sending its R.java id as a parameter.

• 2. You have to cast the return value to the specific kind of view you were expecting back

110

• Looking back at the contents of R and the way the code works here, you can kind of gather what’s going on:

• When you cast, it’s more or less like recovering a subclass reference from a superclass reference

• The superclass would literally be View, but in R, there is a separate id concept—where the id’s are hex values—hashcodes for actual objects of a given class(?)

111

• In any case, in practice this is how you get a handle on the input, EditText, view


• Remember, edit_message originated in layout.xml• It exists in R.java as a result of compilation• It belongs to the app because these files are all parts

of the same project

112

• This is how you acquire the text from the field

• String message = editText.getText().toString();

• In some contexts, a getText() method might return a String, but here we have to cast

113

• We don’t know the type being returned here, but looking at the way things are structured, we can again speculate

• Maybe getText() returns the R id of the reference to the string in strings.xml…

• And for that kind of id, toString() has been implemented to return the string value…

114

• This is how you get a handle on the output text view


• This is analogous to acquiring the handle for the input view

115

• This is how you assign a string to the output text view


• It’s a little odd that getText() from an EditText view apparently doesn’t return a String, but setText() on a TextView expects a String, but so be it

116

Summary and Mission

• After 100+ overheads, your head can spin a little

• What was this all about?• In summary, it covered everything you needed

to know, every aspect of any file that you as a programmer need to touch, in order to create an echoing application.

117

• From a Java programmer’s point of view, the sendMessage() method is where the real work happens

• However, it doesn’t really take that much work there at all

• This is the result of offloading layout, resources, etc. to other locations

118

• The challenge is keeping track of all of the different files in the project, what has to go into them, and their relationships to each other

• As seen, the final thing you have to be aware of in the code for MainActivity.java is how to get a handle on the views that belong to the app

119

• What is your mission?• There is no separate mission for this set of

overheads• The next set of overheads expands on the

topics introduced here and ends with the first assignment that you will need to do and turn in

120

The End

121

• The following slides contain the complete MainActivity.java code done with the explanations as comments rather than as PowerPoint bullets

• It gives the same information in a more compact form

• The descriptions are less complete, but you can essentially take everything in at once in a few short glances

122

Package and Imports• /* If you use the development environment it will• * automatically put your app into a package. */


• /* Here are the general imports for the app. */

• import android.os.Bundle;• import android.app.Activity;• import android.view.Menu;

123

• /* You need to import the view classes in order to work with• * them in your code. These are the Android classes that• * correspond to the views in the layout in• * activity_main.xml.• */

• import android.view.View;• import android.widget.EditText;• import android.widget.TextView;

124

The App Class and the Standard Provided Methods

• /* This is the class of the app as provided by• * system. */

• public class MainActivity extends Activity {

• /* This method is the moral equivalent• * of a main() method. It’s provided• * by the system if you use the development• * environment. */

• @Override• protected void onCreate(Bundle savedInstanceState) {• super.onCreate(savedInstanceState);• setContentView(R.layout.activity_main);• }

125

• /* This method is also system• * provided. Until we develop an app• * with a menu, we don’t have to worry• * about it. */

• @Override• public boolean onCreateOptionsMenu(Menu menu) {• // Inflate the menu; this adds items to the action

bar if it is present.• getMenuInflater().inflate(R.menu.activity_main,

menu);• return true;• }

126

• /* The sendMessage() method is called when the• * button in the layout which belongs to the app• * is clicked */

• /* This is very important: Remember that in• * layout terms, the button is a view.• * The view that comes in as a parameter to• * the method when the button is clicked• * is a reference to the button. */

• public void sendMessage(View view) {

127

• /* The body of the sendMessage() method will come next. */

• /* This is very important: In order to get handles• * on the other views in the layout of the app so that• * you can work with them in the app code, you have to• * call methods to acquire them. You will see that the• * calls are floating in space—they’re on the implicit• * parameter. At this point we don’t really know what• * the implicit parameter is. More explanations will• * come later. For the time being, accept that the• * calls can be made.• * Notice these two critical elements of the calls:

• * 1. You specify the view you want a handle on by• * sending its R.java id as a parameter.• • * 2. You have to cast the return value to the specific• * kind of view you were expecting back.• */

128

• /* The following code accomplishes echoing by taking• * in input and transferring it to output.

• /* This is how you get a handle on the input edit text view. */


• /* This is how you acquire the text from the field. */• String message = editText.getText().toString();

• /* This is how you get a handle on the output text view. */


• /* This is how you assign a string to the output text view. */

Documents

Android 4: A Second Project