At this stage, we have a working Android development environment and we have built and deployed our first app. It is obvious, however, that the auto-generated code from Android Studio is not going to make the next top-selling app on Google Play. We need to explore this auto-generated code so we can begin to understand Android and then learn how to build upon this useful template. With this aim in mind, in this chapter, we will do the following:

• See how to get technical feedback from our apps
• Examine the Java code and UI XML code from our first app
• Get our first taste of using the Android StudioUser Interface(UI) designer
• Learn some core Java fundamentals and how they relate to Android
• Write our first Java code

First, let's see how to get feedback from our apps.

You can find the code for this chapter on GitHub athttps://github.com/PacktPublishing/Android-Programming-for-Beginners-Third-Edition/tree/main/chapter%2002.

In the previous chapter, we mentioned that our app was running in debug mode on the emulator or real device, so we can monitor it and get feedback when things go wrong. So, where is all this feedback then?

You might have noticed a whole load of scrolling text at the bottom of the Android Studio window. If not, click on theLogcat tab, as shown by the highlighted area labeled1 in the next figure:

Note

The emulator must be running, or a real device must be attached in debugging mode, for you to see the following window. Furthermore, if you restarted Android Studio for some reason and have not executed the app since restarting, then theLogcat window will be empty. Refer to the first chapter to get the app running on an emulator or a real device.

Figure 2.1 – The Logcat tab

You can drag the window to make it taller, just like you can in most other Windows applications if you want to see more.

This window is calledlogcat or is sometimes referred to as theconsole. It is our app's way of telling us what is going on underneath what the user sees. If the app crashes or has errors, the reason orclues to the reason will appear here. If we need to output debugging information, we can do so here as well.

Note

The app we are building should not have any problems at this stage, but in the future, if you just cannot work out why your app is crashing, copying and pasting a bit of text from logcat into Google will often reveal the reason.

Filtering the logcat output

You might havenoticed that most if not all of the contents of logcat is almost unintelligible. That's OK. For now, we are only interested in errors, which will be highlighted in red, and the debugging information, about which we will learn next. So that we see less of the unneeded text in our logcat window, we can turn on some filters to make things clearer.

In the previous figure, I highlighted two more areas, as2 and3. Area2 is a drop-down list that controls the first filter. Left-click it now and change it fromVerbosetoInfo. We have cut down the text output significantly. We will see how this is useful when we have made some changes to our app and redeployed it. We will do this after we have explored the code and the assets that make up our project. Also, double-check in the area that is labeled3 that saysShow only the selected application. If it doesn't, left-click on it and change it toShow only the selected application now.

Now we can look at what Android Studio automatically generated for us and then we can set about changing and adding to the code to personalize it beyond what we got from the project creation phase.

We are going to look at the resource files that have the code that defines our simple UI layout and the file that has our Java code. At this stage, we will not try to understand it all, as we need to learn some more basics before it makes sense to do so. What we will see, however, is the basic contents and structure of both files, so we can reconcile their contents with what we already know about Android resources and Java.

Examining the MainActivity.java file

Let's look at the Java code first. If, for some reason, this isn't currently visible, you can see this code by left-clicking on theMainActivity.java tab, as shown in the next figure:

Figure 2.2 – MainActivity.java tab

As we are not looking at the intricate details of the code, an annotated screenshot is more useful than reproducing the actual code in text form. Regularly refer to the next figure while reading on in this section:

Figure 2.3 – Java code

The first thing to note is that I have added a few empty lines among the code to space things out a little bitand present a clearer image.

Code folding (hiding) in Android Studio

Now look at the left-hand sideof the figure where multiple parts are labeled9. This points to all the little + and - buttons in the editor, which can collapse and expand parts of the code. I have indeed collapsed some parts of the code, and other parts I have left visible. So, what you can see on your screen is slightly different to what you will see if you look at the figure. In Android Studio, play with the + and – buttons for a while to practice hiding and unhiding sections of the code. You might want to get your screen to look like the figure, but this is not a requirement to continue. The technical term for hiding code like this isfolding.

The package declaration

Part1 is called thepackage declaration and, as you can see, it is the package name we chose when we created the projectpreceded by the wordpackage. Every Java file will have a package declaration at the top.

Importing classes

Part2 is eight lines of code that all begin with the wordimport. After the wordimport, we can see there are various dot-separated words. The last word of each line is the name of the class that line imports into our project and all the earlier words in each line are the packages and sub-packages that contain these classes.

For example, this next line imports theAppCompatActivity class from theandroidx.appcompat.app package and sub-packages:

import androidx.appcompat.app.AppCompatActivity;

Note

The semicolon at the end of the lines shows the compiler that it is the end of that line of code.

This means that in this file wewill have access to these classes. In fact, it is these classes that the auto-generated code uses to make the simple app that we saw in action in the previous chapter.

We will not discuss all these classes in this chapter. It is just the concept that we can do this importing that is significant right now. Note that we can add extra classes from any package at any time and we will when we improve upon our app shortly.

The class

Part3 of our code is called theclass declaration. Here is that line in full; I have highlighted one part of it:

public classMainActivity extends AppCompatActivity {

The class declaration is the start of a class. Notice the highlighted part,MainActivity. This is the name Android Studio gave the class when we created the project and it is also the same as theMainActivity.java filename as we would expect having discussed Java classes previously.

The class and the file can be renamed, but since this is the key/main activity of our app,MainActivity seems appropriate. Theextends keyword means that our class calledMainActivity will be of the typeAppCompatActivity.

We can, and will, use some classes without thisextends part. We useextends here because we want to use all the code that went into theAppCompatActivity class, as well as adding our own code to it as well. So, weextend it. All this and more will become clear inChapter 10, Object-Oriented Programming.

Finally, for part3, look at the opening curly brace at the end of the line:{. Now look at the bottom of the figure at part4 of our code. This closing curly brace} denotes the end of the class. Everything in between the opening and closing curly braces,{...}, is part of theMainActivity class.

Methods inside the class

Now look at part5 of the code. Here is that line of code in full with the key part for our discussion highlighted:

protected voidonCreate(Bundle savedInstanceState) {

This is a methodsignature. The highlighted part,onCreate, is the methodname. We make a methodexecute its code by using its name. We say we arecalling a method when we do this.

Although we will not concern ourselves now with the details of the parts of the code on either side of the method name, you might have noticedBundle, one of the classes we imported at part2 of our code. If we removed that relatedimport line, Android Studio would not know whatBundle was and it would be unusable and indicated with a red underline as an error.

Our code would then not compile and run. Notice the very last thing in the preceding line of code is an opening curly brace,{. This denotes the start of the code contained within theonCreate method. Now jump to part6 of our code and you will see a closing curly brace,}. You might have guessed that this is the end of the method. Everything in between the opening and closing curly braces of theonCreate method is the code that executes when the method is called.

We do not need to go into what this code does yet, but as an overview, it sets up the appearance/layout of the app by referring to a resource file that was auto-generated by Android Studio when we created the project. I have highlighted the resource files with an outline in the previous figure.

Parts7 and8 are also methods that I have collapsed to make the image and this discussion more straightforward. Their names areonCreateOptionsMenu andonOptionsItemSelected.

We know enough about our Java code to make some progress. We will see this code again and change it later in this chapter.

Summary of the Java code so far

It is true that contained within the codewe have just had an overview of, there is some complex syntax. However, what we are doing is building up just enough knowledge about this code, so we can work with it to begin to make fast progress in learning Java and Android without having to learn hundreds of pages of Java theory first. By the end of the book, all the code will make sense, but to make quick progress now, we just need to accept that some of the details will remain a mystery for a little while longer.

Examining the app layout file

Now we will look at justone of the many.xml files. There are several different layout files and we will meet them all throughout the course of the book, but let's start with the most recognizable one, which decides most of the appearance of our app.

In the project explorerwindow, left-click on theres folder and then left-click on thelayout folder. Now double left-click on thefragment_first.xml file. The XML code contents of the file is now displayed in the main window of Android Studio.

We can ignore theres generated folder.

We will explore this XML code soon but first find and left-click theDesign button (shown next) to switch to the design view:

Figure 2.4 – To open design view

Now we can see the design view that shows us what the XML code will cause to be displayed when the app is run in the emulator:

Figure 2.5 – App display

The preceding figureshould look familiar because it shows the layout of our first app that we ran at the end of the previous chapter – the one with theHello first fragment text and theNext button. If you look in thefragment_second.xml file from the same folder asfragment_first.xml, you will see the second layout we saw in the previous chapter, the one that had thePrevious button on it. In fact, there are even more layout-related files than we might first expect, but we will get to discussing them in this chapter and the next.

Most of the work that we do throughout the book when we design apps will be done in this design view. It is important, however, to know what is going on behind the scenes.

The design view is a graphical representation of the XML code contained in thefragment_first.xml file. Click on theCode tab (near theDesign tab in the previous figure) to see the XML code which forms the layout. I have annotated a screenshot of the XML text, so we can discuss it next:

Figure 2.6 – Screenshot of the XML text

The first thing tonote is that this file does not represent the entire layout. It does however represent most of the surface areaand the entireHello first fragment message and theNext button. Also, on the left-hand side, we can see the now-familiar + and – icons so we can fold and unfold sections of the code.

UI layout elements

If we first look at the part of the codelabeled1, we can see that the very first thing is…ConstraintLayout.... Now,ConstraintLayout is a UI element that is used to wrap other parts of the UI.

When we add a new element to a UI in Android, we always start a line with a< followed by the element's name.

The code that follows that rather long and cumbersome-looking line defines theattributes this element will have. This can include dozens of different things depending upon the type of UI element it is. Here, among a bit of other XML, we can see things such aslayout_width andlayout_height. All these attributes define how theConstraintLayout element will appear on the user's screen. The attributes for theConstraintLayout element end at the first> labeled1b.

If we look at the bottom of our XMLscreenshot, we will see some code labeled2. This code,</…ConstraintLayout>, marks the end of theConstraintLayout element. Anything in between the closing> of the element's attributes and</…ConstraintLayout>, which defines its end, is considered a child of the element. So, we can see that ourConstraintLayout has/contains two child elements. Let's look at those children now.

UI text elements

Using what we just learned, we can say that the UI element that starts at position3 in the screenshot is called aTextView. Just like its parent, it starts with a< and its name:<TextView.... If we look further into ourTextView element, we can see it has several attributes. It has atext attribute that is set to"Hello first fragment". This of course is the exact text that our app shows to the user. It also haslayout_width andlayout_height attributes that are both set to"wrap_content". This tellsTextView it can take up as much space as the content it has needs. As we will see throughout the book, there are many more attributes available for this and other UI elements. The final attribute inTextView isid, and we will see how we and Android use theid attribute in the next section when we improve this first app.

Notice that the code at4 in our XML screenshot is/>. This marks the end of theTextView element. This is slightly different to how the end of theConstraintLayout element was written. When an element in XML has no children, we can just end it like this:/>. When the element has children and its end comes further on in the code from where its attributes are defined, it is much clearer to end the element by repeating its name like this:</…ConstraintLayout>.

Note

You might be wondering why the element name forTextView is clear and concise (simplyTextView) yet the full name for theConstraintView is preceded by complicated apparent clutter (androidx.constraintlayout.widget.ConstraintLayout). ThisConstraintLayout element is a special layout that is used to ensure our app's compatibility with older versions ofAndroid. As we will see in a minute when we add buttons to the app, most elements have simple and concise names.

UI Button elements

Now we should be able to quickly identify that the code that starts at5 in the screenshot is aButton element. Just like its parent, it starts with a< and its name:<Button.... If we look further into ourButton, we can see it has several attributes. It has a text attribute that is set to"Next". This of course is the exact text displayed on the button the user can click. It also haslayout_width andlayout_heightattributes that are both set to"wrap_content". This, as with theTextView element, causes the onscreen button to take up as much space as the content it has needs. The final attribute inButton isid, and for buttons this is often a vital attribute, even more so than for some other parts of the UI. As theid attribute can distinguish this button from other buttons, we can program different functionality for different buttons based on the value held in theid attribute. We will see this principle in action soon.

Notice that the code at6 in our XML screenshot is/>. As we have come to know, this marks the end of theButton element.

We will edit and add to this XML code in the next section and learn more about the attributes.

Note

The elements of a layout are often referred to aswidgets.

Here we will add a couple of button widgets to the screen and we will then see a fast way to make them actually do something. We will add a button in two different ways, firstly using the visual designer and secondly by adding to and editing the XML code directly.

Adding a button via the visual designer

To get started with adding our first button,fragment_first.xml, open it in the editor and switch back to the design view by clicking theDesign tab (shown next):

Figure 2.7 – Design tab

Notice to the left-hand side of the layout we have a window that is called thePalette and is shown next:

Figure 2.8 – Palette window

The palette is divided into two parts. The left-hand list has the categories of UI elements and allows you to select a category, and then the right-hand side shows you all the available UI elements from the currently selected category.

Make sure that theCommon category is selected as shown in the previous figure. Now, left-click and hold on theButton widget and then drag it onto the layout somewhere near the top center.

It doesn't matter if it is not exact. It is good to practice getting it right, however. So, if you are not happy with the position of your button, then you can left-click it to select it on the layout and then tap theDelete key on the keyboard to get rid of it. Now you can repeat the previous step until you have a new neatly placed button that you are happy with, as here:

Figure 2.9 – Updating the layout

At this point, we could run theapp on the emulator or on a real device and the button would be there – kind of. If we clicked it, there would even be a simple animation to represent the button being pressed and released. Feel free to try this now if you like. If you do, you will notice that the button isn't positioned as you expect it to be:

Figure 2.10 – Button not positioned correctly

Don't concernyourself with this apparent anomaly for now; we will look into this over the next few sections.

Next, we are going to edit the attributes of our button in theAttributes window.

Editing the button's attributes

Make sure thebutton is selected by left-clicking it. Now find theAttributes window to the right of the editing window as shown next:

Figure 2.11 – Attributes window

In the previous figure, youcan see that we have access to a wide selection of attributes from the currently selected UI element. To reveal more of the attributes, we click the different categories of attributes and scroll through them using the scrollbar to the right. If they are not open already by default, left-click on theCommonAttributes andAll Attributes sections' arrows to reveal their options.

Now you can see the full details of the button and we can set about editing it. It might seem surprising the substantial number of attributes that something as simple as a button has. This is a sign of the versatility and power that the Android API provides for UI manipulation.

As you can see, there is a large array of different attributes that we can edit right here in the UI designer. InChapter 13, Anonymous Classes – Bringing Android Widgets to Life, we will also edit and manipulate these attributes using our Java code.

For now, we will edit just one attribute. Scroll theAttributes window until you see theonClick attribute in theCommon Attributes section and then left-click it to select it for editing, as shown here:

Figure 2.12 – Common Attributes section

Note

If you ever have trouble finding an attribute, you can always find it in theAll Attributes section, where attributes are arranged in alphabetical order. Therefore, theonClick attribute can also be found about two-thirds of the way down the lengthy list of theAll Attributes section.

TypetopClick in theonClick attribute's edit box and pressEnter on the keyboard. Be sure to use the same case, including theslightly counterintuitive lowercaset and uppercaseC.

TheAttributes window will look like this when you are done:

Figure 2.13 – onClick option

What we have done here is named the Java method in our code that we want to call when this button is clicked by the user. The name is arbitrary but as this button is in the top part of the screen, the name seems meaningful and easy to remember. The odd casing that we used is a convention that will help us keep our code clear and easy to read. We will see the benefits of this as our code gets longer and more complicated.

Of course, thetopClick method doesn't exist yet. Android Studio is very helpful, but there are some things we need to do ourselves. We will write this method using Java code after we have added another button to our UI. You could run the app at this point and it would still work. But if you click the button, it will crash, and you will get an error because the method does not exist. Android Studio is forewarning us of this impending crash by outlining theonClick attribute in red, as shown in the previous figure. If you hover the mouse cursor over this red outline, you will see the details of the problem:Corresponding method handler… Not found.

Examining the XML code for the new button

Before we add our final button for this project. Click theCode tab to switch back to seeing the XML code that makes our UI.

Notice that there is a new block of code among the XML that we examined earlier. Here is an image of the new block of code:

Figure 2.14 – New block of code among the XML

Also, notice the following details, which should correspond to what we know about XML and Android UI elements:

• The new code starts with the text<Button and ends with/>.
• The code has a range of attributes that define the button, includinglayoutWidth andlayoutHeight.
• The code includes theonClick attribute that we just added with a value of"topClick".
• ThetopClick value of theonClick attribute is underlined in red, showing the missing method error.
• The start and end of the code representing the button are enclosed within theConstraintLayout element.

As in the design view, you can hover the mouse cursor over the red-underlinedtopClick code to reveal the details of the problem:Corresponding method handler… Not found.

Note

During the writing of this book, Android Studio updated the way it shows errors in XML. Currently, it highlights the error in red, not underlining in red as shown in the figures and descriptions. The underlining is clearer in black and white print so they have been left as they are.

We can see that the issue is that Android Studio expects a method calledtopClick to be implemented within our Java code. We will do this as soon as we have added that second button.

Adding a button by editing the XML code

Just for variety and to prove that we can, we will now add another button using only XML code, not the UI designer. Most of the time, we will use the UI designer, but this quick exercise should cement in your mind the relationship between the UI designer and the underlying XML code.

We will achieve this by copying and pasting the code for the existing button. We will then make some minor edits to the pasted code.

Left-click just before the button code that starts<Button. Notice that the beginning and end of the code now have a slight highlight:

Figure 2.15 – Button code

This has identified the part of the code we want to copy. Now left-click and drag to select all the button code, including the highlighted start and end, as shown in this next figure:

Figure 2.16 – Select all the button code

Press theCtrl + C keyboard combination to copy the highlighted text. Place the keyboard cursor below the existing button code and tap theEnter key a few times to leave some spare empty lines.

Press theCtrl + V keyboard combination to paste the button code. At this point, we have two buttons. There are a couple of problems, however:

Figure 2.17 – Additional error

We have anadditional error in both blocks of code that represent our buttons. Theid attribute (in both blocks) is underlined in red. The reason for this error is that both buttons have anid attribute that is the same. Theid attribute is supposed to distinguish a UI element from all other UI elements. Let's fix that.

Giving the buttons unique id attributes

We could solve the problem by calling the second button,button2, but it would be more meaningful to change them both. Edit the code in the first button to give it an ID ofbuttonTop. To do so, find the following line of code (in the first button):

android:id="@+id/button"

Change it to this:

android:id="@+id/buttonTop"

Note

Notice the lowercaseb inbutton and the uppercaseT inTop.

Now identify this line of code in the second button:

android:id="@+id/button"

Change it to this:

android:id="@+id/buttonBottom"

The errors on theid attribute lines are gone. At this point, you might think we can move on to solve our missing method problem.

However, if you run the app and take a quick glance at it, you will see we only appear to have one button. Not only that but (as alluded to previously) the buttons are not in the place we expected them to be either:

Figure 2.18 – Single button

The reason for this is we haven't explicitly positioned them, so they have defaulted to the top left. Theposition we see on theDesign tab is just a design-time position. Let's change that now.

Positioning the two buttons in the layout

The reason we can only seeone button is that both buttons are in the same position. The second button is exactly covering the first button. And even in theDesign tab (feel free to have a look), the buttons are still sat on top of each other, although they are in the middle of the screen.

Note

You might be wondering why the UI layout tool was designed in this apparently counterintuitive way. The reason is flexibility. As we will see in the next two chapters, not only is it possible to position UI elements differently at design time to when the app is running but there is also a whole bunch of different layout schemes that the app designer (that's you) can choose from to suit their plans. This flexibility results in a little awkwardness while learning about Android but great design power once you have got past the awkwardness. Don't worry: we will move a step at a time until you have this thing beaten.

We will make Android Studio solve the problem for us automatically by first adding to our code and then using the UI designer. First, let's get the design-time layout right. In the code for the second button, find this line of code:

tools:layout_editor_absoluteY="30dp" />

Edit it to be the same as this:

tools:layout_editor_absoluteY="100dp" />

This subtle change will move the second button down a little, but only for design time. If you look in theDesign tab, the button is positioned neatly underneath the first button, but if you run the app on the emulator, they are both still in the top-left corner and on top of one another.

Note

It is possible, even likely, that the exactdp measurements in your layout will be slightly different to those shown in the book. As long as the second button'slayout_editor_absoluteY attribute is about70dp greater than the first, then all will be neat and tidy. Feel free to play with this attribute on both buttons while switching between theCode andDesign tabs until the buttons are positioned to your liking.

When you are satisfied with the position of the buttons, switch to theDesign tab and find theInfer constraints button, shown next:

Figure 2.19 – Infer constraints button

Click theInfer constraints button. Android Studio will edit the XML. Let's take a brief look at what has happened behind the scenes. From the end of both of the buttons, the following lines of code were removed.

If the constraints aren't being applied, hit theClear All Constraints button, which is to the left ofInfer constraints; sometimes Android Studio can get confused and needs to reset the existing constraints before inferring the rest:

tools:layout_editor_absoluteX="147dp"tools:layout_editor_absoluteY="30dp" />

These two lines of code were what positioned the buttons horizontally (…absoluteX) and vertically (…absoluteY).

Android Studio also added four lines of code to the first button and three to the second. Here is the code added near the start of the first button:

android:layout_marginTop="30dp"

This code causes the button to have a margin of 30 at the top. But at the top relative to what exactly? Look at these three lines of code that were added at the end of the first button:

app:layout_constraintEnd_toEndOf="parent"app:layout_constraintStart_toStartOf="parent"app:layout_constraintTop_toTopOf="parent" />

Notice the new attributes oflayout_constraintEnd_toEndOf,layout_constraintStart_toStartOf, andlayout_constraintTop_toTopOf. The value assigned to each of these attributes is"parent". This causes the first button to be positioned relative to theparent UI element. The parent is the containing layout: theConstraintLayout element.

Now look at the three linesof code added to the second (bottom) button.

Near the start of the code, we see this:

android:layout_marginTop="22dp"

And at the end of the code for the second button, we see these two extra lines:

app:layout_constraintStart_toStartOf="@+id/buttonTop"app:layout_constraintTop_toBottomOf="@+id/buttonTop" />

This means that the second button is positioned with a margin of 22 relative to thebuttonTop widget.

Note

Thedp code is a unit of measurement/distance and will be discussed in more depth inChapter 5, Beautiful Layouts with CardView and ScrollView. The precise values for thedp measurement will likely vary slightly on your layout.

Now run the app and you will see we have two distinct buttons. One has anid attribute ofbuttonTop and it is above the other button, with anid attribute ofbuttonBottom:

Figure 2.20 – Two button options

Clearly, there ismore to layouts than I have alluded to so far, but you have had your first glance at one of the options we have to design the UI of our apps. We will be taking a closer look at theConstraintLayout layout element as well as exploring more layout options inChapter 4, Getting Started with Layouts and Material Design.

We want to make one more change in our XML code.

Making the buttons call different methods

Switch back to theCode tab and identify this next line of code in the second (buttonBottom) button:

android:onClick="topClick"

Edit the code to this:

android:onClick="bottomClick"

Now we have two buttons, one above the other. The top one has anid attribute ofbuttonTop and anonClick attribute with a value oftopClick. The other has anid attribute ofbuttonBottom and anonClick attribute with a value ofbottomClick.

These last XML code changes now mean we need to code two methods (topClick andbottomClick) in our Java code.

Note

It is OK for two buttons to call the same method when they are clicked; it is not a syntax error. However, most buttons do have distinct purposes, so this exercise will be more meaningful if our buttons do different things.

We will do that soon, but before we do, let's learn a little bit more about Java comments and look at some Java code we can write to send messages. We will learn to send messages to the user to keep them informed and to ourselves for debugging purposes.

In programming, it is always a clever idea to write notes, known as code comments, and sprinkle them liberally throughout your code. This is to remind us what we were thinking at the time we wrote the code. To do this, you simply append a double forward slash and then type your comment, as follows:

// This is a comment and it could be useful

In addition, we can use comments tocomment out a line of code. Suppose we have a line of code that we temporarily want to disable. We can do so by adding the two forward slashes, like this:

// The code below used to send a message// Log.i("info","our message here");// But now it doesn't do anything// And I am getting ahead of where I should be

Note

Using comments to comment out code should only be a temporary measure. Once you have found the correct code to use, commented-out code should be deleted to keep the code file clean and organized.

Let's look at twoseparate ways to send messages in Android, and then we can write some methods that will send messages when our new UI buttons are pressed.

In the introduction to this chapterand in the previous chapter, we talked a bit about using other people's code, specifically via the classes and their methods, of the Android API. We saw that we could do some quite complex things with insignificant amounts of code (such as talk to satellites).

To get us started, we are going to use two different classes from the Android API that allow us to output messages. The first class,Log, allows us to output messages to the Logcat window. The second class,Toast, is not a tasty breakfast treat, but it will produce a toast-shaped pop-up message for our app's user to see.

Here is the code we need to write to send a message to the Logcat window:

Log.i("info","our message here");

Exactly why this works will become clearer inChapter 10, Object-Oriented Programming, but for now, we just need to know that whatever we put between the two sets of quote marks will be output to the Logcat window. We will see where to write this type of code shortly.

Here is the code we need to write to send a message to the user's screen:

Toast.makeText(this, "our message",      Toast.LENGTH_SHORT).show();

This is a very convoluted-looking line of code, and exactly how it works, again, will not become clear untilChapter 10, Object-Oriented Programming. The important thing here is that whatever we put between the quote marks will appear in a pop-up message to our users.

Let's put some code, much like we have just seen, into our app for real.

So, we now know the code that will output to Logcat or the user's screen. Butwhere do we write the code? To answer this question, we need to understand that theonCreate method inMainActivity.java executes as the app is preparing to be shown to the user. So, if we put our code at the end of this method, it will execute just as the user sees the app. Sounds good.

Note

We know that to execute the code in a method, we need to call it. We have wired our buttons up to call a couple of methods:topClick andbottomClick. Soon we will write these methods. But who or what is callingonCreate!? The answer to this mystery is that the Android operating system itself callsonCreate. It does so when the user clicks the app icon to run the app. InChapter 6, The Android Lifecycle, we will look deeper at this phenomenon, and it will be clear exactly what code executes and when. You don't need to completely comprehend this now. I just wanted to give you an overview of what was going on.

Let's quickly try this out. Switch to theMainActivity.java tab in Android Studio.

We know that theonCreate method is called just before the app starts. Let's copy and paste some code into theonCreate method of our app and see what happens when we run it.

Adding message code to the onCreate method

Find the closing curly brace} of theonCreate method and add the highlighted code shown next. In the code, I haven't shown the complete contents of theonCreate method but have used… to indicate some lines of code not being shown. The important thing is to place the new code (shown in full) right at the end but before that closing curly brace,}:

@Overrideprotected void onCreate(Bundle savedInstanceState) {………// Your code goes here     Toast.makeText(this, "Can you see me?",                    Toast.LENGTH_SHORT).show();             Log.i("info", "Done creating the app");}

Notice that the twoinstances of the wordToast and the wordLog are highlighted in red inAndroid Studio. They are errors. We know thatToast andLog are classes and that classes are containers for code.

The problem is that Android Studio doesn't know about them until we tell it about them. We must add animport for each class. Fortunately, this is semi-automatic.

Left-click on the redToast code in theonCreate method. Now hold theAlt key and then tapEnter. When prompted, chooseImportclass. Now repeat this process forLog. Android Studio adds the import directives at the top of the code with our other imports and the errors are gone.

Note

Alt + Enter is just one of many useful keyboard shortcuts. The following link is to a keyboard shortcut reference for Android Studio. More specifically, it is for the IntelliJ Idea IDE, upon which Android Studio is based. Look at and bookmark this web page; it will be invaluable over the course of this book:http://www.jetbrains.com/idea/docs/IntelliJIDEA_ReferenceCard.pdf.

Scroll to the top ofMainActivity.java and look at the addedimport directives. Here they are for your convenience:

import android.util.Log;import android.widget.Toast;

Run the app in the usual way and look at the output in theLogcat window.

Examining the output

The next figureshows a screenshot of the output in theLogcat window:

Figure 2.21 – Output in the Logcat window

Look at theLogcat window, you can see our messageDone creating the appwas output, although it is mixed up among other system messages that we are currently not interested in. If you watch the emulator when the app first starts, you will also see the neat pop-up message that the user will see:

Figure 2.22 – Pop-up message

It is possible that you might be wondering why the messages were output at the time they were. The answer is that theonCreate method is called justbefore the app starts to respond to the user. It is for this reason, it's common practice among Android developers to put code in this method to get their apps set up and ready for the user.

Now we will go a step further and write our own methods that will be called by our two buttons in the UI. We will place similarLog andToast messages inside these new methods.

Writing our own Java methods

Let's get straight on with writing our first Java methods with some moreLog andToast messages inside them.

Note

Now would be a good time, if you haven't already, to get the download bundle that contains all the code files. You can view the completed code for each chapter. For example, the completed code for this chapter can be found in theChapter 2 folder. I have further subdivided theChapter 2 folder intojava andres folders (for Java and resource files). In chapters with more than one project, I will divide the folders further to include the project name. You should view these files in a text editor. My favorite is Notepad++, a free download fromhttps://notepad-plus-plus.org/download/. The code viewed in a text editor is easier to read than from the book directly, especially the paperback version, and even more so where the lines of code are long. The text editor is also a great way to select sections of the code to copy and paste into Android Studio. You could open the code in Android Studio, but then you'd risk mixing up my code with the auto-generated code of Android Studio.

Identify the closing curly brace,}, of theMainActivity class.

Note

You are looking for the end of the entire class, not the end of theonCreate method as in the previous section. Take your time to identify the new code and where it goes among the existing code.

Inside that curly brace, enterthe following code that is highlighted.

@Overrideprotected void onCreate(Bundle savedInstanceState) {…………}………public void topClick(View v){             Toast.makeText(this, "Top button clicked",                            Toast.LENGTH_SHORT).show();             Log.i("info","The user clicked the top                   button");}public void bottomClick(View v){             Toast.makeText(this, "Bottom button clicked",                            Toast.LENGTH_SHORT).show();             Log.i("info","The user clicked the bottom                   button");}} // This is the end of the class

Notice that the two instances of the wordView might be red, indicating an error. Simply use theAlt + Enter keyboard combination to import theView class and remove the errors.

Note

The reason I said there "might" be an error is because it depends on how you entered the code. If you copied and pasted the code, then Android Studio may automatically add theView class import code. If you typed the new code, then the error will appear, and you will need to use theAlt + Enter key solution. This is just a quirk of Android Studio.

Deploy the app to a real device or emulator in the usual way and start tapping the buttons so we can observe the output.

Examining the output

At last, our app does something we told it to do when we told it to do it. We can see that the method names we defined in the buttononClick attribute are indeed called when the buttons are clicked, and the appropriate messages are added to theLogcat window and the appropriateToast messages are shown to the user.

Admittedly, we still don't understand why or how theToast andLog classes really work, neither do we fully comprehend thepublic void and(View v) parts of our method's syntax (or much of the rest of the auto-generated code). This will become clearer as we progress. As said previously, inChapter 10, Object-Oriented Programming, we will take a deep dive into the world of classes, and inChapter 9, Learning Java Methods, we will master the rest of the syntax associated with methods.

Check theLogcat window output. You can see that a log entry was made from theonCreate method just as before, as well as from the two methods that we wrote ourselves, each time you clicked one of the buttons. In the following figure, you can see I clicked each button three times:

Figure 2.23 – Logcat window output

As you are now familiar with where to find theLogcat window, in future I will presentLogcat output as trimmed text as follows, as it is easier to read:

The user clicked the top buttonThe user clicked the top buttonThe user clicked the top buttonThe user clicked the bottom buttonThe user clicked the bottom buttonThe user clicked the bottom button

And in the next figure, you can see that the top button has been clicked and thetopClick method was called, triggering the pop-upToast message highlighted here:

Figure 2.24 – Pop-up Toast message

Throughout this book, wewill regularly output to theLogcat window, so we can see what is going on behind the UI of our apps. Toast messages are more for notifying the user that something has occurred. This might be a download that has completed, a new email that has arrived, or some other occurrence that the user might want to be informed about.

1. Can you remind me what methods are?

   Methods are containers for our code that can be executed (called) from other parts of our code. Methods are contained within a class.

2. Like the first, I found this chapter tough going. Do I need to reread it?

   No; if you managed to build the app, you have made enough progress to handle the next chapter. All the blanks in your knowledge will be steadily filled in and replaced with glorious moments of realization as the book progresses.

We have achieved a lot in this chapter. It is true that much of the XML code is still generally incomprehensible. That's OK, because in the next two chapters we will be really getting to grips with the visual designer and learning more about XML, although ultimately our aim is to use XML as little as possible.

We have seen how, when we drag a button onto our design, the XML code is generated for us. Also, if we change an attribute in theAttributes window, then, again, the XML code is edited for us. Furthermore, we saw that we can type (or, in our case, copy and paste) XML code directly in theCode tab to create new buttons on our UI or edit existing ones.

We have seen as well as written our first Java, including comments that help us document our code, and we have even added our own methods to output debugging messages to the Logcat window and pop-upToast messages to the user.

In the next chapter, we will take a full guided tour of Android Studio to see exactly where different things get done at the same time as understanding how our project's assets, such as files and folders, are structured and how we can manage them. This will prepare us to go for a more in-depth look at UI design inChapter 4, Getting Started with Layouts and Material Design, andChapter 5, Beautiful Layouts with CardView and ScrollView, when we will build some significant real-world layouts for our apps.