Last week, the Swift for Android working group announced that Swift now supports Android. This is an exciting milestone for developers who want to leverage Swift's powerful features in Android development. To help developers explore this new capability, I created a Swift Android Gradle Plugin that simplifies the integration of Swift libraries into Android projects.

I've also built a sample application that demonstrates the plugin in action. The app generates fractal images using Swift and renders them with Jetpack Compose. You can read more about it here: https://charlesmuchene.com/swift-android-gradle-plugin-sample-app

Understanding Cross-Compilation for Android

To build a Swift package for Android, we need to cross-compile Swift code to target the Android platform. Cross-compilation is the process of building code on one platform (like your development machine) to run on a different platform (Android devices).

This process requires several tools working together:

1. Swift Toolchain: The core binaries needed to build and run Swift code

2. Swift SDK for Android: Contains all the resources needed to generate and run Swift code for Android (this is what was recently released)

3. Android Native Development Kit (NDK): Cross-compilation tools for native Android development, widely used for building C/C++ code for Android

4. Swift Android Gradle Plugin: Automatically configures build tasks to invoke the required cross-compilation tools

The setup guide in the plugin repository provides detailed instructions for installing these tools on your development machine.

Key Features

The Swift Android Gradle Plugin extends Gradle's functionality by adding new tasks and DSL elements to projects containing Swift code. Here's what makes it powerful:

Seamless Integration with Android Build System
The plugin hooks into the Android project task graph to compile and package Swift sources automatically. It builds for all configured architectures, copies artifacts to the appropriate directories, and cleans up artifacts when the project is cleaned.

Flexible Configuration DSL
The plugin exposes a DSL for build configuration, allowing you to set the target API level, specify which architectures to build for, and customize other build parameters to suit your project's needs.

Android Studio Integration
It works with Android Gradle Plugin (AGP) APIs to suggest Swift source sets in Android Studio, providing a smoother development experience.

Adding the Plugin to Your Project

The Swift Android Gradle Plugin is distributed via JitPack. Here's how to add it to your project:

// build.gradle.kts
plugins {
   // android app/lib plugin must be applied first

   id("com.charlesmuchene.swift-android-gradle-plugin") version "0.1.0-alpha"
}

// settings.gradle.kts
pluginManagement {
   repositories {
      // ...
   }

   // NOTE: Plugin is not published yet!!
   // Clone and add plugin as an included build
   includeBuild("../swift-android-gradle-plugin")
}

Looking Ahead

The Swift SDK for Android is still in its early stages. Currently, there are numerous tools and configuration steps required before building. As the project matures, we can expect this process to become more streamlined and developer-friendly.

That said, you now have everything you need to start experimenting: the SDK, the Swift Android Gradle Plugin, and a sample project to learn from. The foundation is here—now it's time to build.

Happy coding! 😎

Resources

• Swift Android Gradle Plugin Repository

• Sample App Tutorial

• Swift Android Examples

• Swift SDK for Android Getting Started Guide

What the App Does 📱

The app showcases a complete integration between Swift and Android by:

1. Computing fractal images using Swift code

2. Mapping fractal data to colors for each pixel

3. Passing coloring information across the native boundary via Java Native Interface (JNI)

4. Creating bitmap images and rendering them in Compose

5. Continuously animating a zoom into the fractal image

Project Structure 🏗️

Here's an overview of the project layout:

App
├── build.gradle.kts
└── src
    └── main
        ├── AndroidManifest.xml
        ├── java
        │   ├── Activity
        │   ├── StateHolder
        │   ├── Compose UI
        │   └── Native lib definitions
        ├── res
        └── swift
            ├── Package.swift
            └── Sources
                ├── fractals.swift
                └── lib.swift

The project follows the conventional Android app structure with a key addition: the Swift source set. Let me highlight the important components.

Key Components 🔑

1. Native Library Interface 🚪

I created a SwiftLibrary class that serves as the bridge between Kotlin and Swift. This class loads the native library and defines the methods we can call from our app:

class SwiftLibrary {

    init {
        System.loadLibrary("native-lib")
    }

    external fun captionFromSwift(): String

    external fun generateFractal(
        width: Int, 
        height: Int, 
        scale: Double, 
        cx: Double, 
        cy: Double
    ): DoubleArray
}

2. The Swift Source Set ⚡

The Swift source set contains all native Swift code and should be treated as a pure Swift Package Manager (SPM) package.

Package.swift

This manifest file defines what to build from which sources. Here we're building a dynamic library (.so) called native-lib:

// swift-tools-version: 6.3

import PackageDescription

let package = Package(
    name: "native-lib",
    products: [
        .library(name: "Fractals", targets: ["Fractals"]),
        .library(name: "native-lib", type: .dynamic, targets: ["Lib"])
    ],
    targets: [
        .target(name: "Lib", dependencies: ["Fractals"]), 
        .target(name: "Fractals")
    ]
)

Note: The package name native-lib matches the name used to load the native library in our Kotlin code.

lib.swift

This file contains the JNI definitions that link to the external methods in SwiftLibrary:

import Android

@_cdecl("Java_com_charlesmuchene_sample_domain_SwiftLibrary_captionFromSwift")
public func captionFromSwift(
    env: UnsafeMutablePointer<JNIEnv?>, 
    clazz: jclass
) -> jstring { ... }

@_cdecl("Java_com_charlesmuchene_sample_domain_SwiftLibrary_generateFractal")
public func generateFractal(
    env: UnsafeMutablePointer<JNIEnv?>, 
    clazz: jclass, 
    ...
) -> jdoubleArray { ... }

The Android module from the Swift SDK for Android provides the JNIEnv.

fractals.swift

This file contains pure Swift code for fractal generation, exposing the entry point function:

public func generateFractal(
    width: Int, 
    height: Int, 
    scale: Double, 
    cx: Double, 
    cy: Double
) -> [Double] { ... }

With limited Swift support in Android Studio, I wrote the Swift code using Xcode, which offers better language support. Tooling is one area that will likely impact Swift for Android adoption. 💔

3. Project Configuration 📽️

The project is a standard Android app with one important addition—the Swift Android Gradle Plugin:

// build.gradle.kts
plugins {
   // android app/lib plugin must be applied first

   id("com.charlesmuchene.swift-android-gradle-plugin") version "0.1.0-alpha"
}

// settings.gradle.kts
pluginManagement {
   repositories {
      // ...
   }

   // NOTE: Plugin is not published yet!!
   // Clone and add plugin as an included build
   includeBuild("../swift-android-gradle-plugin")
}

Generating the Fractal 🧮

The Swift code generates the Mandelbrot Set, a set of complex numbers C for which the following does not diverge.

$$z_{n+1} = z_n^2 + c$$

This video provides an excellent introduction to the mathematics behind the set.

The algorithm works as follows:

1. For a given grid (width × height), map every pixel to a complex number C

2. For each complex number C, calculate its escape count in the Mandelbrot set

Complex Number Representation 🌀

The Mandelbrot set lives in the complex plane, so I created a struct to represent complex numbers:

internal struct Complex: Sendable {
    var real: Double
    var imag: Double

    func squared() -> Complex {
        let newReal = real * real - imag * imag
        let newImag = 2.0 * real * imag
        return Complex(real: newReal, imag: newImag)
    }

    var magnitudeSquared: Double {
        return real * real + imag * imag
    }
}

The Generation Algorithm 🌿

The core algorithm iterates through each pixel, mapping it to a complex number and calculating its escape count:

func generateMandelbrotGrid(...) async -> [[Double]] {
    var hueGrid: [[Double]] = ...

    for y in 0..<height {
        for x in 0..<width {
            let c = mapPixelToComplex(...)
            let count = mandelbrotEscapeCount(c: c, maxIterations: maxIterations)
            let colorHue = strategy.colorIndex(forCount: count)
            hueGrid[y][x] = colorHue
        }
    }

    return hueGrid
}

Coloring Strategies 🎨

To visualize the fractal, I map each escape count to a color hue. I created a protocol-based system that allows different coloring strategies to be plugged in for various visual effects:

protocol MandelbrotColoringStrategy: Sendable {
    var maxIterations: Int { get }

    /// Maps the escape count (Int) to a color index (e.g., Hue: 0.0 to 1.0)
    func colorIndex(forCount count: Int) -> Double
}

struct DiscreteColoringStrategy: MandelbrotColoringStrategy { ... }

struct ContinuousColoringStrategy: MandelbrotColoringStrategy { ... }

struct InsideColoringStrategy: MandelbrotColoringStrategy { ... }

The demo video uses DiscreteColoringStrategy with 50 iterations. This lower iteration count enables faster rendering during zoom animations, though it results in lower fractal resolution.

Data Transfer via JNI 📄

Data serialization from native code to the Android runtime is the biggest bottleneck in our app. The Mandelbrot generation produces a 2D array of doubles representing escape counts mapped to colors. Passing 2D arrays across JNI is complex and slow.

To improve efficiency, I flatten the array into a single contiguous double array in row-major order:

fileprivate func prepareDataForJNI(grid: [[Double]]) -> [Double] {
    grid.flatMap { $0 }
}

The Kotlin code receives this flat array, converts from HSV to RGB, and uses the colors to construct the image.

Future Optimization: JEP 454: Foreign Function & Memory API was introduced in Java 22. This API enables Java programs to call native libraries and process native data without JNI's brittleness. When Android catches up to Java 22, we could access Mandelbrot data in off-heap memory directly from the app, eliminating this optimization dance.

Swift Concurrency and a 'Recursive Code Fractal' 🫨

The generateMandelbrotGrid function uses Swift's structured concurrency to perform CPU-intensive tasks efficiently. It divides the large problem into smaller, independent tasks (calculating each row), then uses a TaskGroup to solve them in parallel:

func generateMandelbrotGrid(...) async -> [[Double]] {
    var hueGrid: [[Double]] = ...

    await withTaskGroup(of: (Int, [Double]).self) { group in
        for y in 0..<height {
            group.addTask { [capture list] in
                var hueRow = Array(repeating: 0.0, count: width)
                for x in 0..<width {
                    let c = mapPixelToComplex(...)
                    let count = mandelbrotEscapeCount(c: c, maxIterations: maxIterations)
                    hueRow[x] = strategy.colorIndex(forCount: count)
                }
                return (y, hueRow)
            }
        }
        for await (y, row) in group {
            hueGrid[y] = row
        }
    }

    return hueGrid
}

The async keyword signals that the function performs asynchronous work and can pause without blocking threads. The await withTaskGroup(...) pauses execution until all child tasks complete. Each task produces a tuple (Int, [Double]) containing the row index and calculated pixel data.

The Swift runtime schedules tasks to run concurrently across available CPU cores, significantly speeding up the process compared to sequential loops. The for await (y, row) in group loop receives results as tasks finish, and structured concurrency guarantees all tasks complete before proceeding.

The Concurrency Challenge 🧩

Everything worked smoothly until implementing the caller function, generateFractal. This function receives JNI input, creates a coloring strategy, generates the Mandelbrot grid, and returns data to the JNI call.

My initial implementation launched the generator in a Task and used a semaphore to block the thread:

var result: [Double] = []
let semaphore = DispatchSemaphore(value: 0)

Task { [capture list] in
    let renderedGrid = await generateMandelbrotGrid(...)
    result = prepareDataForJNI(grid: renderedGrid)
    semaphore.signal()
}

semaphore.wait()

return result

This failed with a compiler error:

error: sending value of non-Sendable type '() async -> ()' risks causing data races

The problem? A data race. The Task's closure and the generateFractal function can access the result array concurrently, which is unsafe in Swift's concurrency model. The DispatchSemaphore waits for the Task, but doesn't protect the shared result variable from concurrent access.

The Actor Solution 🎭

To protect shared mutable state, I used an Actor to safely manage state and bridge the concurrent and synchronous worlds. Actors serialize access to internal state, guaranteeing only one piece of code can modify the result at a time:

actor ResultHolder<T: Sendable> {
    var value: T?

    func setResult(_ newValue: T) {
        self.value = newValue
    }

    func getResultOrDefault(_ defaultValue: T) -> T {
        self.value ?? defaultValue
    }
}

Refactoring to use the Actor:

let resultHolder = ResultHolder<[Double]>()
let semaphore = DispatchSemaphore(value: 0)

Task { [capture list] in
    let renderedGrid = await generateMandelbrotGrid(...)
    let data = prepareDataForJNI(grid: renderedGrid)
    await resultHolder.setResult(data)
    semaphore.signal()
}

semaphore.wait()

return resultHolder.getResultOrDefault([])

This resolved the data race but introduced a new issue: we must await the call to getResultOrDefault too. The async issue had just moved further down! 🥺

To resolve this, I created a runBlocking function that allows retrieving the result from the actor synchronously. Interestingly, this function has a similar structure to the logic in generateFractal—a recursive code fractal! 🫨

func runBlocking<T: Sendable>(operation: @escaping @Sendable () async -> T) -> T {
    var result: T?
    let semaphore = DispatchSemaphore(value: 0)

    Task {
        result = await operation()
        semaphore.signal()
    }

    semaphore.wait()
    return result! // Safe to force-unwrap: semaphore guarantees result is set
}

The final generateFractal implementation:

let resultHolder = ResultHolder<[Double]>()
let semaphore = DispatchSemaphore(value: 0)

Task { [capture list] in
    let renderedGrid = await generateMandelbrotGrid(...)
    let data = prepareDataForJNI(grid: renderedGrid)
    await resultHolder.setResult(data)
    semaphore.signal()
}

semaphore.wait()

return runBlocking {
    await resultHolder.getResultOrDefault([])
}

Kotlin Concurrency: Choosing the Right Dispatcher 🚫

At first glance, Dispatchers.Default seems like the right choice since we're performing CPU-bound work. However, from the Kotlin perspective, we're invoking native methods (JNI calls) that block the calling JVM thread while native code executes.

Dispatchers.IO is designed specifically for blocking operations and has ideal behavior for our use case:

• Uses an on-demand, uncapped (or very large) pool of worker threads

• When a thread is blocked by a native call, a new thread can be created to handle other IO tasks, preventing starvation of the Default pool

• Ensures native Swift code execution doesn't unnecessarily delay other parts of the application

Animating the Fractal 💫

After the first UI composition, we request the initial fractal image at the default scale. This calls through SwiftLibrary, suspends until the native code responds with the flattened hue array, then maps hue values to RGB and creates a bitmap:

fun createImage(hueArray: DoubleArray, width: Int, height: Int): ImageBitmap {
    val bitmap = createBitmap(width, height)

    for (y in 0 until height) {
        for (x in 0 until width) {
            val index = y * width + x
            val hue = hueArray[index].toFloat()
            val color = Color.hsv(hue * 360f, 1.0f, 1.0f)
            bitmap[x, y] = color.toArgb()
        }
    }

    return bitmap.asImageBitmap()
}

When the image updates in Compose, we animate a float value that updates the image scale, creating a zoom effect. When the animation finishes, we request the next fractal image from the native layer at the new scale. The native layer generates the hue array at the given scale and returns the image, creating a continuous loop.

Conclusion 😮‍💨

This project was both fun and challenging to create. Juggling Compose, app logic, and Swift code is certainly demanding. However, the project showcases an architecture close to production-ready, using modern Android components driven by logic living in native Swift code.

I'm curious to see how adoption of Swift SDK for Android evolves. You now have the SDK, the Swift Android Gradle Plugin, and this sample project to learn from. Go build something amazing.

Happy coding! 😎

Resources 🚚

• Swift Android Gradle Plugin Introduction

• Swift Android Gradle Plugin Sample App Repository

• Swift Android Examples

• Swift SDK for Android Getting Started Guide

I spent the last few days exploring Android XR, Google's latest platform for extended reality applications. After working through the documentation and experimenting with the SDK, I built a demo application featuring an A320neo jetliner in a holding pattern. The project served as a practical way to understand the spatial computing capabilities now available to Android developers. In the video below, you’ll see a typical interaction with an XR device to launch the demo app, navigate from Home Space to Full Space mode and a user looking around in the 3D environment.

Android XR: Spatial Computing on Android 🌌

Android XR represents Google's renewed commitment to extended reality for the masses, developed in collaboration with Samsung and Qualcomm. The platform extends the familiar Android development environment into three-dimensional space, allowing developers to build applications that blend digital content with physical environments.

The platform provides three core capabilities that shaped my approach to the jetliner demo:

1. Developers can spatialize their applications, positioning UI in 3D space rather than constraining them to a traditional 2D screen.

2. SceneCore enables loading and manipulating 3D models with straightforward APIs.

3. ARCore integration allows applications to understand and interact with the physical environment around the user.

Samsung's Project Moohan (aka Galaxy XR ?) launches tomorrow on October 21st at the "Worlds Wide Open" event. This marks the first commercial headset running Android XR, providing developers with actual hardware to target compared to the emulator environment currently available.

Prerequisites 🧰

I built the demo on AS Narwhal 4 Feature Drop | 2025.1.4. The emulator used was an Android 14 (“UpsideDownCake”) arm64-v8a, api level 34, google-xr headset with 12GB disk size — see these instructions on how to set it up. These are the versions for the dependencies used for XR:

androidx-compose = { group = "androidx.xr.compose", name = "compose", version = "1.0.0-alpha07" }
androidx-runtime = { group = "androidx.xr.runtime", name = "runtime", version = "1.0.0-alpha06" }
androidx-scenecore = { group = "androidx.xr.scenecore", name = "scenecore", version = "1.0.0-alpha07" }

Jetpack Compose for XR: Extending Familiar Patterns 🎨

What made Android XR approachable was how it leveraged existing Jetpack Compose knowledge. I have been writing Compose UI for a couple of years now, and the XR SDK introduced spatial extensions that felt natural to adopt. The learning curve focused on spatial thinking rather than completely new frameworks. Here are 2 spatial composables and their use in the demo app:

Subspace: This composable creates a partition of 3D space for spatial layouts. Subspaces are only rendered when spatialization is enabled i.e. in Full Space mode. This capability allowed me to structure my application for both traditional and spatial environments without maintaining separate codebases/modules. For example, here’s my main layout:

@Composable
fun MainScreen() {
    The3DContent() // Contains a Subspace, thus only rendered in Full Space Mode
    The2DContent() // Rendered in Home Space Mode
}

@Composable
fun The3DContent() {
    Subspace {
        Jetliner()
    }
}

Volume: The Volume composable integrates SceneCore entities directly into the Compose hierarchy. This allows me to add and position the 3D jetliner model. The Volume acts as a container for 3D content while maintaining the declarative patterns of Compose.

@Composable
fun Jetliner() {
    ...

    Volume(modifier = modifier) { parent ->
        jetlinerEntity.parent = parent
    }
}

SpatialPanel: SpatialPanels are used to display 2D content in 3D space. The XR codelabs have a good example of using these panels.

Orbiter: This composable attaches UI elements to SpatialPanels, creating companion interfaces that follow panels through space. The orbiter is the ideal choice for contextual UI that needs to remain accessible regardless of panel position.

There are a couple of other Spatial-prefixed composables available in the SDK for creating immersive experiences e.g. Row, CurvedRow, Column, Box, Dialog, Popup, ExternalSurface.

You can find the complete Jetliner XR project at github.com/charlesmuchene/jetliner-xr, demonstrating how some of these composables work together in a functional application.

The Jetliner’s Holding Pattern Implementation ✈️

The core of the application lives in ui/composables/Jetliner.kt. I loaded an A320neo 3D model — sourced from "A320neo" (https://skfb.ly/oKTUt) by pranav27 on Sketchfab under Creative Commons Attribution. Loading models in android XR uses SceneCore APIs that support glTF resources. After loading, I then positioned the model within a Volume. To demo spatial capabilities, the model needed to move continuously, mimicking a holding pattern: the elliptical flight path that pilots execute when awaiting landing clearance — I watch Mentour Pilot 👨‍✈️.

@Composable
fun Jetliner() {
    val modelEntity = loadModelEntity()

    AnimateModelEntity(modelEntity)

    Volume(modifier = modifier) { ... }
}

I implemented the movement animation using Jetpack Compose’s animation APIs and SceneCore's entity transform system. The animation updates the Jetliner’s position and rotation on each frame, calculating new coordinates along an elliptical path.

I control the 2 ellipse radii (a, b), the speed of travel (set by the animation time), and the banking angle of the aircraft. The animation loop runs continuously, providing smooth movement visible from any viewing angle. After that, it’s just a matter of fine-tuning these parameters to create an almost realistic holding pattern. Users wearing an XR device can walk around the virtual environment and marvel at the Jetliner’s motion.

@Composable
private fun AnimateModelEntity(modelEntity: GltfModelEntity?) {
    val angle = animatedAngle()
    val pose = calculatePose(angle)
    modelEntity?.setPose(pose)
}

@Composable
private fun animatedAngle(): Float {
    // Returns an angle between 0 and 360
    // duration: 12s
    // easing: Linear
}

private fun calculatePose(angle: Float): Pose {
    // Convert to radians
    radians = angle × (π / 180)

    // Calculate elliptical position using parametric equations
    x = radiusX × cos(radians)
    z = radiusZ × sin(radians)

    // Add vertical oscillation and offset
    hover = sin(radians × 6) × 0.2
    position = (x, 6 + hover, z - 15)

    // Calculate forward direction (tangent to ellipse)
    forwardX = -radiusX × sin(radians)
    forwardZ = radiusZ × cos(radians)
    forward = normalize(forwardX, 0, forwardZ)

    // Apply banking angle (varies 15-25° through turn)
    bankAngle = 20 + 5 × cos(radians × 2)
    up = rotate(UP_VECTOR, around: forward, by: bankAngle)

    // Combine into orientation
    orientation = lookTowards(forward, up)

    Pose(position, orientation)
}

Building for Spatial Computing 🏗️

Android XR lowers the barrier for developers to explore spatial computing. The platform provides first-class tools; Jetpack Compose for XR, Material Design for XR, and SceneCore, built on languages and patterns already familiar to the Android community. This approach differs significantly from traditional XR development, which typically required game engine expertise.

My jetliner demo was a straightforward implementation, but it validated the development experience. The time from concept to working 3D application was compressed compared to what I expected. Official documentation provided a good starting point, and the Compose-based APIs felt intuitive.

Tomorrow's Project Moohan launch transitions Android XR from emulator-based development to physical hardware. This shift matters — testing spatial experiences on actual headsets reveals usability considerations that emulators cannot fully capture. For example, I would like to walk around the environment, experience raycasting, scale models, move panels with my hands etc. The availability of commercial hardware should accelerate both developer experimentation and practical application development.

For developers considering Android XR, the existing Android skillset translates directly. The spatial aspects add a new dimension, literally 😉, but the underlying development patterns remain consistent. Starting with small experiments, like positioning a simple 3D object or creating a floating panel, provides hands-on learning without overwhelming complexity.

Gotchas 🫨

• Controlling your perspective in the 3D environment on the emulator takes some time to get used to. There are only 4 controls (interaction, view direction, movement, forward/backward) but I constantly forgot to switch between them to get the control I wanted. To be fair, each control has handy keyboard shortcuts that one can learn to switch between controls effectively.

• There’s a non-critical but spammy log from the XR SDK printed for every render frame. You can filter this out from logcat by setting a pattern like to: -message: "Attempt to remove non-JNI local reference"

2025-10-19 10:48:04.708 com.charlesmuchene.xr W Attempt to remove non-JNI local reference

• My Jetliner animation was not as smooth as I expected. I used the code snippet below to measure the animation fps. The measurements in my logs showed anything between 18.0 to 27.0 fps. It could be due to the emulated environment I was running the project on or the size of my Jetliner model. On a dedicated XR hardware, I expect smoother animations for reasonably sized models.

    val fpsState = remember { mutableStateOf("Calculating FPS...") }
    val frameCount = remember { mutableIntStateOf(0) }
    val lastTime = remember { mutableLongStateOf(System.currentTimeMillis()) }
  
    // Log the FPS every second
    LaunchedEffect(Unit) {
        while (true) {
            kotlinx.coroutines.delay(1000) // Wait for 1 second
            val currentTime = System.currentTimeMillis()
            val elapsed = (currentTime - lastTime.longValue) / 1000f
            val fps = frameCount.intValue / elapsed
            fpsState.value = String.format(Locale.getDefault(), "FPS: %.1f", fps)
            Log.d("Animation-FPS", fpsState.value)
  
            // Reset for the next second
            lastTime.longValue = currentTime
            frameCount.intValue = 0
        }
    }
  
    // TODO: Increment frame count on each calculation of the pose
  

Conclusion 🚀

The platform is ready. The tools are in alpha. The first XR consumer device launches tomorrow. For those interested in spatial computing, this represents an accessible entry point built on established technologies. What will you build?

Happy coding! 😎

Resources: Android XR documentation | Jetliner XR project on GitHub

How many times have you been in this situation? You're developing an Android app, need to test different preference values, and find yourself stuck in this frustrating cycle 😢:

1. Change a preference value in code

2. Build the app (wait 30+ seconds)

3. Install on device (wait another 15 seconds)

4. Navigate to the screen to test

5. Realize you need a different value

6. Repeat the entire process

If you're nodding your head, you're not alone. This workflow wastes hours of development time every week. Whether you're working with legacy SharedPreferences or the modern Preferences DataStore, testing different preference configurations shouldn't require constant app rebuilds.

Enter Pref Editor – a game-changing tool that lets you view and modify Android app preferences directly on your device in real-time, without root access.

What is Pref Editor?

Pref Editor is a developer tool that provides instant access to your Android app's preference files during development. It works with both:

• SharedPreferences (legacy preference storage)

• Preferences DataStore (modern preference storage)

The Old Way vs. The New Way

Traditional Workflow:

• Edit code → Build → Install → Test

• 2-5 minutes per change

• Lost context switching

• Multiple APK builds required

With Pref Editor:

• Edit preference → Test immediately

• 5-10 seconds per change

• Stay in testing flow

• Zero rebuilds needed

Key Features That Save Development Time

✅ No Root Required

Works on any Android device with USB debugging enabled – no need to root your test devices.

✅ Real-Time Editing

Changes take effect immediately without app restarts in most cases.

✅ Type Safety

Built-in validation prevents you from saving incompatible data types (e.g., string in an integer field).

✅ Rollback Protection

Every edit can be backed up automatically to enable reverting the changes if necessary (desktop version only).

✅ AI-Powered Natural Language Control

Use plain English commands like "Toggle the dark mode preference" or "Set user level to 5".

Two Powerful Versions to Choose From

Pref Editor comes in two variants designed for different development workflows:

1. Desktop Application (GUI)

Perfect for visual preference management and team members who prefer graphical interfaces.

Best for:

• Developers who prefer visual interfaces

• Team members less comfortable with command-line tools

• Complex preference debugging sessions

2. MCP Server (AI-Powered)

Ideal for developers who want to integrate preference editing into their AI-assisted workflow.

Best for:

• Developers using GitHub Copilot or Claude

• Teams adopting AI-driven development workflows

• Quick preference changes without leaving the IDE

• Natural language preference management

Getting Started: Desktop Application

Prerequisites

• Android device with USB debugging enabled

• ADB (Android Debug Bridge) installed

• Java 17 or higher

Installation & Setup

1. Download the Desktop App

   https://github.com/charlesmuchene/pref-editor-desktop/releases/latest

2. Enable USB Debugging

   • Go to Settings → About Phone

   • Tap "Build Number" 7 times to enable Developer Options

   • Go to Settings → Developer Options

   • Enable "USB Debugging"

3. Connect Your Device

    # Verify ADB connection
    adb devices
    # Should show your device as "device" (not "unauthorized")
   

Basic Usage Walkthrough

Step 1: Launch and Select Device

• Launch Pref Editor Desktop

• Your connected devices appear in the listing

• Select/filter your target device

Step 2: Choose Your App

• Browse/filter installed applications

• Search by package name or app name

• Select the app whose preferences you want to edit

Step 3: Select Preference File

Common preference file names include:

• shared_prefs/[package_name]_preferences.xml

• shared_prefs/user_settings.xml

• files/datastore/app_config.preferences_pb

Step 4: Edit Preferences

• View all preference key-value pairs

• Edit any value inline

• Changes are validated by data type

• Click "Save" to apply changes immediately

Real-World Example: Testing User Onboarding

<!-- Before: User hasn't completed onboarding -->
<boolean name="onboarding_completed" value="false" />
<integer name="onboarding_step" value="0" />
<string name="user_level" value="beginner" />

<!-- After: Simulate experienced user -->
<boolean name="onboarding_completed" value="true" />
<integer name="onboarding_step" value="5" />
<string name="user_level" value="expert" />

Result: Instantly test your app's behavior for users at different onboarding stages without creating multiple test accounts or rebuilding.

Getting Started: MCP Server (AI-Powered)

The MCP (Model Context Protocol) server brings AI-powered preference editing directly to your IDE. Use natural language to modify preferences while coding.

There are plans to re-implement this using ddmlib to take advantage of pre-installed JVM toolchain.

Prerequisites

• Node.js 16+ or npx (or use docker image)

• Android Studio with GitHub Copilot plugin

• OR Claude Desktop

• OR VS Code with compatible AI extension

Android Studio Setup

1. Install the MCP Server

    npm install -g @charlesmuchene/pref-editor-mcp-server
   
    // OR
   
    docker pull charlesmuchene/pref-editor-mcp-server
   

2. Configure GitHub Copilot

   • Open Android Studio

   • Click the "Agent mode" tab in Copilot

   • Click "Add tools" button

   • Click "Add More tools..." (opens mcp.json file)

3. Add Server Configuration

    {
      "servers": {
        "pref-editor-mcp-server": {
          "type": "stdio",
          "command": "npx", // or docker
          "args": ["@charlesmuchene/pref-editor-mcp-server"]
        }
      }
    }
   

Natural Language Commands You Can Use

// Toggle boolean preferences
"Toggle the dark mode setting"
"Enable notifications for this user"
"Turn off the tutorial flag"

// Update numeric values  
"Set the user level to 10"
"Increase the retry count by 5"
"Change the timeout to 30 seconds"

// Modify string preferences
"Update the username to 'testuser123'"
"Set the API endpoint to staging"
"Change the theme to 'material_dark'"

// Add new preferences
"Add a new preference called 'feature_flag_enabled' with value true"
"Create a timestamp preference with the current epoch time"

Example AI Workflow

Developer: "I need to test the premium user experience"
AI + Pref Editor: 
✅ Set user_subscription_status to "premium"
✅ Set subscription_expiry to future date
✅ Enable all premium features
✅ Update user tier to "gold"

Developer: "Now test the expired subscription flow"  
AI + Pref Editor:
✅ Set subscription_expiry to past date
✅ Set user_subscription_status to "expired"
✅ Disable premium features
✅ Add grace_period_days with value 7

Common Use Cases and Time Savings

1. Feature Flag Testing

Before: Rebuild app for each feature flag combination (5 minutes per test)

After: Toggle flags instantly (10 seconds per test)

Time Saved: 4+ minutes per test × 10 tests = 40+ minutes daily

2. User State Simulation

Before: Create multiple user accounts or reset app data

After: Modify user preferences directly

Time Saved: 2-3 minutes per user state test

3. API Environment Switching

Before: Change code, rebuild, test each environment

After: Switch API endpoints via preferences

Time Saved: 3-5 minutes per environment switch

4. Onboarding Flow Testing

Before: Clear app data and repeat onboarding

After: Set completion flags and test any step

Time Saved: 5+ minutes per onboarding test

Troubleshooting Common Issues

Device Not Detected

# Check ADB connection
adb devices

# If "unauthorized", check device screen for USB debugging dialog  
# If no devices, try:
adb kill-server
adb start-server

Permission Denied Errors

# Ensure USB debugging is enabled
# Try different USB cable (data cable, not charge-only)
# Enable "Disable adb authorization timeout" in Developer Options

App Not Listed

# App must be installed on device
# Some system apps may be filtered out
# Try searching by exact package name

Preferences Not Updating

# Some apps cache preferences - try force-stopping the app
# Verify the correct preference file is selected
# Check if app is using DataStore vs SharedPreferences

Which Version Should You Choose?

Choose Desktop App if:

• ✅ You prefer visual interfaces

• ✅ You frequently do complex preference debugging

Choose MCP Server if:

• ✅ You use AI coding assistants (Copilot, Claude, etc.)

• ✅ You want to stay in your IDE while testing

• ✅ You prefer command-line/text-based workflows

Why Not Both?

Many developers use both versions:

• MCP Server for quick changes during active development

• Desktop App for detailed debugging sessions and team collaboration

Performance Impact and Best Practices

Performance Considerations

• Minimal Impact: Reading preferences has negligible performance overhead

• Safe Editing: Type validation prevents crashes from invalid data

• Non-Intrusive: No code changes required in your app

Best Practices

1. Backup Important States: Use the automatic backup feature (only on GUI version) before major changes

2. Test Edge Cases: Try invalid values to ensure your app handles them gracefully

3. Document Configurations: Save useful preference combinations as presets

4. Team Standards: Establish naming conventions for shared preference configurations

Conclusion: Reclaim Your Development Time

Developer time is precious, and every minute spent waiting for builds is a minute not spent solving real problems. Pref Editor transforms Android preference testing from a time-consuming bottleneck into an instant, seamless process.

What You Gain:

• 2-5 minutes saved per preference change (that's hours per week for most developers)

• Faster iteration cycles leading to better-tested features

• Reduced context switching and improved focus

• Enhanced debugging capabilities for preference-related issues

• Better collaboration between developers and QA teams

Getting Started Today:

1. For GUI lovers: Download Pref Editor Desktop

2. For AI enthusiasts: Install Pref Editor MCP Server

3. For teams: Try both and see which fits your workflow better

The future of Android development is about removing friction and focusing on what matters: building great user experiences. Pref Editor is your first step toward a more efficient, enjoyable development process.

Ready to revolutionize your Android preference workflow? Try Pref Editor today and join the developers who've already reclaimed hours of their development time each week.

Happy Androiding! 😎

Additional Resources

• Desktop App Repository: Pref Editor Desktop

• MCP Server Repository: Pref Editor MCP Server

• Docker Hub: Pref Editor MCP Server

• Core Library: Pref Editor Library

• Issues & Feature Requests: Contribute to the project's development: Desktop App / MCP Server

Different languages support creating iterators when working with collections. Check out this article for an example of using iterators in the Rust language. In the JVM land, a language like Java has the concept of a collections framework. In the framework, we find a Set, a List, and a Deque among other types. All these types define a Collection of elements that can be iterated. Their difference lies in how elements are stored and retrieved.

All Java collections conform to the Iterable interface. This interface requires that any object that conforms to it, provide an implementation that will return an instance of an Iterator:

public interface Iterator<E> {

    boolean hasNext();

    E next();

    ...
}

The idea behind this definition is that for any iterator, we can:

• Check if there's a next element in the iteration

• Ask for the next element

By combining these two operations, we can traverse any generic collection without consideration of how the elements are stored and for any number of elements.

If we call iterator.hasNext() and it returns false, what happens if we call iterator.next()? 🤔

While we can directly invoke the above traversal methods to advance an iteration, most JVM languages offer iteration syntactic sugar that decomposes to these calls on an Iterator. Let us consider the following example:

fun main() {
    val numbers = listOf(1, 2, 3, 4)

    for (number in numbers) {
        println(number)
    }
}

The byte code result of compiling the above snippet shows a couple of INVOKEINTERFACE calls to methods on the Iterator interface. Decompiling this byte code, we get the stripped-out listing below:

List numbers = CollectionsKt.listOf(new Integer[]{1, 2, 3, 4});
Iterator var2 = numbers.iterator();

while(var2.hasNext()) {
  int number = ((Number)var2.next()).intValue();
  System.out.println(number);
}

We see that the compiler extracts an Iterator from our numbers collection and replaces the for-loop construct with a while-loop. It then invokes hasNext() to check the existence of the next element. If this returns true, a call to next() retrieves the next element in the collection and we act on it. These last two steps are executed numbers.size() times. This is the typical use case of the iterator pattern for built-in collection types. Let's look at a use case in Android.

Iterating on Android Fragments

Android facilitates building UI by composing several standalone UI portions. When we create these modular UI portions, we bind them to a Fragment and add these fragment instances to an Activity.

The following snippet shows a method that retrieves ids of all fragments added to an Activity.

class SomeActivity : AppCompatActivity() {

    fun fragmentIds(): List<Int> = 
        supportFragmentManager
            .fragments
            .map(Fragment::getId)
}

It might not be obvious that the iterator pattern is in use here. But if we dig into the map(...) call, we find that it is an extension function that iterates and maps elements in an Iterable according to the given transform function. There are a couple more such extensions that add operators applicable to the implementations of Iterable.

As seen, we are oblivious to how the fragments are stored in the FragmentManager. Our algorithm receives each added fragment, extracts its id, and adds this id to a list of fragment ids. This operation is powered by the iterator pattern.

Countries of Africa

As a final example, let's look at a Compose desktop app with a custom implementation of the iterator pattern.

https://ontheworldmap.com/africa/africa-political-map.jpg

The African continent has 54 countries. In our sample code, each country is represented by a couple of properties such as its name, flag etc. We model the continent using a type, Africa, as shown below. By conforming to Iterable, we can iterate through all constituent countries of Africa. We can achieve this by defining an internal iterator, CountryIterator, and returning its instance for a call to iterator() on Africa. In our implementation, we maintain the state of the iteration using the nextIndex property.

class Africa(private val countries: Countries) : Iterable<Country> {

    override fun iterator(): Iterator<Country> = CountryIterator(countries)

    private class CountryIterator(private val countries: Countries) : Iterator<Country> {

        private var nextIndex = if (countries.isEmpty()) -1 else 0

        override fun hasNext(): Boolean = nextIndex in countries.indices

        override fun next(): Country {
            if (!hasNext()) throw NoSuchElementException("No more countries")
            return countries[nextIndex].also {
                nextIndex += 1
            }
        }
    }
}

We then iterate through all countries, adding a corresponding CountryRow item in the LazyColumn for each country.

LazyColumn {
    val iterator = africa.iterator()
    while (iterator.hasNext()) {
        val country = iterator.next()
        item(key = country.code) {
            CountryRow(country = country)
        }
    }
}

This creates the country UI listing as shown:

Get the full source on GitHub.

Conclusion

We can iterate over a collection multiple times, create iterators that mutate the collection, iterate an ordered collection backward and so much more. The iterator pattern is a welcome addition to our set of patterns for software design.

Happy coding!

• Leaf - a primitive object

• Composite - a group of component objects

We (mostly) do not care which underlying object type the interface is representing but we can always find out if need be (see bonus example section). As shown in the diagram above, the component is the common interface for accessing the structure. A composite stores instances of child components -- either leaves or other composites.

With the composite pattern, you only need a reference to the root component and with it, you have access to the rest of the tree. Let us look at an implementation of this pattern in Android.

The Android View(Group)

From the Android docs on View and ViewGroup, we derive a visualization similar to the one above:

• View is the base class for building UI elements (the component)

• A widget is a view representing an interactive UI component (a leaf)

• A Viewgroup is a view representing a container component to hold other Views (the composite)

We use the relationship described here to create rich Android UIs, comprised of a hierarchy of Views. A subtle but important consequence is that each layout is referenced through a single View instance i.e. the root node of the view tree structure. The Activity class provides a setContentView api that accepts a root View instance for representing its UI.

class TheActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Some inflated view e.g. using viewbinding
        val rootView: View = ...

        setContentView(rootView)
    }
}

The View argument to the setContentView method could be representing a one-button UI or a whole suite of widget combinations in a UI hierarchy. All the Activity requires is a reference to the root of the view hierarchy.

Consider two xml-based layouts. One has a TextView as the only view component in the layout and the other, a ConstraintLayout (a ViewGroup) that contains a TextView. Inflating each of these layouts in an Activity, we visually get the same UI.

<!-- activity_ui_with_single_widget.xml -->

<?xml version="1.0" encoding="utf-8"?>
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/textView"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:gravity="center"
    android:text="@string/app_name"
    android:textSize="@dimen/textSize"
    tools:context=".MainActivity" />

<!-- activity_ui_with_viewgroup -->

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/container"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <TextView
        android:id="@+id/textView"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="@string/app_name"
        android:textSize="@dimen/textSize"
        android:gravity="center"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

</androidx.constraintlayout.widget.ConstraintLayout>

To render a UI on the screen, the Android framework invokes methods in the View class such as onMeasure and onDraw. These invocations are then dispatched accordingly to all nodes in the tree structure; either to a Widget or a ViewGroup. This is the composite design pattern in use.

A bonus example

For a bonus example of the composite pattern, let's model a hypothetical representation for a filesystem. (You can find a more robust design in the Java IO package)

A file in our design can be represented as follows:

sealed interface File {
    val name: String
}

File is the common interface as laid out in the pattern. We'll keep this interface simple by ignoring other typical file attributes e.g. permissions, extension etc.

For the basic filesystem elements, our design allows for two types of files - a normal and a directory file.

class Normal(override val name: String) : File

class Directory(
    override val name: String,
    private val files: MutableList<File> = mutableListOf()
) : File, MutableCollection<File> by files

A normal file's definition is trivial, overriding the required name property as a constructor parameter to conform to the File contract.

The directory file is a tad bit involved but conveniently expressible using Kotlin. We start by overriding the required name property as a constructor parameter. Since a directory is a mutable collection of other Files, we model it using the MutableCollection interface and delegate the collection's implementation to a MutableList instance. The list instance also facilitates the actual storage of File entries.

The relationship for File, Normal and Directory can be viewed as follows:

If we are tasked with printing all files for a sample filesystem shown below, our use of the composite design makes it straightforward.

Given a starting directory, here's a typical walk implementation:

fun walk(file: File, printer: Printer) {
    if (file !is Directory) return // runtime-type-check

    for (child in file) {
        printer.print(child)
        walk(child, printer)
    }
}

The walk method takes as arguments a File instance and a Printer. In Kotlin, we can check the type represented by a File instance at runtime using the is operator. This allows for an early return in the method by ignoring Normal files during a recursion as they are not iterable. Each child file in a directory is then printed and then we recurse. Can you work out the output of this algorithm?

fun interface Printer {
    fun print(file: File)
}

Using the File type for our printing method, as shown above, we can print any File instance - whether a normal or directory file - as Liskov Substitution principle applies. Therefore, given a root directory file, we get access to all files in the tree structure thanks to the composite pattern.

Conclusion

The composite design pattern is useful for modeling a tree structure where individual objects and composites are treated uniformly. Given a handle to the root node, you can act on all nodes in the structure. This pattern occurs time and again in written software and is a good addition to your software architecture toolbelt.

Happy coding!

Thanks, Ali for your review and suggestions.

Scenario

Say we are required to print all the numbers in a given range. But before printing the last number, output "I knew it was <last-number>!".

fn print_em(numbers: Range<u32>) {
    let last = numbers.end;
    for number in numbers {
        if number == last {
            println!("I knew last was {}!", number);
        }
        println!("{number}");
    }
}

Straightforward! The requirements are changed such that we're given an Iterator instead of a Range. A possible refactor would look like the following:

fn print_em(numbers: impl Iterator<Item=u32>) {
    let last = numbers.last().expect("No last number");
    for number in numbers {
        if number == last {
            println!("I knew last was {}!", number);
        }
        println!("{number}");
    }
}

In this snippet, we change the type of the parameter to an impl Iterator<Item=u32> i.e. any type that implements the Iterator trait with an associated type of u32.

Our program, however, fails to compile after this change. To determine the last value, we call numbers.last(). This call moves numbers because we have to consume the iterator to reach the last number. numbers is then invalidated and we cannot use it again. This move is highlighted by the compiler as shown below:

Is there another way to determine the last item in an iterator without consuming it?

A Peekable approach

Checking the docs, we find Peekable - an iterator that wraps another iterator. Peekable provides a peek() method that will return an optional reference to the next() value without advancing the iterator. Hmm. Promising.

Using a Peekable while inside an iteration, we can peek() and inspect the optional. If it is the None variant, then we are in the last iteration. Perfect!

fn print_em(numbers: impl Iterator<Item=u32>) {
    let mut peekable = numbers.peekable();
    for number in peekable {
        if let None = peekable.peek() {
            println!("I knew last was {}!", number);
        }
        println!("{number}");
    }
}

Refactor. Save. cargo check. Bam! 🤯

What now? Another move? Well, I suppose these are common gotchas in Rust. Let's take a closer look at the note in the compiler output:

into_iter takes ownership of the receiver self, which moves peekable

Back in the docs, we look for into_iter(). We learn that in the standard library, all Iterators implement the IntoIterator trait and just return themselves. Also, when using a for loop, some de-sugaring happens at compile time for implementations of IntoIterator i.e. peekable::into_iter() is called and that moves our peekable!

Recap: we can take a peek into the future but our iterator is consumed by the de-sugar magic. We, therefore, need to get around this move or avoid it altogether. So, what's our next move? 😎

Change the loop structure

Rust has three kinds of loops:

• for - loop over an iterator -- not suitable for our situation 🙅🏾‍♂️

• loop - loop forever until we stop it -- a possible solution 🤷🏾‍♂️

• while - loop while a condition is true -- a better solution 🙋🏾‍♂️

Using a while loop syntax, we can pattern-match the peekable.next() and bind the value to number in each iteration. With this change, we can iterate over our numbers and peek() to determine if the current number is the last one. Mission accomplished!

fn print_em(numbers: impl Iterator<Item=u32>) {
    let mut peekable = numbers.peekable();
    while let Some(number) = peekable.next() {
        if let None = peekable.peek() {
            println!("I knew last was {}!", number);
        }
        println!("{number}");
    }
}

The code above is safe, consumes the iterator once and adapts to an iterator of any given number of elements. Bam! 🥳

Conclusion

Rust, like any language, takes some getting used to. Learning the gotchas, the standard library and, generally, getting a hang of things in an ecosystem. What better way to learn anything than by doing it?

Tip: when working on a project, have a browser tab open at https://doc.rust-lang.org/std/index.html. Searching works like a charm and the docs are even more charming!

Happy coding!

Rusty Tree 🌲

I created a command line program, rusty-tree, that lists the contents of the current directory. The complete source is on GitHub. When run, you'll get output similar to:

If you've worked with Swift, you'll have some headstart understanding Rust's syntax such as Result<T, E>, associated types, tuples, Option(al), let, mut(ating) struct, Self, references (&), and reference counting. Most concepts in Rust will be familiar but others are uniquely new. Two Rusty terms useful before proceeding:

• Crate - is a compilation unit in Rust

• Cargo - is the package manager for Rust

The Entry Point 🚪

...
fn main() {
    if let Err(e) = run() {
        eprintln!("Error: {e}");
        process:exit(1);
    }
}

The entry function, main(), for our program aka binary crate is short but packs a lot! It contains an if-control structure but with an unsual syntax for evaluating the condition. This is called pattern matching. The pattern is Err(e) and is matched against the return value of run(). If the value is an Err, bind the error it contains to a variable e then evaluate the code block.

The function run() returns an instance of an enum Result - either a success (Ok) or a failure (Err). This enumeration is generic over the types of data for either case as shown below:

enum Result<T, E> {
    Ok(T),
    Err(E)
}

// An example of a function definition that
// either returns a success value or an error
fn a_rust_function() -> Result<Success, Error> {
    ...
}

Note that run() returns a Result - a type alias defined as type Result<T = ()> = std::result::Result<T, RustyError>;

Back to main(). e is an instance of RustyError - a custom error type used in the program. Now to the fun part.

The Heart ❤️

The logic for our rusty-tree program is spread over two functions: run and list.

1. run()

pub fn run() -> Result {
    printer(String::from("."));

    let read_dir = env::current_dir()?.read_dir()?;
    list(read_dir, String::new())?;
    Ok(())
}

We start by printing a "." to denote the current directory. Next, from the process's environment, we grab the current directory and extract an iterator (ReadDir) for the directory's contents. We then call list(..) with this iterator and an empty prefix string.

The above function uses a nifty shortcut for propagating errors - the ? operator. Remember how errors are handled using Result in Rust? The ? operator unwraps the result of a function call, e.g. env::current_dir(), and if it is an Ok it returns the value inside Ok. If it is an Err, it performs an early return of the function in scope propagating the error Result to the caller.

1. list()

The listing algorithm is straightforward:

• Given a directory, iterate over its contents

• Print each entry found (skipping hidden entries)

• If an entry is a directory, repeat these steps

fn list(read_dir: ReadDir, prefix: String) -> Result {
    let mut peekable = read_dir
        .filter(|entry| !is_hidden(entry))
        .peekable();

    ...

    Ok(())
}

In the list() function, we filter the entries in the iterator to exclude hidden files. Iterators in Rust are evaluated lazily hence the above snippet just sets up the 'operation pipeline' in preparation for the iteration.

Curious about peekable()? Check out: Can I borrow the Moved Iterator?

fn list(read_dir: ReadDir, prefix: String) -> Result {
    ...
    while let Some(entry) = peekable.next() {
        ...
        printer(format!("{}{}{}", prefix, symbol.symbol, file_name));

        if file_type.is_dir() {
            let read_dir = entry.path().read_dir()?;
            let prefix = format!("{}{}", prefix, symbol.separator);
            list(read_dir, prefix)?;
        }
    }
    Ok(())
}

The next implementation is a while loop that iterates as long as peekable.next() yields Some(..) value; entry is bound to the value from the iterator. This is a similar pattern-matching syntax as discussed in the previous section.

In each iteration, we print the filename (along with its prefix) and then check if the current entry is a directory. If it is, entry.path().read_dir()? acquires an iterator for the entry's contents and recursively lists them.

When all entries are printed, list() returns an Ok(()) to signal success.

The Run 🏃🏾‍♂️

With the algorithm implemented, we can invoke cargo r to run the project:

$ cargo r
.
├── Cargo.toml
├── LICENSE
├── Cargo.lock
├── README.md
└── src
  ├── test.rs
  ├── error.rs
  ├── lib.rs
  └── main.rs

And to keep test coverage above zero 😀, cargo t yields all green ✅!

$ cargo t
...
running 3 tests
test test::test::create_filename_symbol ... ok
test test::test::create_last_filename_symbol ... ok
test test::test::extract_filename ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Conclusion 🎬

Programs written in Rust are inspected for correctness at compile time by the borrow checker, type checking etc. For example, the Rust compiler will flag the creation of a dangling reference or prevent a data race when using "Safe Rust" - I tried it. I also found the compiler error reporting impressive with the formatting, concise messages, useful hints and error codes to explain an error, usually with an example e.g. default variable immutability.

Rust is fun, has a steep learning curve, a strict compiler, pleasant docs, unique language concepts, and a cool unofficial mascot. I am interested in it to write software for embedded DIY projects but obviously, it's resourceful for performing a variety of other development tasks.

So, when is the next SO developer survey? 😀

Happy coding!

The ViewModel

The ViewModel is an application architecture component we've come to love and talk about -- VM in MVVM architecture. The Android team has packaged a ViewModel in the lifecycle library that we can subclass to model data for our views. From the docs:

A ViewModel is always created in association with a scope (a fragment or an activity) and will be retained as long as the scope is alive. E.g. if it is an Activity, until it is finished.

If the ViewModel is created in association with a scope, wouldn't it be nice to know when the scope is destroyed? Well, it is. Enter the Template Method Pattern.

The Template Method Pattern

The Template Method Pattern is a behavioral pattern in which a step in an operation is deferred to subclasses - a classic case for code reuse. The superclass defines a "hook" with some default behavior and subclasses can extend it if necessary.

Looking at the definition of the Android ViewModel, we find a method clear().

public abstract class ViewModel {
    ... // other important things

    @MainThread
    final void clear() {
        ... // omitted clean-up logic
        onCleared();
    }

    protected void onCleared() {
        // the hook
    }
}

clear() is invoked to perform clean-up logic and in the end, it calls onCleared(). (clear() is called when ViewModel scope is destroyed)

The default implementation for onCleared() is a no-op in the parent class but the protected keyword in the signature tells us that subclasses can have a go at it - and that's our hook, the template method pattern. Any code you put in the overridden method on a ViewModel subclass will be invoked when the ViewModel's scope is destroyed.

Example

Take an example where you have a subscription from some implementation of the reactive streams specification. onCleared() then becomes a suitable last-resort callback for canceling the subscription. Thanks to the template method pattern, we know it is invoked when the ViewModel is destroyed.

class PatternViewModel : ViewModel() {
    private val subscription: Subscription = ...

    override fun onCleared() {
        subscription.cancel()
    }
}

Conclusion

Design patterns make the software we write reusable, and clearer to read and maintain. The template method pattern occurs over and over again in production software and is a useful pattern to learn and use.

Happy coding.

Here's a few hours work -- mostly spent on Flutter's documentation. This' good.

Cross Platform Frameworks

I once, back in 2015, worked with a cross platform framework, Ionic. This was an app rewrite to native Android. That's it. I avoid any work having to do with React Native, Flutter, Xamarin you name them. See. I have been a native iOS, Android dev for more than 5 years now and all has been well for me in this arena. Cross platform tech in my (previous) view is slow, cumbersome to work with, little to no support by major IDEs I prefer, you name it. But that's until Flutter came along.

Flutter hints

I came across Flutter sometime in 2018. My reaction was, "Yet another cross-platform framework 😏". At that time I was in my second year adopting Kotlin at my workplace and was not about to start looking into Flutter.

Just last week, I was thinking of a hobby app. I use such to hone my development skills but I always do them in 2s: iOS (Swift, Xcode and all), then Android (Kotlin, Studio and all). This takes quite some time, as you can imagine, but in the end it's always worthwhile. This time it was different. I wanted an app done -- and fast. Enter Flutter.

One codebase for multiple target platforms is something we've always wanted on mobile -- think what Java did for desktop. And Flutter seems to have nailed it. Or put differently, caught my attention.

The framework

It's been a couple of days playing around with the framework and here are my thoughts.

• Dart. What a language! Derives a lot from other modern languages. Feels 'fluid' like Javascript, but it's statically typed. It's functional, object oriented, imperative with support for both AOT (Ahead of Time) and JIT (Just in Time) compilation. I'll mention more in the Dart section later in this article.

• Minimalist structure

A Flutter project is configured using a yaml file: pubspec.yaml. Assets e.g. images, fonts, sdk, dependencies, project name, description are all declared here. One wonderful thing about the project structure is that you work on the lib directory for the majority of the time.

CLI commands are concise too.

$ flutter create amazing_app

$ flutter run

There's a common phrase in the Flutter community:

Everything is a widget.

How minimalist can it get than that? Flutter is a UI framework and you'll be working with widgets a lot!

• Composition over Inheritance. This was a favourite discussion point to ask in screening interviews. Let Flutter teach you. The fundamental idea of composition is to promote reusability and enhance decoupling in your codebase. From the sdk itself to the framework API, Flutter is built with composition in mind. Say you need to display a list item for your app. Compose it from widgets. What will be the body of my new awesome screen? You got it. Any widget courtesy of composition! This doesn't mean there's no inheritance. In fact you will often be extending some existing common widgets: StatefulWidget and StatelessWidgets. But the core design of the framework embraces composition to give you control.

• IDE support. Through the power of plugins, Flutter development is a breeze in VS Code, Android Studio (and IntelliJ) and even on Emacs! The plugins provide formatting, hot reloading, common Flutter code snippets, debugging tools etc.

Flutter is a welcome addition to my tools. Expressive UI, native performance and fast development are some of the biggest benefits you get from it. Learn more at the official website.

Dart

Dart is brilliant. Having done some Javascript, Swift, Java, Kotlin, Typescript, I can appreciate the effort by the language developers in making a modern language. (I'll also use these languages as my references in this section).

Some of the key language highlights I have come across are:

• Type inference. Every modern language needs to have this feature in my opinion. Compilers are becoming smarter with every release. Dart uses the var, final, const keywords to declare a variable. If the context has enough information, it will infer the correct type. You can always provide an explicit type or use casting to disambiguate.

• First class functions. Dart supports higher order functions with the Function type to represent functions. Single expression functions have a special syntax similar to Kotlin's.

• Generics. Of course. 🙈

• Extension methods. Swift and Kotlin come to mind. This is the ability of Dart to add a method on an existing type.

• Null safety. As of the time of writing, this feature of the Dart's type system is in tech preview. The implementation is familiar to Kotlin or Swift users -- types in your code are non-nullable by default. You explicitly declare the nullability of a type using a ? after the type e.g. int?. More information here.

• Built-in concurrency. Dart has async-await keywords and then-able Futures that allow us to write asynchronous code.

  Future<num> derivePlanksConstant(energy, frequency) async => /* Ask the universe. */;
  

  Streams, json de/encoding, HttpServer 😱, math library, collections, a whole html library and so much more. More on a tour of Dart's libraries.

Grimacing points 😬

Finally, here's a rant on not-so-good things from both Flutter and Dart.

• State! State is cumbersome to write and understand on the first run. I've found IDEs helpful with the restructuring to accommodate state.

  Disclaimer: I have found out that understanding under-the-hood working of Flutter clarifies why state is implemented this way -- widgets are just blueprints for what to render and state is stored by element in the element tree and not the widget in the widget tree).

• Underscore for private scope. Seriously Dart?

• Native platform UI. Flutter controls every pixel by drawing on a canvas. If you need a native platform there's some work on your side. Some widgets are adaptive eg. Switch but still you have to explicitly ask it to adapt to the platform look. In fact, the nature of the platform widgets comes from the material theming. For iOS look and feel, you need to use Cupertino widgets (Cupertino because of trademark issues I presume).

• Semicolons. I have to include this. Having written quite some Swift code of late, I'm finding myself forgetting the semicolon a lot. This' not a deal-breaker though. We've had a lot more Java days.

Conclusion

Love them, hate them, cross platform frameworks have done well for themselves. Addition of Flutter to the list by a tech giant only suggests there's a need and freelance opportunities online tell the same story.

The speed at which you can spin up an app for both platforms using Flutter is just mind blowing! Having done native development for both iOS and Android, I can appreciate the niche this framework is addressing.

What can I say?

Welcome Flutter to my toolbelt.

Have a project? Let's connect.

Happy coding! 😎

References

• Flutter

• Dart

Results here. Project not running? I've probably turned off the Pi or using it for another project. Source code: https://github.com/charlesmuchene/speedtest

RaspberryPi

A RaspberryPi is a credit card sized computer: a favorite for hobby electronics or just a plain computer to play around with. For this article, I choose the latter.

Primer

Working from home in 2020 has come with its own requirements, one being a stable internet connection. Freezing in a zoom call or missing the last part of a meeting has nothing but frustrated those of us in never ending meetings for work, study, meets etc. I wanted to do a speed test on my ISP's service. My go to service for such tests if fast.com. It has been reliable and quite accurate but I have to continuously reload the browser and record my speeds. However, I recently learnt of speedtest.net, quite an intuitive name. In addition to the browser (and other clients), speedtest has a CLI client. Perfecto! 🎉

Enough chat. Let's build this.

The Project

To run a speed test, we need our computer setup.

The Pi

My Raspberry is a Pi 3 Model with a Quad Core 1.2GHz Broadcom BCM2837 64bit CPU, and 1GB RAM. Not bad at all for this project. Check out the full specs on the official website. It had a 16GB sdcard running Android Things OS for a previous project I did in 2018 on Android Debug Bridge. This had to go out and in came Raspberry Pi OS. The Pi organization has a new way of burning the OS on an sdcard: the Raspberry Pi Imager. Let's give this a try.

I chose a headless version of the OS as I don't need the desktop -- who needs one? 😀. This is suitable for my use case, SSHing and terminal work, and above all, a lightweight download, 400MB.

After a few minutes, the download completes, verified and ready for us to boot the Pi.

Configuration

The installed Raspberry Pi OS is a port of Debian and thus with a quick search online, you can get anything up and running. As my Pi is headless, I added empty file to the boot partition named ssh to enable ssh. I followed this awesome, quick help on the official website. With this in place, I boot the Pi and plugin an ethernet cable from my home router.

Next, we need a way to 'get into the Pi'. To find out its address, I used this quick help. My Pi version runs an mDNS, and thus with just a ping to raspberrypi.local, voila! Address resolved!

Having to plugin the Pi to the router for configuration and internet access is tedious and obviously limiting on the location you can place it. A quick search on the official website, I find a short article on enabling wireless access here. Now we are one wire-less.

Tools

SSHing into the Pi, I run an update on the OS and installed some tools. Here's the fun part.

Ookla's speedtest

The instructions on their website are sufficient to have the cli tool up and running on the Pi. After installation, a quick run of speedtest on the Pi's terminal seems to do the job.

Speedtest's cli client is suitable for my use since I can launch it using a bash script. In addition, the tool has different options on the output of the test with the default one, human readable format (shown above) being good enough for me. But I'll have to parse this to extract the interesting parts. More on this later.

The cronjob

I wrote a short script to run the speedtest after every 10 mins for 1 week then killed the job. Crontab guru can help you out on this.

For reference here's the speed.sh. It executes the speedtest and appends a stripped down version of the output to a file.

#!/bin/bash

output_file=~/internet/result
output=$((speedtest | tail -n 5) 2>&1)
url=$((echo "$output" | tail -n 1 | cut -d / -f 6) 2>&1)
output=$((echo "$output" | head -n 4) 2>&1)
echo >> $output_file
echo "**********************************************" >> $output_file
echo $(date) >> $output_file
echo "**********************************************" >> $output_file
echo "$output" >> $output_file
echo "Url: $url" >> $output_file

Node Js

Next, I install Node Js. I use it to parse the output file of the speedtest in to the respective parts: download, upload, loss and latency.

const { EOL } = require('os');
const fs = require('fs');
const path = require('path');

let latencyRegex = /latency:\s+(\d{1,3}\.\d{1,2})/gi;
let downloadRegex = /download:\s+(\d{1,3}\.\d{1,2})/gi;

...

const inputStream = fs.createReadStream(path.join(__dirname, 'result')).setEncoding('utf-8');
inputStream.on('data', (chunk) => {
    let text = Buffer.from(chunk).toString('utf-8');

...

    [ timeRegex, latencyRegex, downloadRegex, uploadRegex, lossRegex ].forEach((regex) =>
        populateData(text, regex, currentLastIndex, data)
    );

    // Write data to file
    outputStream.write(data.flatMap((element) => element.join()).join(EOL));

    // If out of bounds, flush back to readstream
    if (chunk.length - currentLastIndex > 0) inputStream.unshift(text.substring(currentLastIndex), 'utf-8');
});

inputStream.on('end', () => {
    inputStream.close();
    ...
});

inputStream.on('error', console.log);

...

The complete script can be found at play.js on this project's repository here: https://github.com/charlesmuchene/speedtest.

Lighttpd

For presentation, I wanted access on the browser. I installed Lighttpd, a lightweight server with a small memory footprint to serve the files of the project - a html file, a js file and the parsed output from the above operation. For the results, I chose to draw a line graph depicting the performance of my connection using D3 -- a popular Js lib for graphing.

let svg = d3
        .select(`#data${index}`)
        .append('svg')
...
            svg
                .append('path')
                .datum(data)
                .attr('fill', 'none')
                .attr('stroke', colors[index])
                .attr('stroke-width', 1.5)
                .attr('d', d3.line().x((d) => x(d.x)).y((d) => y(d.y[index])));
...
        }
    );

The complete file is available here

Remote Access

Whenever I want to tunnel into my local system, I go for ngrok. This' perfect to show you my results.

Results

If all goes well, you can check the fruits of your labor from your ngrok's public url: mine is here.

From these results, it looks like my connection is quite unstable.

PS: Sending this to my ISP for reimbursement 😁

The speeds in the resulting project are not hypothetical and don't come cheap where I live. But you're reading of a successful project, no? 🤷🏾‍♂️

Conclusion

This was fun for me to do. I ended up adding some LEDs to show when my server was online. But it'd be interesting to blink an LED for every http request. Anyways, you can do so much more with a Pi. Check online tutorials and DIYs for more.

Happy tinkering/coding!

References

• Source Code

• Raspberry Pi

• speedtest.net

• Node Js

• D3

• Ngrok

• Crontab Guru

Optional Basics

Optional is a (generic) type that is used to represent the presence or absence of a value. Here's its declaration:

@frozen
public enum Optional<Wrapped>: ExpressibleByNilLiteral {
  /// The absence of a value.
  case none

  /// The presence of a value, stored as `Wrapped`.
  case some(Wrapped)

  ... 
}

I've left out some method definitions in the type such as map, flatMap etc along with a couple of its extensions.

@frozen is a Swift attribute that guarantees no further cases will be added (removed or reordered) on the enum declaration (This facilitates some compiler optimizations and allows a user to perform an exhaustive matching on the cases with no need for a default/'unknown' case check. For more info, check out this and this Swift Evolution proposal). Wrapped is the generic type to be wrapped by the Optional. ExpressibleByNilLiteral conformance denotes that this type that can be initialized using the nil literal, nil.

Before continuing with our discussion, it's important to mention that the Optional type gets some extra compiler love:

• A trailing question mark (?) on a type is treated as an Optional wrapping that type. This eases reading and writing Optionals in code. For instance, the following two declarations are the same.

--> let optionalString: Optional<String> = nil

--> let optionalString: String? = nil

• If let, while let, guard statements can evaluate the Optional and control program flow based on the presence or absence of the wrapped value.
• Sending a message to an Optional that represents an absence of a value results in a no-op e.g. optionalString?.removeAll() does nothing if optionalString is nil.
• Checking for equality with an Optional type (where Wrapped conforms to Equatable) promotes the non-optional value to an optional to make the types e.g. nonOptionalString == optionalString works out of the box.

These and many other nifty 'tricks' make working with Optional beautiful in Swift.

Optional of an Optional

Being a generic, Optional can thus be over any type including another Optional something like Optional<Optional<String>> aka String??.

Take an example of the following declaration. What's the type of languages?

let languages = ["Swift", "Kotlin", nil, "Rust"]

A quick glance would yield an assumption of Array<Any> but on closer inspection, we note that it's intuitive for the compiler to infer Array<Optional<String>> aka Array<String?> of which it does.

What's the type of first here let first = languages.first?

Now you've got it. It's a Optional<Optional<String>>.

Here's my attempt to explain. An element of the languages array is an Optional wrapping a string. The first property of an array (declared as public var first: Element? { get }) yields an Optional wrapping the Element -- the single type held by the array. In our case, it's an Optional wrapping a String and hence we get Optional<Optional<String>> 🤯!

Therefore, in the snippet below, you need to be aware that print is working with an Optional<String> (from reasons mentioned so far).

guard let first = languages.first else { return }

print(first)

In many cases, the compiler will emit warnings and offer fixes such as:

or subtle ones like the following (NB: self.deserializeEntity(from:) returns a T?):

Conclusion

And there you have it. Optionals make representing absence of a thing intuitive in Swift and have many uses such as in collections to denote a sentinel value when retrieving an element or during iteration. Being a generic, Optionals can be over any type including a couple of optionals such as String????? -- which is the valid, rather unuseful, type: Optional<Optional<Optional<Optional<Optional<String>>>>>.

Anyways. You get the idea. 🙈

let signOut: String? = "Happy Coding!"

print(signOut!)

References

• Swift Evolution
• Swift Core Lib

Attributes

A Swift attribute attributes a declaration or type. Seriously. Merriam Webster defines an attribute as a quality, character, or characteristic ascribed to someone or something. Therefore, as such, we have something in our program say a declaration and we'd like to annotate it.

The Swift documentation has the following to say:

A Swift attribute provides more information about a declaration or type.

Swift attributes are very similar to annotations in other languages. It's a form of providing metadata to your programs. Attributes serve different purposes but in the end, they are just instructions for the compiler.

Syntax

An attribute is specified by prefixing it's name with an @ symbol e.g. @State. Some attributes accept arguments to provide more information on their functionality with the following syntax: @attribute(arguments).

Swift has 2 categories of attributes:

• Type: this kind is applicable to types only
• Declaration: applies to declarations only

Sample attributes

Let's look at a few attributes you might might be familiar with.

discardableResult

I think this was my first attribute to write (so I write it first 😎). This attribute is used to suppress the compiler's warning when we don't use the result of a function/method call that returns a value.

Say we have a method to start a poll that returns a boolean to indicate whether the polling process started successfully or not. Furthermore, for some particular invocations, we do not care about this return value. If we ignore the return value of the call, we get the following compile time warning:

To inform the compiler we sometimes don't care about the returned result, we attribute the poll method with @discardableResult.

@discardableResult
func poll() -> Bool {
    ...
}

// call site
poll() // no compiler warning reported here

Alamofire, a popular networking library, heavily uses this attribute e.g. see its Request.swift file.

UIApplicationMain

The all familiar @UIApplicationMain is in all Swift iOS applications. It indicates that the attributed class is the Application's delegate.

@UIApplicationMain
class AppDelegate: UIResponder {
    ...
}

There's usually one application delegate thus the UIApplication.shared.delegate will return an instance of the above attributed class.

objc

Working with UIKit has definitely exposed you to this attribute. The @objc instructs the compiler to avail the attributed declaration for use in Objective-C code. Let's take a tap action for example.

let gestureRecognizer = UITapGestureRecognizer(target: self, action: #selector(tapAction(_:)))
self.actionView.addGestureRecognizer(gestureRecognizer)

@objc private func tapAction(_ recognizer: UITapGestureRecognizer) {
    // useful action
}

In this example, the tapAction(_:) declaration is exposed to Objective-C for dispatch at runtime to respond to the tap action on self.actionView. The @objc attribute hints for this exposure.

testable

Ah. Testing. A test bundle is a target for a project. As such, the module under test needs to be imported for invocation in the test bundle. @testable is used to attribute an import declaration of the module's code for use in testing eg:

@testable import TheProject

"Why?", you may ask. Swift's documentation says the following about adding @testable attribute on an import declaration:

• The imported module must be compiled with testing enabled
• Entities in the imported module that are marked with the internal access-level modifier are imported as if they were declared with the public access-level modifier
• Classes and class members that are marked with the internal or public access-level modifier are imported as if they were declared with the open access-level modifier

escaping

Swift supports closures - self-contained blocks of code passed around. A closure escapes a function when it's passed as an argument but invoked after the function returns. Lets create a Queue structure that enqueues tasks to be performed after some time:

final class Queue {

    private let queue: DispatchQueue = .main

    func enqueue(after deadline: DispatchTime, execute work: @escaping () -> Void) {
        self.queue.asyncAfter(deadline: deadline, execute: work)
    }

}

Our enqueue method schedules some work to be done after a given deadline using DispatchQueue. This request is delegated to a DispatchQueue using a method asyncAfter, that executes the given closure after a given deadline. The provided closure, work, therefore escapes (executes after the methods return) both our enqueue method and the asyncAfter method. Omitting the @escaping attribute in the enqueue(after:execute:) definition results in the following compiler error:

As shown in the above code snippet, we need to attribute the closure declaration with @escaping. With this in place, our Queue class is ready to be used for scheduling work:

let queue = Queue()
queue.enqueue(after: .now() + 0.3) {
    print("Delayed work")
}

propertyWrapper

This is a recent addition to the Swift's attributes list that is applied to classes, structs or enumerations. It creates a custom attribute with the same name as the attributed type. A factory of attributes? It appears so. This makes it a powerful attribute and a useful one for that matter. For this reason (and the wide application in SwiftUI), I'll dedicate an article to discuss @propertyWrappers.

Conclusion

We've taken a look at some common attributes and their use cases. There're many more. Check out the Swift attribute documentation.

SwiftUI, the declarative UI framework, makes heavy use of Swift attributes such as @State, @Environment, @Published, @EnvironmentObject and many more making this an even more important concept to learn. Happy coding!

References

• Swift Attributes Docs

• Alamofire

• Closures

• DispatchQueues

A Struct is a Swift language construct that can be used to encapsulate state and behaviour. It's the recommended way of storing state and modeling behaviour. What's the alternative you ask? Classes. The two are similar in many ways but also have a some huge distinctions. Luckily there are some guidelines from Apple on when to use which.

Value vs Reference

Structs are value types.

A value type is a type whose value is copied when it’s assigned to a variable or constant, or when it’s passed to a function.

Passing a struct around results in a copy. This is optimised in the language in the case of large structs. Nevertheless, any changes you make to a struct instance result in a different instance. The alternative is a class -- a reference type. Classes are fundamentally shared instances. Upon creating an instance, you pass around its reference and any local modifications are visible to the caller code.

Syntax

struct Tweet { }

We'd then use let awesomeTweet = Tweet() to create an instance. Well, that's not useful enough and so structs can store state through properties: stored (variable or constant) or computed. In addition, we can model behaviour via methods on the struct.

struct Tweet {
    let text: String
    let date: Date
    var imageUrl: String?

    mutating func edit(_ newText: String) {
        // Sorry you can't edit a tweet! 😎
        // The text is declared as a **let** property
    }

}

Memberwise Initializers

One of the nice features a struct has over a class is a memberwise initializer. This is an initializer generated automatically by the compiler. For example, the above tweet definition can be initialized as follows: let tweet = Tweet(text: "🇰🇪", date: .distantFuture, imageUrl: nil) without us declaring an explicit initializer.

One of my best Swift proposal was by Alejandro Alonso. This was a proposal for the compiler to synthesize a memberwise initializer taking into account the default values. This was implemented in Swift 5.1. So you can already enjoy this welcome addition.

Now, say I'm using the iOS Twitter app for real-time tweeting. The Tweet struct can declare a default date (.now -> private extension Date { static let now: Date = .init(timeIntervalSinceNow: 0) }) and all I have to provide is the text and perhaps the optional image url.

struct Tweet {
    let text: String
    let date: Date = .now
    var imageUrl: String? = nil

    ...
}

Voila! let tweet = Tweet(text: "🇰🇪")

Adopting Protocols

One of the strong arguments in using structs is to share behaviour using protocol inheritance. Structs can adopt protocols. Equatable and Hashable protocols get great language support -- the compiler automatically synthesizes their requirements.

Consider two instances of tweets:

let tweet = Tweet(text: "🇰🇪")
let anotherTweet = Tweet(text: "🤷🏾‍♂️")

A comparison is of course not supported automatically and the compiler won't allow it. After all what is the comparison on? Memory address? One property?. Thus let areEqual = tweet == anotherTweet results in a compiler error. But say we need to enable this comparison behavior based on the properties. Well, we simply adopt the Equatable protocol and automatically get this behavior (implementation).

struct Tweet: Equatable {
    ...
}

Now, the previous comparison is permitted. Hashable protocol adoption can also get automatic protocol requirements synthesis. Nothing prevents us from implementing these requirements but some compiler 'magic' is always welcome.

Deep down

Structs are used extensively in the language. Numbers, arrays, strings, dictionaries etc are all implemented as Structs. Take arrays for instance.

The Swift's collection library declares an array as a generic struct:

@frozen public struct Array<Element> {
    @inlinable public mutating func append(_ newElement: Element)
    ...
}

You'll also note that all methods that mutate an array say:

• append
• insert
• remove
• replace
• pop

are all marked as mutating -- a compiler requirement when modifying value types.

Nonetheless, as mentioned earlier, collections get some optimization to reduce the performance cost of copying by sharing the storage memory. Instance copying is still effectively done after a modification on the copy. You can read more on the swift language guide here.

Conclusion

Much more can be said about structs but the key takeaway is:

Always use structures by default

The idea of protocol inheritance and using structs has been heavily adopted by SwiftUI as demonstrated in its usage samples. So it's a worthwhile investment to learn and use. And there you have it: Structs. Happy coding!

References

• Swift Docs

• Apple Docs

• Proposal: SE-0242

• Adopting common protocols

What does a Product listing, Shopping cart, Orders list, Chat messages' list, Contacts list, Maps, etc have in common? They are all scrollable content: content that can't fit on the screen at once. All these are built using one underlying ui component: UIScrollView.

UIScrollView

Apple's documentation states that a UIScrollView is:

A view that allows scrolling and zooming of its contained views.

That's a pretty good summary about this ui component. I call it, the ruler of apps. See. Handheld devices have quite a small screen real estate unlike lap or desk held devices such as your Macbook or iMac. And thus content has to be crunched to fit and be displayed efficiently and for quick consumption.

This view is so conveniently named since, in its main use case, the content to be displayed is much larger than it's bounds (usually covering the whole device screen) and thus it needs to be scrolled to view the rest of the content. (Technically, it also supports a zooming gesture also but we won't discuss that here.)

As shown in the diagram above, the visible content rectangle corresponds to the scroll view's bounds. Any content outside this region is not drawn. To view the clipped content, you scroll up or down. (I've put cell-like content that simulates a table or collection view but you can put any content you desire, sized however you like, say a map or a huge image that you can scroll horizontally and/or vertically).

Let's take a look at some of the frequently used properties of a scroll view.

Content Size

Question. How does the scroll view know how big its scrollable content is? contentSize. This is a CGSize typed property on the scroll view that is very fundamental to its functionality. To denote when the scroll view's content has been scrolled all the way downward (and rightward if allowing horizontal scrolling), the scroll view's bounds origin is at point .zero. On the other hand, the furthest you can scroll upward (and leftward, if allowing horizontal scrolling) is governed by the contentSize. And thus this property gives us the limits of scrolling. I like to think of the scrollable portion of the scroll view being determined by the rect CGRect(origin: .zero, size: contentSize).

Two scenarios can be spun from this.

1. When the contentSize is smaller than or equal to the scroll view's bounds (non-scrollable 😎)

2. When the contentSize is larger than the scroll view's bounds

Non-scrollable

When the content size is less than or equal to the scroll view's bounds, there's nothing to scroll -- all content is visible within the bounds.

Scrollable

When the content size is larger than the scroll view's bounds, scrolling is required to be able to view all content. The animation below shows scrolling to origin point .zero and then to the furthest scroll possible represented by the contentSize.

Content Inset

The contentInset give us a margin around the scroll view's content. Say we add edge insets of 100 on either side of the scroll view, the resulting setup is as shown below. Note that the subview is still positioned relative to the scroll view's origin CGRect(x: 0, y: 0, width: 100, height: 100) but appears to have a 100 units padding from the top and left edges of the scroll view. This is as a result of giving the scroll view content inset.

Here's the source for the above hierarchy.

Adjusted Content Inset

I had not become fond of adjustedContentInset property until recently when I had to account for the safe area of an edge-to-edge scroll view. I learnt about safe area propagation in the view hierarchy from Matt Neuburg's Programming iOS 13 book. I highly recommend this book.

As the name of the property connotes, this value accounts for the content insets that have been adjusted. "Adjusted by what?", you may ask. Safe area insets. This value can be thought to be expressed as: adjustedContentInset = contentInset + safeAreaInset.

Looking at the above relation, adjusted content inset would be relatively easy to calculate and no need for an extra property on the scroll view. It's there because there's more. There's another property that controls this value -- specifically the safe area inset part: contentInsetAdjustmentBehavior. Lucky for us, the resulting adjusted insets are calculated automatically with respect to the content inset adjustment behavior. This behavior property takes one of the options enumerated in the documentation (.always, .never, .scrollableAxes, or .automatic) to alter the final value of the adjustedContentInset. In summary, you choose any of these options to configure how you want the safe area insets to adjust your scroll view's content inset.

Content Offset

This is a CGPoint property that denotes the current scroll position. Its range is governed by the scrollable portion of the scroll view mentioned earlier: CGRect(origin: .zero, size: contentSize).

Scroll View Delegate

Ah delegates! I guess my most love-to-hate architectural decision by Apple. Whenever I switch from other frameworks and work with iOS, I'm always fond of looking for which delegates are available for me to explore. Usually there's one or sometimes, a protocol-chain of delegates.

The scroll view's delegate is a class adopting the UIScrollViewDelegate protocol. There're a handful of methods for you to explore but the one method I've kinda always used is the scrollViewDidScroll(_:). This method tells you that the scroll view has scrolled. In most scenarios, this method is called several times hence a guard statement or some code that executes fast is necessary not to do too much processing during scrolls. To detect when dragging will begin, end and so on, check out Apple's documentation on other delegate methods available.

Static subviews

I recently had to implement a feature where a view was to stay stationary in relation to the scroll view's content scrolling. Upon some digging, I found out about the scroll view's frameLayoutGuide. This property is controlled by the scroll view's frame and serves as a great way to create static subviews positioned wherever you'd like on the scroll view's frame.

Subclasses

Some of the main scroll view's subclasses you might be familiar with are the well known UITableView and it's superior cousin, UICollectionView. These classes build upon the basics discussed above (and in the documentation) to give a great developer experience in presenting scrollable content. They are also a great source of iOS interview questions 😎.

Conclusion

We've just scratched the surface on working with a scroll view. As hinted, it forms the basis of many iOS app designs and development. The basic premise of scrollable (and zoomable) functionality fits well with the paradigm of providing an entry point to seemingly endless content. Many apps heavily use a scroll view or any of its subclasses to present content to users. In one way or the other, you'll work with this view in your development lifetime: embrace it. Let it rule. Happy coding!

References

• Apple's UIScrollView documentation

• Programming iOS 13

Sometime back, I came across a view controller lifecycle-related challenge which I cover in another article. That led me to this discussion between Activity and ViewController lifecycle callbacks.

Tl;dr

The Android and iOS teams have taken different approaches in application platform designs. Blindly borrowing concepts from either platform will only result to chaos in your app development. Invest time learning each. 😎

Assumptions

In my opinion, taking a one-to-one possible mapping in concepts can be a shortcut to dive into the other platform but I think understanding the basics of how each works will be most helpful in the long run.

One of the biggest assumptions I made was that Activity lifecycle callbacks map to ViewController callbacks. Let’s look why this isn’t necessarily the case as we look beyond the basics.

Activity/UIViewController Lifecycle

Activity

From the Android documentation we get the following:

An activity is a single, focused thing that the user can do. Almost all activities interact with the user, so the Activity class takes care of creating a window …

But let us go with a clearer explanation presented elsewhere in the documentation:

An activity is the entry point for interacting with the user. It represents a single screen with a user interface.

You use an instance of the activity to place your UI but we are more interested in its lifecycle (and related callbacks).

Activity lifecycle (source developer.android.com)

From the image above, we can count 7 lifecycle callbacks methods exposed by the activity to hook up your logic. There are other supporting callbacks, for instance, methods to save the activity state in a bundle. All these are in response to the activity’s lifecycle itself. For an instance, when the activity is going away (e.g the app is backgrounded), a series of callbacks in the activity, starting with onPause(), are invoked in response. One may expect a corresponding behavior in the ViewController but let’s have a look at it.

UIViewController

From Apple’s documentation, a UIViewController is:

An object that manages a view hierarchy for your UIKit app.

From the documentation, we can see that one of the main responsibilities of the view controller is to manage a view (for which it maintains a reference using the view property). In the view controller, you can override view callbacks e.g. viewDidAppear(), viewWillDisappear() etc. Check out the state transition diagram and corresponding literature here. These callbacks are in relation to the view that the UIViewController is managing and not the UIViewController itself.

UIViewController's View lifecycle (source https://developer.apple.com/documentation/uikit/uiviewcontroller)

Nevertheless, in regards to detecting when the UIViewController is going away, the best bet is to still rely on the view*() callbacks e.g. viewDidDisappear() is invoked after a view controller has been dismissed by the presenting controller. NB: child view controllers have lifecycle methods e.g. willMove(), didMove() etc in which you can use in your app. Also, WatchKit has methods awake(), *Activate() and *Appear() that hook up well with the WKInterfaceController’s lifecycle events.

viewDidLoad(), therefore, is technically not the corresponding equal for onCreate() even though both are called in the initial stages of their parents’ lifecycles. The former is called after the controller’s view is loaded into memory and the latter is invoked when the activity is starting. Clearly, these two can’t just be mapped one-to-one!

Conclusion

Hope this article has debunked any ideas of blindly comparing Activity’s and UIViewController view’s lifecycle callbacks. I can learn a thing or two on how you approach either platform using the knowledge you know about the other.

Resources

• View Controller
• Activity

Alamofire is an elegant HTTP networking library de facto in iOS development; perhaps in the same league as Retrofit in Android programming. It’s built to be asynchronous from ground up as it uses Apple’s URL loading system thus full of handlers (check out RxAlamofire to enjoy an even nicer api for your networking needs).

Making a Request

Alamofire 5 has a new namespace, AF, that encapsulates all of its request methods. Thus to make a get request, prefix your request method with AF (this was previously available in the global namespace).

Handling Response

The request method returns a DataRequest object which handles in-memory data download. When a request is done, the parent Request class has a finish method invoked to start registered response serializers. The serializers adopt the ResponseSerializer protocol which is a composition of DataResponseSerializerProtocol (to handle data response) and the DownloadResponseSerializerProtocol (to handle download response). Some of the built in serializers are:

• DataResponseSerializer
• StringResponseSerializer
• JSONResponseSerializer
• DecodableResponseSerializer

Out of the box, Alamofire has 6 response handlers that utilize these serializers to hand you a serialized response. They are:

• Generic handler — unserialized response
• Serializer handler — serializes response using the provided serializer
• Data handler — serializes response into Foundations’ Data struct
• String handler — yields a String struct
• JSON handler — uses Foundation’s JSONSerialization — yields Any
• Decodable handler — serializes into aDecodable type

Here’s a signature to add a handler for JSON serialized response:

The Need

Ignoring network and server errors, api calls typically have a response and Alamofire treats a completed network request as successful by default. (The library can also handle an EmptyResponse).DataRequest can take a validation closure to determine if the response is interpreted as an error (based on an unacceptable status code, incorrect MIME type or the given closure).

Imagine we are login in a user on an iOS app. The api is documented to give us back a Token object when the credentials are valid or a custom APIError object otherwise. If our Token struct conforms to the Decodable protocol, we can use the responseDecodable handler to receive a decoded Token object from the response.

JWT token object

The login request (request payload omitted) could be made as follows.

If the credentials provided were valid, the response variable is of type AFDataResponse<Token> which is a typealias for DataResponse<Token, AFError> where AFError is a custom error type by Alamofire. What if the credentials were invalid? How do we receive the decoded APIError object?

If APIError conforms to the Decodable protocol, as shown below, we could write a custom serializer and handler that returns to us a Result<Token, APIError>.

Custom Serializer

To write a custom data serializer, you write a class that conforms to the DataResponseSerializerProtocol. The protocol is defined as follows:

Note that to handle disk downloads as well, your custom serializer should also adopt the DownloadResponseSerializerProtocol.

As noted above, Alamofire has an inbuilt decodable data serializer. We create a custom TwoDecodableResponseSerializer that uses a composition of DataResponseSerializers, one for each type we want decodable. After a short ceremony of making sure the response is even valid for decoding, we invoke either serializer conditionally. I pass in a _HTTP status cod_e to determine when to invoke the APIError serializer.

Custom Handler

A custom handler is straight forward. It uses the serializer we’ve written above. I’ve made it generic to accept any type that is Decodable.

And we use it as shown below:

And that’s it.

The documentation has a section on creating a custom serializer (for your specific type of data). Happy coding.

Reading

I’m building an application in which I would like to play an animation when the (root) view controller comes into the foreground and pause it when it (app) goes to the background.

The Platform

iOS exposes the Application Delegate that provides callback methods to hook into in response to the application’s foreground/background transition. This is great if all you want to do is write application-wide logic. In this article, I discuss how I handled a view controller specific logic in response to the application’s lifecycle events.

Approach

Luckily for me, the platform sends notifications in response to a change in app’s lifecycle events as highlighted in the documentation:

• didBecomeActiveNotification: Posted when the app becomes active.
• didEnterBackgroundNotification: Posted when the app enters the background.
• willEnterForegroundNotification: Posted when the app is entering the foreground.
• willResignActiveNotification: Posted when the app is no longer active.
• willTerminateNotification: Posted when the app is about to terminate.

A typical usage registers the containing view controller as an observer to the desired notification perhaps in the init method. The registration also takes an objc method to callback when the notification is received.

NotificationCenter.default.addObserver(self, selector: #selector(onAppDidEnterBackground), name: UIApplication.didEnterBackgroundNotification, object: nil)

Your callback method in the view controller will have such a signature:

@objc func onAppDidEnterBackground() {
   // some awesome logic
}

Conclusion

This works for me since the view controller is the root controller. For modally presented view controllers, I can, and probably would, use the view* lifecycle callbacks to achieve the same e.g. viewWillDisappear().

My first programming language to learn was Visual Basic 6. I had this book that gave a nice introduction to the language with all the Sub…End Sub, Dim title() As String etc. Using forms with drag and drop support, I’d create beautiful UI on my PC that gave me that super power I longed for — instructing a computer to do what I want. If you think about it, that’s what programming is all about.

I desired to write mobile apps but didn’t know where to start. My research led to Java2ME and NetBeans 6.0 was installed. I toyed around with this new found tech but lacked a proper introduction to the language used — Java.

If I remember correctly, the first Java book to encounter on was Teach Yourself Java in 21 days. Such a quick walk through of the language! Later on, I found out about Deitel & Deitel, Java How to Program, 6th Edition and I fell in love with their books and mode of teaching. Armed with these, I went on to write routines for those pesky maze games on the Java2ME platform.

Android Programming

I first laid my hands on Android development at a Google event dubbed

gKenya 2.0 (I think I also attended gKenya 1.0 🤔). I’m surprised the schedule is still up here at the time of writing. Day 2 was the most interesting as it was focused on developers. Someone at the event made a remark:

If you know Java, you know 50% Android development!

That was my cue. How true this was, I left it to chance. I learnt the basics; Activities, Services, Broadcast Receiver and Content Providers. This got me going as I continued to learn from the official documentation and samples I would gather online + Stack Overflow. I have written several hobby apps since then (just published one of them — open source) and also had a chance to be a consultant on an app rewrite; Ionic to native Android.

Full time employment as a mobile application developer altered the course of my development career. Writing a hobby app is one thing. Delivering a business solution is another. Being in a work environment adheres to two major points:

• Delivering quality solutions
• Delivering those solutions in a timeframe

These two requirements seem paradoxical for a beginner/junior developer but experience teaches you that’s how a business runs. To the first point, you need to learn Computer Science fundamentals; commonly used data structures such as arrays, sets, lists, maps, hash tables etc as well as have some skills in problem solving — knowing how and when to use these data structures alongside common techniques like Dynamic Programming or general recursion. My two go to practice sites are the famous LeetCode and CodeSignal. Pramp is also a good resource especially for interview-like preparation.

iOS Programming

Diving into iOS was by self-inflicted fire. I had to deliver a clone of an Android app within the shortest time possible. I mention this in the introductory section of another article. Official documentation served me well for this task as well as samples online for a couple of features. YouTube tutorials from Brian Voong, Sean Allen, Cocoacasts, Brian Advent among others came in handy in bootstrapping my iOS learning journey. Awesome writers such John Sundell and Paul Hudson keep me up to date with content. I am currently reading iOS 13 Programming fundamentals, a great book by Matt Neuberg.

YouTube has been a great resource in my learning. I’ve watched videos from Devoxx, Android Dev Summit & Google IO, WWDC videos, William Fiset (Graph theory + Data Structures) and My Code School (Algorithms and DS).

Conclusion

I engage a lot with my peers on their view on development and find out how they keep up with the industry: books, conference videos, code labs, tutorials, blog posts, twitter, OSS and podcasts among others come up as some ways to learn content. I write apps using Swift, Kotlin and Java. These 3 languages, in addition to the various frameworks and libraries on Android and iOS, sure keep me learning something everyday. Keep learning!

Resources

Data Structures + Algorithms

• William Fiset
• My Code School
• Introduction to Algorithms
• LeetCode
• CodeSignal
• HackerRank
• BaseCS

iOS

• Matt Neuburg
• John Sundell
• Paul Hudson
• WWDC + other videos
• Kickstarter iOS OSS
• Brian Advent
• Cocoacasts
• Sean Allen
• Brian Voong

Android

• Kotlin
• Android Dev Summit + IO
• Codelabs
• Devoxx
• Kickstarter Android OSS
• Fragmented Podcast

Tl;dr A string is a linear sequence of characters.

A character is a symbol representing a digit or letter say 7 or @. Computers in essence see these as sequences of 0s and 1s and thus we need a way to translate them from what we humans know and interpret them as to what computers can understand and this is called character encoding.

In computing, you've definitely come across the most popular of these encodings -- ASCII (American Standard Code for Information Interchange). As a standard, it gives us a way to encode (represent) upper and lower case English letters, numbers, and punctuation symbols mapped to 7-bit numbers and thus it can only encode a maximum of 128 characters.

On a side note, the folks at ANSI who came up with this encoding did a clever thing. They set the MSB to 1 and started counting from 1 to represent upper case A and these follow in sequence till Z. The same was done for lower case letters but with a 11 prefix. This makes it easy to know the position of the character in the alphabet given its LSB bits. See the illustration below:

To make things interesting, we've evolved to create more and more encodings to suite our communication needs separately and this bred incompatibilities when communicating across language or region boundaries. Therefore a standard was adopted - Unicode maintained by the Unicode Consortium. This encoding supports a large character set (ASCII got the privilege of being a subset of this set encoding the first 128 characters). As of this writing, the specification can represent 143,859 characters!

Unicode is often defined as UTF-8, UTF-16 or UTF-32 where UTF stands for Unicode Transformation Format and the number for the number of digits used to represent each character. Being a large character set, Unicode therefore facilitates encoding of the ever evolving characters like emojis 😎. Specification 13.0.0 added 55 new emoji characters!

The Kotlin Char

As at version 1.3.72, the Kotlin language guarantees the following character sets to be available on every implementation of the JVM platform.

• UTF_8: (Eight-bit UCS Transformation Format.)
• UTF_16: (Sixteen-bit UCS Transformation Format, byte order identified by an optional byte-order mark.)
• UTF_16BE: (Sixteen-bit UCS Transformation Format, big-endian byte order.)
• UTF_16LE: (Sixteen-bit UCS Transformation Format, little-endian byte order.)
• US_ASCII: (Seven-bit ASCII, a.k.a. ISO646-US, a.k.a. the Basic Latin block of the Unicode character set.)
• ISO_8859_1: (ISO Latin Alphabet No. 1, a.k.a. ISO-LATIN-1.)
• UTF_32: (32-bit Unicode (or UCS) Transformation Format, byte order identified by an optional byte-order mark)
• UTF_32LE: (32-bit Unicode (or UCS) Transformation Format, little-endian byte order.)
• UTF_32BE: (32-bit Unicode (or UCS) Transformation Format, big-endian byte order.)

Kotlin characters are represented by the Char type. Literals are surrounded by single quotes e.g. 'F' or '\u1F069'. With that primer on characters, let's look at Strings.

The Kotlin String

This is represented by the type String and is a classic example of an immutable type i.e. when you form a sequence of characters and need to alter their order, insert, remove or any kind of mutation, a new instance is created to reflect this.

The String type in Kotlin conforms to the CharSequence interface. This interface gives us 3 useful members.

public interface CharSequence {

    public val length: Int

    public operator fun get(index: Int): Char

    public fun subSequence(startIndex: Int, endIndex: Int): CharSequence
}

These are self documenting. Highlighting the second one, get(index:) is defined as an operator and allows us to index Chars in a String via a subscript with a 0-based index:

val name = "SenseiDev"

println(name[6]) // D

The Kotlin String definition on the JVM is as follows:

public class String : Comparable<String>, CharSequence {
    companion object {}

    public operator fun plus(other: Any?): String

    public override val length: Int

    public override fun get(index: Int): Char

    public override fun subSequence(startIndex: Int, endIndex: Int): CharSequence

    public override fun compareTo(other: String): Int
}

Remember all classes are final in Kotlin, hence enforcing the immutability highlighted earlier. As seen above, there are some additions to what the CharSequence interface defines that are particular to the String type.

1. plus operator. This allows us to concatenate strings with the + operator e.g. "SenseiDev" + 5. (NB: the definition of the + operator is defined on the String type and hence it is not commutative i.e. it's a compile error to define 5 + "SenseiDev" -- unless you have such an extension function on Int)!
2. A String can be compared to another String as allowed by the Comparable interface and the compareTo method.
3. An empty companion object

The Kotlin compiler has other neat tricks e.g it allows you to:

• Create String instances from literals e.g. val language = "Kotlin"
• Express literal raw String using triple quotes: """
• Add template expressions to String literals e.g. val displayAmount = "Ksh. ${quantity * basePrice}"

The JVM Bridge

You might be wondering, "Wait a minute. That's weird. Those are very few members on the String class while we have much more functionality from the class in our JVM programs e.g. toUpperCase(), replace(), etc." Well, you're right my friend. Kotlin has a whole hundreds-of-lines file called StringsJVM.kt in the package kotlin.text that defines all your favorite methods as extension functions on the CharSequence interface, the String class or its companion object and this is the file where most (if not all) of the JVM bridging is defined.

One fascinating highlight in the StringsJVM.kt file are the constructor-seeming function calls that are single line expressions to construct a String e.g. String(chars: CharArray). To remove function call overhead, these functions are declared as inline. This depicts how Kotlin language features (top-level functions and inline functions) work together while improving developer productivity.

Conclusion

We use the String class so often when writing our programs as it's useful in expressing a lot from our real world. String manipulation and the available operations are clearly important to understand as a developer. To dig deeper, I came across an article on Baeldung that discusses String interning in the JVM and some of the changes in regards to treating the String class. Check it out.

This article covered some fundamentals of the String class and the APIs exposed by the Kotlin Language in regards to the representing Strings. Happy coding!

References

• Unicode Consortium
• Tech Terms
• Kotlin Character Sets
• Kotlin Basic Types