Whether you're targeting Android development, scalable backend services, or cross-platform applications, this course takes you from writing your first line of code to mastering asynchronous programming and reactive streams.

Here are the things covered in this course:

• Fundamentals & Setup
  Installing IntelliJ IDEA, understanding the JVM, type inference, primitive types, control flow (when, loops), and Kotlin’s built-in null safety.

• Functions & Collections
  Default arguments, vararg, lambda functions, arrays, collections (List, Set, Map), binary search, and error handling.

• Modern OOP
  Primary/secondary constructors, init blocks, data classes, sealed classes, companion objects, singletons, delegation, and extension functions.

• Deep-Dive Generics
  Variance (in/out), upper bounds, the where clause, and working around JVM type erasure using reified type parameters.

• Coroutines
  Non-blocking asynchronous programming using launch, async, runBlocking, structured concurrency, timeouts, cancellations, and withContext.

• Kotlin Flows & Reactive Streams
  Cold streams, intermediate and terminal operators (launchIn, asLiveData), exception transparency, retry logic, and lifecycle handling.

The course is completely free and available now on the freeCodeCamp.org YouTube channel (10-hour watch).

Historically, accessibility has often been treated as an afterthought. Something to consider only if time permitted before a release.

Today, that perspective has fundamentally changed. With regulations like the European Accessibility Act (EAA) taking effect across European Union markets, building accessible software is increasingly a legal and business requirement.

More importantly, building accessible applications is just good engineering. Accessible apps improve usability for all users and help make sure that you're not excluding a substantial portion of your potential audience.

Jetpack Compose simplifies accessibility compared to the traditional Android View system. Because Compose is declarative and state-driven, it manages semantic metadata alongside your visual user interface.

In this comprehensive guide, you will learn how accessibility works in Jetpack Compose, how to use the Semantics tree, how to apply essential and advanced accessibility patterns, and how to thoroughly test your apps using automated tests, Google's Accessibility Scanner, Android Studio's Layout Inspector, and TalkBack.

Prerequisites

To follow along with this guide, you'll need:

• Basic familiarity with Kotlin and Jetpack Compose (such as Composables, Modifiers, and State).

• Android Studio (Hedgehog, Iguana, Jellyfish, Koala, Ladybug, or newer).

• An Android device or emulator running Android 9.0 (API 28) or higher with access to the Google Play Store (to install and run the current version of Google Accessibility Scanner).

Table of Contents

• Prerequisites

• Why Accessibility Matters in Modern Android Development

• Core Concepts of Android Accessibility

• Semantics in Jetpack Compose

• Essential Accessibility Practices

• Advanced Accessibility Techniques

• How to Test and Debug Accessibility

• Real-World Accessible UI Patterns

• Accessibility Audit Checklist

• Conclusion and Next Steps

• Essential Resources

Why Accessibility Matters in Modern Android Development

According to the World Health Organization (WHO), more than 1.3 billion people (representing roughly 16% of the global population) live with a significant disability. This includes people with permanent visual impairments, hearing loss, physical motor limitations, and cognitive or neurological differences.

In addition to permanent disabilities, users can often experience temporary or situational limitations. A person holding a baby with one hand has temporary motor constraints. Someone using their phone in harsh midday sunlight experiences situational visual impairment. And someone in a loud airport terminal experiences situational hearing limitations.

Designing an accessible app ensures that your interface remains resilient and usable across all of these scenarios and more.

Beyond empathy and inclusive design, accessibility is increasingly governed by international law.

In the European Union, the European Accessibility Act (EAA) mandates accessibility for a defined list of products and services, including smartphones and computers, e-commerce, consumer banking services, e-books, and passenger transport services. In practice, conformity is typically demonstrated against EN 301 549, the European accessibility standard for digital products and services.

In the United States, the Americans with Disabilities Act (ADA) applies to state and local governments (Title II, which, since 2024, has an explicit web and mobile app rule requiring compliance with WCAG 2.1 Level AA) and to public accommodations (Title III). Separately, Section 508 of the Rehabilitation Act requires federal agencies' information and communications technology to be accessible.

Failing to meet these standards can result in legal penalties and brand damage. Conversely, prioritizing accessibility expands your total addressable market and boosts user retention.

Quality also affects distribution: Google's Android vitals documentation notes that a high user-perceived crash rate hurts your app's discoverability on Google Play.

Core Concepts of Android Accessibility

To design accessible applications in Jetpack Compose, you must understand how the underlying Android operating system communicates with assistive technologies.

Understanding Android Accessibility Services

Android includes several built-in accessibility services that run as background processes. These services intercept the app's user interface and translate it into alternative sensory feedback or alternative input mechanisms:

• TalkBack (Screen Reader): TalkBack is Android's built-in screen reader designed for blind and low-vision users. It inspects your interface elements, converts visual content and semantic descriptions into synthesized speech and haptic vibrations, and enables non-visual navigation using linear swipe gestures.

• Switch Access: Designed for users with severe motor impairments who can't use a physical touch screen, Switch Access allows users to control their device using one or more physical switches (such as foot pedals, sip-and-puff devices, or single buttons) or a connected keyboard. It scans through focusable screen elements sequentially, allowing the user to select items when highlighted.

• Voice Access: Allows users to control their entire phone using spoken commands (such as "Tap Open," "Scroll down," or "Type hello"). It assigns numeric badges to interactive elements based on their accessibility labels so users can trigger actions by number.

• Select to Speak: Allows users to highlight specific paragraphs, buttons, or icons on the screen to hear them spoken aloud without turning on full TalkBack navigation.

All of these accessibility services share one common requirement: they don't interact directly with visual pixels. Instead, they read the Semantics Tree generated by your application.

How the Compose Semantics Tree Works

When you build a user interface in Jetpack Compose, Compose generates two separate but linked internal tree structures:

1. The Layout (UI) Tree: This tree contains the visual rendering nodes that measure, place, and draw pixels on the screen (such as Canvas, Box, Row, Column, Text, and Image).

2. The Semantics Tree: This tree runs in parallel with the Layout tree. It contains metadata that describes the meaning, purpose, state, and interactive capabilities of each element.

Standard Material Compose components (such as Button, Checkbox, Slider, Switch, and Text) automatically populate appropriate semantic properties into the Semantics tree. For example, a Button composable automatically sets its role to Role.Button and attaches a click action.

But when you build custom layouts, canvas drawings, or non-standard interactive widgets, Compose can't automatically infer your design intent. In those cases, you must use Compose's semantic modifiers to enrich the Semantics tree manually.

The WCAG 2.1 POUR Principles

The international benchmark for digital accessibility is the Web Content Accessibility Guidelines (WCAG) 2.1, published by the World Wide Web Consortium (W3C). These guidelines are organized around four core principles known by the acronym POUR:

• Perceivable: Information and UI components must be presentable to users in ways they can perceive. Content can't be invisible to all of a user's senses. In Android apps, this means providing descriptive text alternatives for all visual media, supporting dynamic font scaling, and maintaining high color contrast.

• Operable: User interface components and navigation must be operable. Users must be able to perform all interactions regardless of whether they use a touchscreen, a hardware keyboard, voice commands, or a switch device. This requires adequate touch targets (Android's guideline is at least 48dp × 48dp) and logical navigation orders.

• Understandable: Users must be able to understand both the information and the interface's operation. This means writing clear labels, providing meaningful validation error messages, avoiding sudden unexpected layout shifts, and structuring forms predictably.

• Robust: Content must be sufficiently robust to be reliably interpreted by a wide variety of user agents and assistive technologies. In Compose, this means avoiding hacky workarounds, using standard semantic roles, and honoring system-level user preferences.

Semantics in Jetpack Compose

In this section, we'll examine how Compose exposes and manipulates semantic metadata.

What Are Semantics?

Semantics in Jetpack Compose are key-value properties attached to layout nodes using the Modifier.semantics modifier. They convey information such as:

• What an element is called (contentDescription)

• What kind of UI control it represents (role = Role.Checkbox, Role.Button, Role.Tab)

• What state it currently holds (stateDescription = "Checked", progressBarRangeInfo)

• What actions the user can perform (onClick, onLongClick, customActions)

Basic Semantic Properties and Content Descriptions

The most widely used semantic property is contentDescription. It provides a localized textual representation of non-textual UI elements, such as icons, photographs, and vector graphics.

Here's how you provide content descriptions for visual components:

// A functional icon button that performs an action
IconButton(onClick = { /* Open camera */ }) {
    Icon(
        painter = painterResource(id = R.drawable.ic_camera),
        contentDescription = "Open camera"
    )
}

// A decorative background illustration
Image(
    painter = painterResource(id = R.drawable.decorative_pattern),
    contentDescription = null, // Informs TalkBack to skip this node completely
    modifier = Modifier.fillMaxWidth()
)

How It Works Under the Hood

When TalkBack navigates to the Icon, it reads the contentDescription aloud (something like "Open camera, button, double tap to activate"). TalkBack automatically appends the word "button" because IconButton exposes Role.Button. (Exact TalkBack phrasing varies by version and locale. The spoken examples throughout this guide are illustrative.)

For decorative elements (such as subtle background shapes, divider lines, or visual illustrations that accompany adjacent descriptive text), you should explicitly set contentDescription = null. Setting contentDescription = null instructs Compose to omit that element from the Semantics tree, preventing screen readers from stopping on meaningless visual noise.

Custom Semantics and State Descriptions

When an element changes its state dynamically (such as toggling between playing and paused, or expanded and collapsed), screen reader users need to be notified of the current state before they interact with it.

You can set stateDescription and role inside the Modifier.semantics block:

var isPlaying by remember { mutableStateOf(false) }

IconButton(
    onClick = { isPlaying = !isPlaying },
    modifier = Modifier.semantics {
        // Explicitly declare what state the media player is in
        stateDescription = if (isPlaying) "Playing audio" else "Audio paused"
        role = Role.Button
    }
) {
    Icon(
        imageVector = if (isPlaying) Icons.Default.Pause else Icons.Default.PlayArrow,
        contentDescription = if (isPlaying) "Pause" else "Play"
    )
}

How It Works Under the Hood

Without stateDescription, TalkBack only reads the action ("Play, button"). The user has to guess whether the audio is currently playing or stopped.

By adding stateDescription, TalkBack announces: "Playing audio, Pause, button, double-tap to toggle." This gives the user immediate confirmation of the current state followed by the action that activating the control will perform.

How to Merge Semantics with mergeDescendants

In complex layouts, multiple individual composables often combine to represent a single logical entity. For instance, a user profile row might contain an avatar image, a username, an online badge, and a timestamp.

By default, TalkBack will treat every child Text and Image node as an independent stop, forcing the user to swipe four or five times just to move past a single list item.

You can use Modifier.semantics(mergeDescendants = true) to combine all descendant nodes into a single, cohesive accessibility node:

// Bad: TalkBack focuses three separate times: "Star icon", "4.5", "Customer rating"
Row(modifier = Modifier.clickable { /* Navigate to reviews */ }) {
    Icon(
        imageVector = Icons.Default.Star,
        contentDescription = "Star icon"
    )
    Text(text = "4.5")
    Text(text = "Customer rating")
}

// Good: Merged into one single stop: "Customer rating: 4.5 out of 5 stars, button"
Row(
    modifier = Modifier
        .clickable(onClickLabel = "View all reviews") { /* Navigate to reviews */ }
        .semantics(mergeDescendants = true) {
            contentDescription = "Customer rating: 4.5 out of 5 stars"
        }
) {
    Icon(
        imageVector = Icons.Default.Star,
        contentDescription = null // Suppressed because parent provides full description
    )
    Text(text = "4.5")
    Text(text = "Customer rating")
}

How It Works Under the Hood

When mergeDescendants = true is set, Compose collapses the accessibility boundaries of all child composables. Instead of generating multiple stops in the Semantics tree, Compose exposes a single node to the accessibility framework. TalkBack focuses the entire Row as a single bounding box and reads the parent's contentDescription.

How to Clear Semantics with clearAndSetSemantics

In certain situations, a standard composable may include default semantic behaviors that interfere with your intended accessibility experience.

The Modifier.clearAndSetSemantics modifier clears all semantic properties that would otherwise be inherited from child composables or default implementations, allowing you to define a clean, custom semantic definition:

// A composite badge displaying notification count
Box(
    modifier = Modifier.clearAndSetSemantics {
        contentDescription = "3 unread messages"
        role = Role.Button
    }
) {
    Icon(
        imageVector = Icons.Default.Email,
        contentDescription = "Email icon" // Cleared and ignored
    )
    Text(text = "3") // Cleared and ignored
}

How It Works Under the Hood

Unlike Modifier.semantics, which adds or overrides specific keys, clearAndSetSemantics discards all existing keys generated by the composable subtree. In the example above, the separate "Email icon" and "3" text nodes are completely erased from the Semantics tree and replaced with the single announcement: "3 unread messages, button."

Essential Accessibility Practices

Now we'll cover the core accessibility practices you should implement in your applications, along with explanations of why each practice matters.

How to Write Meaningful Content Descriptions

A content description should concisely explain the purpose or action of an element rather than its visual appearance.

What to Do (Recommended Practice)

// Descriptive, action-oriented label
IconButton(onClick = { deleteDraft() }) {
    Icon(
        imageVector = Icons.Default.Delete,
        contentDescription = "Delete draft message"
    )
}

// Contextual weather information
Image(
    painter = painterResource(R.drawable.weather_sunny),
    contentDescription = "Current weather: Sunny, 75 degrees Fahrenheit"
)

The icon description tells the user exactly what will happen when they tap the button ("Delete draft message"). The weather image communicates the actual underlying data rather than describing the art style.

What Not to Do (Antipattern)

// Avoid generic or redundant descriptions
IconButton(onClick = { deleteDraft() }) {
    Icon(
        imageVector = Icons.Default.Delete,
        contentDescription = "Trash can icon button" // Bad: includes visual style and element type
    )
}

// Avoid empty strings on interactive elements
IconButton(onClick = { openSettings() }) {
    Icon(
        imageVector = Icons.Default.Settings,
        contentDescription = "" // Bad: leaves the button with no accessible label
    )
}

Including words like "icon" or "button" is redundant because TalkBack already announces the component's role. Using an empty string ("") on an interactive element leaves TalkBack with nothing meaningful to announce (typically read out as an unlabeled button), giving screen reader users zero context about what the button does. Compose's accessibility checks treat an empty content description the same as a missing one.

How to Ensure Minimum Touch Target Sizes

Google's Material Design and Android accessibility guidelines require all interactive elements to have a minimum touch target size of at least 48dp × 48dp, which corresponds to a physical size of about 9mm. This is squarely within the 7–10mm range Google recommends for touchscreen targets.

For comparison, WCAG itself sets lower web-oriented baselines: WCAG 2.1 Success Criterion 2.5.5 requires 44×44 CSS pixels at Level AAA, and WCAG 2.2 Success Criterion 2.5.8 requires 24×24 CSS pixels at Level AA. The 48dp rule is Android's stricter platform standard.

What to Do (Recommended Practice)

// Method A: Using minimumInteractiveComponentSize()
Box(
    modifier = Modifier
        .minimumInteractiveComponentSize() // Expands touch area to 48dp x 48dp
        .clickable { /* Toggle bookmark */ }
) {
    Icon(
        imageVector = Icons.Default.Bookmark,
        contentDescription = "Bookmark article",
        modifier = Modifier.size(24.dp) // Visual size is 24dp, touch target is 48dp
    )
}

// Method B: Standard IconButton (built-in 48dp target)
IconButton(onClick = { /* Toggle bookmark */ }) {
    Icon(
        imageVector = Icons.Default.Bookmark,
        contentDescription = "Bookmark article"
    )
}

Modifier.minimumInteractiveComponentSize() allows your visual design to remain compact (for instance, a 24dp icon) while ensuring that the invisible, clickable hit box expands to 48dp × 48dp. This prevents touch misses for users with motor tremors or limited fine motor control.

What Not to Do (Antipattern)

// Bad: Tightly constrained 20dp clickable area
Icon(
    imageVector = Icons.Default.Close,
    contentDescription = "Close dialog",
    modifier = Modifier
        .size(20.dp)
        .clickable { dismissDialog() } // Touch target is strictly 20dp x 20dp!
)

A 20dp touch target is nearly impossible to tap reliably, especially on high-density displays or while walking. Google's Accessibility Scanner will flag it as a touch target issue.

How to Maintain Accessible Color Contrast Ratios

Color contrast measures the difference in luminance between foreground text and its background. If the contrast ratio is too low, people with low vision, color blindness, or older eyes will likely not be able to read your text.

WCAG 2.1 defines the following minimum contrast ratios (Android's accessibility documentation maps WCAG's point sizes to sp):

• Normal text (smaller than 18sp, or smaller than 14sp bold): Minimum 4.5:1

• Large text (18sp or larger, or 14sp bold or larger): Minimum 3.0:1

• UI components and graphical objects: Minimum 3.0:1

What to Do (Recommended Practice)

// Using Material 3 color tokens (paired roles maintain usable contrast)
Text(
    text = "Account Overview",
    color = MaterialTheme.colorScheme.onPrimaryContainer,
    modifier = Modifier.background(MaterialTheme.colorScheme.primaryContainer)
)

// Explicit high-contrast colors (for example, Black on White = 21:1 ratio)
Text(
    text = "Order Confirmed",
    color = Color(0xFF1B5E20), // Dark green
    modifier = Modifier.background(Color(0xFFE8F5E9)) // Light green tint
)

Material 3 color tokens (such as onPrimaryContainer paired with primaryContainer) are generated by the Material color system so that "on" colors maintain usable contrast against their paired container colors across both light and dark themes. You should still verify contrast for any custom brand colors you override.

What Not to Do (Antipattern)

// Bad: Light gray on pure white (Contrast ratio ~ 1.6:1 - Fails WCAG)
Text(
    text = "Terms and Conditions apply",
    color = Color(0xFFB0B0B0),
    modifier = Modifier.background(Color.White)
)

Light gray text on a white background is one of the most common accessibility violations on the mobile web and in native apps. Sighted users in bright ambient light and users with low vision can't read this text.

How to Provide Custom Clickable Labels

When a user navigates to a clickable element using TalkBack, the screen reader appends default instructions such as "Double-tap to activate."

You can customize this instruction using the onClickLabel parameter in Modifier.clickable to describe the precise outcome of the interaction.

What to Do (Recommended Practice)

ListItem(
    headlineContent = { Text("Wi-Fi Networks") },
    supportingContent = { Text("Connected to Office_5G") },
    modifier = Modifier.clickable(
        onClickLabel = "Open Wi-Fi network settings"
    ) {
        navigateToWifiSettings()
    }
)

TalkBack will announce: "Wi-Fi Networks, Connected to Office_5G, double-tap to open Wi-Fi network settings." The user knows exactly what will happen before committing to the action.

What Not to Do (Antipattern)

// Bad: Generic clickable element without context
Card(
    modifier = Modifier.clickable { openInvoiceDetails() }
) {
    Text("Invoice #4092")
}

TalkBack announces: "Invoice #4092, double-tap to activate." The user is left uncertain whether tapping will pay the invoice, download a PDF, or open an edit screen.

How to Establish Heading Hierarchies

Visual readers scan large, bold text headings to understand a screen's layout and hierarchy. Screen reader users need the exact same structural overview.

By applying the heading() semantic modifier, you designate a text node as an accessibility heading. TalkBack users can change their navigation mode to "Headings" and quickly swipe up or down to jump between sections.

What to Do (Recommended Practice)

Column(modifier = Modifier.padding(16.dp)) {
    // Screen title heading
    Text(
        text = "Security Settings",
        style = MaterialTheme.typography.headlineMedium,
        modifier = Modifier.semantics { heading() }
    )

    Spacer(modifier = Modifier.height(16.dp))

    // Section 1 heading
    Text(
        text = "Two-Factor Authentication",
        style = MaterialTheme.typography.titleMedium,
        modifier = Modifier.semantics { heading() }
    )
    
    // Section 1 content...

    Spacer(modifier = Modifier.height(16.dp))

    // Section 2 heading
    Text(
        text = "Connected Devices",
        style = MaterialTheme.typography.titleMedium,
        modifier = Modifier.semantics { heading() }
    )
    
    // Section 2 content...
}

TalkBack users can bypass dozens of individual switches and descriptions to jump directly to "Connected Devices" in seconds.

What Not to Do (Antipattern)

// Bad: Visual heading without semantic markup
Text(
    text = "Two-Factor Authentication",
    style = MaterialTheme.typography.titleLarge // Visually large, but invisible as a heading to TalkBack
)

Without semantics { heading() }, TalkBack treats the text as regular body copy, preventing users from navigating by headings.

How to Announce Dynamic Updates with Live Regions

When content on the screen updates asynchronously (such as a timer countdown, a file upload completion message, or a real-time validation banner), sighted users see the change immediately.

But screen reader users won't know that anything changed unless you mark the changing container as a live region.

Compose provides liveRegion = LiveRegionMode.Polite and liveRegion = LiveRegionMode.Assertive:

• LiveRegionMode.Polite: TalkBack waits until the current audio announcement is finished before reading the update. Use this for almost all status updates.

• LiveRegionMode.Assertive: TalkBack announces the change immediately, ahead of other feedback. Reserve this strictly for time-sensitive, high-urgency alerts (such as emergency warnings).

What to Do (Recommended Practice)

var uploadStatus by remember { mutableStateOf("Ready to upload") }

Text(
    text = uploadStatus,
    modifier = Modifier.semantics {
        liveRegion = LiveRegionMode.Polite
    }
)

// Later, when upload finishes:
LaunchedEffect(Unit) {
    performUpload()
    uploadStatus = "Upload complete! 12 files saved."
}

As soon as uploadStatus changes, TalkBack automatically speaks: "Upload complete! 12 files saved," keeping non-sighted users fully informed without requiring them to search the screen.

How to Support Dynamic Text Scaling

Users with low vision often increase their system font size in Android Settings (under Display or the accessibility settings, depending on the device). Android 14 and newer support non-linear font scaling up to 200%.

To respect this user preference, you must define all text sizes in sp (scale-independent pixels), never in dp or raw pixels.

What to Do (Recommended Practice)

// Good: Using Material Typography (uses sp automatically)
Text(
    text = "Dashboard Summary",
    style = MaterialTheme.typography.titleMedium
)

// Good: Explicit sp sizing
Text(
    text = "Custom Label",
    fontSize = 18.sp
)

When a user sets their font scale to 1.5×, an 18sp font cleanly renders at 27sp, ensuring readable text.

What Not to Do (Antipattern)

// Bad: Fixed dp size converted to sp (does not scale with system settings)
Text(
    text = "Fixed Size Warning",
    fontSize = with(LocalDensity.current) { 16.dp.toSp() } // Will not scale!
)

Sizing text with fixed dp measurements prevents the text from enlarging when users increase their system font size, directly violating accessibility standards.

Advanced Accessibility Techniques

For complex, production-grade applications, you can apply advanced accessibility techniques to handle non-trivial user interactions.

How to Control Traversal and Focus Order

By default, accessibility services traverse screen elements based on their visual and structural coordinates (top-to-bottom, start-to-end). In multi-column layouts, financial ledgers, or custom grids, this default order can create confusing announcements.

You can customize the navigation sequence using traversalIndex and isTraversalGroup:

Column(
    modifier = Modifier.semantics { isTraversalGroup = true }
) {
    Text(
        text = "Step 1: Account Info",
        modifier = Modifier.semantics { traversalIndex = 1f }
    )
    
    Text(
        text = "Step 3: Confirmation",
        modifier = Modifier.semantics { traversalIndex = 3f }
    )
    
    Text(
        text = "Step 2: Payment Details",
        modifier = Modifier.semantics { traversalIndex = 2f }
    )
}

How the code works under the hood:

1. Setting isTraversalGroup = true creates a self-contained accessibility boundary, ensuring TalkBack reads all elements inside this container before moving to other screen elements.

2. The traversalIndex floating-point value establishes the exact relative order (lowest index first). TalkBack will read Step 1, then Step 2, and finally Step 3, regardless of their visual placement in the layout.

How to Create Custom Accessibility Actions

Consider an e-commerce product card that contains "Quick View," "Add to Wishlist," and "Add to Cart" buttons. For a screen reader user, tabbing through three separate buttons on twenty consecutive cards is tedious.

With customActions, you can attach secondary actions directly to the parent card node. When the card gains focus, TalkBack tells the user that actions are available, and the user opens the TalkBack menu to pick one.

var isBookmarked by remember { mutableStateOf(false) }

Card(
    modifier = Modifier
        .fillMaxWidth()
        .semantics {
            customActions = listOf(
                CustomAccessibilityAction(
                    label = if (isBookmarked) "Remove from bookmarks" else "Add to bookmarks",
                    action = {
                        isBookmarked = !isBookmarked
                        true // Return true to indicate the action was handled
                    }
                ),
                CustomAccessibilityAction(
                    label = "Share article link",
                    action = {
                        shareArticle()
                        true
                    }
                )
            )
        }
) {
    // Visual card content...
}

When a TalkBack user focuses on the card, TalkBack informs them that custom actions are available. The user opens the TalkBack menu (or uses accessibility gestures) to see a clean list containing "Add to bookmarks" and "Share article link." This keeps your visual design streamlined while providing direct, high-efficiency navigation for power users.

How to Design Accessible Form Inputs and Text Fields

Accessible form inputs require more than just a visual placeholder. They need explicit labels, clear input type hints, and logical keyboard navigation actions:

var emailValue by remember { mutableStateOf("") }

OutlinedTextField(
    value = emailValue,
    onValueChange = { emailValue = it },
    label = { Text("Work Email") },
    placeholder = { Text("alex@example.com") },
    singleLine = true,
    keyboardOptions = KeyboardOptions(
        keyboardType = KeyboardType.Email,
        imeAction = ImeAction.Next
    ),
    keyboardActions = KeyboardActions(
        onNext = { /* Move focus to password field */ }
    ),
    modifier = Modifier
        .fillMaxWidth()
        .semantics {
            contentDescription = "Work email address input field"
        }
)

How it works under the hood:

• The label composable provides persistent context that remains visible even after the user types.

• keyboardType = KeyboardType.Email instructs Android to display an email-optimized keyboard (including @ and .com shortcuts) and hints to accessibility services that standard email syntax is expected.

• imeAction = ImeAction.Next ensures hardware keyboard users and switch device users can smoothly advance through form fields using the keyboard Enter key.

How to Communicate Dynamic Error States

When client-side validation fails, setting the visual border to red isn't enough. You must attach semantic error metadata so screen readers announce the validation failure immediately.

var password by remember { mutableStateOf("") }
val isPasswordInvalid = password.isNotEmpty() && password.length < 8

OutlinedTextField(
    value = password,
    onValueChange = { password = it },
    label = { Text("Password") },
    isError = isPasswordInvalid,
    supportingText = {
        if (isPasswordInvalid) {
            Text(
                text = "Password must be at least 8 characters long",
                color = MaterialTheme.colorScheme.error
            )
        }
    },
    modifier = Modifier
        .fillMaxWidth()
        .semantics {
            if (isPasswordInvalid) {
                error("Password must be at least 8 characters long")
            }
        }
)

How it works under the hood:

The isError = isPasswordInvalid parameter handles the visual styling (red outline and error icons).

• The error("...") semantic property tells TalkBack to treat this element as invalid and announce the specific validation error message as soon as the user focuses the text field.

How to Manage Progress Indicators and Asynchronous Loading

Loading states must clearly convey whether a task is indeterminate (in progress with unknown duration) or determinate (progressing toward 100%).

// Indeterminate Progress (such as initial network fetch)
CircularProgressIndicator(
    modifier = Modifier.semantics {
        contentDescription = "Syncing messages, please wait"
    }
)

// Determinate Progress (such as file download)
val downloadProgress = 0.65f // 65%

LinearProgressIndicator(
    progress = { downloadProgress },
    modifier = Modifier.semantics {
        progressBarRangeInfo = ProgressBarRangeInfo(
            current = downloadProgress,
            range = 0f..1f
        )
        contentDescription = "Downloading update: ${(downloadProgress * 100).toInt()}% completed"
    }
)

For determinate progress indicators, ProgressBarRangeInfo tells assistive technologies the minimum, maximum, and current values. TalkBack interprets this information and provides periodic spoken and haptic updates as progress increases.

How to Handle Expandable and Collapsible Content

Accordion menus and expandable FAQ cards must clearly indicate whether they're open or closed, and what action tapping them will trigger.

var isExpanded by remember { mutableStateOf(false) }

Column(modifier = Modifier.fillMaxWidth()) {
    Row(
        verticalAlignment = Alignment.CenterVertically,
        modifier = Modifier
            .fillMaxWidth()
            .clickable(
                onClickLabel = if (isExpanded) "Collapse section" else "Expand section"
            ) {
                isExpanded = !isExpanded
            }
            .semantics {
                stateDescription = if (isExpanded) "Expanded" else "Collapsed"
            }
            .padding(16.dp)
    ) {
        Text(
            text = "Frequently Asked Questions",
            style = MaterialTheme.typography.titleMedium,
            modifier = Modifier.weight(1f)
        )
        Icon(
            imageVector = if (isExpanded) Icons.Default.ExpandLess else Icons.Default.ExpandMore,
            contentDescription = null // Decorative: parent Row communicates full state
        )
    }

    AnimatedVisibility(visible = isExpanded) {
        Text(
            text = "Our refund policy allows returns within 30 days of purchase...",
            modifier = Modifier.padding(16.dp)
        )
    }
}

The stateDescription announces whether the section is currently open or closed ("Expanded" or "Collapsed"). Simultaneously, onClickLabel clarifies the upcoming action ("Collapse section" or "Expand section"). The icon has contentDescription = null to avoid redundant announcements.

How to Enhance Lazy Lists and Large Collections

When users navigate a long feed or list, they need context regarding where they are and how many items exist.

val messages = remember { listOf("Order Shipped", "Delivery Delayed", "Payment Received") }

LazyColumn(
    modifier = Modifier.semantics {
        contentDescription = "Notifications list, ${messages.size} total alerts"
    }
) {
    itemsIndexed(messages) { index, messageText ->
        Card(
            modifier = Modifier
                .fillMaxWidth()
                .padding(vertical = 4.dp)
                .semantics {
                    contentDescription = "Notification ${index + 1} of ${messages.size}: $messageText"
                }
        ) {
            Text(
                text = messageText,
                modifier = Modifier.padding(16.dp)
            )
        }
    }
}

TalkBack announces positional indexes ("Notification 1 of 3: Order Shipped"), allowing screen reader users to track their progress through lists without losing their place.

How to Test and Debug Accessibility

Building accessible software requires a multi-layered testing strategy: automated regression checks, on-device diagnostic tools, semantics tree inspection, and manual verification with TalkBack.

How to Test Manually with TalkBack

Nothing replaces manually navigating your application using TalkBack.

How to Enable and Use TalkBack

1. Open your device's Settings app and navigate to Accessibility and then TalkBack.

2. Toggle the switch to On and accept the system permissions. (You can also use the volume key shortcut, if enabled: hold both volume keys for a few seconds to toggle TalkBack).

3. Core TalkBack gestures:

   • Swipe Right: Move accessibility focus to the next element.

   • Swipe Left: Move accessibility focus to the previous element.

   • Double Tap: Activate the currently focused element.

   • Two-Finger Swipe: Scroll lists or pages.

   • Three-Finger Tap (or swipe down then right in one motion): Open the TalkBack menu.

What to check during your TalkBack walkthrough:

• Can you complete critical user journeys (such as registration, login, searching, and checkout) with your eyes closed?

• Are all buttons and interactive controls clearly announced with meaningful names?

• Does focus move in a logical, expected reading order?

• Are error messages and dynamic state changes announced automatically?

How to Write Automated Compose Accessibility Tests

You can integrate automated accessibility assertions into your JUnit instrumented tests to catch missing descriptions and undersized touch targets on continuous integration (CI) servers.

Add Dependencies to build.gradle.kts:

androidTestImplementation("androidx.compose.ui:ui-test-junit4")
androidTestImplementation("androidx.compose.ui:ui-test-manifest")

Writing Compose Accessibility Tests:

@RunWith(AndroidJUnit4::class)
class AccessibilityTest {

    @get:Rule
    val composeTestRule = createAndroidComposeRule<ComponentActivity>()

    @Test
    fun testLoginButton_hasProperTouchTargetAndLabel() {
        composeTestRule.setContent {
            MaterialTheme {
                Button(
                    onClick = { /* Submit login */ },
                    modifier = Modifier.minimumInteractiveComponentSize()
                ) {
                    Text("Sign In")
                }
            }
        }

        // Verify the node exists with correct text and semantics
        composeTestRule
            .onNodeWithText("Sign In")
            .assertExists()
            .assertHasClickAction()
            .assertHeightIsAtLeast(48.dp)
            .assertWidthIsAtLeast(48.dp)
    }

    @Test
    fun testIconButton_containsContentDescription() {
        composeTestRule.setContent {
            MaterialTheme {
                IconButton(onClick = {}) {
                    Icon(
                        imageVector = Icons.Default.Favorite,
                        contentDescription = "Add to favorites"
                    )
                }
            }
        }

        // Verify content description is accurately exposed in semantics tree
        composeTestRule
            .onNode(hasContentDescription("Add to favorites"))
            .assertExists()
            .assertHasClickAction()
    }
}

Step-by-Step Guide to Google Accessibility Scanner

Google Accessibility Scanner is an Android diagnostic tool that inspects your app's rendered UI and flags accessibility violations.

How to Install and Set Up Accessibility Scanner

1. Install from Google Play: Open the Google Play Store on your test device and install Accessibility Scanner (published by Google LLC).

2. Enable in Accessibility Settings:

   • Go to Settings then Accessibility and then Accessibility Scanner.

   • Toggle the switch to On and grant the required screen-reading permissions.

3. Locate the Floating Button: A blue floating action button with a checkmark icon (✓) will appear overlaid on your screen.

Running a Scan and Interpreting Results

Open your Android application and navigate to the screen you want to audit. Tap the floating blue Scanner button.

Then tap the Snapshot (camera) icon to analyze the static screen, or tap Record to audit a multi-step user flow.

The Scanner outlines each flagged UI component with an orange rectangle. Typical findings include interactive touch targets smaller than 48dp, missing labels on buttons and images, insufficient text or image contrast, and duplicate or redundant descriptions.

Tap any highlighted result to view a detailed breakdown explaining the problem, a link to the relevant accessibility guidance, and suggested remediation steps. Keep in mind that Scanner is a diagnostic aid. A clean scan doesn't guarantee that your app is fully accessible.

Figure: Google Accessibility Scanner auditing the AccessibilityDemo app, flagging an undersized 24dp touch target and displaying remediation guidance.

How to Inspect Semantics with Android Studio Layout Inspector

Android Studio's Layout Inspector allows you to inspect your running Compose hierarchy in real time and view the exact Semantics Tree exposed to the operating system.

How to Inspect Semantics Step-by-Step

1. Run your Compose application on an emulator or physical device connected via USB debugging.

2. In Android Studio, open View then Tool Windows and then Layout Inspector.

3. In the process selector dropdown, select your application's process (such as com.example.accessibilitydemo).

4. In the Layout Inspector component tree panel on the left, navigate to the composable you want to inspect (such as the Card under Semantic Merging).

5. Look at the Attributes panel on the right. You'll see dedicated sections for:

   • Merged Semantics: Displays the collapsed semantic metadata exposed to accessibility services when mergeDescendants = true is used (including merged ContentDescription, Text lists, OnClick actions, and container flags).

   • Declared Semantics: Shows the explicit semantic properties directly attached to that specific composable node.

Figure: Android Studio Layout Inspector inspecting the AccessibilityDemo app, displaying the Component Tree on the left, visual wireframes in the center, and the Merged Semantics attributes panel on the right.

Using Layout Inspector provides visual confirmation that:

• semantics(mergeDescendants = true) is properly grouping disparate children into a single node.

• Decorative icons are successfully excluded from the accessibility tree.

• Click actions (OnClick: AccessibilityAction) and custom actions are correctly wired to the composable.

Real-World Accessible UI Patterns

Here are complete, production-ready implementations of common UI patterns:

Fully Accessible Login Form

Forms are critical entry points. This implementation combines heading semantics, email input validation, dynamic error announcements, and proper touch target sizing:

@Composable
fun AccessibleLoginForm(
    onLoginSubmitted: (String, String) -> Unit
) {
    var email by remember { mutableStateOf("") }
    var password by remember { mutableStateOf("") }
    var isSubmitted by remember { mutableStateOf(false) }

    val isEmailInvalid = isSubmitted && !android.util.Patterns.EMAIL_ADDRESS.matcher(email).matches()
    val isPasswordInvalid = isSubmitted && password.length < 8

    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(24.dp)
    ) {
        // 1. Designated Screen Title Heading
        Text(
            text = "Welcome Back",
            style = MaterialTheme.typography.headlineLarge,
            modifier = Modifier.semantics { heading() }
        )

        Text(
            text = "Sign in to access your account",
            style = MaterialTheme.typography.bodyMedium,
            color = MaterialTheme.colorScheme.onSurfaceVariant
        )

        Spacer(modifier = Modifier.height(24.dp))

        // 2. Accessible Email Input
        OutlinedTextField(
            value = email,
            onValueChange = { email = it },
            label = { Text("Email Address") },
            isError = isEmailInvalid,
            singleLine = true,
            keyboardOptions = KeyboardOptions(
                keyboardType = KeyboardType.Email,
                imeAction = ImeAction.Next
            ),
            supportingText = {
                if (isEmailInvalid) {
                    Text(
                        text = "Please enter a valid email address",
                        color = MaterialTheme.colorScheme.error
                    )
                }
            },
            modifier = Modifier
                .fillMaxWidth()
                .semantics {
                    if (isEmailInvalid) {
                        error("Please enter a valid email address")
                    }
                }
        )

        Spacer(modifier = Modifier.height(16.dp))

        // 3. Accessible Password Input
        OutlinedTextField(
            value = password,
            onValueChange = { password = it },
            label = { Text("Password") },
            isError = isPasswordInvalid,
            singleLine = true,
            visualTransformation = PasswordVisualTransformation(),
            keyboardOptions = KeyboardOptions(
                keyboardType = KeyboardType.Password,
                imeAction = ImeAction.Done
            ),
            supportingText = {
                if (isPasswordInvalid) {
                    Text(
                        text = "Password must be at least 8 characters long",
                        color = MaterialTheme.colorScheme.error
                    )
                }
            },
            modifier = Modifier
                .fillMaxWidth()
                .semantics {
                    if (isPasswordInvalid) {
                        error("Password must be at least 8 characters long")
                    }
                }
        )

        Spacer(modifier = Modifier.height(24.dp))

        // 4. Accessible Submit Button
        Button(
            onClick = {
                isSubmitted = true
                if (!isEmailInvalid && !isPasswordInvalid) {
                    onLoginSubmitted(email, password)
                }
            },
            modifier = Modifier
                .fillMaxWidth()
                .minimumInteractiveComponentSize()
                .semantics {
                    contentDescription = "Sign in to your account"
                }
        ) {
            Text("Sign In")
        }
    }
}

Why this pattern works:

1. Screen Heading: TalkBack users can instantly jump to "Welcome Back" when entering the screen.

2. Error Semantics: If validation fails, error("...") ensures TalkBack immediately speaks the validation requirement when the text field receives focus.

3. Keyboard Routing: ImeAction.Next and ImeAction.Done guide keyboard and switch users smoothly between input fields.

E-Commerce Product Card with Custom Actions

This pattern demonstrates how to combine mergeDescendants = true with customActions to create a concise, power-user-friendly card:

data class Product(
    val id: String,
    val title: String,
    val priceFormatted: String,
    val rating: Float,
    val imageRes: Int
)

@Composable
fun AccessibleProductCard(
    product: Product,
    onCardClick: () -> Unit,
    onToggleFavorite: () -> Unit,
    onAddToCart: () -> Unit
) {
    Card(
        modifier = Modifier
            .fillMaxWidth()
            .clickable(onClickLabel = "View product details") { onCardClick() }
            .semantics(mergeDescendants = true) {
                // Group all descriptive properties into one coherent announcement
                contentDescription = "${product.title}, Price: ${product.priceFormatted}, Rated ${product.rating} out of 5 stars"
                
                // Expose secondary operations as custom accessibility actions
                customActions = listOf(
                    CustomAccessibilityAction("Add to shopping cart") {
                        onAddToCart()
                        true
                    },
                    CustomAccessibilityAction("Save to favorites") {
                        onToggleFavorite()
                        true
                    }
                )
            }
    ) {
        Row(
            modifier = Modifier.padding(16.dp),
            verticalAlignment = Alignment.CenterVertically
        ) {
            Image(
                painter = painterResource(product.imageRes),
                contentDescription = null, // Decorative: covered by merged description
                modifier = Modifier
                    .size(80.dp)
                    .clip(RoundedCornerShape(8.dp))
            )

            Spacer(modifier = Modifier.width(16.dp))

            Column(modifier = Modifier.weight(1f)) {
                Text(
                    text = product.title,
                    style = MaterialTheme.typography.titleMedium
                )
                Text(
                    text = product.priceFormatted,
                    style = MaterialTheme.typography.bodyLarge,
                    fontWeight = FontWeight.Bold
                )
                Text(
                    text = "★ ${product.rating}",
                    style = MaterialTheme.typography.bodySmall,
                    color = MaterialTheme.colorScheme.onSurfaceVariant
                )
            }
        }
    }
}

Why this pattern works:

1. Single Semantic Stop: Instead of swiping four times through separate image and text views, TalkBack reads the entire card in one unified statement.

2. Action Shortcuts: Users can add items to their cart or favorites directly from the TalkBack actions menu without navigating into the details page.

Tab Navigation with Selection State

This pattern demonstrates accessible tab bar navigation using stateDescription and custom tab announcements:

@Composable
fun AccessibleTabNavigation(
    tabs: List<String>,
    selectedTabIndex: Int,
    onTabSelected: (Int) -> Unit
) {
    TabRow(
        selectedTabIndex = selectedTabIndex,
        modifier = Modifier.semantics {
            contentDescription = "Navigation tabs, ${tabs[selectedTabIndex]} selected"
        }
    ) {
        tabs.forEachIndexed { index, title ->
            val isSelected = selectedTabIndex == index
            Tab(
                selected = isSelected,
                onClick = { onTabSelected(index) },
                modifier = Modifier.semantics {
                    role = Role.Tab
                    stateDescription = if (isSelected) "Selected" else "Not selected"
                    contentDescription = "$title tab"
                }
            ) {
                Text(
                    text = title,
                    modifier = Modifier.padding(vertical = 16.dp)
                )
            }
        }
    }
}

Why this pattern works:

1. Explicit Role: Marking each item with Role.Tab informs accessibility services that this is a selectable tab container.

2. Selection Feedback: The stateDescription tells the user whether a tab is currently active before they tap it.

Confirmation Dialog with Action Descriptions

This pattern shows how to structure an accessible confirmation dialog:

@Composable
fun AccessibleDeleteConfirmationDialog(
    itemName: String,
    onDismissRequest: () -> Unit,
    onConfirmDelete: () -> Unit
) {
    AlertDialog(
        onDismissRequest = onDismissRequest,
        title = {
            Text(
                text = "Delete Item?",
                style = MaterialTheme.typography.headlineSmall,
                modifier = Modifier.semantics { heading() }
            )
        },
        text = {
            Text("Are you sure you want to permanently delete \"$itemName\"? This action cannot be undone.")
        },
        confirmButton = {
            TextButton(
                onClick = onConfirmDelete,
                modifier = Modifier.semantics {
                    contentDescription = "Confirm deletion of $itemName"
                }
            ) {
                Text("Delete", color = MaterialTheme.colorScheme.error)
            }
        },
        dismissButton = {
            TextButton(
                onClick = onDismissRequest,
                modifier = Modifier.semantics {
                    contentDescription = "Cancel deletion and close dialog"
                }
            ) {
                Text("Cancel")
            }
        },
        modifier = Modifier.semantics {
            contentDescription = "Delete item confirmation dialog"
        }
    )
}

Why this pattern works:

1. Clear Focus: When the dialog appears, TalkBack automatically traps focus within the dialog bounds so users can't accidentally click background elements.

2. Context-Rich Buttons: Button descriptions explain the exact consequence of clicking ("Confirm deletion of Shopping List" rather than just "Delete").

Accessibility Audit Checklist

Before releasing your app to production or submitting it to app stores, run through this accessibility audit checklist:

Visual and Typography

• Scalable Text: Define all font sizes in sp (never fixed dp) so text scales cleanly up to 200%.

• Color Contrast: Maintain at least a 4.5:1 contrast ratio for normal text and 3.0:1 for large text and essential UI components against their backgrounds.

• Color Independence: Never convey information through color alone. Always pair color cues with text labels or distinct icons.

Interactive Elements and Touch Targets

• Touch Target Sizing: Ensure every clickable or interactive component has a minimum hit target of 48dp × 48dp using Modifier.minimumInteractiveComponentSize().

• Actionable Descriptions: Provide descriptive, action-oriented contentDescription strings on all functional icon buttons and interactive images.

• Decorative Elements: Set contentDescription = null on purely decorative icons and illustrations to keep TalkBack feedback concise.

• Click Context: Provide custom onClickLabel parameters on cards, list items, and custom buttons to clarify the outcome before activation.

Screen Structure and Navigation

• Accessibility Headings: Mark major section titles and screen headers with Modifier.semantics { heading() } for rapid heading navigation.

• Semantic Merging: Group related visual sub-elements (such as ratings or multi-text card headers) using Modifier.semantics(mergeDescendants = true).

• Live Announcements: Designate asynchronous UI updates with liveRegion = LiveRegionMode.Polite so TalkBack announces background changes.

• Form Optimization: Specify appropriate keyboardType and imeAction configurations on all text inputs.

• Validation Feedback: Declare active input error states using Modifier.semantics { error("...") }.

Testing and Verification

• Automated Unit Tests: Add Compose accessibility assertions in continuous integration to catch touch target and missing label regressions.

• On-Device Diagnostic Audit: Run Google Accessibility Scanner across all key app screens to catch contrast or sizing defects.

• Semantics Tree Inspection: Use Android Studio Layout Inspector to verify merged semantics and declared accessibility actions.

• Manual Screen Reader Walkthrough: Complete end-to-end user journeys (login, checkout, navigation) with TalkBack enabled.

Conclusion and Next Steps

Building accessible applications in Jetpack Compose doesn't mean just retrofitting code at the end of a project. You need to understand Compose's dual-tree architecture and design your user interface so that both visual pixels and semantic metadata accurately represent your application's intent.

By applying semantic properties, ensuring 48dp touch targets, maintaining WCAG contrast ratios, and verifying your work with TalkBack and Google Accessibility Scanner, you ensure that your Android applications are welcoming, compliant, and intuitive for all users worldwide.

Essential Resources

To deepen your understanding of Android accessibility, consult these essential references:

• Android Developers Official Guide: Accessibility in Jetpack Compose

• Android Developers Official Guide: Semantics in Compose

• W3C Web Content Accessibility Guidelines (WCAG) 2.1 Quick Reference

• Google Material Design 3: Accessible Design Foundations

We just posted a massive 60-hour Kotlin and Android Development course on the freeCodeCamp.org YouTube channel. This course will help you master modern Android practices. Alexandru Cristian developed this course. It’s packed with hands-on practice, ensuring you not only learn the theory but also apply it by building multiple real-world applications.

This is a thorough exploration of the Kotlin programming language and the Android development ecosystem. Here’s a glimpse of what you’ll learn:

Kotlin from the ground up

• Solidify your understanding of Kotlin syntax, variables, operators, control flow (loops, conditionals), and null safety.

  • Dive deep into Object-Oriented Programming (OOP) with Kotlin, covering classes, inheritance, interfaces, abstract classes, and data classes.

  • Master Kotlin Collections (lists, sets, maps) and powerful functions to manipulate them.

  • Explore advanced concepts like Generics, Lambda functions, and Kotlin Coroutines for efficient asynchronous programming.

  • Even touch upon SQL basics to understand data persistence.

Comprehensive android development

• Get started with Android Studio and understand the Android project structure.

  • Learn traditional UI development with XML, including various layouts (LinearLayout, RelativeLayout, ConstraintLayout) and UI widgets.

  • Master Android Activities and Fragments, their lifecycles, and how to navigate between screens using Intents and the modern Navigation Component.

  • Build dynamic lists with RecyclerView.

  • Understand and implement Material Design principles.

  • Work with data persistence using Room Database and connect to the cloud with Firebase Firestore.

  • Make network requests and handle APIs using Retrofit and parse JSON data.

  • Implement robust app architecture using MVVM (Model-View-ViewModel), LiveData, and potentially Dependency Injection.

  • Get an introduction to the future of Android UI with Jetpack Compose.

Theory is important, but practice is what makes a developer. Throughout this 60-hour course, you'll be building a portfolio of applications. The final project is an Uber clone that will have you implementing features like maps integration, user authentication, real-time location tracking, and more, demonstrating truly professional-grade development techniques.

Start learning today

Learning Kotlin and Android development opens doors to an exciting career in mobile technology. Android powers billions of devices worldwide, and skilled developers are in constant demand. Kotlin is a modern, concise, and powerful language officially supported by Google for Android development, making it an essential skill for today's app creators.

Watch the full course on the freeCodeCamp.org YouTube channel (60-hour watch).

Imagine you're running a bustling restaurant. Orders fly in, dishes need cooking, tables require clearing, and happy customers demand attention. How can you handle all this chaos without everything turning into a total disaster? This is where concurrency comes in.

In the world of server-side development, things can get just as hectic. Users fire off requests, databases need querying, calculations demand crunching, and all this needs to happen smoothly and efficiently. Without concurrency, it's like having one overworked chef trying to do everything.

But with concurrency, it's like adding a whole team of skilled multitaskers to your kitchen. You have specialized "coroutines" handling different tasks – one taking orders, another cooking, one washing dishes, and so on. Each works simultaneously, but in a coordinated way, ensuring your customers get their delicious meals fast and with a smile.

Examples of Concurrency

Here are some real-world examples of how concurrency works in server-side development:

Serving multiple users at once: Imagine your website gets slammed by eager shoppers during a flash sale. Without concurrency, each user request would have to wait its turn, leading to frustratingly slow loading times.

But with coroutines, multiple requests can be processed simultaneously, keeping everyone happy and shopping with ease.

Processing data pipelines: Do you work with really large datasets? Concurrency can break them down and analyze them bit by bit.

Handling asynchronous requests: Think of API calls, database queries, or file uploads. These often take time to complete. With concurrency, your main program doesn't have to sit and wait. It can launch separate coroutines to handle these requests and get back to other tasks, keeping everything running smoothly.

Concurrency isn't just some fancy buzzword – it's a powerful tool that lets you handle the ever-growing demands of server-side development with ease and efficiency.

Now, we'll dive deeper into the differences between threads and coroutines, the fundamental building blocks of concurrent programming in Kotlin.

Threads vs. Coroutines

Now, let's talk about the two main players on this team: threads and coroutines.

What are Threads?

Threads are powerful, and capable of handling complex tasks – but they're also a bit resource-hungry. Each thread requires its memory space and attention from the operating system.

This can be great for demanding tasks like breaking down big numbers or sending critical emails, but if you have too many threads running around, your server starts getting overwhelmed, leading to slowdowns and even crashes.

What are Coroutines?

Coroutines are lightweight, flexible, and able to switch between tasks in a flash. They don't need their dedicated tables, they share resources efficiently, and they can even pause their work gracefully if something else needs immediate attention.

Think of them as taking orders, checking on tables, and cleaning dishes – always contributing, but in a light and adaptable way.

Table showing differences bewteen threads and coroutines.

So, which of them should you choose? Well, it depends! For heavy lifting, threads are strong and reliable. But for the everyday hustle and bustle, coroutines are your agile friends.

Kotlin favours coroutines for concurrent programming because they're more efficient and easier to manage, especially when dealing with lots of asynchronous tasks.

How to Launch Coroutines

In your server-side code, there are two main ways to launch coroutines.

Launch and Forget: Using the launch Keyword

This fires up a new coroutine and sends it off to its assigned task, but doesn't wait for it to finish.

Here's how it looks in code:

fun updateCustomerOrder(
  orderId: Int,
  newDish: String
) {
  launch {
    updateOrderInDatabase(orderId, newDish)
  }
  sendConfirmationEmail(orderId)
}

This is ideal for tasks that don't need immediate feedback. You can launch multiple coroutines like this without overloading your server, as they work independently and share resources efficiently.

Wait and Receive: The async Keyword

Now, let's say you need to know the total bill before you can settle up with the customer. This is where async comes in. It's like sending an assistant to calculate the bill and then patiently waiting for them to return with the answer.

Here's how it works:

fun calculateBill(orderId: Int): Double {
  val billResult = async {
    calculateBillFromDatabase(orderId)
  }
  val totalBill = billResult.await()
  return totalBill
}

This is useful for tasks where you need the result before proceeding. The async keyword creates a coroutine that calculates the bill in the background (performs the task), but the main program pauses and waits until the result is ready.

Channels: Communication Lifelines

Channels allow coroutines to send and receive messages in a safe and organized way, even when things get crazy. Here's how they work:

One-Way Streets: Send Channels

A send channel allows one coroutine to send a message that another coroutine can receive on the other end. Only one direction, just like a one-way street.

Bi-Directional Bridges: Receive Channels

Receive channels allow a coroutine to wait for and receive a message that was sent on the corresponding send channel. Two-way communication, like a bridge in both directions.

Putting Channels to Work:

Here's an example of using channels to update customer orders:

val orderUpdatesChannel = Channel<Pair<Int, String>>()

fun updateCustomerOrder(orderId: Int, newDish: String) {
  launch {
    updateOrderInDatabase(orderId, newDish)
    orderUpdatesChannel.send(orderId to newDish)
  }
}

fun sendOrderConfirmationEmails() {
  while (true) {
    val orderUpdate = orderUpdatesChannel.receive()
    val (updatedOrderId, newDish) = orderUpdate
    sendConfirmationEmail(updatedOrderId)
  }
}

In this case, the updateCustomerOrder coroutine sends the updated order details through the orderUpdatesChannel. The sendOrderConfirmationEmails coroutine constantly waits on the channel, receiving updates one by one and sending out confirmation emails.

Structured Concurrency

Think of structured concurrency like assigning roles and responsibilities in your kitchen. It helps you:

1. Define the scope: You can create coroutine contexts that provide specific resources and boundaries for your coroutines to work within. This keeps things organized and prevents rogue coroutines from mucking up the system.
2. Cancellation: Imagine a customer changing their order halfway through cooking. Structured concurrency allows you to easily cancel the wrong dish and start preparing the new one, without everything crumbling into a greasy mess.
3. Supervision: Structured concurrency lets you set up supervisors who monitor their "child" coroutines, ensuring they finish their tasks properly or handle errors gracefully.

Key tools for structured concurrency:

Dispatchers: They control where and how your coroutines run, like assigning them to specific threads or pools.

Jobs: Think of them as the tasks themselves, assigned to specific coroutines within a context. You can track their progress, cancel them if needed, and keep things organized.

Supervisor Jobs: They supervise child jobs, handling failures and propagating them properly, preventing errors from cascading and ruining the whole meal.

Different types of tasks in your server-side code demand different environments. This is where the various dispatcher types come in:

1. The Main Dispatcher: Think of it as the front of the house, handling UI updates and interacting directly with the customer (user). It's a single thread, ensuring smooth and responsive interactions without any chaotic multitasking.
2. The Default Dispatcher: This is the workhorse for general computation tasks. It uses a thread pool, assigning coroutines to available threads. Great for CPU-intensive calculations, database processing, and other heavy lifting.
3. The IO Dispatcher: This dispatcher handles blocking I/O operations like network calls, file access, or database queries.
4. Custom Dispatchers: You can create custom dispatchers with specific thread pools or even single threads, tailoring them to the needs of your unique tasks.

Choosing the right dispatcher is very important for optimizing performance and avoiding congestion. Here are some tips:

• Use the main dispatcher only for UI updates and user interaction.
• Default dispatcher for most CPU-intensive tasks.
• IO dispatcher for any blocking I/O operations.
• Consider custom dispatchers for specific high-volume or sensitive tasks.

Flows

Imagine your restaurant is booming, orders flying in faster than the chefs can cook. How do you handle this data deluge without everything turning into a soggy mess?

Think of Flows as streams of data flowing through your server-side code, like the continuous stream of orders coming from the tables. Instead of dealing with each dish individually, Flows let you handle the data continuously, adapting to the pace and transforming it on the fly.

Here's why Flows are a game-changer:

• No more waiting around for data to arrive. Flows let you launch coroutines to handle the stream asynchronously, keeping your main program free to keep taking orders and managing the overall experience.
• Flows allow you to extract insights, generate reports, or trigger actions in real-time.
• Flows automatically adjust their pace based on downstream processing capabilities, preventing backlogs and ensuring smooth data flow through your system.
• Errors are handled delicately with flows, which transmit them without bringing down the entire service.

Here's an example of using Flows to process a stream of sensor readings:

val sensorReadingsFlow = sensorManager.readings()
    .filter { reading -> reading.temperature > 80 } 
    .map { reading -> "Alert! Sensor ${reading.id} at ${reading.temperature} degrees!" }    
    .launchIn(Dispatchers.IO) 
    .onEach { message -> logger.warn(message) } 
    .collectLatest { message -> sendPushNotification(message) }

This Flow reads sensor readings continuously, filters for high temperatures, transforms them into alert messages, and sends them to users, all in a non-blocking, resilient way.

Flows are a powerful tool for modern server-side development. They let you embrace the world of asynchronous data processing with grace and efficiency, keeping your code responsive, scalable, and ready to handle whatever data banquet your users throw at you.

Testing Your Concurrency Setup

So, you've built your server-side kitchen with agile coroutines, smooth communication channels, and efficient dispatchers. Your data flows like a rushing stream, and your customers (users) are singing your praises. But before you hang the "Open" sign permanently, there's one more crucial step: testing your concurrency magic.

Testing helps you uncover edge cases, prevent crashes, and ensure everything runs smoothly even under heavy load.

Here are some key points for testing concurrent code:

• Focus on isolation: Test individual coroutines and channels in isolation to identify problems in specific components. You can use libraries like kotlinx-coroutines-test to control time and simulate asynchronous behavior.
• Mock dependencies: External dependencies like databases or APIs can add complexity. Mocking these dependencies allows you to focus on coroutine behavior without introducing real-world uncertainties.
• Verify state changes: Ensure coroutines update data structures and flags correctly as they execute. Assert expected values at different points in the execution flow.
• Stress test performance: Push your code to its limits with high volume or complex scenarios. This helps you identify bottlenecks and ensure your system scales gracefully.

Remember, testing concurrent code is not always straightforward. Be patient, experiment with different methods, and don't be afraid to seek help from experienced developers and testing frameworks.

Conclusion

We've explored agile coroutines dancing across tasks, efficient channels keeping them in sync, and smart dispatchers directing the flow. We've seen how Flows seamlessly handle data streams, and we've learned the importance of robust testing to ensure everything runs smoothly.

Now, with this knowledge, you should understand the concept of concurrency in your Kotlin applications. Embrace it, use it wisely, and watch your applications soar to new heights of responsiveness, scalability, and efficiency.

In server-side application development using Kotlin, taking robust security measures is important. Developers encounter various threats and vulnerabilities that can compromise applications. This article delves into comprehensive security strategies tailored for Kotlin server applications, aiming to equip developers with the knowledge to fortify their systems against potential risks.

Security in Kotlin server applications isn't just about preventing unauthorized access. It's also about safeguarding against diverse threats such as injection attacks, cross-site scripting (XSS), and data breaches.

In this article, we'll explore fundamental security practices, authentication methods, access control, input validation, secure communication, and much more.

Authentication Mechanisms

In Kotlin server applications, implementing robust authentication mechanisms is important in controlling access and ensuring data security. One popular method is token-based authentication, which employs tokens (like JSON Web Tokens - JWTs) for user verification. It offers scalability and flexibility, enabling stateless authentication.

Let's delve into a simple implementation of JWT-based authentication using the java-jwt library:

import com.auth0.jwt.JWT
import com.auth0.jwt.algorithms.Algorithm
import java.util.*

fun generateToken(userId: String): String {
    val algorithm = Algorithm.HMAC256("secret_key")
    return JWT.create()
        .withIssuer("your_issuer")
        .withSubject(userId)
        .withExpiresAt(Date(System.currentTimeMillis() + 3600000))
        .sign(algorithm)
}

This function generates a JWT token for a given user ID, signed using an HMAC algorithm. Ensure to securely manage the secret key.

Authorization and Access Control

Authorization involves defining and managing user roles and permissions to regulate access to various parts of an application. In Kotlin, implementing RBAC (role-based access control) ensures proper access control within the server.

Let's create a simple RBAC setup using Ktor:

enum class UserRole {
ADMIN, USER, GUEST
}

fun checkPermission(userRole: UserRole, resource: String, action: String): Boolean {
    return when (userRole) {
        UserRole.ADMIN -> true
        UserRole.USER -> resource == "profile" && (action == "read" || action == "write")
        UserRole.GUEST -> resource == "public" && action == "read"
    }
}

In this example, checkPermission() validates whether a user with a specific role has permission to perform a particular action on a resource.

Input Validation and Data Sanitization

Input validation is crucial to prevent security vulnerabilities like SQL injection and XSS attacks. Kotlin, when used in server applications, should meticulously validate and sanitize user inputs before processing.

Let's consider an example of input validation using regular expressions in Kotlin:

fun isValidEmail(email: String): Boolean {
    val emailRegex = "^[A-Za-z](.*)([@]{1})(.{1,})(\\.)(.{1,})"
    return email.matches(emailRegex.toRegex())
}

fun sanitizeInput(input: String): String {
    return input.replace("<", "&lt;").replace(">", "&gt;")
}

The isValidEmail() function uses a regular expression to verify if an email address is in the correct format. Meanwhile, sanitizeInput() escapes HTML tags to prevent XSS attacks.

Secure Communication and HTTPS

Securing communication between clients and servers is imperative to protect sensitive data. Enabling HTTPS (HTTP Secure) ensures encrypted data transmission over the network.

In Kotlin server applications, configuring HTTPS can be achieved using Ktor:

import io.ktor.server.engine.embeddedServer
import io.ktor.server.netty.Netty
import io.ktor.features.HSTS
import io.ktor.features.HttpsRedirect

fun main() {
    val server = embeddedServer(Netty, port = 8080) {
        install(HttpsRedirect) {
            sslPort = 8443
        }
        install(HSTS) {
            includeSubDomains = true
        }
    }
    server.start(wait = true)
}

In this example, Ktor's HttpsRedirect feature redirects HTTP requests to HTTPS, ensuring secure communication.

Make sure your project has the necessary Ktor dependencies and that you've imported the required features (HSTS and HttpsRedirect) to use these functionalities.

If you encounter errors with the code, make sure that you've included the appropriate Ktor dependencies in your project's build file (for example, build.gradle.kts or pom.xml for Gradle or Maven respectively) and have updated your project to resolve these dependencies.

Handling Security Headers and CSRF Protection

Security headers play a vital role in mitigating various web vulnerabilities. Configuring headers like Content Security Policy (CSP), X-Frame-Options, and others is essential in Kotlin server applications to enhance security.

Let's implement security headers using Ktor:

import io.ktor.application.*
import io.ktor.features.*

fun Application.installSecurityHeaders() {
    install(DefaultHeaders)
    install(ContentNegotiation)
    install(Compression)
    install(CachingHeaders)
    install(XForwardedHeaderSupport)
    install(FrameOptions) {
        frameOptionsHeader = "DENY"
    }
    install(ContentSecurityPolicy) {
        default {
            frameAncestors {
                self
            }
            script {
                unsafeInline = ContentSecurityPolicyHeader.UnsafeInlineSource
            }
        }
    }
}

Here, we use Ktor's ContentSecurityPolicy and FrameOptions features to define security headers like Content Security Policy and X-Frame-Options, mitigating potential risks like clickjacking attacks.

Logging and Monitoring for Security

Comprehensive logging is crucial for detecting security incidents and analyzing application behaviour. Logging security-related events and suspicious activities helps you identify potential threats in Kotlin server applications.

Let's implement logging using the Logback logging framework in Kotlin:

import org.slf4j.LoggerFactory

val logger = LoggerFactory.getLogger("SecurityLogger")

fun logSecurityEvent(event: String) {
    logger.info("Security event: $event")
}

In this example, we've created a SecurityLogger instance using Logback to record security events such as authentication failures or access denied attempts.

Securing Dependencies and Patch Management

Maintaining the security of dependencies within Kotlin projects is fundamental to preempting vulnerabilities introduced by third-party libraries. Regularly updating and managing dependencies is critical to addressing potential security flaws that could compromise the application's integrity.

To ensure the security of dependencies, it's vital to employ best practices such as version pinning and utilizing tools like Gradle or Maven.

Version Pinning

Defining specific versions of dependencies in project configuration files (like build.gradle.kts for Gradle or pom.xml for Maven) ensures that known vulnerabilities are patched. By explicitly specifying versions, developers can control which libraries and versions their project utilizes, minimizing exposure to security risks associated with outdated or vulnerable dependencies.

Dependency Update Automation

Leveraging automated tools or services that periodically scan for dependency updates and security vulnerabilities (for example Dependabot, Renovate) can significantly streamline the process of managing dependencies. These tools automatically identify outdated dependencies and suggest updated versions or patches, simplifying the task of keeping dependencies secure and up-to-date.

In Kotlin projects, managing dependencies securely involves explicitly declaring libraries and versions in build configuration files:

Gradle (build.gradle.kts):

dependencies {
    implementation("org.jetbrains.kotlin:kotlin-stdlib:1.6.0")
}

Maven (pom.xml):

<dependencies>
    <dependency>
        <groupId>org.jetbrains.kotlin</groupId>
        <artifactId>kotlin-stdlib</artifactId>
        <version>1.6.0</version>
    </dependency>
    <!-- Add other dependencies securely and define versions -->
</dependencies>

By employing these practices and utilizing tools that aid in dependency analysis and updates, Kotlin projects can maintain a more robust and secure ecosystem, mitigating the risks associated with outdated or vulnerable dependencies.

Testing and Secure Development Practices

Security testing plays a pivotal role in identifying vulnerabilities within Kotlin server applications. Adopting various testing methodologies helps in detecting and rectifying security flaws early in the development lifecycle.

Penetration Testing:

Performing penetration tests involves simulating attacks to assess the system's security posture. Tools like OWASP ZAP or Burp Suite assist in identifying potential vulnerabilities like SQL injection, XSS, or CSRF.

Vulnerability Scanning:

Automated vulnerability scanning tools, such as Nessus or OpenVAS, can help you identify security weaknesses within the application and its dependencies. These tools scan for known vulnerabilities, outdated libraries, or misconfigurations.

Conclusion

Throughout this guide, we've explored diverse security measures tailored for Kotlin server applications. From authentication mechanisms to securing communication, input validation, and compliance considerations, each aspect contributes significantly to fortifying the application against potential threats.

Ensuring the security of Kotlin server applications is an ongoing endeavour. It's crucial to emphasize the need for continuous vigilance, proactive monitoring, and a proactive approach to address evolving security challenges.

To create secure Kotlin applications, you must adopt a security-first mindset. Prioritizing security considerations at every stage of the development lifecycle helps in crafting robust and trustworthy server applications.

By implementing the best practices discussed in this guide and staying updated on emerging security trends, you can significantly enhance the security of your server applications.

We just posted a 10-hour Android course on the freeCodeCamp.org YouTube channel. Alexandru Cristian created this course. I will help you understand how to develop with Kotlin and Android.

This course will take you on a journey through:

• Collections such as lists, sets, and maps
• Generics and type parameters
• Lambda functions and scope functions
• Android Studio, its file structure, and XML design
• Android widgets like buttons, TextView, EditText, and more
• How to build a fully functional quiz application for Android devices.

The course is divided into several chapters, each focused on a specific topic, to provide a structured learning experience. Here's a glimpse of the chapters included in the course:

1. Introduction
2. List, Set, Map
3. Mapping
4. Zipping and Association
5. Flatten
6. String Representation
7. Filtering
8. Test predicates - any(), none(), all()
9. Plus and Minus Operators
10. Grouping
11. Retrieve Collections Parts
12. Retrieve Single Elements
13. Aggregate Operations - sum(), count(), average(), minOrNull(), maxOrNull()
14. Comparable and Comparator
15. Binary Search
16. Generics - Type Parameters and Casting
17. Generics - Upper Bounds
18. Generics - Covariance and Contravariance
19. Generics - Type Erasure and reified keyword
20. Generics - Where keyword; and 2 Upper Bounds
21. Access Modifiers
22. Packages and Imports
23. Exceptions - Try Catch, Finally
24. Lambda Functions
25. Lambdas - it modifier
26. Scope Functions
27. Download Android Studio
28. Android Studio Presentation
29. Android File Structure
30. Android XML and Design
31. Android XML properties
32. Android - what does findViewById() function do?
33. String XML
34. Android Manifest
35. Android Button and TextView
36. Android Button OnClickListener
37. Android EditText
38. Android App - Convert Inches
39. Android App - Convert Inches 2
40. Android App - Change Color
41. Android Radio Buttons 1
42. Android Radio Buttons 2
43. Android SeekBar
44. Android Toggle Button
45. Quiz App - UI Welcome Screen
46. Quiz App - Creating Question Model
47. Quiz App - Setting the QuizActivity
48. Quiz App - Connecting the UI with the model
49. Quiz App - Adding the Button functionality
50. Quiz App - Selecting the Right and Wrong answers
51. Quiz App - Setting up the UI for ResultActivity
52. Quiz App - Improve Code
53. Quiz App - Sending data to Result Activity
54. Quiz App - Solve score bug

This course is designed to give you a holistic understanding of Kotlin and Android development, with hands-on examples and real-world applications.

Watch the full course on the freeCodeCamp.org YouTube channel (10-hour watch).

Technology advances very quickly these days, and there's always a new programming language or tool to learn.

You may have heard developers discussing the merits of and differences between two popular programming languages – Java and Kotlin.

So what's the difference between them? Which one should you learn? Well, you are in the right place, because that's what we'll talk about in this guide. I'll highlight the major differences between Java and Kotlin that you need to know in a very simple way.

Overview of Kotlin and Java

Kotlin and Java are two popular programming languages used to build software applications for a variety of platforms. While Java has been a dominant language in the software industry for over two decades, Kotlin is a newer language that has gained popularity in recent years due to its modern features and seamless interoperability with Java.

Java was first released in 1995 by Sun Microsystems, and it quickly became a popular language for building enterprise software applications. It is an object-oriented language with a strong emphasis on readability, maintainability, and portability.

Java is platform-independent, which means that it can be compiled and run on any platform that has a Java Virtual Machine (JVM).

Kotlin, on the other hand, was created by JetBrains in 2011 as an alternative to Java. It is a modern, statically-typed programming language that runs on the JVM, Android, and can be compiled to JavaScript.

Kotlin is designed to be concise, safe, and interoperable with Java, making it easy to integrate into existing Java projects.

In recent years, Kotlin has gained significant traction in the developer community, with many companies and organizations adopting it as their primary language for building software applications. But Java still remains a popular choice for building enterprise software, and it is likely to continue to be used for many years to come.

Differences Between Kotlin and Java

In this section, we will examine the key differences between these two programming languages.

It's important to note that this is not an exhaustive list, and there are other differences between Kotlin and Java depending on your specific use case. But this table provides some of the key differences between the two technologies.

Code examples of differences between Kotlin and Java

To write a Lambda Expression in Kotlin looks like this:

val list = listOf(1, 2, 3, 4, 5)
val evenNumbers = list.filter { it % 2 == 0 }

But in Java, it is much more verbose:

List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
List<Integer> evenNumbers = list.stream()
                                 .filter(n -> n % 2 == 0)
                                 .collect(Collectors.toList());

Another practical example is using Extension Functions.

Kotlin allows you to add new functions to existing classes using extension functions:

fun String.isPalindrome(): Boolean {
    return this == this.reversed()
}

In Java, you cannot define extension functions. Instead, you can create utility classes with static methods:

public class StringUtils {
    public static boolean isPalindrome(String str) {
        return str.equals(new StringBuilder(str).reverse().toString());
    }
}

Use Cases for Kotlin and Java

Both Kotlin and Java have their own unique use cases and when it is most suitable to use either of them.

When to use Kotlin:

• Android app development: Kotlin is the recommended language for developing Android apps by Google. It offers features like null safety, concise code, and better readability, making it easier to build and maintain Android applications.
• Web development: you can also use Kotlin for server-side development, and it can run on the Java Virtual Machine (JVM). This makes it a great choice for building web applications, especially when you need interoperability with Java.
• Data science and machine learning: Kotlin has recently gained popularity in the field of data science and machine learning due to its ability to integrate well with Python libraries, such as TensorFlow and PyTorch.
• Cross-platform development: you can use Kotlin to build applications for multiple platforms, including desktop, mobile, and web. This makes it an attractive choice for developers who want to build applications that can run on multiple devices.

When to use Java:

• Enterprise application development: Java has been the go-to language for enterprise application development for decades. It has a vast ecosystem of libraries and frameworks you can use to build complex enterprise applications.
• Legacy systems: Many legacy systems are built on Java, and migrating them to a new language may not be feasible or cost-effective. In these cases, Java is still the best choice for maintaining and updating these systems.
• High-performance applications: Java is known for its performance and scalability, and it is often used for building high-performance applications that require high throughput and low latency.
• Android app development: While Kotlin is now the recommended language for Android app development, Java is still a viable option. Many existing Android apps are built on Java, and you can still use it to build new applications for the platform.
• Large-scale projects: Java's strong type system and emphasis on maintainability and scalability make it an ideal choice for large-scale projects. Its modular architecture also makes it easier to manage and maintain large codebases.
• Desktop application development: you can use Java to build cross-platform desktop applications, making it a good choice for developers who want to build applications that can run on multiple operating systems.
• Financial applications: Java's security features and stability make it a popular choice for building financial applications that require high levels of security and reliability.
• Gaming: Java can also be used for game development, especially for browser-based games. It has a built-in 2D and 3D graphics engine that makes it easy to create games that run on multiple platforms.

Conclusion

In conclusion, Kotlin and Java are both powerful programming languages with their own unique strengths and use cases.

Kotlin is a relatively new language that offers features like null safety, concise code, and better readability, making it a great choice for Android app development, web development, data science, and cross-platform development.

Java, on the other hand, has been around for decades and is the go-to language for enterprise application development, legacy systems, high-performance applications, desktop application development, financial applications, and gaming.

If you're building an Android app, Kotlin is the recommended language by Google. If you're working on a legacy system or an enterprise application, Java is likely the best choice.

Finally, it's worth noting that Kotlin and Java are not mutually exclusive, and in many cases, they can be used together to achieve the best of both worlds.

Let's connect on Twitter and on LinkedIn. You can also subscribe to my YouTube channel.

Happy Coding!

On the other hand, Kotlin is a relatively new programming language that has been gaining popularity in recent years. Both languages are used to build applications for the Java Virtual Machine (JVM), but they differ in terms of syntax, features, and performance.

Java has been around for quite some time and has a vast community and a plethora of libraries. On the other hand, Kotlin is a relatively new language that offers contemporary features and concise syntax, which makes it an appealing alternative for developers.

In this article, we will discuss the differences between Kotlin and Java.

Differences Between Kotlin and Java

Syntax

One of the most significant differences between Kotlin and Java is the syntax. Kotlin has a more concise syntax than Java, which means that it requires less code to perform the same operations.

For example, let's compare the syntax for creating a class in both languages:

//java

public class MyClass {
   private int myField;

   public MyClass(int myField) {
      this.myField = myField;
   }

   public int getMyField() {
      return myField;
   }

   public void setMyField(int myField) {
      this.myField = myField;
   }
}

//kotlin

class MyClass(private var myField: Int) {
   fun getMyField() = myField
   fun setMyField(value: Int) { myField = value }
}

As you can see, the Kotlin version is much more concise and readable than the Java version. In Kotlin, we can define the class and its fields in a single line, and the getters and setters are replaced with property accessors.

Additionally, Kotlin supports type inference, which means that you do not have to specify the data type of a variable explicitly.

//kotlin

val myString = "Hello, world!"

As seen in the Kotlin code above, we can use type inference to declare a variable without explicitly specifying its data type. The compiler will automatically determine the data type based on the value that we assign to the variable. This can make our code more concise and easier to read.

//java

String myString = "Hello, world!";

In the Java code above, you are required to specify the data type of the variable which can make your code more verbose.

Here is another example showing the difference between the verbose syntax of Java and a more concise Kotlin syntax.

//java

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

The code above is a simple "Hello, World!" program in Java that prints “Hello, World!” to the console.

//kotlin

fun main() {
    println("Hello, World!")
}

As you can see, the Kotlin version is much shorter and more expressive. Kotlin achieves this by eliminating unnecessary boilerplate code, such as type declarations and semicolons, and using more natural language constructs.

Null Safety

Both Kotlin and Java compile to bytecode that runs on the JVM, which means they have similar performance characteristics.

But Kotlin has some performance advantages over Java in certain cases. For example, Kotlin's null safety feature can help reduce the number of runtime exceptions and improve the overall performance of the application. And Kotlin's use of immutable data structures can also lead to improved performance.

Null safety is another area where Kotlin differs from Java. In Java, it's possible to have null values assigned to a variable, which can lead to null pointer exceptions at runtime. Kotlin, on the other hand, requires you to explicitly define whether a variable can be null or not. This makes it easier to avoid null pointer exceptions during runtime.

For example, in Kotlin, all variables are non-null by default, meaning that they cannot hold a null value unless explicitly declared as nullable using the "?" operator. This helps to prevent null-related errors at compile-time, rather than waiting until runtime.

//kotlin

var name: String = "John" // non-null variable
var age: Int? = null // nullable variable

Functional Programming

Another significant difference between Java and Kotlin is their support for functional programming. While Java has added some support for functional programming in recent years with the release of Java 8, Kotlin was designed from the ground up to support functional programming concepts.

For example, Kotlin supports lambda expressions, higher-order functions, and extension functions. These features make it easier to write code that is both concise and expressive and can help to improve code quality. Here is a code sample showing this:

//kotlin
// lambda expression
val list = listOf(1, 2, 3)
val doubledList = list.map { it * 2 }

// higher-order function
fun higherOrderFunc(x: Int, y: Int, f: (Int, Int) -> Int): Int {
    return f(x, y)
}
val result = higherOrderFunc(3, 4) { x, y -> x + y }

// extension function
fun Int.isEven() = this % 2 == 0
val isFourEven = 4.isEven()

Conclusion

In summary, Kotlin and Java are both awesome programming languages that have some significant differences. While Java is a more established language with a large community and extensive libraries, Kotlin provides modern features and concise syntax, making it an attractive choice for many developers.

Kotlin's focus on null safety and support for functional programming make it well-suited for modern application development, while Java's performance and library ecosystem make it a good choice for enterprise applications.

Ultimately, the choice between Java and Kotlin will depend on the specific needs of your application and your development team's preferences and skills.

I hope this article was informative.
Happy learning.

If you have ever worked with a database or fetching data from a server, this should all be familiar to you. If not, you have come to the right place.

In this tutorial, we will go over:

• How to setup serialization in a Jetpack Compose project
• How to serialize a data class
• How to de-serialize a data class

You might be asking yourself, what’s so special about serialization in Jetpack Compose? In essence, there isn’t a lot of difference than with a regular Kotlin Android project. The only difference is in the setup.

How to Set Everything Up

Each version of Jetpack Compose corresponds with a version of Kotiln that it is compatible with. Each version of the kotlin-serialization library is also compatible with a specific version of Kotlin. So you need to make sure that each of the three parts in this tripod are compatible with one another.

How can you that?

Your first resource you'll want to consult is the Compose to Kotlin Compatibility Map.

Here you can see which version of Jetpack Compose corresponds to which Kotlin version.

The second resource you will need is the releases page for the kotlin-serialization library. There you will find which library version is compatible with which Kotlin version.

Confused? 😕

Let’s illustrate this with an example:

• Your Jetpack Compose version is 1.1.0.
• Looking over the compatibility map, you see it is compatible with Kotlin version 1.6.10.
• Heading to the releases page of kotlin-serialization library, you see that the version of the kotlin-serialization library that you need to use is 1.3.2.

Head into your project level build.gradle file, and inside the buildscript object, in the dependencies section, put in classpath for the kotlin-serialization library with the version you need.

dependencies {
        ...
        classpath "org.jetbrains.kotlin:kotlin-serialization:X.Y.Z"
 }

Then, head over to your application build.gradle file and do these two things:

1. Add the id ‘org.jetbrains.kotlin.plugin.serialization’ inside of the plugins at the top of the file:

plugins {
   ...
   id 'org.jetbrains.kotlin.plugin.serialization'
}

2. At the bottom of the file, inside the dependencies section add implementation ‘org.jetbrains.kotlinx:kotlinx-serialization-json:X.Y.Z’:

dependencies {
   ...
   implementation 'org.jetbrains.kotlinx:kotlinx-serialization-json:X.Y.Z'
}

Sync your project and you should be good to go.

Note that we are using the json format of the library, but there are other formats that are supported as well:

• Protocol Buffers
• CBOR (Concise Binary Object Representation)
• Properties
• HOCON (Human Optimized Config Object Notation)

⚠️ If you encounter any errors, make sure the versions you put are correct

How to Build Your Data Class

In order to have something we can serialize and later de-serialize, we need to work with data classes.

Creating a data class is simple. If you are using Android Studio, just right click inside your project’s module and choose New Kotlin file. Enter your class name and then append the data keyword before it.

For the sake of this article, let's say we are working with an API that returns a list of users. Each user object has a range of attributes it can have (just to name a few):

• First name
• Last name
• Age
• Birthdate
• Id

To make our data class serializable, all you need to do is add the @Serializable annotation above the class declaration.

@Serializable
data class UserModel(
   val firstName: String,
   val lastName: String,
   val age: Int,
   val birthdate: Date,
   val id: Long
)

Pretty nifty, right?

Well, there’s more.

The variable that will hold the user’s first name is written as firstName. That means that in the response from our server, it needs to return in a field with the same name.

Sometimes, in API responses, the keys are not written in camelCase, but rather in kebab_case. That would mean that the key for first name, might be first_name. In that case, we would have to write it out like this:

@Serializable
data class UserModel(
   val first_name: String,
   val lastName: String,
   val age: Int,
   val birthdate: Date,
   val id: Long
)

But that is not the convention for property names in Kotlin.

So what can we do?

We can use the @SerialName annotation. This allows us to mark what the name of the field will be from the response and then write anything as the property for it.

@Serializable
data class UserModel(
   @SerialName("first_name")
   val firstName: String,
   val lastName: String,
   val age: Int,
   val birthdate: Date,
   val id: Long
)

How to Serialize and De-Serialize

Now that our data class is set up, let’s enjoy the fruits of our labor. Whenever we need to serialize our data class, we will use the Json.encodeToString method:

val dataAsString: String = Json.encodeToString(user)

When we run the above line of code, we will get our data class in string form.

De-serializing our data is as simple as serializing it. We will use the Json.decodeFromString method:

val user: UserModel = Json.decodeFromString<UserModel>(dataAsString)

✋ Notice that we specified which type of data we want to de-serialize to with the type parameter ().

_Photo by [Unsplash](https://unsplash.com/@macroman?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Immo Wegmann / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Time for some extra credit.

Let’s say that in your data class you have a field that you don’t want to serialize. If we take our UserModel class, imagine that we want to have a user’s actual picture (bitmap).

@Serializable
data class UserModel(
   @SerialName("first-name")
   val firstName: String,
   val lastName: String,
   val age: Int,
   val birthdate: Date,
   val id: Long,
   var photo: Bitmap?
)

This is not something we will get from our API call, so how can we exclude it? Because if we don’t, our serialization will fail.

Here to our rescue is the @Transient annotation.

@Serializable
data class UserModel(
   @SerialName("first-name")
   val firstName: String,
   val lastName: String,
   val age: Int,
   val birthdate: Date,
   val id: Long,
   @Transient
   var photo: Bitmap?
)

This will exclude the marked field from being serialized and de-serialized.

• If you want to see a real life example of using serialization inside a project, you can check out a project I made here
• And if you would like to read other articles I have written, you can go here
• For more information about the kotlin-serialization library, you can go here

Thank you for reading! Happy serializing.

I will explain what they are in simple terms, but my main goal is to change how you think about abstractions in general. All of this is in service of helping you develop the art of programming.

These are the topics I will cover:

• What is an abstraction?

• How to use abstractions in your programs
  – How to use interfaces and protocols
  – How to use function types and lambda expressions

• Is abstraction the most important idea in programming?

• How much abstraction do I need?

The code samples will be in Kotlin, but I have written the article assuming you only have basic programming knowledge in any industry standard language.

I also use a variety of approaches to cover both object-oriented and functional styles of code.

What Is An Abstraction?

To begin with, we will discuss what this term means in the most general sense. Here is a simplified definition I have come up with for an abstraction:

“A less detailed representation of an object or concept in nature.”

I know my definition sounds very vague, but we will discuss some clear examples shortly. First, we must understand what detail is.

What Is Detail?

Detail refers to the quantity, or density perhaps, of information. Here are two examples of data models which are more and less detailed:

User {
  name,
  id
}

User {
  name: String,
  id: Integer,
  phone: Integer,
  email: String
}

There is no need to overthink this point! More details is another way of saying more information or more complexity.

The only other key point is to understand what a representation is.

How to Represent Something

Suppose you are going to travel somewhere which has a particularly deadly kind of venomous snake. In order to gain information about this snake, you have a few different options:

• Read a verbal description of the snake and its behaviour

• Look at a drawing or picture of the snake

• Listen to audio of what it sounds like when behaving aggressively

All of the above points are examples of different kinds of representations, or abstractions, of the venomous snake.

In each case, some pieces of information, which accurately represent properties of the real snake, are conveyed. However, neither a verbal description, nor an image, nor a recording can bite you!

Here we see the main utility of abstractions: Conveying important information (also known as details or properties) of an object or concept, while leaving out the unnecessary information.

How to Use Abstractions In Your Programs

Before we discuss some specifics, it is worth mentioning that everything in a computer program is technically an abstraction.

In fact, programming languages, as well as all forms of mathematics, are systems of abstractions.

However, programmers tend to think of abstractions as a narrow band of software entities usually referred to as:

• Interfaces or Protocols

• Abstract Classes

• Function Types/References/Signatures

• Super/Parent-Classes

Unfortunately, the names and mechanics of the above software entities can vary substantially in different programming languages.

For this reason, I will take two examples which may be more or less appropriate to your preferred languages:

1. An interface or protocol (which will also cover abstract classes)

2. A function type or method reference

In any case, don't worry so much about the names or any minor differences in how these things work across languages. Instead, I invite you to focus on the general ideas.

How to Use Interfaces and Protocols

I will use the term interface from here on, but this term is synonymous with protocol. I will also use the term function synonymously with method.

Interfaces allow you to define behaviour of functions, classes, or objects, without defining their implementation.

Don't worry, I am not like some teachers who throw out some jargon and pretend like I am teaching you something.

Let's look at exactly what I mean by behaviour and implementation.

Behaviour literally means a function declaration:

interface UserDataSource {
//this line below has a function declaration but no function "body"
  fun getUserById(id: String): User?
}

data class User(
  val id: String,
  val someData: Any
)

You can see the footnotes below regarding my usage of the term “function declaration.”

To translate this into English, this function declaration says the we are defining a function which:

• Is named “getUserById”

• Accepts a String type called “id” as an argument when called

• Returns a “User” or a null value if no user exists (this is because we have a “?” after the “User” type)

Implementation refers to the function body:

//Note that ":" is short for extends/implements in Kotlin for the class
//declaration
class UserDatabase(): UserDataSource {
//the curly braces, and everything between them, is the implementation
  override fun getUserById(id: String): User? {
    var user: User? = null
    //… not important for this example
    return user
  }
}

Another name for the function inside of the interface is an abstract function. Hopefully, our discussion on abstract meaning “less detail” is starting to make more sense here!

Some notes for accuracy:

1. Some languages have features to define properties, variables, and even implementations (that is, function declarations + function bodies) within interfaces. This does not change the primary purpose of interfaces, though.

2. The term function declaration will be defined differently depending on the language. Instead of worrying about verbal definitions, please consider my code examples to follow what I mean.

What About Abstract Classes?

Apart from in Python (and perhaps other languages I am not aware of), abstract classes are very similar to interfaces except for one key difference: a class may only inherit from a single abstract class.

In my opinion, before languages started to include ways for interfaces to define their own implementations, the use of abstract classes versus interfaces was clear:

• If you only want to share behaviour across a set of software entities, use an interface

• If you want to share implementation and behaviour, use an abstract class instead

Unfortunately, this distinction is very blurry since many languages now have features to add implementation to interfaces (like Java’s Default Methods).

The only general recommendation I can make which does not account for the specific details of any particular programming language is this: Use the simplest construct to get the job done.

How to Use Function Types and Lambda Expressions

There are different ways to achieve abstraction without defining interfaces or classes. But the amount of structure these language features require is still subject to language specifics.

Kotlin provides enough of these features that you will hopefully be able to make some connections with your preferred languages.

How to Use Function Types Instead Of An Interface

We will start with a practical example and then explain the finer details part by part.

Suppose we want to set up an abstract function (recall that this means a function with no implementation) to handle a click event.

Using something like an interface, we could do the following:

//assume this is an platform/OS component that tells you when
//a user clicks something on screen
class PlatformComponent(
  var clickListener: ClickListener? = null
) {
  fun userClickedScreen() {
    //Note: the "?" means handleClick() is only
    //called when clickListener is NOT NULL
    clickListener?.handleClick()
  }
}
//This interfaces hides (abstracts) the concrete class/type
//which handles the click
interface ClickListener {
  fun handleClick()
}
//This concrete class/type handles the click
//by extending the interface
class ScreenController() : ClickListener {
  override fun handleClick() {
    println("Click handled.")
  }
}

fun main() {
  PlatformComponent(
    ScreenController()
  ).userClickedScreen()
}

An alternative approach is to use a function type instead of an interface:

fun main() {
  val controller = ScreenController()
  val component = PlatformComponent(
    //The double colon tells the compiler that we are referring to
    //the function handleClick defined in ScreenController
    controller::handleClick
  )
  component.userClickedScreen()
}

//assume this is an platform/OS component that tells
//you when a user clicks something on screen
class PlatformComponent(
  var clickListener: () -> Unit
) {
  fun userClickedScreen() {
    //This is equivalent to calling ScreenController.handleClick(),
    //but PlatformComponent does not know that. Abstraction!
    clickListener()
  }
}
//This concrete class/type handles the click
class ScreenController() {
  fun handleClick() {
    println("Click handled.")
  }
}

In this example, we can see how there is even less structure required to achieve the same result. But keep in mind that having less structure does not immediately imply better code. Really, it depends.

In any case, with a practical example in mind, we can break down how this code actually works in more detail.

How to Use Function References

If you are unfamiliar with how function types, method references (or whatever else they are called) work, this section explains them in Kotlin. Feel free to jump to the next section if you are already familiar.

Similar to most modern programming languages, we can create a reference variable to a particular function in Kotlin:

var clickListener: () -> Unit

In Kotlin, function types have the following syntax:

(optional list of parameter types) -> return type

For example:

• (Int, Int) -> Int means that the associated function must take in two Int parameters, and return a single Int

• () -> Unit means that a function has no parameters and executes without returning a meaningful value

Unit is roughly equivalent to Java’s void return type or Python’s None type – at least in principle.

When it comes time to call (invoke) a function reference, we have two options:

• clickListener() for short

• clickListener.invoke() is the full syntax, which is necessary when making null-safe calls like clickListener?.invoke(), for example

How to Use Lambda Expressions

In the previous example, it is worth noting that ScreenController does not care what the actual function it is invoking happens to be named.

We can take this level of abstraction even further, by not even defining a ScreenController:

fun main() {
  //note that the outer parenthesis are optional in Kotlin,
  //but may make this easier to understand
  val component = PlatformComponent(
    { println("Click handled.") }
  )
  component.userClickedScreen()
}
//assume this is an platform/OS component that tells
//you when a user clicks something on screen
class PlatformComponent(
  var clickListener: () -> Unit
) {
  fun userClickedScreen() {
    clickListener()
  }
}

Unlike the previous examples, this one is not intended to resemble a practical scenario – just to demonstrate a lambda expression.

The actual lambda expression is this:

{ println(“Click handled.”) }

As you can see, it does not get much more abstract than a lambda expression.

On the surface, it's almost like defining only the implementation but not the behaviour. But at least in Kotlin, the lambda expression must conform to the type we are assigning it to.

In this case, { println(“Click handled.”) } has no parameters and does not return a meaningful value. So it conforms to () -> Unit.

Which Approach Should I Use?

You may wonder which approach you should be using – assuming your language allows for multiple approaches.

The most accurate answer I can give you is that there is no general rule.

Plenty of teachers these days will say “x is worse than y” or simply “x is bad,” because it works great for clickbait and search engine optimization.

But a language, platform, code construct, architecture, and just about anything else can only be judged good, bad, better, or worse relative to your requirements.

In fact, different requirements are the reason we have languages as different as Python and Java which are both extremely popular.

So instead, try different approaches and be skeptical of anyone who makes absolute statements without discussing requirements.

Is Abstraction the Most Important Idea in Programming?

The point of this article was never to say: “Using interfaces and abstract classes everywhere will make you a better programmer.”

In fairness, as many developers do, I went through a phase around 2016–2018 where I did actually think that statement was pretty accurate.

Instead, the point of this article is to explain two things:

• Abstraction in programming, in my opinion, should not specifically mean abstract classes, or any particular code construct

• Abstraction in programming is a process by which we design our software entities according to how much detail they internally (privately) contain and externally (publicly) provide

In a sense, every decision we make about the structure of our code, regardless of the language, comes down to this process of abstraction.

With that being said, how do we know when making some aspect of our program more abstract is beneficial, useless, or detrimental?

How Much Abstraction Do I Need?

I can only think of one kind of situation where you should strongly consider using something like an interface or function type.

Recall that these software entities provide variability of implementation but consistent behaviour. Further, that implementation typically refers to the body of a function.

Two things follow from that observation:

• If no variability of implementation is required, there is not likely to be a benefit of using a more abstract software entity.

• If variability of implementation is required, using a more abstract software entity is likely beneficial.

We will now discuss two situations I have encountered where variability is a requirement.

How to Make Your Code Easier to Test

Suppose that we have some kind of software entity, which must request some user data from a database or network adapter:

class PresentationLogic(
 val datasource: Datasource
) {
    fun start() {
        val someData = datasource.getData()
        presentData(someData)
    }

    //...
}

class Datasource() {
    fun getData(): Data {
        var someData = getLocalOrRemoteData()
        //... error handling and so on

        return someData
    }
}

Also suppose that we want to test PresentationLogic without needing a real datasource to supply the data.

There are a few different ways to solve this problem (see the note below), but a simple solution is to make the datasource more abstract:

class PresentationLogic(
 val datasource: DatasourceInterface
) {
    fun start() {
        val someData = datasource.getData()
        presentData(someData)
    }

    //...
}

interface DatasourceInterface {
    fun getData(): Data
}

From there, we can create a fake implementation of the datasource in a test environment:

class FakeDatasource(): DatasourceInterface {
        override fun getData(): Data {
            return Data()
        }
}

@Test
fun testLogic() {
    val logic = PresentationLogic(
       //here we provide the fake version
       FakeDatasource()
    )
}

Using abstraction, PresentationLogic does not know or care whether it is talking to a fake or real datasource. By extension, it does not need to change to work with either of them. Variability of implementation!

Note that there are other way to achieve this variability apart from using an interface. You could use a mocking library, or configure a build tool to swap out implementations.

There is no clear answer to which approach is better outside of discussing specific requirements.

Also, note that this approach would not actually work unless the details of how the datasource is created are kept separate from PresentationLogic.

This is commonly referred to as Dependency Injection, which I will discuss in a separate article.

How to Work With Different Versions and Vendors of a Service

Suppose that for some reason, you must work with different versions or vendors of the same service depending on different requirements.

An example could be supporting both AWS and Firebase to store the same data. Another example could be supporting a legacy version of a service along with a newer version of that same service.

In any case, it is another situation where variability of implementation is expected.

The code examples we will discuss have the following requirements:

• A client program must use three services, all from different vendors, to perform the same behaviour

• The decision to choose a particular service is determined at runtime based on the environment (platform, OS, hardware, and so on) of the client program

For those wondering, “client” in this context is a generic word for some program or software entity which uses other programs or software entities.

For example, YouTube’s website and mobile apps are “client apps” of YouTube’s backend servers.

Without applying any abstraction, our client program will need to know about every possible service and be told which service to choose:

fun clientProgram(
    request: Request, 
    awsService: AwsService,
    firebaseService: FirebaseService,
    parseService: ParseService
): Result {
    val use: USE_SERVICE = determineBestService()

    val result = when (use) {
        USE_SERVICE.AWS -> awsService.executeRequest(request)
        USE_SERVICE.FIREBASE -> firebaseService.executeRequest(request)
        USE_SERVICE.PARSE -> parseService.executeRequest(request)
    }

    //assume additional work is done before returning the result
    return result
}

enum class USE_SERVICE {
    AWS,
    FIREBASE,
    PARSE
}

Notice that clientProgram has a parameter which refers to specific vendors of the service:

• Amazon Web Services (AWS)

• Firebase

• The now defunct Parse service from Facebook

It follows that any changes to our services will require clientProgram to be refactored (rewritten) appropriately.

The reason I chose Parse as one of the example services is specifically because it was shut down, despite being widely used. There are various reasons why a particular service may no longer fit requirements, but not working any more is a good one.

An alternative approach would be to hide all the details about the service being used from clientProgram. You could use an interface, but for variety’s sake I have used a function type instead:

fun main() {
    //Creating the services
    val awsService = AwsService()
    val firebaseService = FirebaseService()

    //determining which service to use must 
    //not be included in clientProgram
    val use: USE_SERVICE = determineBestService()

    //Assign serviceToUse to the appropriate function
    val serviceToUse: (Request) -> Result = when (use) {
        USE_SERVICE.AWS -> awsService::executeRequest
        USE_SERVICE.FIREBASE -> firebaseService::executeRequest
    }

    val request = getRequest()

    clientProgram(
       request,
       serviceToUse
    )
}


fun clientProgram(
    request: Request, 
    service: (Request) -> Result
): Result {

    val result = service.invoke(request)

    //assume additional work is done before returning the result

    return result
}

enum class USE_SERVICE {
    AWS,
    FIREBASE
}

class AwsService() {
    fun executeRequest(request: Request): Result = Result()
}
class FirebaseService() {
    fun executeRequest(request: Request): Result = Result()
}

The end result of this abstraction is that we can change services without needing to change clientProgram – assuming our behaviour does not change.

I want to point out that I am not advocating that you hide every service behind some kind of abstraction. If no variability is required or expected, there may not be any benefit to extra abstraction.

Closing Thoughts

I hope it is clear when reading this article that my intention is not to push dogmatic opinions about how abstract your code should be.

As a junior and intermediate developer, it took me a few years to realize that it really does depend on project requirements.

I also hope that this article gave you some new ideas and perspectives about what abstraction is and how it can be applied in your code. Good luck and happy coding!

Before you go...

If you liked this article and want more information on these principles and code constructs, check out my free, full length programming fundamentals course. It includes professionally written English, Burmese, and Arabic subtitles.

We just published a full Kotlin course for beginners on the freeCodeCamp.org YouTube channel.

Alex Cristian developed this course. Alex is an experienced developer who has created multiple Android apps.

This course will teach you Kotlin starting from the absolute beginning and going through advanced Kotlin concepts. The course uses intuitive and practical examples and at the end of each section there is a challenge to test your understanding.

Here are the sections covered in this course:

• Introduction
• Install Intellij IDEA
• Hello World
• Variables
• Window
• Integer Type
• DataType: Byte, Short and Long
• Float and Double
• Char and Boolean
• Operators
• Comments
• IfThenElse: Statement-Expression
• Less Than or Equal To Operator
• logical AND operator
• logical OR operator
• When Statement-Expression
• Null
• Functions
• Function: return and expressions
• Functions Overloading
• Functions Default Values
• Functions vararg keyword
• loops: FOR loop
• loops: WHILE and DO WHILE loop, Labels and continue and break
• loops Challenge
• Arrays
• Arrays Challenge
• OOP: Classes
• OOP: Primary Constructor
• OOP: Initializer Blocks
• OOP: Secondary Constructors
• OOP: Constructor Parameters Default Values
• OOP: Getters and Setters
• OOP: lateinit keyword
• OOP: Companion Object
• OOP: Singleton
• OOP: Lazy Initialization
• OOP: Enum Classes
• OOP: Inner Classes
• OOP Challenge
• OOP: Inheritance 1
• OOP: Inheritance 2
• OOP: Sealed Class
• OOP: Abstract Classes
• OOP: Data Class
• OOP: Interfaces 1
• OOP: Interfaces 2
• OOP: Object Expression
• OOP: Delegation
• Lambda Functions and Lambda Expressions
• it parameter in lambda
• List, Set, Map
• Mapping
• Zipping
• Flatten
• String Representation
• Filtering
• Test predicates: any(), none(), all()
• Plus and Minus Operators
• Grouping
• Retrieve Collection parts
• Retrieve Single Elements
• Aggregate Operations: sum(), count(), average(), minOrNull(), maxOrNull()
• Comparable and Comparator
• Binary Search
• Generics: Type Paramenters and Casting
• Generics: Upper Bounds

Watch the full course on the freeCodeCamp.org YouTube channel (13-hour watch).

Hello, everyone. In this step-by-step tutorial, I would like to show you how to deploy a Kotlin Microservice using Docker and AWS App Runner.

Together, we will learn:

• what exactly is AWS App Runner?
• how to configure AWS Command Line Interface on your local machine
• how to push Docker images to Amazon Elastic Container Registry (ECR)
• and finally, how to deploy our containerized application with AWS App Runner

I know, it might sound like a tremendous amount of work. But I am convinced that you will find out how simple it can be with the above tech stack.

Prerequisites

Before we start, make sure that you have Docker already installed on you local machine. We'll need to containerize our application.

If you don't have Docker, then the official Docker documentation will help you set it up in a few minutes.

What Exactly is AWS App Runner?

First, let's take minute to understand what exactly AWS App Runner is.

To put it simply, it is a fully managed service which allows you to build and deploy containerized web applications and APIs with ease.

It takes care of plenty of things, like traffic load balancing, or scaling, which helps developers like you and me focus on the code.

AWS App Runner oftentimes is a great choice when creating a demo or proof of concept, but it's also worth considering for smaller teams without a dedicated person working on infrastructure.

How to Create aSimple Kotlin Microservice

With that being said, let's prepare a simple REST API using Kotlin and Ktor.

If you are not interested in the Ktor implementation, then you can simply clone this GitHub repository and proceed to the How to Build the Docker Image step.

If you are using the IntelliJ IDEA Ultimate Edition, then you can create a Ktor project using the app. Otherwise, you can use the Ktor Project Generator tool and download project to your local machine.

Regardless of your choice, make sure to import the following plugins:

• ContentNegotiation
• kotlinx.serialization
• Routing

How to Configure Serialization

After you've imported the project, create the Serialization.kt file and register application/json content type to the ContentNegotiation feature:

fun Application.configureSerialization() {
    install(ContentNegotiation) {
        json()
    }
}

In simple words, with this code snippet we will be able to serialize Kotlin objects into JSON (and deserialize the JSON into objects, as well).

How to Create a DTO

Now let's implement a MessageDto data class like this:

@Serializable
data class MessageDto(val message: String)

Basically, we will use this generic class to provide messages for our API consumers.

How to Expose Endpoints

As the next step, let's create a Routing.kt file and expose a new endpoint:

fun Application.configureRouting() {
    routing {
        helloWorldRoute()
    }
}

fun Routing.helloWorldRoute() {
    route("/hello") {
        get {
            call.respond(HttpStatusCode.OK, MessageDto("Hello World!"))
        }
    }
}

As you can see, our application will respond with a 200 OK status code to each GET request to the /hello path.

How to Configure the App

Now, let's combine everything inside the Application.kt file:

fun main() {
    embeddedServer(Netty, port = 8080, host = "0.0.0.0") {
        configureRouting()
        configureSerialization()
    }.start(wait = true)
}

As you can see, our Kotlin microservice will be a Netty embedded server running on localhost:8080.

I highly encourage you to run the application and verify that everything is working properly:

GET localhost:8080/hello

Status: 200 OK
Response Body: 
{
    "message": "Hello World!"
}

How to Implement the Dockerfile

Finally, let's add the Dockerfile to the root directory of our project:

FROM openjdk:8-jdk
EXPOSE 8080:8080
RUN mkdir /app
COPY ./build/install/com.codersee.ktor-app-runner/ /app/
WORKDIR /app/bin
CMD ["./com.codersee.ktor-app-runner"]

Make sure that the directory specified for the COPY and CMD commands matches the value of rootProject.name inside the settings.gradle.kts file. If the project's name is xyz , then these commands should reflect that:

...
COPY ./build/install/xyz/ /app/
...
CMD ["./xyz"]

How to Build the Docker Image

At this point, we have everything we need to build our Docker Image, which we will use later for the AWS App Runner deployment.

Run the Gradle Command

As the first step, let's run the installDist command with Gradle Wrapper:

./gradlew installDist

The above command is responsible for assembling the distribution content and installing it on the current machine. Although it might sound difficult, it will simply create necessary files inside the ./build/install/{project-name}/ directory.

Build the Docker Image

As the next step, let's build a Docker Image:

 docker build -t ktor-aws-runner .

As you can see, we named our desired image ktor-aws-runner with the -t option (a shortcut for --tag).

Verify Docker Configuration

Finally, let's run our container to make sure that our Kotlin microservice is working properly:

docker run -p 8080:8080 ktor-aws-runner

As a word of explanation, the -p flag (--port) is responsible for publishing the container's 8080 port to the host 8080 port.

With that being done, after a few seconds we should see the following message in logs:

Application started in 0.078 seconds

Similarly, we can perform a GET request to check if the exposed endpoint is responding correctly.

How to Create and Configure an AWS User

With all of that being done, we can finally start working with AWS. But before we're able to push our Docker Image, we need to make sure that we have AWS CLI installed on our local machine.

We can do that easily with the below command:

 aws --version

 # Result:
 aws-cli/2.5.3 Python/3.9.11 Windows/10 exe/AMD64 prompt/off

The above result indicates that everything is setup correctly. Nevertheless, if we would like to install or update the CLI, then AWS ships with a really good article on that in their official documentation.

Additionally, we have to have the access to AWS Cloud from our computer – and that's what we are going to set up in this step.

In order to set up the access, let's sign in to the AWS Management Console and navigate to the Users feature of the IAM Console. We can do that easily with the search bar at the top:

On the next page, let's click the Add users button:

Then we'll specify the preferred User name along with the Access key – Programmatic access credential type:

With these settings, we will be able to access AWS using a combination of access key and secret.

With that being done, let's hit the Next button. On this page, we have to select the group for our user. For the purpose of this tutorial, let's create a new one, using the button visible below:

Nextly, let's specify a Group name ( admin-group in my case) in the modal and select the AdministratorAccess:

For simplicity, we are going to use the AdministratorAccess. But in real-life scenarios, we should always stick to The Principle of Least Privilege.

After the group is created, let's hit the Next button once again:

On the next page, we have the option of adding custom tags as key-value pairs.

But we won't need them today, so let's simply skip this page:

Finally, we will be redirected to the Review page, where we can validate our previous steps:

As you can see, everything looks good, so let's click Create user:

The user was created successfully, so we can finally import our access and secret keys.

Keep in mind that access and secret keys are highly confidential data and you should never share them with anyone!

Let's click the Download .csv button and fetch the file. Personally, I named it some_user_credentials.csv , but feel free to pick whatever name you like (and remember it :) ).

Next, let's navigate to the download directory and run the following command:

 aws configure import --csv file://some_user_credentials.csv

 # Result:
 Successfully imported 1 profile(s)

Given the above message, we can expect that everything was set up correctly. Additionally, we can verify that a new file called credentials has been created (or updated) inside the .aws directory.

If you are using Windows then your path will be C:\Users\[your_user_name]\.aws:

[some-admin]
aws_access_key_id = [your access key id] 
aws_secret_access_key = [your secret]

How to Push the Docker Image to ECR

At this point, our CLI is properly prepared, so we can learn how to push our local Docker Image to the Elastic Container Registry.

As the first step, let's get back to the Management Console and type container registry in the search bar:

Let's click on the Elastic Container Registry and on the next page, the Create repository button. On the next page, let's select a Private repository and specify a name for it:

For the rest of settings, let's leave the default values, just like below:

Finally, let's hit the Create repository button.

After that, we will be redirected to the Private repositories list, which now contains our newly created repository:

Let's copy the URI and specify the following command in the terminal on our local machine:

docker tag ktor-aws-runner:latest [your_registry_uri]:latest

# Example: docker tag ktor-aws-runner:latest 111111111111.dkr.ecr.us-east-1.amazonaws.com/my-ktor-registry:latest

Why do we need that? Well, basically, when working with Docker we need to tag images with registry host and port (if necessary) in order to push them to any private repository.

With that being done, let's authenticate to the Amazon ECR registry:

aws ecr get-login-password --profile some-admin --region us-east-1 | docker login --username AWS --password-stdin [your registry URI]

# Result:
Login Succeeded

After that, we can run the git push command in order to push the image to ECR:

docker push [your_tagged_image] 

# Example: docker push 111111111111.dkr.ecr.us-east-1.amazonaws.com/my-ktor-registry:latest

Depending on your connection it can take some time, but finally, we should see the update list in our repository:

How to Deploy the Application to AWS App Runner

Now we have everything we need to share our Kotlin microservice with the world :)

Let's get back to the Management Console and search for app runner:

On the next page, let's hit the Create service button.

For the Source configuration, let's choose the Container registry along with Amazon ECR:

As you might have noticed, AWS App Runner can deploy services directly from a source code repository. If you are interested in such a configuration, just get in touch with me via email (contact[at]codersee[dot]com).

Next, let's click Browse and select previously created image:

Let's click continue and for the Deployment settings let's choose Manual and Create new service role:

The role name is not important in this tutorial, so we can specify any value.

As the next step, let's click Next and on the next page, let's provide a Service name along with CPU, Memory and Port information:

Image presents Service name, cpu, memory, environment variables, port and additional configuration settings

As you can see, we have chosen the minimum available combination (and that's what I suggest you do as well).

If we would like to specify some additional environment variables or a custom Start command, then this page allows us to do so. But we won't need any environment variables and we have already added a start command to our Docker Image, so let's leave it as it is.

On the Auto scaling page, select the Custom configuration:

Next, let's create a new configuration called my-configuration:

As I have mentioned in the beginning, AWS App Runner takes care of plenty of things out of the box. One of them is auto scaling. Although it is a great feature, we have to limit it to our preferences and always remember that more resources means higher costs.

As you can see above, this example configuration will not scale our Kotlin Microservice. However, if we increase the Maximum size, then a new instance will be created each time the number of simultaneous request increases by 10.

Let's add the above config and leave the rest of items with their defaults. After we click Next, we will see the Review page with deployment summary.

On this page, let's click Create and Deploy button, which will start the deployment process:

And again, this process can take a few minutes. After it finishes, the status will change from Operation in progress to Running and we will be able to test our Ktor REST API.

Just like previously, let's test the GET /hello endpoint. But this time, as a host name of our microservice, we need to use the value from Default domain:

#Example: 

GET https://aaaaaaaaaa.us-east-1.awsapprunner.com/hello

Status: 200 OK
Response Body: 
{
    "message": "Hello World!"
}

🛑 Important Notice

Please remember to delete all the resources we've created today, so that you won't be charged for them.

It's really easy to forget about all the things we create when learning AWS Cloud and at some point, you may exceed your free quota. Thus, it is a good practice to remove all of that.

Summary

And that's all for this tutorial on how to deploy Kotlin Microservice to AWS Cloud with AWS App Runner. I really hope that after following along with this guide, you're able to easily deploy your applications to Amazon Cloud.

If you enjoyed this material, then you might want to check my other articles. On my blog, I cover plenty of topics related to Kotlin, Ktor, and Spring Boot.

If you would like to ask me about anything, please reach out to me at contact[at]codersee[dot]com.

If you're building an Android app, you should consider adding animations. They can improve your app's user experience and increase retention.

These days, if you see an app that has no animation, it can feel odd and out-dated. And since interactive experiences are kind of the new norm, you'll want to figure out ways to set your app apart.

What We'll Build Here

Now, it might seem difficult to make your app stand out if you just have something basic like a quote sharing app (which is what we are going to work on here). It can be hard to hook the user and keep them interested.

Of course, you could just add two simple buttons to load the next/previous quote and call it a day. But that's pretty basic and any app could do that! Even if you're just building a simple side-project, there's no trade-off for good UX :)

So what we'll do in this tutorial is drop the buttons, and instead have logic where a user can swipe the card to the left. When they've swiped far enough, the app will load a new card with a new quote.

By the end of this post, you will learn how to make a really smooth animated card which a user can swipe that can perform whatever action you choose. Here's a demo of how it works:

Amazing, right? Let's get into it!

Prerequisites

For this tutorial, we will use Kotlin as the programming language for our app – but you can easily translate the code to Java and it would work the same.

For reference, this is the quote card that we wish to enable the swipe feature on.

It is an androidX CardView with a bunch of TextViews and an ImageView. There's also a ProgressBar that gets shown while loading a new quote.

We won't be making the XML code for the user interface. You can get the layout I used here from the GitHub repository, or build your own.

Here's the complete code for our Quotes app, if you wish to check it out. It uses the MVVM design pattern, but this article doesn't rely on what pattern you use for the business logic of your app, as we'll just be working on the UI part.

Now, we're ready to make that awesome swipe interface!

How to Handle Swipes in Our App

To handle swipes, we first need to set a touch listener on the card. Each time an action is performed on the card, the touch listener is called. Within the listener, we will add the logic to do the math and perform the animations.

Here is the blueprint of the touch listener we will be using:

quoteCard.setOnTouchListener(
    View.OnTouchListener { view, event ->
        when (event.action) {
            MotionEvent.ACTION_MOVE -> {
                // TODO: Handle ACTION_MOVE
            }
            MotionEvent.ACTION_UP -> {
                // TODO: Handle ACTION_UP
            }
        }

        // required to by-pass lint warning
        view.performClick()
        return@OnTouchListener true
    }
)

Here, we are specifically listening for 2 actions on the card – the ACTION_MOVE and the ACTION_UP.

• The ACTION_MOVE event is called when a user starts swiping the card, that is, moving it.
• The ACTION_UP is called when a user lifts their finger from the card, basically, when they release it.

There are many other action events that we can override, such as ACTION_DOWN that's called when a person gets hold of the view, but we don't need them for this feature.

The basic setup for the card is done, so let's figure out the swiping logic.

The math behind the swipe action

First, let's re-think what we want to achieve. Implementing functionality is easier when you know exactly what you wish to have. Your code will also make more sense when your requirements are clear.

Here, we have a quote card. We want users to be able to swipe it only to the left, and if the minimum threshold to load a new quote is reached, it should move back to its original position and load a new quote.

Now, to achieve this, let's think of it in terms of the card. Let's define the mean position as the center of the card.

Mean Position of the Card

We want the card to swipe if and only if the user swipes it to the left of the mean position.

Swipe only if moved towards the left of mean position

So how can we make this happen?

You guessed it – we will calculate the mean position and on the ACTION_MOVE event, we will check if the user swiped to the left and move the card accordingly.

How to implement the swipe logic

To implement the logic, we first need to have the starting position of the card, which is fairly easy to calculate. We will just make sure that it is calculated with respect to the full-screen width, not just the card's width.

Place these lines of code before the when(event.action) statement:

quoteCard.setOnTouchListener(
    View.OnTouchListener { view, event ->

        // variables to store current configuration of quote card.
        val displayMetrics = resources.displayMetrics
        val cardWidth = quoteCard.width
        val cardStart = (displayMetrics.widthPixels.toFloat() / 2) - (cardWidth / 2)

        when (event.action) {
            ...
        }
        ...
    }
)

First we get the displayMetrics from resources, which will give us the width of the screen using displayMetrics.widthPixels.toFloat().

Then we get the cardWidth using the width property of the quoteCard.

Finally, we calculate the starting position of the card using the formula (width of screen/2) - (cardWidth/2). Essentially, this gives us the x-coordinate of this position of the card:

Starting position of card.

Now, let's implement the code for the ACTION_MOVE event.

How to handle the ACTION_MOVE event

Inside the ACTION_MOVE block, we first initialise the newX variable that holds the new x-coordinate that the card has been swiped to.

val newX = event.rawX

event.rawX gives us the absolute value of the new coordinate with respect to the screen width.

newX will contain the x-coordinate where the user's finger is, at any given moment. The value 0.0 for newX means that the user swiped to the left-most part of the screen. And for my emulator, 1080.0 represents the right-most edge of the screen.

Since, we want the card to swipe only if newX is less than the mean position of the card, we will place an if-condition here to verify that this is the case.

Think of this with simple values. Let's suppose that the mean position of the card is at x-coordinate 540.0 (small x-coordinate) and the user swipes to 710.0 (bigger x-coordinate). But we don't want them to be able to swipe to the right. And if the user swipes to 320.0 (smaller x-coordinate), then we need to carry out the swipe and move the card to the new position.

Here's the code to implement the above logic:

if (newX - cardWidth < cardStart) { // or newX < cardStart + cardWidth
    quoteCard.animate().x(
        min(cardStart, newX - (cardWidth / 2))
    )
    .setDuration(0)
    .start()
}

We subtract cardWidth from newX because newX is an absolute value which is not relative to the card. It has a higher value because cardStart is towards the start of the screen, and newX is initially somewhere in the middle (a user would generally swipe from the middle).

We want to compare the value of shift in the x-coordinate and median to the value of cardStart, not the value of newX, so we take this into account by subtracting cardWidth.

Then, we carry out the animation using quoteCard.animate() and we change its x coordinate using the x() function.

Now, why do we do min(cardStart, newX - (cardWidth/2))?

This is very interesting and intuitive to understand. From the beginning, we are emphasizing that the card should move only to the left and not to the right.

newX - (cardWidth/2)) is nothing but the swiped distance towards the left (so subtraction is involved – for the right side, it should be added).

The min() function here returns the minimum of the two values provided. If the swiped distance is less than the cardStart, it is returned, otherwise cardStart is used. This is the condition we want to meet and min() makes it really easy to handle.

setDuration(0) ensures that the animation is carried instantaneously (which keeps swiping from feeling laggy). start() actually starts the animation with the given properties.

This animation will clear any doubt your have on how this works:

Visualisation of the aforementioned concept

(I don't have expertise on making animations, this was the best I could come up with.)

Here is the final code for the ACTION_MOVE event:

MotionEvent.ACTION_MOVE -> {
    // get the new coordinate of the event on X-axis
    val newX = event.rawX

    // carry out swipe only if newX - cardWidth < cardStart, that is
    // the card is swiped to the left side, not to the right
    if (newX - cardWidth < cardStart) {
        quoteCard.animate()
            .x(
                min(cardStart, newX - (cardWidth / 2))
            )
        .setDuration(0)
        .start()
    }
}

You can also include a TextView to the UI that reflects when the user should release the card. Place this code inside the above if statement too:

if (quoteCard.x < MIN_SWIPE_DISTANCE) textView.text = getString(R.string.releaseCard)
else textView.text = getString(R.string.infoText)

where MIN_SWIPE_DISTANCE is -250:

// -250 produces best result, feel free to change to your liking
const val MIN_SWIPE_DISTANCE = -250 // User should move alteast -250 from mean position to load new quote

Now, the ACTION_MOVE event is handled properly. Let's write the code to handle the ACTION_UP event, that is, when the card is released.

How to handle the ACTION_UP event

For the ACTION_UP event, we want the card to come back to its original position, wait for about 100 milliseconds, then load a new quote.

The logic to animate the card is similar, but this time we will make its animation duration about 150 millisecond to make it look smooth.

First, create a variable currentX that holds the current value of the x coordinate of the quote card. We'll use this variable later.

var currentX = quoteCard.x

Then, start the animation on the card. Pass the cardStart variable to the x() function to make it return to its original position and set the duration to 150.

quoteCard.animate()
    .x(cardStart)
    .setDuration(150)
// continued below

This time, we set a listener on the animation. A listener is something that keeps an eye on the animation. By using it, we can perform actions on various animation events such as start, end, resume, and more.

// continuation
.setListener(
    object : AnimatorListenerAdapter() {
        override fun onAnimationEnd(animation: Animator) {
            viewLifecycleOwner.lifecycleScope.launch(Dispatchers.Default) {
                delay(100)
                // check if the swipe distance was more than
                // minimum swipe required to load a new quote
                if (currentX < MIN_SWIPE_DISTANCE) {
                    // Add logic to load a new quote if swiped adequately
                    viewModel.getRandomQuote()
                    currentX = 0f
                }
            }
        }
    }
)
.start()

We set a listener to look for the ending of the animation by overriding the onAnimationEnd() function.

As soon as the animation ends, we launch a coroutine (similar to Threads in Java but much more efficient) with a delay of 100 milliseconds. It then checks if the user had swiped further than the MIN_SWIPE_DISTANCE needed to load a new quote. The variable currentX is used for the comparison here.

If the user actually swipes passing the minimum distance, the coroutine is delayed for 100 milliseconds. Then the view model loads a new random quote from the API, also resetting the currentX variable to 0f.

The final code for the ACTION_UP event looks like this:

MotionEvent.ACTION_UP -> {
    var currentX = quoteCard.x
    quoteCard.animate()
        .x(cardStart)
        .setDuration(150)
        .setListener(object : AnimatorListenerAdapter() {
            override fun onAnimationEnd(animation: Animator) {
                viewLifecycleOwner.lifecycleScope.launch(Dispatchers.Default) {
                    delay(100)
                    // check if the swipe distance was more than
                    // minimum swipe required to load a new quote
                    if (currentX < MIN_SWIPE_DISTANCE) {
                        // Add logic to load a new quote if swiped adequately
                        viewModel.getRandomQuote()
                        currentX = 0f
                    }
                }
            }
        })
        .start()
    textView.text = getString(R.string.infoText)
}

Final Code

This is the final code for the complete onTouchListener():

quoteCard.setOnTouchListener(
    View.OnTouchListener { v, event ->

        // variables to store current configuration of quote card.
        val displayMetrics = resources.displayMetrics
        val cardWidth = quoteCard.width
        val cardStart = (displayMetrics.widthPixels.toFloat() / 2) - (cardWidth / 2)

        when (event.action) {
            MotionEvent.ACTION_UP -> {
                var currentX = quoteCard.x
                quoteCard.animate()
                    .x(cardStart)
                    .setDuration(150)
                    .setListener(
                        object : AnimatorListenerAdapter() {
                            override fun onAnimationEnd(animation: Animator) {
                                viewLifecycleOwner.lifecycleScope.launch(Dispatchers.Default) {
                                    delay(100)

                                    // check if the swipe distance was more than
                                    // minimum swipe required to load a new quote
                                    if (currentX < MIN_SWIPE_DISTANCE) {
                                        // Add logic to load a new quote if swiped adequately
                                        viewModel.getRandomQuote()
                                        currentX = 0f
                                    }
                                }
                            }
                        }
                    )
                    .start()
                textView.text = getString(R.string.infoText)
            }
            MotionEvent.ACTION_MOVE -> {
                // get the new co-ordinate of X-axis
                val newX = event.rawX

                // carry out swipe only if newX < cardStart, that is,
                // the card is swiped to the left side, not to the right
                if (newX - cardWidth < cardStart) {
                    quoteCard.animate()
                        .x(
                            min(cardStart, newX - (cardWidth / 2))
                        )
                        .setDuration(0)
                        .start()
                    if (quoteCard.x < MIN_SWIPE_DISTANCE) 
                        textView.text = getString(R.string.releaseCard)
                    else textView.text = getString(R.string.infoText)
                }
            }
        }

        // required to by-pass lint warning
        v.performClick()
        return@OnTouchListener true
    }
}

Congrats! In this tutorial, we've implemented animation that lets a user swipe a card containing a quote to get a new quote.

Don't forget to download the app and test it out yourself. Stars and contributions on the GitHub repository are welcomed!

Conclusion

Now you have learned how to animate a card and handle animation listeners on it. This helps create better UX that makes your app stand out.

Using the knowledge you gained in this post, you can now create most of the following animations for views in Android:

• Programmatically create sliding animations for Android views.

Just as we did in this tutorial.

• Left to right animation

This is fairly simple, just turn the subtraction in the variables to addition and < signs in the if statements to > signs. With these few tweaks here and there, the right to left animations in card view can be turned into left to right ones!

• You can also show and hide views using animations.

For this, you have to keep track of the start position and end position then animate them with alpha() from 0 to 1. For an example, you can refer to my library Accolib to create animated FAQ accordions.

• Basic animated layout changes can be achieved with view animations.

Thanks a lot for reading so far, I hope this post added some value. Subscribe to my newsletter at Genics Blog to stay updated with my future articles!

Compose is a new UI framework for Android (though Desktop and Web support is being developed), which replaces the old XML-based View system.

While still in beta release as of writing this article, I do not expect this particular part of the library to change drastically for the stable release.

Topics include:

• A brief recap of the XML approach

• How to migrate from the XML-based colors, themes, and typography (font) system

• How to set up light and dark themes for your apps in only a few lines of code

• How to use your new Kotlin-based style information in your composables

• How to style Text Composables specifically

Before proceeding, it is important that you understand what a composable is. I will not be stopping to explain that concept here, as I already have in this article.

How We Used to Style Android Apps Using XML Resources

As usual, I like to share with you the motivations behind, and a bit of history on, these topics. In case you do not care, feel free to skip to the next section where we get into the practical stuff.

Android Resources

The Android app resources system is something which the Android team deserves a high five for, at least in my opinion. But like every design decision, a feature in one situation becomes a flaw in another situation.

To be specific, one of the greatest challenges for both platform and application developers alike is to create what I will call localized resources. I am referring to the challenge of building apps which:

• Display text and graphics in a variety of different languages and alphabets

• Look and feel proportionate to a wide variety of form factors (dimensions, densities, and so on.)

Those are just two common examples – there are plenty more. The resource system gives us a place where app developers can provide localized resources which the platform can select for at compile time. This saves us having to write that boilerplate code ourselves.

Feature or Flaw?

While I would never want to manage the boilerplate code necessary for localized string resources myself, that does not mean I enjoy writing XML.

In fact, there are very few things I would prefer to do in XML over a modern, idiomatic, and elegant language such as Kotlin or Swift. Personal preference aside, there is a more technical reason why XML resources are not always ideal.

Please note that this is not meant as a criticism of the platform developers/engineers. It is merely an observation of how design decisions always have benefits and costs.

In order to integrate our XML-based resources into our JVM-based application code, we must necessarily have layers of translation (compilation) and platform bridges (APIs). This can present difficulties for both platform and application developers.

Two common problems I ran into were:

• I want access to a resource in a place where I do not want tight coupling to the platform APIs which provide the resource

• I have to write some ridiculous boilerplate code just to change the look of a View (that is, override something defined within resource styles and themes)

The root problem for everyone involved is tight coupling to the View system and the Android resource system (which are themselves tightly coupled together).

For the platform developers, this means they have to build on top of, or work around gigantic and old codebases. Add that they must also try to have new features work on older Android OS versions, and that becomes a very thankless job.

The result for us application developers is most often a lot of boilerplate code, some hacky workarounds for things which intuitively seem like they should be one-liners. Not to mention the main API for getting these resources is Context, which is a class you really do not want to leak in memory.

Enter Jetpack Compose.

How to Set Up Themes, Colors, and Fonts with Jetpack Compose

With our review of the old system out of the way, let's explore a much prettier and simpler way to style and theme an Android application. I said I would keep this practical, but allow one point.

Since we will be doing that work in Kotlin, it means one very important thing: Both we and the platform developers are much less bound by translation (compilation) and API bridges (Android's R class and Context) between XML and the JVM.

In simple terms, this means much less boilerplate code, and much more control at runtime.

For the practical part of this article, my suggestion to you is to follow this process in the order I explain it. I have structured it in the order I follow when writing this code in a new App.

How to Replace Colors.xml Resources with Kotlin Compose

If you have not already decided upon a color scheme for your application, I suggest that you use the various resources available on the official Material Design website. Try out:

• The color palettes

• The color tool

If you plan to support light and dark app themes (explained shortly), try to select a color scheme which supports white text and a color scheme which supports black text.

Example of light and dark color schemes.

Create a file called something like Color.kt (the name does not matter) and fill it with immutable values:

import androidx.compose.ui.graphics.Color

val primaryGreen = Color(0XFF00bc00)
val primaryCharcoal = Color(0xFF2b2b2b)
val accentAmber = Color(0xFFffe400)

val textColorLight = Color(0xDCFFFFFF)
val textColorDark = Color(0xFFf3f3f3)
val gridLineColorLight = Color.Black
//...

You can either use a predefined value like Color.Black or supply your own ARGB Hex value.

Since ARGB Hex is just a bunch of jargon to describe what the heck "0XFF00bc00" means, let me translate:

• First two characters 0x tell the compiler that this is a hexadecimal number

• Second two characters , "FF" or "DC", represent Transparency/Opaqueness/Alpha in Hex

• The remaining six character pairs represent Red, Green, and Blue

How to Add Fonts and Replace the fontFamily Attribute

Typography (fonts) is also very easy to manage. This is the kind of thing where Kotlin's default arguments are very useful.

Create a file called something like Type.kt (the name still does not matter) and create Typography class...:

val typography = Typography(
    body1 = TextStyle(
        fontFamily = FontFamily.Default,
        fontWeight = FontWeight.Normal,
        fontSize = 16.sp
    ),

    button = TextStyle(
        fontFamily = FontFamily.Default,
        fontWeight = FontWeight.Bold,
        fontSize = 32.sp
    ),

    caption = TextStyle(
        fontFamily = FontFamily.Default,
        fontWeight = FontWeight.Normal,
        fontSize = 12.sp
    )
)
//...

...and some TextStyle classes:

//...
val mainTitle = TextStyle(
    fontFamily = FontFamily.Default,
    fontWeight = FontWeight.Light,
    fontSize = 48.sp,
    textAlign = TextAlign.Center
)

fun dropdownText(color: Color) = TextStyle(
    fontFamily = FontFamily.Default,
    fontWeight = FontWeight.Normal,
    fontSize = 32.sp,
    textAlign = TextAlign.Center,
    color = color
)
//...

Whether you provide public functions or values (I advise against using **var** here) is up to your individual preference and current requirements.

How to Create an App Theme in Jetpack Compose

The last thing you need to configure before using your theme in your composables is a MaterialTheme @Composable. I have mine, and along with my light and dark color palettes in a file called GraphSudokuTheme:

import androidx.compose.foundation.isSystemInDarkTheme
import androidx.compose.material.MaterialTheme
import androidx.compose.material.darkColors
import androidx.compose.material.lightColors
import androidx.compose.runtime.Composable
import androidx.compose.ui.graphics.Color

private val LightColorPalette = lightColors(
    primary = primaryGreen,
    secondary = textColorLight,
    surface = lightGrey,
    primaryVariant = gridLineColorLight,
    onPrimary = accentAmber,
    onSurface = accentAmber
)

private val DarkColorPalette = darkColors(
    //main background color
    primary = primaryCharcoal,
    //used for text color
    secondary = textColorDark,
    //background of sudoku board
    surface = lightGreyAlpha,
    //grid lines of sudoku board
    primaryVariant = gridLineColorLight,
    onPrimary = accentAmber,

    onSurface = accentAmber

)

@Composable
fun GraphSudokuTheme(
    darkTheme: Boolean = isSystemInDarkTheme(),
    content: @Composable () -> Unit
) {

    MaterialTheme(
        colors = if (darkTheme) DarkColorPalette else LightColorPalette,
        typography = typography,
        shapes = shapes,
        content = content
    )
}

Since you should already be familiar with what a composable is (I gave you fair warning), the only new thing here is darkTheme: Boolean = isSystemInDarkTheme().

To give a simplified explanation, isSystemInDarkTheme() is a call which asks any compatible Android device for the user's preference of a light or dark theme.

It returns a boolean value which we can use in a Ternary (Conditional) Assignment expression such as colors = if (darkTheme) DarkColorPalette else LightColorPalette.

That is actually it. Colors, Fonts, and two Themes defined in a few minutes.

How to Use a Theme in Compose

It is now time to use this Theme in your app. In this app, which only has two primary screens, I just use an Activity as a container for my composables:

class NewGameActivity : AppCompatActivity(), NewGameContainer {
    //...
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        //...

        setContent {
            GraphSudokuTheme {
                NewGameScreen(
                    onEventHandler = logic::onEvent,
                    viewModel
                )
            }
        }
        //...
    }

Wherever you find yourself calling setContent {}, my suggestion for beginners is to immediately place your Theme composable inside of it. Doing so will cause the style information to cascade/inherit to each nested composable.

You are done! Almost.

How to Override Styles and Themes

If you can help it, try to include any colors you will want in your light and dark palettes. This way, when you call MaterialTheme.colors.<Color>, the system will handle the conditional logic necessary to pick the appropriate palette:

@Composable
fun NewGameContent(
    onEventHandler: (NewGameEvent) -> Unit,
    viewModel: NewGameViewModel
) {
    Surface(
        Modifier
            .wrapContentHeight()
            .fillMaxWidth()
    ) {
        ConstraintLayout(Modifier.background(MaterialTheme.colors.primary)) { 
            //...
        }
        //...
      }
}

However, sometimes it is more suitable to write your own conditional logic...or I just got lazy. Fortunately Compose makes many such configurations available as properties:

@Composable
fun DoneIcon(onEventHandler: (NewGameEvent) -> Unit) {
    Icon(
        imageVector = Icons.Filled.Done,
        tint = if (MaterialTheme.colors.isLight) textColorLight 
        else textColorDark,
        contentDescription = null,
        modifier = Modifier
            .clickable(
            //...
            )
    )
}

MaterialTheme.Colors.isLight returns a boolean indicating what mode they are in, then we can use another Ternary Assignment from there.

How to Style a Text Composable

Just set the style argument equal to one of your text styles (whether it comes from MaterialTheme or one of the styles within Type.kt):

Text(
    text = stat.toTime(),
    style = statsLabel.copy(
        color = if (isZero) Color.White
        else MaterialTheme.colors.onPrimary,
    fontWeight = FontWeight.Normal
    ),
    modifier = Modifier
        .wrapContentSize()
        .padding(end = 2.dp, bottom = 4.dp),
        textAlign = TextAlign.End
)

TextStyle has its own copy function ready to go should you need to overwrite anything.

And that's it! You now know how to style and theme an application using Jetpack Compose. Thanks for reading :)

Social

You can find me on Instagram here and on Twitter here.

Here are some of my tutorials & courses

https://youtube.com/wiseass https://www.freecodecamp.org/news/author/ryan-michael-kay/ https://skl.sh/35IdKsj (introduction to Android with Android Studio)

In the old system, we used OnClickListeners and other interfaces. In Compose, we can take full advantage of Kotlin’s Sealed Classes, Function Types and Lambda Expressions.

If you do not know what a composable is, consider reading this article which explains the fundamentals.

How to Model UI Events with a Sealed Class

First, we must learn what is meant by UI Events and how to model them with Sealed Classes.

I have described this same process for Java and Kotlin (with the old view system) before, so I will keep this brief.

The Process

For each screen or sub-screen of your UI, ask yourself this question: What are all the different ways which the user can interact with it?

Let's take an example from my first app built fully in compose, Graph Sudoku:

Screenshot of a Sudoku Android App

The sealed class I use to represent the UI interactions of this screen looks like this:

sealed class ActiveGameEvent {
    data class OnInput(val input: Int) : ActiveGameEvent()
    data class OnTileFocused(val x: Int, 
    val y: Int) : ActiveGameEvent()
    object OnNewGameClicked : ActiveGameEvent()
    object OnStart : ActiveGameEvent()
    object OnStop : ActiveGameEvent()
}

To explain briefly:

• OnInput represents a user touching an input button (like 0, 1, 2, 3, 4)

• OnTileFocused represents a user selecting a tile (like the amber highlighted one)

• OnNewGameClicked is self-explanatory

• OnStart and OnStop are lifecycle events which my composables do not care about, but they are used in the Activity which acts as a Container for the composables

Once you have your sealed class set up, you can now handle a wide variety of events using a single event handler function. Sometimes it might make more sense to have multiple event handler functions, so keep in mind that this approach must be adapted to your project's specific requirements.

How to Connect Your Software Architecture

What you have handling these events is totally up to you. Some people think that MVVM is the golden standard of software architectures, but it seems like more and more people are realizing that there is no single architecture which works best for every situation.

For Android with Compose, my current approach is to use a very 3rd party minimalist approach which typically has these things in each feature (screen):

• A (Presentation) Logic class as an event handler

• A ViewModel to store the data necessary to render the View (as the name implies)

• An Activity which acts as a Container (not a god object)

• Composables to form the View

Model-View-Whatever

I do not care what you use as long as you are applying separation of concerns. This is how I arrived at this architecture, by simply asking what should and should not be put together in the same class.

Whether you want your ViewModel, a Fragment, or an Activity to be your event handler, all of them can be set up the same way: Function Types!

Within your class of choice, set up an event handler function which accepts your sealed class as its argument:

class ActiveGameLogic(
    private val container: ActiveGameContainer?,
    private val viewModel: ActiveGameViewModel,
    private val gameRepo: IGameRepository,
    private val statsRepo: IStatisticsRepository,
    dispatcher: DispatcherProvider
) : BaseLogic<ActiveGameEvent>(dispatcher),
    CoroutineScope {
    //...
    override fun onEvent(event: ActiveGameEvent) {
        when (event) {
            is ActiveGameEvent.OnInput -> onInput(
                event.input,
                viewModel.timerState
            )
            ActiveGameEvent.OnNewGameClicked -> onNewGameClicked()
            ActiveGameEvent.OnStart -> onStart()
            ActiveGameEvent.OnStop -> onStop()
            is ActiveGameEvent.OnTileFocused -> onTileFocused(event.x, event.y)
        }
    }
    //...
}

This approach is very organized and makes it easy to test every Unit in this 3rd party library free class through a single entry point.

However, we are not done yet. Naturally, we need a way to get a reference to this event handler function, onEvent, to our Composables. We can do this using a function reference:

class ActiveGameActivity : AppCompatActivity(), ActiveGameContainer {
    private lateinit var logic: ActiveGameLogic

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val viewModel = ActiveGameViewModel()

        setContent {
            ActiveGameScreen(
                onEventHandler = logic::onEvent,
                viewModel
            )
        }

        logic = buildActiveGameLogic(this, viewModel, applicationContext)
    }

      //...
}

I am sure some of you are wondering why I am using an Activity. You can ask me during a livestream Q&A sometime for a detailed answer.

In short, Fragments appear to be a bit pointless with Compose with my approach to architecture (I do not use Jetpack Navigation), and there is nothing wrong with using Activities as a feature specific container. Just avoid writing god activities, basically.

To be specific, the way you make a reference to a function in Kotlin, is by providing the class/interface name (or skip that if it is a Top-Level function), followed by two colons, and the name of the function without any arguments or brackets:

onEventHandler = logic::onEvent

How to Replace onClickListener With Jetpack Compose onClick Modifier

With that stuff ready, we can look at how this works within the composable. Naturally, your root composable will need the event handler function as a parameter:

@Composable
fun ActiveGameScreen(
    onEventHandler: (ActiveGameEvent) -> Unit,
    viewModel: ActiveGameViewModel
) {
//...
}

It can be a bit tricky to get function type syntax correctly, but understand that this really is a reference to a function, which is not so different from a reference to a class.

Just as you should not build god objects, you should not build giant composables:

1. Break your UI down into the smallest reasonable parts

2. Wrap them in a composable function

3. For each composable which has a UI interaction associated with it, it must be given a reference to your event handler function

Here is a composable which represents the input buttons of the Sudoku app, which is given the event handler by reference:

@Composable
fun SudokuInputButton(
    onEventHandler: (ActiveGameEvent) -> Unit,
    number: Int
) {
    Button(
        onClick = { onEventHandler.invoke(ActiveGameEvent.OnInput(number)) },
        modifier = Modifier
            .requiredSize(56.dp)
            .padding(2.dp)
    ) {
        Text(
            text = number.toString(),
            style = inputButton.copy(color = MaterialTheme.colors.onPrimary),
            modifier = Modifier.fillMaxSize()
        )
    }
}

To actually pass the event to the logic class, we must use the invoke function, which will accept arguments as per the function type definition (which accepts an ActiveGameEvent in this case).

At this point, you are ready to handle UI interaction events in Kotlin (compose or not) by taking full advantage of this beautiful and modern programming language.

If you liked this article, share it on social media and consider checking out the resources below to support an independent programmer and content creator.

Social

You can find me on Instagram here and on Twitter here.

Here are some of my tutorials & courses

https://youtube.com/wiseass https://www.freecodecamp.org/news/author/ryan-michael-kay/ https://skl.sh/35IdKsj (introduction to Android with Android Studio)