1. Welcome to Android & Kotlin

Written by Ricardo Costeira

The year 2023 marked 50 years since the first mobile phone call was made. Since then, mobile phones evolved to be much more than “simple” brick-like devices that let you make phone calls.

Today, smartphones (and consequently mobile apps) are ingrained in the DNA of modern society. Around 90 percent of the world’s population has a smartphone, and each smartphone has in it a selection of apps its user chose to install — or that came already loaded on the phone.

To install an app, the smartphone user will generally rely on an app store. App stores like Google Play provide access to millions of apps, which can be anything from simple games to educational, self-organization or banking apps. The world is overflowing with mobile apps, to the point where it’s not uncommon to hear someone saying things like, “There’s an app for that”.

To allow for such variety and to use all the useful features of a smartphone — things like geolocation, audio, video or simply internet access — can you imagine how large a mobile development framework must be? Well, it has to be huge. And spoiler alert: Android is even larger than that, given the amount of “developer quality of life” focused bits it has. In fact, it’s so large at this point that even people who have been developing on Android for years sometimes feel overwhelmed by it.

How Apps Work

Don’t let what you just read scare you. One of the good things about Android is that you don’t really need to know all about the framework to build apps in a proper, maintainable way. Instead, it’s way less time consuming (and healthier for you!) if you learn it as you need it.

Developers can write Android apps using a variety of technologies. You can write apps using a natively supported language like Java or Kotlin (the Android framework is a mix of both), or you can follow a different path and use a framework like React Native or Flutter. With external frameworks, you have the advantages of having specific aspects of app development already implemented for you while developing for both Android and iOS at the same time. However, there usually are trade-offs, such as a decrease in app performance or API availability.

For this book, you’ll use Kotlin, which has been Google’s recommended development language for Android since 2019. Kotlin is a modern and powerful language that incorporates a lot of features from both the object-oriented and functional programming paradigms. It can be really fun to use, and it fits Android like a glove. Not only does it have the advantage of being natively supported — which means fewer compatibility issues and therefore greater API support and performance — but its multiplatform features have evolved enough to make it compete with every other Android and iOS hybrid solution.

Now, before you start building an app, it’s useful to understand the gist of how Android apps work, so you later can connect the dots as you develop your own.

Each app lives in its own security sandbox. What happens in the app, stays in the app. No other apps can know about what’s happening in it, unless the app specifically allows it. On the other hand, this also means the app can’t access specific parts of the system (like other apps, specific files or device information) unless the system allows it.

App Components

To build an Android app, developers use components. There are four components:

• Activity: This is probably the one you’ll use the most. In the beginning of Android, you could assume an Activity would represent a single screen of an app, letting the user interact with it. These days, you can host multiple screens in the same Activity. In fact, that is the preferred architecture now, because Activity creation and maintenance can become resource-heavy.
• Service: Services can keep an app working in the background. For instance, do you have an app that keeps playing music even when you put it in the background? Then there’s likely a Service running. Because their purpose is to do some kind of work, Services do not provide any user interaction.
• Content Provider: It manages and persists data, with the advantage of letting the app share that data with other apps. If the content provider allows it, these other apps can even modify the data. In general, you create a content provider when you want to share data. If your purpose is to simply store data, you can use other methods that better suit your needs — you’ll learn about them in this book!
• Broadcast Receiver: As the name implies, it lets the app receive specific events the system broadcasts. The app itself or other apps can send those events. As event handlers, these components usually just delegate whatever work the event implies to other kinds of components.

All components are entry points to an app. This means that the Android system is capable of either launching your app or at least creating a process for it, to execute whatever component it’s trying to run. This can happen in two situations:

1. When the user tries to open your app. Here, the system launches the Activity you set as the starting one.
2. When another app requires some work or action your app is capable of. In this case, the system launches the required component.

To launch a component or communicate between different ones, you use Intents for Activities, Services and Broadcast Receivers, or Content Resolvers for Content Providers.

An Intent is like a message an app can send to the system. The Intent contains all the information the system needs to figure out what component it should launch. For instance, when an Android app has many Activities, it uses Intents so a certain Activity can start the next one. The cool thing about Intents is they can also launch components from other apps. An example of this is when you press a “share” button in an app, and a bottom sheet with app suggestions pops up.

A Content Resolver, on the other hand, is much more limited. It “simply” acts as a middle man between a Content Provider and the component that wants to communicate with it.

App Manifest

The Android system needs to know about every component an app has. Otherwise, it won’t know which components to launch. This is done through the Manifest file. In the manifest, you define every component an app has, along with all their capabilities. For example, this is how you’d define the Activity that the system launches when opening your app:

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
  <!-- // 1 -->
  <application ... >
    <!-- // 2 -->
    <activity
      android:name=".MainActivity"
      android:exported="true"
      android:label="@string/app_name"
      android:theme="@style/SplashTheme">
      <!-- // 3  -->
      <!-- Specifies the kind of Intents the Activity can respond to -->
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
    </activity>
    ...
  </application>
</manifest>

Glancing through the code, you can see:

1. The <application> element, the parent for all component elements.
2. The <activity> element, which effectively declares the existence of an Activity called MainActivity.
3. An <intent-filter> element, which tells the system this is the Activity to launch first if the user tries to launch your app and there’s no running process for the app.

Every time you add a new component to your app, you need to declare it here. If you don’t, don’t worry — an immediate crash when you try to launch the component in the app will let you know something’s wrong. :]

You can use the manifest file for more things, like declaring any user permissions your app might need or what hardware features it requires. If your app was a pack of cookies, the manifest would be the “ingredients” label on the back. It’s through the manifest file that the Android system knows what to expect from your app.

App Resources

Besides regular code, apps also need other kinds of resources: things like images, sounds, animations, colors … they all fall under the umbrella of app resources.

Anything that doesn’t have its own format (like images or sounds), you define with XML just like the manifest file. For instance, you can use XML to define user interfaces or themes for your screens. You’ll have access to these resources programmatically through code. Also, resources can access other resources.

Resource files are really important because they let Android apps adapt to multiple devices and languages. You can use resources to define the strings of text your app displays and do so in different languages so your app automatically uses the correct one. You can also use resources to prepare your app for different device screen sizes and resolutions: through the use of different resource files, you can make your app’s screens show a completely different element arrangement depending on how much screen real estate is available on the device.

Putting it All Together

When you have your code ready, resources loaded and components declared, you’ll want to compile your code. To do that, Android typically uses the Gradle build system. Gradle is a build automation tool that sometimes can be as scary as it is powerful.

The easiest way to build an Android app with Gradle is by using the Android Gradle plugin, which adds several Android specific features on top of Gradle. On top of this, you can still define your own Gradle scripts for any specific actions you might need.

You can write Gradle scripts using Groovy or, as of late, Kotlin. As you go through the book, you’ll interact with Gradle using — surprise, surprise — Kotlin. Just like with Android code, Google now recommends Kotlin as the preferred way to build your Gradle scripts. Kotlin provides a few extremely important advantages over Groovy, such as IDE support, compile-time checking and better readability. Thanks for the green light, Google!

When you’re ready to publish an app, you can use Gradle to build a release version. In a release version, all the code is compiled (and ideally obfuscated) into a file you can then use to install and distribute the app, either by yourself or through an app store.

What You’ll Learn in This Book

Whew, that’s a lot of stuff to go through. It’s easy to get lost in all that, especially as you start digging more deeply. But fear not! That’s precisely where this book comes in.

You’ll start by learning how to set up Android Studio, and from there you’ll learn the fundamentals of an Android app, such as lifecycles, views and other important topics. You’ll also dig deeper into some of the topics already mentioned here, such as manifests, resources and Intents.

You’ll learn how to deal with app dependencies and how to configure your Gradle build system. You’ll learn how to build cool user interfaces with Jetpack Compose, the UI toolkit that got Android developers all over the world excited for UI again, because it replaces the original XML-based one.

You’ll learn how to manage the state of a screen and how to navigate between the screens of your app. You’ll learn how to perform network requests to enrich your app with external data and how to store and keep data secure as well. To top it all off, you’ll also learn a few best practices as you go, both around app architecture and coding in general.

As you progress through the book, you’ll work on different apps. Sometimes, chapters will build upon the previous chapter’s app. Other times, you’ll work on an entirely new one. But each time, the app you’ll work on will adapt to the topic you’re learning.

By the end of the book, you’ll have a solid grasp of all the basics you need to build performant and scalable Android apps from the ground up. Heck, you’ll even learn some advanced stuff as a bonus!

Anyway, buckle up: Your journey as an Android Developer starts now. Have fun! :]

Key Points

• You can write native Android apps using Java or Kotlin. There are also multiplatform frameworks, such as React Native or Flutter.

• Android apps may consist of the following components: Activities, Services, Content Providers and Broadcast Receviers.

• You write a manifest file to declare the components an app has. You also declare permissions and hardware features the app requires.

• Besides regular code, an app also contains resources, such as images, sounds, animations and colors.

• To compile an app, you’ll use Gradle.

Where to Go From Here?

If you can’t wait to get started and want to learn how to set up and work with Android Studio, you can proceed to the next chapter of the book.

The book can only fit so much information, so sometimes you might feel the need to dig more deeply into some specific topic. If that’s the case, you have two excellent starting points: the Android content at Kodeco, or Android’s official documentation.

To learn more about Kotlin, you can check Kodeco’s Kotlin content or the official Kotlin documentation.