The manifests folder has just one file inside it. Expand the manifests folder and double-click on the AndroidManifest.xml file. Notice that the file has been opened in the editor window and a tab has been added so that we can easily switch between this and other files. The following screenshot shows the new tab that has been added, as well as the XML code contained in the AndroidManifest.xml file within the manifests folder:

We don't need to understand everything in this file, but it is worth pointing out that we will make occasional amendments here, for example, when we need to ask the user for permission to access some features of their device, such as the messaging app or the images folder. We will also edit this file when we want to make a fullscreen app for immersion, such as for a game.

Notice that the structure of the file is very similar to the structure of the layout file that we saw in the previous chapter. For instance, there are clearly denoted sections that start with <section name and end with </section name>. Real examples of this are <application and </application>, and <activity and </activity>.

Indeed, the entire file contents, apart from the first line, are wrapped in <manifest and </manifest>.

In the same way that we enter the brackets of a calculation into a calculator, these opening and closing parts must match or the file will cause an error in our project. Android Studio indents (that is, places tabs) in front of the lines to make the sections and their depth in this structure clearer.

A number of specific parts of this code are worth noting, so I will point out some of the lines.

The following line tells Android that the icon that we want to show the user in their app drawer/home screen, and with which they can launch the app, is contained in the mipmap folder and is called ic_launcher:

android:icon="@mipmap/ic_launcher"

We will verify this for ourselves as we continue our exploration.

The next line has two aspects that are worth discussing. First, it denotes the name that we gave our app; and second, this name is contained as a String with a label of app_name:

android:label="@string/app_name"

We can, therefore, guess that the alphanumeric value of the label of app_name is Empty Activity App, because that is what we called the app when we created it.

This might sound unusual, but we will see this file shortly along with its label. And, in later projects, we will add more labels and values to it. We will also come to understand the reasons why we add text to our apps in what might, at this stage, seem like a convoluted manner.

We could discuss every line in the AndroidManifest.xml file, but we don't need to. Let's take a look at another two lines as they are related to each other. The following line indicates the name of our Activity, which was auto-generated when we created the project. I have highlighted the Activity name just to make it stand out:

<activity android:name=".MainActivity">

The following line, which appears within the <activity and </activity> tags, denotes that it is an attribute of the activity file. This tells us that this Activity is the one that should run when the app is started; it is the LAUNCHER:

<category android:name="android.intent.category.LAUNCHER" />

This implies that our apps can have more than one Activity. Very often, if you have an app with multiple screens, such as a home screen or settings screen, those screens are built from multiple Activity class instances.

As you have just seen, activity in XML has a name attribute with a value that refers to an instance of a Kotlin Activity.

Let's now dig into the java folder.

Here, we will find all the Kotlin code. To begin with, this consists of just one file, but as our projects grow further, we will add more. Expand the java folder and you will find three more folders, as shown in the following screenshot:

For this book, we will only need one of these three folders; that is, the top one. The names of these folders are composed of the package name (chosen when we created the app), and the app name, presented in lowercase and with no spaces (this was also chosen when we created the app).

The only folder that we are interested in for this book is the top folder, which for this app (on my screen) is com.gamecodeschool.emptyactivityapp. Depending on your chosen package name and the name of the app that we are currently working on, the folder name will change, but it will always be the top folder that we need to access and add or edit the contents of.

Expand the com.gamecodeschool.emptyactivityapp (or whatever yours is called) folder now to view its contents. In the following screenshot, you can see that the folder has just one file:

It is the MainActivity.kt file, although the file extension isn't shown in the project window, even though it is in the tab above the editor window. In fact, all the files in the java/packagename.appname folder for this book will have the .kt extension.

If you double-click on the MainActivity.kt file, it will open in the editor window, although we could have just clicked on the MainActivity.kt tab above the editor window. As we add more Kotlin files to our project, knowing where they are kept will be useful.

Examine the MainActivity.kt file and you will see that it is a simplified version of the Kotlin file that we worked with in the first project. It is the same, except that there are fewer functions and less code in the onCreate function. The functions are missing because the UI is simpler, and they are not needed; therefore, Android Studio didn't generate them.

For reference, take a look at the contents of the MainActivity.kt file in the following screenshot:

The file still has the onCreate function, which runs when the app is run, but there is much less code in it, and onCreate is the only function. Take a look at the last line of code in the onCreate function, which we will discuss before moving on to explore the res folder. Here is the line of code under discussion:

setContentView(R.layout.activity_main)

The code is calling a function named setContentView and is passing some data into setContentView for the code in the setContentView function to make use of. The data being passed to setContentView is R.layout.activity.main.

For now, I will just mention that the setContentView function is provided by the Android API and is the function that prepares and displays the UI to the user. So, what exactly is R.layout.activity_main?

Let's find out by exploring the res folder.

The res folder is where all the resources go. Left-click to expand the res folder and we will examine what's inside. Here is a screenshot of the top level of folders inside the res folder:

Let's begin with the top of the list; that is, the drawable folder.

The name gives things away a little bit, but the drawable folder holds much more than just graphics. As we progress through this book, we will indeed add graphics to this folder; however, for now, it holds just two files.

These files are ic_launcher_foreground and ic_launcher_background. We will not examine these files because we will never need to alter them, but I will quickly mention what they are.

If you open the files, you will see that they are quite long and technical. They include lists of coordinates, colors, and more. They are what is known as a graphical mask.

They are used by Android to adapt or mask other graphics; in this case, the launcher icon of the app. The files are instructions to Android on how to adapt the app launcher icon.

This system is made available so that different device manufacturers can create their own masks to suit their own Android devices. The masks, which are in the drawable folder by default (ic_launcher_foreground and ic_launcher_background), are default adaptive masks that add visually pleasing shadows and depth to the launcher icon.

Now that we know enough about drawable, let's move on to layout.

Expand the layout folder and you will see our familiar layout file that we edited in the previous chapter. There is less in it this time because we generated an Empty Activity project. It is not entirely empty, as it still holds a ConstraintLayout layout wrapping a TextView widget that says Hello World!.

Be sure to look at the contents – you should find that it looks as you might expect, but it is not the contents that are of interest here. Take a closer look at the name of the file (without the XML file extension): activity_main.

Now think back to the Kotlin code in the MainActivity.kt file. Here is the line of code that sets up the UI; I have highlighted a portion of the code:

setContentView(R.layout.activity_main);

The R.layout.activity_main code is indeed a reference to the activity_main file within the res/layout folder. This is the connection between our Kotlin code and our XML layout/design.

There is a difference in the first project; in the layout folder of the first project, there is an additional file. Later in this chapter, we will build another project using the same template (Basic Activity) that we used in the first chapter to understand why.

Before doing that, let's explore the final two folders and all their subfolders, starting with the next in the list, mipmap.

The mipmap folder is straightforward – that is, fairly straightforward. Expand the folder to see its contents, as shown in the following screenshot:

Here, you can see two subfolders; they are ic_launcher and ic_launcher_round. The contents of ic_launcher include the graphics for the regular launcher icon we see in the app drawer/home screen of the device, while ic_launcher_round holds the graphics for the devices that use round icons, as opposed to square icons. Double-click on one of the .png files from each folder to have a look. I have photoshopped one of each side by side in this screenshot to aid our discussion:

You are probably also wondering why there are five ic_launcher….png files in each folder. The reason for this is that it is good practice to provide icons that are suitably scaled for different sizes and resolutions of the screen. Providing an image with the hdpi, mdpi, xhdpi, xxhdpi, and xxxhdpi qualifications allows different Android devices to choose the icon that will look best for the user.

The final conundrum from the mipmap folder is that there is also an XML file in each of the two subfolders. Open one of them up and you will see that they refer to the ic_launcher_foreground and ic_launcher_background files that we looked at in the drawable folder. This tells the Android device where to get the details for the adaptive icons. These files are not required, but they make the icons look better, as well as add flexibility to the appearance.

We have one more folder and all its files to explore, and then we will finally understand the structure of an Android app.

Open the res/values folder to reveal three files that we will talk about briefly in turn. All these files interlink and refer to each other and other files that we have seen already.

For the sake of completeness, here is a screenshot of the three files in the res/values folder:

The key to understanding is not in memorizing the connections, and certainly not in trying to memorize or even understand the code in the files, but rather to get an appreciation of the interlinked nature of all the files and code we have seen so far.

Let's glance inside the files one at a time.

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <color name="colorPrimary">#008577</color>
    <color name="colorPrimaryDark">#00574B</color>
    <color name="colorAccent">#D81B60</color>
</resources>

<resources>
    <string name="app_name">Empty Activity App</string>
</resources>

android:label="@string/app_name"

<resources>
<!-- Base application theme. -->
<style name="AppTheme" 
parent="Theme.AppCompat.Light.DarkActionBar">
   <!-- Customize your theme here. -->
   <item name="colorPrimary">@color/colorPrimary</item>
   <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
   <item name="colorAccent">@color/colorAccent</item>
</style>
</resources>

<style name="AppTheme" 
parent="Theme.AppCompat.Light.DarkActionBar">

android:theme="@style/AppTheme"