What Android development actually involves

Most people picture Android development as drawing screens. Screens are the visible part, and the smaller part. The job is making those screens behave on a phone you have never seen, running a version of Android you did not test on, with a signal that comes and goes, while the operating system reserves the right to kill your app whenever it needs the memory. This lesson says what the work actually is, what this course uses to do it, and introduces the app you will build.

What the job is

An Android app is a program that the operating system starts, pauses, stops and sometimes destroys, mostly without asking you. Everything in this course is a response to that. Here is the work, and where each piece is taught:

Notice how little of that table is "drawing". A junior who can build a beautiful screen but loses the user's form on rotation is not yet useful on a team. Android rewards the developer who understands the platform, not the one who can make the prettiest mock-up.

Kotlin and Compose: today's default

Two choices are made for you in this course, and they are the same two a new Android team would make today.

Kotlin, not Java. Google declared Android development "Kotlin-first" in 2019, and every new library, sample and guide since has been written for Kotlin first. Java still works and you will meet it in older codebases, but Jetpack Compose cannot be written in Java at all. You learnt the language in the Kotlin Complete Foundation course; this course assumes it, including coroutines.

Jetpack Compose, not XML layouts. Compose describes a screen as Kotlin functions: you say what the screen should look like for the current data, and Compose redraws the parts that changed. Android Studio's New Project wizard now recommends its Compose template as the starting point for every new app.

What this costs you, honestly:

• Most answers on the internet are older than Compose. Search for an Android problem and half the results talk about findViewById, setContentView(R.layout...) and RecyclerView. Those are the XML View system. They are not wrong, they are a different toolkit, and pasting them into a Compose app produces confusion rather than errors.
• Existing apps are full of XML. Any company app older than a few years has hundreds of XML layouts. That is why this course has one module on reading them, near the end. Nobody starts new screens that way, so one module is all they get.

What Android development is not

Being clear about this saves some of you weeks.

• It is not iOS. An Android app does not run on an iPhone. If your users are on iPhones, you need our Swift and iOS Development course, which needs a Mac. If you want one codebase for both, our Kotlin Multiplatform with Compose course shares Kotlin code, and much of the UI, across Android and iOS. Learn Android first either way; Multiplatform assumes it.
• It is not the web. If what you need is a page people visit once, such as a price list or a booking form, a fast website reaches more people for less work and needs no install. An app earns its place when it is used repeatedly, works offline, sends notifications or uses the phone's hardware.
• It is not "write once, run anywhere". Android runs on thousands of device models. Your code is the same everywhere; the conditions it runs in are not.

The phone your users actually have

Here is the fact that shapes every decision in this course. Your laptop is fast, your phone is probably decent, and your Wi-Fi is good. Your users' situation is usually none of those.

In India, a large share of Android users are on budget phones. Think of a phone that was cheap two or three years ago:

• Little memory, shared with everything. WhatsApp, the camera, a payments app and a dozen apps the manufacturer preinstalled are all competing with yours. When memory runs short, Android kills background apps, and yours is one of them. Coming back to an app that was killed is the scenario the lifecycle module exists for.
• An old Android version that will never be updated. Many budget phones get one major update, or none. The phone a farmer bought in 2020 may run that year's Android for its whole life. This is called fragmentation: your app runs on many versions at once, and you must decide which is the oldest you support. That decision has a name, minSdk, and you make it in lesson 3.
• Patchy, metered data. A mobile signal in a mandi yard or on a train out of Pune drops to almost nothing, and people buy data in small packs. An app that shows a spinner forever, or downloads 10 MB on every launch, gets uninstalled.
• Storage nearly full. A 200 MB app competes with family photos for the last gigabyte. App size matters.
• Aggressive battery savers. Several manufacturers add their own rules on top of Android's for killing background work. Your daily sync must be built to survive them.

This is why the course spends so long on lifecycle, state, caching and background work. Those modules are not padding. They are the difference between an app that works on your desk and one that works in a farmer's pocket.

The app you will build: Mandi Bhav

Across the course you build one app, Mandi Bhav ("market price"), which shows agricultural market prices from APMC mandis to farmers and traders.

A price in Mandi Bhav is always for one commodity, at one market, on one date, in rupees per quintal (100 kg). A mandi does not have one price for onions on a given day; lots of different quality sell at different prices. So each record has three numbers:

The modal price is the one people mean when they ask "what is onion at today?". The maximum is usually a few lots of the best quality and misleads anyone who reads it as typical.

The markets you will see are real: Pune (Gultekdi) APMC, Lasalgaon (Asia's largest onion market), Nashik and Vashi in Navi Mumbai. The commodities are the everyday ones: onion, tomato, potato, soybean, wheat, tur dal.

Two people use it:

• Arjun, a farmer near Nashik with forty quintals of onion, deciding whether the drive to Lasalgaon is worth more than selling at Nashik. He has a three-year-old budget phone and one bar of signal.
• Kavita, a trader in Pune comparing tomato prices across four markets before she places an order. She checks the app twenty times a day.

You will start with a single screen that says hello, and by the end Mandi Bhav will remember the last prices it downloaded so it works with no signal, refresh them once a day in the background, notify Arjun when onion crosses a price he chose, and find the nearest market from his location. Each of those is a module, and each one exists because of the phone in Arjun's pocket.

The trap: building for your own phone

The most common mistake in Android development is invisible while you make it. You build on a fast laptop, test on a fast emulator or your own recent phone, on office Wi-Fi, and everything is instant. Then the app reaches a two-year-old budget phone on a weak signal, and it starts slowly, stutters on every scroll and shows a blank screen while it waits for the network.

Nothing in your code was wrong in the sense of a compiler error. It was wrong for the user. The habit to build from today: every time you finish a feature, ask how it behaves on Arjun's phone, not yours. Lesson 4 shows you how to make your emulator slower and your network worse on purpose.

Check your work

Why is "drawing screens" the smaller part of the job? Most of the work is keeping state, handling the lifecycle, storing data, networking and background work, because Android starts, stops and kills apps without asking.

Why can you not write this course's screens in Java? Jetpack Compose is Kotlin-only.

You find an answer that uses findViewById and setContentView(R.layout.main). What is it? Code for the older XML View system, not Compose. Useful for reading old apps, not for pasting into Mandi Bhav.

A friend wants their app on iPhones too. What do you tell them? Android apps do not run on iOS; they need the Swift and iOS course, or Kotlin Multiplatform for one shared codebase.

What is fragmentation? Your app running on many Android versions and device models at once, many of them never updated.

In Mandi Bhav, what unit is every price in, and which of the three numbers is "the price"? Rupees per quintal (100 kg); the modal price is the typical one.

Practice

1. On your own phone, open Settings → About phone and find the Android version. Note it down; in lesson 4 you read its API level straight off the phone with adb.
2. Ask two or three people in your family which phone they use, how old it is, and roughly how much free storage it has. Write the answers down. These are your real users.
3. Turn on your phone's data saver, stand somewhere with weak signal, and open three apps you use daily. Note which ones show something useful immediately and which show a spinner. That difference is a design decision someone made.
4. For Mandi Bhav, write one sentence each on what Arjun should see if he opens the app with no signal at all, with a weak signal, and with good signal. Keep the page; the caching module answers it properly.
5. Harder: pick an app you use that you suspect was built on a fast phone. Find one specific thing it does badly on a slow connection or an old device, and write down how you would have built it differently. You do not need code yet; you need the habit of looking.

Official documentation

• Android — Kotlin-first — Google's own statement of why new Android work is Kotlin, including the table of what is Kotlin-only.
• Jetpack Compose — The official home of the UI toolkit this course uses throughout.
• Kotlin Multiplatform — get started — Where to go if you need iOS as well as Android from one codebase.

Next: installing Android Studio and the SDK, and what all those downloads actually are.