Implementing Navigation Drawer in Android Studio Step by Step

A navigation drawer gives an Android app a compact way to expose several destinations from one screen. It is especially useful when the app has sections such as Home, Profile, Settings and Help, while keeping the main content area uncluttered.

This guide explains implementing Navigation Drawer in Android Studio with Kotlin, XML layouts and AndroidX components. The approach suits a practical Australian app, whether it serves commuters in Sydney, students in Melbourne or customers checking services during a Brisbane commute.

Approach	Best for	Advantages	Trade-offs
DrawerLayout with NavigationView	Traditional XML-based apps	Reliable, familiar and quick to implement	Requires careful fragment and state handling
Navigation component with a drawer	Multi-screen applications	Centralised destinations and back-stack support	More setup at the beginning
Jetpack Compose drawer	New Compose projects	Modern declarative UI and flexible styling	Not ideal for an existing XML project

Choose The App Structure

A drawer normally contains a DrawerLayout as its root. Inside it, place the main content view first and a NavigationView second. The navigation view slides over the content from the start edge, which automatically adapts to left-to-right and right-to-left languages.

For a maintainable project, use one activity with multiple fragments. The activity owns the drawer, toolbar and navigation events, while each fragment displays one destination. This keeps the interface consistent and prevents every screen from implementing its own side panel.

The Android navigation component can manage fragment transactions and back-stack behaviour. It is a sound choice for an app that may grow beyond a few screens, such as a local transport, retail or community service application.

Create The Android Studio Project

Start a new Android Studio project using the Empty Views Activity template. Select Kotlin, set a sensible minimum SDK, and use an application name that reflects the product. Australian users may access an app on a broad range of devices, so test layouts on both compact phones and larger tablets.

Add the AndroidX dependencies required by the project. In a typical module-level Gradle file, these include Material Components, DrawerLayout, NavigationView, the Navigation component and lifecycle libraries. Android Studio can suggest current versions, so avoid copying old versions from unrelated tutorials.

For a practical reference while comparing XML patterns, Android tutorial examples can provide additional background. Treat external snippets as learning material and check their APIs against the current Android Studio release before adding them to a production project.

Create three simple fragments such as HomeFragment, ProfileFragment and SettingsFragment. Give each fragment a clear layout and a visible heading. Distinct content makes it easier to confirm that drawer selection and back navigation work correctly.

Build The Drawer Layout

Open res/layout/activity_main.xml and create the main container. A basic structure looks like this:

<androidx.drawerlayout.widget.DrawerLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:id="@+id/drawer_layout"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical">

        <com.google.android.material.appbar.MaterialToolbar
            android:id="@+id/toolbar"
            android:layout_width="match_parent"
            android:layout_height="?attr/actionBarSize" />

        <androidx.fragment.app.FragmentContainerView
            android:id="@+id/nav_host"
            android:layout_width="match_parent"
            android:layout_height="match_parent" />
    </LinearLayout>

    <com.google.android.material.navigation.NavigationView
        android:id="@+id/navigation_view"
        android:layout_width="wrap_content"
        android:layout_height="match_parent"
        android:layout_gravity="start"
        app:menu="@menu/drawer_menu" />

</androidx.drawerlayout.widget.DrawerLayout>

The content area must appear before the NavigationView, allowing the drawer to overlay it. android:layout_gravity="start" is preferable to left, because it supports different writing directions and follows Android accessibility conventions.

Keep the drawer width comfortable without allowing it to dominate the screen. Material guidance generally places it around 280 to 320dp on phones. Use a navigation header only when it adds real value, such as showing a signed-in name or account status.

Add Menu Items And Destinations

Create res/menu/drawer_menu.xml and define the destinations with stable IDs:

<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <group android:checkableBehavior="single">
        <item
            android:id="@+id/nav_home"
            android:icon="@drawable/ic_home"
            android:title="@string/home" />
        <item
            android:id="@+id/nav_profile"
            android:icon="@drawable/ic_person"
            android:title="@string/profile" />
        <item
            android:id="@+id/nav_settings"
            android:icon="@drawable/ic_settings"
            android:title="@string/settings" />
    </group>
</menu>

Place visible text in strings.xml, rather than hard-coding labels in the menu. This supports translation and makes wording easier to update. Use familiar language for the target market: “Account” may be clearer than “User Details”, while “Help and Support” is more useful than a vague “Info”.

Icons should be simple, recognisable and visually consistent. Do not rely on colour alone to identify the current destination. The selected menu item should have a clear state, sufficient contrast and a touch target that works for people using a phone one-handed on a train or tram.

Connect The Drawer To Kotlin

In MainActivity.kt, bind the toolbar, drawer and navigation view. If using the Navigation component, connect the navigation controller to the toolbar and drawer:

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val drawer = findViewById<DrawerLayout>(R.id.drawer_layout)
        val toolbar = findViewById<MaterialToolbar>(R.id.toolbar)
        val navigationView = findViewById<NavigationView>(R.id.navigation_view)
        val navHost = supportFragmentManager
            .findFragmentById(R.id.nav_host) as NavHostFragment
        val navController = navHost.navController

        setSupportActionBar(toolbar)

        val appBarConfiguration = AppBarConfiguration(
            setOf(R.id.nav_home, R.id.nav_profile, R.id.nav_settings),
            drawer
        )

        setupActionBarWithNavController(navController, appBarConfiguration)
        navigationView.setupWithNavController(navController)
    }
}

The destination IDs in the navigation graph must match the IDs in the drawer menu. Add each fragment to nav_graph.xml, set nav_home as the start destination, and define actions only when a direct transition is required. setupWithNavController then handles selection and closes the drawer after navigation.

If you are handling fragments manually, set an OnNavigationItemSelectedListener, replace the fragment inside a transaction, mark the selected item, and call drawer.closeDrawer(GravityCompat.START). The Navigation component is usually less error-prone because it handles back-stack details for you.

Manage State And Back Navigation

A drawer should open from the toolbar icon and close when the user presses the system Back button. The Navigation component generally manages destination changes, but custom behaviour should still be tested. Avoid creating duplicate fragments every time a menu item is tapped, as this can make Back navigation confusing.

Preserve screen state with ViewModel, SavedStateHandle or fragment state rather than relying on view references. For example, a form in Profile should not unexpectedly lose its fields when the user briefly opens Settings. Restore scroll positions and loading states when appropriate.

Use DrawerLayout callbacks sparingly. They are useful for analytics or updating accessibility announcements, but navigation logic belongs in the controller or activity. On slow mobile connections, such as those experienced in regional New South Wales or while travelling through patchy coverage, show loading feedback inside the destination rather than blocking the drawer.

Test The User Experience

Run the app on an emulator and a physical Android phone. Test opening the drawer with the toolbar icon, swiping from the edge, selecting every item, pressing Back and rotating the device. Check that the selected destination remains highlighted and that the toolbar title changes correctly.

Test accessibility with TalkBack, larger font settings and sufficient colour contrast. Make sure icons have meaningful descriptions where required, menu labels are concise and the drawer does not trap focus. Australian users include people with varied devices, network conditions and accessibility needs, so a polished drawer should remain useful beyond a developer emulator.

Also check tablet and landscape layouts, offline behaviour and authentication expiry. If an account session ends while a customer is checking a service in Perth or reviewing an order in Adelaide, the drawer should show a clear route to sign in again rather than failing silently.

Build the release variant, inspect the APK or app bundle, and test it on the Android versions your support policy covers. Then implement the drawer in a small feature branch, connect each destination to real content, and verify the complete navigation flow before releasing it through your chosen distribution channel.