Android Unit 4: Second Project

1. Android Unit 4: Second Project Creating Code, and Using Content

2. The R.java Class • Remember the location of the R file in the project explorer hierarchy: • /gen/com.example.myechoapp/R.java

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

5. The screenshot on the following overhead shows the editor view of the R.java file for MyEchoApp scrolled down to show the following: • The id associated with the echo message • The id associated with the edit message • The layout’s definition in R • The strings associated with the app, both those defined in strings.xml and those that are system supplied

7. The code from the R.java file, copied from the editor, is given beginning on the overhead following the next one • The code begins at the beginning and runs through the string resources • The key point is this: • Successful compilation results in automatically generated identifiers in R.java for all app resources

8. These resources can be strings from strings.xml, id’s from activity_main.xml, or other resources • These system generated id’s in the R.java file are critically important • We will be looking at the app code in MainActivity.java next • That code will refer to the layout and resources belonging to the app by the system generated id’s

9. Here is the Codefor 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 intic_launcher=0x7f020000; • }

10. public static final class id { • public static final intecho_message=0x7f070001; • public static final intedit_message=0x7f070000; • public static final intmenu_settings=0x7f070002; • } • public static final class layout { • public static final intactivity_main=0x7f030000; • } • public static final class menu { • public static final intactivity_main=0x7f060000; • }

11. public static final class string { • public static final intapp_name=0x7f040000; • public static final intbutton_echo=0x7f040002; • public static final intecho_placeholder=0x7f040005; • public static final intmenu_settings=0x7f040003; • public static final inttext_message=0x7f040001; • public static final inttitle_activity_main=0x7f040004; • }

12. An Important Side Note, 2 • Recall that in the layout file, the button in the app wasn’t given an id • Therefore, the system doesn’t auto generate an id for it in the R.java file • You do not refer directly to the button in the Java code for the app in the same way as you refer to the other views • This will be explained further when looking at MainActivity.java

13. The MainActivity.java File • Remember the location of the MainActivity.java file in the project explorer hierarchy: • /src/com.example.myechoapp/MainActivity.java

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

16. Here is the Java Code: • The complete code for MainActivity.java is considered section-by-section beginning on the following overhead

17. Package and Imports • If you use the development environment it will automatically put your app into a package • package com.example.myechoapp; • Here are the general imports for the app • import android.os.Bundle; • import android.app.Activity; • import android.view.Menu;

18. 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;

19. An Important Side Note, 3 • Based on everything shown so far, you may be wondering why there is no specific import for the button • It will turn out that the plain View import will work for the button • When the code is explained in more detail, you’ll see what the relationship is.

20. The App Class • Android code is essentially Java code • When you are writing code for an app, you are writing the code for the class MainActivity • MainActivity is a subclass of Activity • This is the declaration line for the class, which is provided by the system whenever you start writing code for an app • public class MainActivity extends Activity {

21. The Standard Provided Methods • In addition to providing the class declaration, the system provides the standard, default methods that an app will contain • Just like a Java program has a main() method, an app will have an onCreate() method • Here is the signature for the method as provided by the system: • @Override • protected void onCreate(Bundle savedInstanceState) { • super.onCreate(savedInstanceState); • setContentView(R.layout.activity_main); • }

22. The onCreateOptionsMenu() method is also system provided • Until we develop an app with a menu, we don’t have to worry about it • Here is the code for it: • @Override • public booleanonCreateOptionsMenu(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; • }

23. The sendMessage() Method • The app user can interact with MyEchoApp in two ways: • The user can enter input text • The user can click the button to have it echoed as output • The sendMessage() method is the piece of code that responds to the button click • The code for this method supports input and output

24. The sendMessage() method is specified in activity_main.xml • This line of code in the layout specified that the sendMessage() method would be called when the button was clicked in the app: • android:onClick="sendMessage" /> • It’s important to note that if the layout specifies this, the MainActivity.java code has to implement it • Otherwise the project won’t compile successfully

25. 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

26. An Important Side Note, 4 • This is the conclusion, in this set of overheads, of the side notes concerning the button • These are the critical points: • When the button is clicked, the Android system causes the sendMessage() method to be called in the app code

27. When sendMessage() is called, the system also sends a reference to the button as an explicit parameter to the method • That means that within the method code it is possible to work with the button, if necessary • In general, a button is a View, and the explicit parameter is typed to View, rather a more specific button type • A superclass reference to a subclass object is always OK

28. Inside the code itself, when working with the EditText and TextView, it is necessary to work with the id’s of those components as made available in R.java • Those components of the app’s layout are not sent to the sendMessage() method as parameters in the same way as the button itself

29. There is one more thing that can be mentioned now as a preview of coming attractions • Future example apps will have more than one button • Clicking any button in the method will call the sendMessage() method • We will see the technique then of how to identify specific methods and sort out the code logic for them

30. The Implementation 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

31. As noted, the reference to the button comes in as the explicit parameter • You have to call particular methods in order to access the input, EditText, and output, TextView, views • You will see what methods accomplish this • You will also see that the method calls are floating in space

32. The Implicit Parameter • Let one method contain a line of code which calls another method • Let the line of code be a method call that doesn’t show what object it is called on • It is a method call “floating in space” • In this case, that line of code is called on whatever object called the method that contains it

33. Formally, you say that the calls are on the implicit parameter • Explicit parameters are passed in through the parentheses when a method is called • The system always makes the object that a method was called on available • It is represented by the key word “this”

34. Acquiring References to EditText and TextView • In a minute we will see the calls in the body of sendMessage() that acquire the references to the EditText and TextView • These calls are floating in space • They are made on the implicit parameter

35. What is the implicit parameter of the sendMessage() method? • It is the MainActivity that is currently being executed • It is worth beginning to understand this idea now, because it will become important in order to understand more complicated examples that will come later

36. In the example in the next set 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 • Activities will be explained in greater detail in a future set of overheads • In the current example we can simply accept that such calls can be made

37. 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

38. The complete code is shown on the following overhead • After that, the code is examined line-by-line

39. EditTexteditText = (EditText) findViewById(R.id.edit_message); • String message = editText.getText().toString(); • TextViewechoText = (TextView) findViewById(R.id.echo_message); • echoText.setText(message); • } • }

40. The calls to get and set the text string are straightforward • The calls to acquire the reference 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

41. Acquiring a Reference to edit_message • This is how you get a handle on the input, EditText, view • EditTexteditText = (EditText) findViewById(R.id.edit_message); • The method call floating in space is findViewById() • This is the method that allows you to acquire a reference to a component in an app by referring to it by the id that it has in the R.java file

42. Remember, edit_message originated in layout.xml in this way: • <EditText • … • android:id="@+id/edit_message" /> • It exists in R.java as a result of compilation in this form: • public static final class id { • public static final intedit_message=0x7f080000;

43. edit_messagebelongs to the app because these files are all parts of the same project • In the java code, this is the full syntax for referring to a component’s id in the R.java file, as shown above: • R.id.edit_message

44. Finally, notice the casting in the full line of code: • EditTexteditText = (EditText) findViewById(R.id.edit_message); • The findViewById() method returns a reference to a View • EditText is a kind of View, so that’s OK • But you have to cast the returned reference to the specific kind of object that it is, namely an EditText object

45. Making use of edit_message • The previous line of code made it possible to acquire a reference to the edit_messageEditText component of the app • The reason for wanting this is to be able to get the text that it contains • This is how you acquire the text from the field • String message = editText.getText().toString();

46. The line of code contains two method calls • The call to getText() literally acquires the contents of the EditText view • Calling toString() on that guarantees that we have the text in the desired form, namely a string • That string is what the remaining code will echo as output of the app

47. Acquiring a Reference to echo_message • This is how you get a handle on the output text view • TextViewechoText = (TextView) findViewById(R.id.echo_message); • The method call floating in space is findViewById() • This is the method that allows you to acquire a reference to a component in an app by referring to it by the id that it has in the R.java file

48. Remember, echo_messageoriginated in the layout, activity_main.xml in this way: • <TextView • … • android:id="@+id/echo_message" /> • It exists in R.java as a result of compilation in this form: • public static final class id { • public static final intecho_message=0x7f080001;

49. echo_messagebelongs to the app because these files are all parts of the same project • In the java code, this is the full syntax for referring to a component’s id in the R.java file, as shown above: • R.id.echo_message

50. Finally, notice the casting in the full line of code: • TextViewechoText = (TextView) findViewById(R.id.echo_message); • The findViewById() method returns a reference to a View • TextView is a kind of View, so that’s OK • But you have to cast the returned reference to the specific kind of object that it is, namely a TextView object