Welcome to the exciting world of Android and Kotlin! In this first chapter, we won't waste any time before getting started developing Android apps.
We will look at what is so great about Android, what Android and Kotlin are, how they work and complement each other, and what that means to us as future developers. Moving on, we will set up the required software, so that we can build and deploy a simple first app.
In this chapter, we will cover the following topics:
Learning how Kotlin and Android work together
Setting up our development environment, Android Studio
Learning what makes an android app
Learning about Kotlin
Building our very first Android app
Deploying an Android emulator
Running our app on an Android emulator and a real device
This is a lot to get through, so let's get started.
When Android first arrived in 2008, it was a bit drab compared to the much more stylish iOS on the Apple iPhone/iPad. But, quite quickly, through a variety of handset offers that struck a chord with practical, price-conscious consumers, as well as those who are fashion-conscious and tech-savvy, Android user numbers exploded.
For many, myself included, developing for Android is the most rewarding pastime and business, bar none.
Quickly putting together a prototype of an idea, refining it, and then deciding to run with it and wire it up into a fully-fledged app, is such an exciting and rewarding process. Any programming can be fun – I have been programming all my life – but creating for Android is somehow extraordinarily rewarding.
Defining exactly why this is the case is quite difficult. Perhaps it is the fact that the platform is free and open. You can distribute your apps without needing the permission of a big controlling corporation – nobody can stop you. And, at the same time, you have well-established, corporate-controlled mass markets, such as Amazon Appstore and Google Play.
It is more likely, however, that the reason that developing for Android gives such a good feeling is the nature of the devices themselves. They are deeply personal. You can develop apps that interact with people's lives, which educate, entertain, tell a story, and so on, and it is there in their pocket ready to go – in the home, in the workplace, or on holiday.
You can certainly build something bigger for the desktop but knowing that thousands (or millions) of people are carrying your work in their pockets and sharing it with friends is more than just a buzz.
No longer is developing apps considered geeky, nerdy, or reclusive. In fact, developing for Android is considered highly skillful, and the most successful developers are hugely admired, even revered.
If all this fluffy, spiritual stuff doesn't mean anything to you, then that's fine too; developing for Android can make you a living, or even make you wealthy. With the continued growth of device ownership, the ongoing increase in CPU and GPU power, and the non-stop evolution of the Android operating system itself, the need for professional app developers is only going to grow.
In short, the best Android developers – and, more importantly, the Android developers with the best ideas and the most determination – are in greater demand than ever. Nobody knows who these future Android app developers are, and they might not even have written their first line of code yet.
So, why isn't everybody an Android developer? Obviously, not everybody will share my enthusiasm for the thrill of creating software that can help make people's lives better, but I am guessing that, because you are reading this, you might.
Unfortunately, for those who do share my enthusiasm, there is a kind of glass wall on the path of progress that frustrates many aspiring Android developers.
Android asks aspiring developers to choose from three programming languages to make apps. Every Android book, even those aimed at so-called beginners, assumes that readers have at least an intermediate level of Kotlin, C++, or Java, and most need an advanced level. So, good-to-excellent programming knowledge is considered a prerequisite for learning Android.
Unfortunately, learning these languages in a completely different context to Android can sometimes be a little dull, and much of what you learn is not directly transferable into the world of Android either. You can see why beginners to Android are often put off.
It doesn't need to be like this. In this book, I have carefully placed all the Kotlin topics that you would learn in a thick and weighty Kotlin-only beginner's tome, and reworked them into three multi-chapter apps and more than a dozen quick mini-apps, starting from a simple memo app, progressing to a cool drawing app and a database app.
If you want to become a professional Android developer, or just want to have more fun when learning Kotlin and Android, this book will help.
The Android Software Development Kit (SDK) is largely written in Java, because Kotlin is the new kid on the block; but when we tell Android Studio to turn our Kotlin code into a working app, it is merged together with the Java from the SDK in an intermediate form before being converted into a format called DEX code, which the Android device uses to convert into a running app. This is seamless to us as developers, but it is worth knowing (and, perhaps, is quite interesting) to know what is going on behind the scenes.
Whether you have programmed your app in Kotlin or Java, the resulting DEX code is the same. However, there are some significant advantages to working with Kotlin.
Kotlin is named after an island near St Petersburg, Russia. Kotlin is very similar to Apple's Swift language, so learning Kotlin now will stand you in very good stead for learning iPhone/iPad development.
Kotlin is the most succinct language, and therefore is the least error-prone, which is great for beginners. Kotlin is also the most fun language, mainly because the succinctness means you can get results faster and with less code. Google considers Kotlin an official (first-class) Android language. There are some other advantages to Kotlin that make it less error-prone and less likely to make mistakes that cause crashes. We will discover the details of these advantages as we proceed.
Loads of the most advanced, innovative, and popular apps were coded using Kotlin. Just a few examples include Kindle, Evernote, Twitter, Expedia, Pinterest, and Netflix.
Before we start our Android quest, we need to understand how Android and Kotlin work together. After we write a program for Android, either in Java or Kotlin, we click a button and our code is transformed into another form, a form that is understood by Android. This other form is called Dalvik Executable, or DEX code, and the transformation process is called compiling. When the app is installed on a device, the DEX code is transformed again by the operating system into an optimized executable state.
We will see this process in action right after we set up our development environment later on in the chapter.
Android is a complex system, but you do not need to understand it in depth to be able to start making amazing apps.
To get started, we only need to understand the basics. Android runs on a specially adapted version of the Linux operating system. So, what the user sees of Android is just an app running on yet another operating system.
One purpose of this is to hide the complexity and diversity of the hardware and software that Android runs on, but, at the same time, exposing all its useful features. The exposure of these features works in two ways:
First, the operating system itself must have full access to the hardware, which it does.
Second, this access must be programmer-friendly and easy to use, and it is because of the Android application programming interface (API).
Let's continue by looking further into the Android API.
The Android API is code that makes it easy to do exceptional things. A simple analogy could be drawn with a machine, perhaps a car. When you press on the accelerator, a whole bunch of things happen under the hood. We don't need to understand combustion or fuel pumps, because some smart engineer has made an interface for us; in this case, a mechanical interface – the accelerator pedal.
For example, the following line of code probably looks a little intimidating at this stage in the book, but it serves as a good example of how the Android API helps us:
Once you learn that this single line of code searches for available satellites in space, communicates with them in their orbits around the Earth, and then retrieves your precise latitude and longitude on the surface of the planet, it becomes easy to glimpse the power and depth of the Android API.
That code does look a little challenging, even mind-boggling at this stage of the book, but imagine trying to talk to a satellite some other way!
The question we must ask, and the one this book tries to answer, is as follows: how do we use all this code to do cool stuff? Or, to frame the question to fit the earlier analogy: how do we find and manipulate the pedals, steering wheel, and, most importantly, the sunroof of the Android API?
The answer to this question is the Kotlin programming language, and the fact that Kotlin was designed to help programmers handle complexity, avoid mistakes, and make fast progress. Let's look deeper into Kotlin and object-oriented programming (OOP).
Kotlin is an object-oriented language. This means that it uses the concept of reusable programming objects. If this sounds like technical jargon, another analogy will help. Kotlin enables us and others (like the Android API development team) to write code that can be structured based on real-world things, and here is the important part – it can be reused.
So, using the car analogy, we could ask the following question: if a manufacturer makes more than one car in a day, do they redesign every part for every car that comes off the production line?
The answer, of course, is no. They get highly skilled engineers to develop exactly the right components, honed, refined, and improved over years. Then, those same components are reused again and again, as well as being occasionally improved.
If you are going to be fussy about my analogy, then you can point out that each of the car's components must still be built from the raw materials using real-life engineers or robots. This is true.
What software engineers do when they write their code is build a blueprint for an object. We then create an object from their blueprint using code and once we have that object, we can configure it, use it, combine it with other objects, and more besides.
Objects in short.
We could go on making analogies all day long. As far as we care at this point, Kotlin (and most modern programming languages) is a language that allows us to write code once that can then be used repeatedly.
This is very useful because it saves us time, and allows us to use other people's code to perform tasks we might otherwise not have the time or knowledge to write for ourselves. Most of the time, we do not even need to see this code, or even know how it does its work!
One last analogy. We just need to know how to use that code, just as we need to learn how to drive a car.
So, some smart software engineers up at Android HQ write a desperately complex program that can talk to satellites, and as a result of this, in a single line of code, we can get our location on the surface of the planet. Nice.
Most of the Android API is written in another language (Java), but this doesn't matter to us as we have full access to the functionality (coded in Java) while using the more succinct Kotlin. Android Studio and the Kotlin compiler handle the complexities behind the scenes.
The software engineers have considered how they can make this code useful to all Android programmers who want to make amazing apps that use users' locations to do cool things. One of the things they will do is make features, such as getting the device's location in the world into a simple one-line task.
So, the single line of code we saw previously sets in action many more lines of code that we don't see, and don't need to see. This is an example of using somebody else's code to make our code infinitely simpler.
If the fact that you don't have to see all the code is a disappointment to you, then I understand how you feel. Some of us, when we learn about something, want to learn every intricate detail. If this is you, then be reassured that the best place to start learning how the Android API works internally is to use it as the API programmers intended. And, throughout the book, I will regularly point out further learning opportunities where you can find out the inner workings of the Android API. Also, we will be writing classes that are themselves reusable, kind of like our own API, except that our classes will focus on what we want our app to do.
Welcome to the world of OOP. I will constantly refer to OOP in every chapter, and there will be a big reveal in Chapter 10, Object-Oriented Programming.
To get things done on Android, we write code of our own, which also uses the code of the Android API. This is then compiled into DEX code, and the rest is handled by the Android device, which, in turn, runs on an underlying operating system called Linux, which handles the complex and extremely diverse range of hardware that is the different Android devices.
The manufacturers of Android devices and of the individual hardware components obviously know this too, and they write advanced software called drivers that ensure that their hardware (for example, CPU, GPU, GPS receivers, memory chips, and hardware interfaces) can run on the underlying Linux operating system.
The DEX code (along with some other resources) are placed in a bundle of files called an Android application package (APK), and this is what the device needs to run our app.
It is not necessary to remember the details of the steps that our code goes through when it interacts with the hardware. It is enough just to understand that our code goes through some automated processes to become the app that we will publish to the Google Play store.
There is an entire range of tools needed to develop for Android, and we also need the Android API, of course. This whole suite of requirements is collectively known as the SDK. Fortunately, downloading and installing a single application will give us these things all bundled together. The application is called Android Studio.
Android Studio is an integrated development environment (IDE) that will take care of all the complexities of compiling our code and linking with the Android API. Once we have installed Android Studio, we can do everything we need inside this single application, and put to the back of our minds many of the complexities we have been discussing.
Over time, these complexities will become second nature. It is not necessary to master them immediately to make further progress.
So, we had better get our hands on Android Studio.
Visit developer.android.com/studio/index.html. Click the big DOWNLOAD ANDROID STUDIO button to proceed:
Accept the terms and conditions by checking the checkbox, and then click the DOWNLOAD ANDROID STUDIO FOR WINDOWS button:
When the download is complete, run the file you just downloaded. It has a name that starts
Click the Next > button to proceed:
The install wizard recommends 500 MB of free space, but you probably noticed from the previous screen that 2.1 GB was suggested. However, there are even more requirements later in the installation process. Furthermore, it is much easier if you have all your Android Studio parts, as well as your project files, on the same hard drive.
For these reasons, I recommend having at least 4 GB of free space. If you need to switch drives to accommodate this, then use the Browse.. button to browse to a suitable place on your hard drive.
When you are ready, click the Next > button.
In this next window, choose the folder in your start menu where Android Studio will appear. You can leave it as the default, as follows:
Click Next >.
Choose the Standard install type, as shown in the following screenshot:
Click the Next button.
Click the Finish button. Android Studio will now commence some more downloads, which could take some time.
When Android Studio is ready, you will have the option to run it. At this point, click the Finish button. Android Studio is most likely ready. You can leave it open if you are carrying straight on with the next section, or you can close it and then reopen it when instructed to in the next section.
Using your preferred file manager software, perhaps Windows Explorer, create a folder called
AndroidProjects. Make it at the root of the same drive where you installed Android Studio. So, if you installed Android Studio at
C:/Program Files/Android, then create your new folder at
Or, if you installed Android Studio at
D:/Program Files/Android, then create your new folder at
Note that the screenshots in the next section show the
AndroidProjects folder on the
D: drive. This is because my
C: drive is a bit full up. Either is fine. I did the install tutorial screen captures on a borrowed PC with plenty of space on the C: drive, because that is the default for Android Studio. Keeping it on the same drive as the Android installation is neater and could avoid future problems, so do so if you can.
Notice that there is no space between the words
Projects, and that the first letter of both words is capitalized. The capitalization is for clarity, and the omission of a space is required by Android Studio.
Now, let's look a little bit at the composition of an Android app.
We already know that we will write Kotlin code that will use other people's code, and that will be compiled into DEX code that is used on our users' Android devices. In addition to this, we will also be adding and editing other files that get included in the final APK. These files are known as Android resources.
As mentioned earlier in this chapter, our app will include resources, such as images, sound, and user interface layouts, that are kept in separate files from the Kotlin code. We will slowly introduce ourselves to them over the course of the book.
They will also include files that have the textual content of our app. It is convention to refer to the text in our app through separate files because it makes them easy to change, and easy to create apps that work for multiple different languages and geographical regions.
Android (or any computer) cannot read and recognize text in the same way that a human can. Therefore, we must present our resources in a highly organized and predefined manner. To do so, we will use Extensible Markup Language (XML). XML is a huge topic; fortunately, its whole purpose is to be both human- and machine- readable. We do not need to learn this language; we just need to note (and then conform to) a few rules. Furthermore, most of the time, when we interact with XML, we will do so through a neat visual editor provided by Android Studio. We can tell when we are dealing with an XML resource because the filename will end with the
You do not need to memorize this, as we will constantly be returning to this concept in the book.
In addition to these resources, it is worth noting that Android has a structure to its code. There are many millions of lines of code that we can take advantage of. This code will obviously need to be organized in a way that makes it easy to find and refer to. It is organized into packages that are specific to Android.
Whenever we create a new Android app, we will choose a unique name, known as a package. We will see how we do this very soon, in the section titled Our first Android app. Packages are often separated into sub-packages so that they can be grouped together with other similar packages. We can simply think of these as folders and sub-folders, which is almost exactly what they are.
We can think of all the packages that the Android API makes available to us as code from a code library. Some common Android packages that we will use include the following:
If you want to get an idea of the sheer depth and breadth of the Android API, then look at the Android package index at https://developer.android.com/reference/packages
Earlier, we learned that the reusable code blueprints that we can transform into objects are called classes. Classes are contained in these packages. We will see in our very first app how we can easily import other people's packages, along with specific classes from those packages for use in our projects. A class will usually be contained in its own file with the same name as the class.
In Kotlin, we further break up our classes into sections that perform the different actions of our class. We call these action-oriented sections functions. It is the functions of the class that we will use to access the functionality provided within all the millions of lines of Android code.
We do not need to read the code. We just need to know which class has what we need, which package it is in, and which function from within the class gives us precisely the result we are after.
We can think of the structure of the code we will write ourselves in the same way, although we will usually have just one package per app.
Of course, because of the object-oriented nature of Kotlin, we will only be using selected parts from this API. Note also that each class has its own distinct data. Typically, if you want access to the data in a class, you need to have an object of that class.
You do not need to memorize this, as we will constantly be returning to this concept in the book.
By the end of this chapter, we will have imported multiple packages, as well as some classes from them. By the end of Chapter 2, Kotlin, XML, and the UI Designer, we will have even written our very own functions.
Now we can get started on our first app. In programming, it is tradition for the first app of a new student to use whatever language/OS they are using to say hello to the world. We will quickly build an app that does just that, and, in Chapter 2, Kotlin, XML, and the UI Designer, we will go beyond that and add some buttons that respond to the user when they are clicked.
The complete code as it stands at the end of this chapter is in the download bundle in the
Chapter01 folder for your reference. You can't simply copy and paste this code, however. You still need to go through the project creation phase explained in this chapter (and at the beginning of all projects) as Android Studio does lots of work behind the scenes. Once you become familiar with these steps and understand which code is typed by you, the programmer, and which code/files are generated by Android Studio, you will then be able to save time and typing by copying and pasting from the files I supply in the download bundle.
Follow these steps to start the project:
Run Android Studio in the same way you run any other app. On Windows 10, for example, the launch icon appears in the start menu.
After this, Android Studio will bring up the Choose your project window, as follows:
We will use the Basic Activity option, as selected in the previous screenshot. Android Studio will autogenerate some code and a selection of resources to get our project started. We will discuss the code and the resources in detail in the next chapter. Select Basic Activity and click Next.
This next screen is the Configure your project screen, where we will perform the following steps and a few more things as well:
Name the new project
Provide a company domain as a package name to distinguish our project from any others, in case we should ever decide to publish it on the Play Store
Choose where on our computer the project files should go
Select our preferred programming language
The name of our project is going to be
Hello World,and the location for the files will be your
AndroidProjectsfolder that we created in the Setting up Android Studio section.
The package name can be almost anything you like. If you have a website, you could use the
com.yourdomain.helloworldformat. If not, feel free to use
com.gamecodeschool.helloworld,or something that you just make up. It is only important when you come to publish it.
To be clear, in case you can't see the details in the following screenshot clearly, here are the values I used. Remember that yours might vary depending upon your choice of company domain and project save location:
Minimum API Level:
Leave at whatever the default is
This project will support instant apps:
Leave at whatever the default is
Use AndroidX artifacts:
Select this option
Note that the application name has a space between "Hello" and "World," but the project location does not, and will not work if it does.
Regarding the Minimum API level setting, we already know that the Android SDK is the collection of packages of code that we will be using to develop our apps. Like any good SDK, the Android SDK is regularly updated, and each time it gets a significant update, the version number is increased. Simply put, the higher the version number, the newer the features you get to use; the lower the version number, the more devices our app will work on. For now, the default API 15, Android 4.0.3 (IceCreamSandwich) version will give us lots of great features and near 100% compatibility with the Android devices currently in use. If, at the time of reading, Android Studio is suggesting a newer API, then go with that.
If you are reading this some years in the future, then the Minimum API option will probably default to something different, but the code in this book will still work.
You can write Android apps in a few different languages, including C++ and Java. There are various advantages and disadvantages to each compared to using Kotlin. Learning Kotlin will be a great introduction to other languages, and Kotlin is also the newest (and arguably best) official language of Android.
At this stage, you might be ready to proceed but, depending on the install process, you might need to click a couple of extra buttons.
Look in the bottom window of Android Studio and see if you have the following message:
Before we explore any of the code and learn our first bit of Kotlin, you might be surprised to learn that we can already run our project. It will be a fairly featureless screen, but as we will be running the app as often as possible to check our progress, let's see how to do that now. You have three options:
Run the app on the emulator on your PC (part of Android Studio) in debug mode
Run the app on a real Android device in USB debugging mode
Export the app as a full Android project that can be uploaded to the Play Store
The first option (debug mode) is the easiest to set up, because we did it as part of setting up Android Studio. If you have a powerful PC, you will hardly see the difference between the emulator and a real device. However, screen touches are emulated by mouse clicks, and proper testing of the user experience is not possible in some of the later apps, such as the drawing app. Furthermore, you might just prefer to test out your creations on a real device – I know I do.
The second option, using a real device, has a couple of additional steps, but, once set up, is as good as option one, and the screen touches are for real.
The final option takes about five minutes (at least) to prepare, and then you need to manually put the created package onto a real device and install it (every time you make a change to the code).
The best way is probably to use the emulator to quickly test and debug minor increments in your code, and then use the USB debugging mode on a real device fairly regularly to make sure things are still as expected. Only occasionally will you want to export an actual deployable package.
If you have an especially slow PC or a particularly aging Android device, you will be fine just running the projects in this book using just one option or the other. Note that a slow Android phone will probably be OK and cope, but a very slow PC will probably not handle the emulator running some of the later apps, and you will benefit from running them on your phone/tablet.
For these reasons, I will now go through how to run the app using the emulator and USB debugging on a real device.
On the Android Studio main menu bar, select Tools | AVD Manager. AVD stands for Android Virtual Device (an emulator). You will see the following window:
Notice that there is an emulator in the list. In my case, it is Pixel 2 XL API 28. If you are following this sometime in the future, it will be a different emulator that was installed by default. It won't matter. Click the green play icon (to the right) shown in the following screenshot, and wait while the emulator boots up:
Now you can click the play icon on the Android Studio quick-launch bar as shown in the following screenshot and, when prompted, choose Pixel 2 XL API 28 (or whatever your emulator is called) and the app will launch on the emulator:
We need to test and debug our apps often throughout development to check for any errors, crashes, or anything else unintended.
We will see how we get errors and other feedback for debugging from our apps in the next chapter.
It is also important to make sure it looks good and runs correctly on every device type/size that you want to target. Obviously, we do not own one of each of the many thousands of Android devices. This is where emulators come in.
Emulators, however, are sometimes a bit slow and cumbersome, although they have improved a lot recently. If we want to get a genuine feel for the experience our user will get, then you can't beat deploying to a real device. So, we will want to use both real devices and emulators while developing our apps.
If you are planning on using the emulator again soon, leave it running to avoid having to wait for it to start again.
If you want to try out your app on a tablet, you're going to need a different emulator.
Creating a new emulator
It is simple to create an emulator for a different Android device. From the main menu, select Tools | AVD Manager. In the AVD Manager window, left-click Create New Virtual Device. Now left-click on the type of device you want to create – TV, Phone, Wear OS, or Tablet. Now simply left-click Next and follow the instructions to create your new AVD. Next time you run your app, the new AVD will appear as an option to run the app on.
Now we can look at how we can get our app onto a real device.
The next few steps will set up the Android device for debugging. Note that different manufacturers structure the menu options slightly differently to others. But the following sequence is probably very close, if not exact, for enabling debugging on most devices:
Tap the Settings menu option or the Settings app on your phone/tablet.
This next step will vary slightly for different versions of Android. The Developer options menu is hidden away so as not to trouble regular users. You must perform a slightly odd task to unlock the menu option. Tap the About device or About Phone option. Find the Build Number option and repeatedly tap it until you get a message informing you that You are now a developer!
Go back to the Settings menu.
Tap Developer options.
Tap the checkbox for USB Debugging.
Connect your Android device to the USB port of your computer.
Click the play icon from the Android Studio toolbar, as shown in the following screenshot:
When prompted, click OK to run the app on your chosen device.
Q) So, Android isn't really an operating system; it is just a virtual machine and all Android phones and tablets are really Linux machines?
A) No, all the different subsystems of an Android device, which include Linux, the libraries, and the drivers, are what make up the Android operating system.
So far, we have set up an Android development environment, and created and deployed an app on both an emulator and a real device. If you still have unanswered questions (and you probably have more than at the start of the chapter), don't worry, because as we dig deeper into the world of Android and Kotlin, things will become clearer.
As the chapters progress, you will build a very rounded understanding of how everything fits together, and then success will just be a matter of practice and digging even deeper into the Android API.
In the next chapter, we will edit the UI using the visual designer and raw XML code, as well as writing our first Kotlin functions, and we will get to use some of the functions provided for us by the Android API.