Project Structure

Now that TrailLog actually runs, it's worth taking a step back and touring the rest of the folders Android Studio generated. You'll be reaching into most of these throughout the entire track, so knowing what belongs where — before you need it — will save you a lot of hunting later.

Reference: The Generated Project Layout

Why .gradle.kts Instead of .gradle

If you've looked at older Android tutorials (including this site's own Android (Java) track), you may have seen build files named build.gradle and written in Groovy. Recent versions of Android Studio generate Kotlin DSL build scripts by default instead — build.gradle.kts and settings.gradle.kts — because they give you real Kotlin syntax, type checking, and IDE auto-complete inside your build configuration, rather than Groovy's more loosely-typed script syntax. A quick preview of what that looks like:

android {
    compileSdk = 34

    defaultConfig {
        applicationId = "com.codingwithsonu.traillog"
        minSdk = 24
        targetSdk = 34
        versionCode = 1
        versionName = "1.0"
    }
}

We'll cover this syntax properly, including how dependencies are declared and how build variants work, in the dedicated Gradle Kotlin DSL lesson later in this track. For now, just recognize the .kts extension as "this is a Kotlin-flavored build file," and know it behaves the same conceptually as the older Groovy files even though the syntax differs.

The strings.xml Convention

res/values/strings.xml holds every piece of user-facing text in the app as a named resource, rather than as a literal string typed directly into a layout or a Kotlin file. This is a convention worth taking seriously from the very first screen, for one main reason: localization. If you ever want TrailLog to support more than one language, Android resolves strings.xml based on the device's locale automatically — you add a res/values-fr/strings.xml (for French) or res/values-es/strings.xml (for Spanish) with translated versions of the same resource names, and the system picks the right one with zero changes to your layouts or code. Text hardcoded directly into a layout's android:text attribute can't be translated this way at all.

Worked Example: Adding TrailLog's App Name as a String Resource

First, the resource itself in res/values/strings.xml:

<resources>
    <string name="app_name">TrailLog</string>
</resources>

Referencing it from an XML layout uses the @string/ prefix followed by the resource name:

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/app_name" />

And referencing the same resource from Kotlin code uses getString(), available on any Activity or Context:

val appName = getString(R.string.app_name)
println("Running: $appName")

Both references point at exactly the same underlying value, so updating the string in one place — strings.xml — updates it everywhere it's used, in every layout and every Kotlin file, without a single find-and-replace.

res/drawable and res/mipmap

Two more resource folders you'll touch constantly:

• res/drawable — icons, shapes, and images used inside the app's UI (a trail difficulty icon, a background shape for a button, a photo placeholder).
• res/mipmap — specifically the app's launcher icon, kept separate from drawable because launcher icons need to be generated at several densities for different home-screen icon sizes across devices.

What's Ahead

Right now, res/layout only holds the single activity_main.xml from the previous lesson. As this track progresses through the Core Concepts and UI sections, we'll steadily fill this folder in with real TrailLog screens — a trail list, a trail detail screen, an add/edit form for logging a new hike — each backed by its own Activity or Fragment, its own layout file, and its own set of string resources following the same conventions covered on this page.