DEV Community: Karol Wrótniak

When Zero‑Width Isn’t Zero: How I Found and Fixed a Vulnerability

Karol Wrótniak — Wed, 28 Jan 2026 16:01:56 +0000

When you set a max length on a form field or API, you expect it to hold. But what if a four-character string could secretly carry 10,000 extra bytes of invisible data, crashing your database or bypassing your validation? That was the vulnerability I found and fixed in the popular JavaScript library validator. It was a subtle bug involving Unicode Variation Selectors that allowed attackers to inject massive payloads while still passing length checks.

Introduction

The isLength function is simple on the surface: count characters and compare to a limit. But in a Unicode world, “character” is tricky. You need to match the perceived length (what the user sees) with the storage length (what your database handles), or you risk truncation, performance issues, and, as I found, critical bypasses.

Unicode and the illusion of length

JavaScript strings use UTF‑16. Some visible “characters” span two code units (surrogate pairs). isLength adjusts for that. It treats a base character plus a Variation Selector as one perceived character. That’s because the selector only changes the presentation.

// Emoji still count as one perceived character
const smile = '';
console.log(smile.length);          // 2 (UTF-16 code units)
// With isLength, it's treated as 1

The attack vector: Variation selectors gone wild

Variation Selectors (U+FE0F, U+FE0E) tweak how a base character displays. They aren’t content on their own. The old logic subtracted all selectors. So one can pad a short string with thousands of them while still passing the check with a low max.

// Apparent 4 chars, but thousands of extra selectors
const s = 'test' + '\uFE0F'.repeat(10_000);
console.log(s.length); // 10,004 (UTF-16)

What are unicode variation selectors?

These are zero‑width code points (U+FE0E for text and U+FE0F for emoji among the others) that modify the presentation of the character that immediately precedes them. They change appearance, not meaning. A base character plus a selector is meant to count as one perceived character.

As of Unicode 17.0, using them to choose emoji vs. text for many legacy dingbat bases is being phased out. The new emojis have separate code points assigned for each style. For example, the emoji 🪯 (U+1FAAF KHANDA) has a dedicated emoji code point. The older dingbat-style symbol is ☬ (U+262C ADI SHAKTI). Variation selectors still exist and work for bases that support them. But modern additions increasingly prefer distinct code points over selector‑based presentation. Unicode provides the emoji presentation sequences chart.

Here are some examples (text vs. emoji):

Heart: ❤︎ (text, U+2764 U+FE0E) vs ❤️ (emoji, U+2764 U+FE0F)
Airplane: ✈︎ (text, U+2708 U+FE0E) vs ✈️ (emoji, U+2708 U+FE0F)
Snowman: ☃︎ (text, U+2603 U+FE0E) vs ☃️ (emoji, U+2603 U+FE0F)
Writing hand: ✍︎ (text, U+270D U+FE0E) vs ✍️ (emoji, U+270D U+FE0F)
Telephone: ☎︎ (text, U+260E U+FE0E) vs ☎️ (emoji, U+260E U+FE0F)

Console example:

// Base character: Heavy Black Heart
const heart = '\u2764';
const heartText = heart + '\uFE0E'; // request text style
const heartEmoji = heart + '\uFE0F'; // request emoji style

console.log(heart, heartText, heartEmoji); //  ❤︎

By default, (with no selector), presentation differs by platform, browser, and font. Some show emoji by default; others prefer text. If you need a specific look, add U+FE0E (text) or U+FE0F (emoji). On the web, you can use the font-variant-emoji CSS property.

Important: A selector only makes sense right after a compatible base. Multiple selectors don’t stack or change meaning. ❤︎\uFE0F\uFE0F doesn’t become “more emoji.” Only the first base+selector pair affects the presentation. All the extras are stray code points.

For validation, ignore only one base+selector pair. Count stray or repeated selectors toward length. Otherwise, a tiny word can hide kilobytes and waste CPU. You can find more information about the issue in the Snyk Vulnerability database under SNYK-JS-VALIDATOR-13653476 entry.

The surgical fix: Counting only valid pairs

The change is precise: subtract only base+selector pairs instead of every selector. Old: /(\uFE0F|\uFE0E)/g. New: /[^\uFE0F\uFE0E][\uFE0F\uFE0E]/g. [^…] means “not these,” which forces a preceding non‑selector base. So stray or repeated selectors get counted. This distinction is the key to the fix.

Effective length: str.length — surrogatePairs — basePlusSelectorPairs.

// Padding with stray selectors now fails the max check
const payload = 'test' + '\uFE0F'.repeat(5);
console.log('isLength(payload, { max: 4 }):', isLength(payload, { max: 4 })); // false

// A valid base+selector pair still counts as one perceived char
const basePair = 'A' + '\uFE0F';
console.log('isLength(basePair, { max: 1 }):', isLength(basePair, { max: 1 })); // true

Disclosure and timeline

I followed a responsible disclosure process. I reported the issue, prepared a minimal PoC, and worked with the maintainers on a fix. The maintainers merged the patch, published a release, and then the advisory went live.

I reported the issue along with a proposed fix on October 18, 2025. The maintainers merged a pull request on November 5. Finally, CVE-2025–12758 was published on November 26. More info and links on the GitHub Security Advisory.

Conclusion

The key takeaway remains: Variation Selectors are modifiers, not content. The bug allowed them to be used as invisible padding to bypass max-length checks. After the fix only valid base-and-selector pairs pass the length check. It ensures all stray or repeated selectors are counted toward the actual length.

Please update to validator@13.15.22 or newer. When working with string length, always measure what you are storing, not just what users see.

A Practical Guide to Flutter Accessibility - Part 1: The Basics

Karol Wrótniak — Fri, 07 Nov 2025 12:08:20 +0000

Learn how to build accessible Flutter apps using built-in tools. Fix common issues like screen reader incompatibility, confusing structure, and unclear state changes to create inclusive, user-friendly apps.

Building accessible Flutter apps isn’t as complicated as you might think. Most accessibility problems happen because screen readers can’t understand your controls. Your information structure confuses users. You’re not communicating state changes. This guide will fix these problems using Flutter’s built-in accessibility tools.

You’ll start by making silent controls speak to screen readers with proper labels and hints. Assistive technology users will get the same information as everyone else.

Why this matters to you as a developer

Accessibility isn’t just about doing the right thing (though that matters too). It’s about building better software. When you add proper semantic information to your widgets, you help more than screen reader users. You create clearer code that’s easier to test, debug, and maintain. Many accessibility improvements make the experience better for everyone — better focus management, clearer state communication.

The legal reality

Let’s talk about the elephant in the room: legal requirements. The EU Accessibility Act requires digital services to be accessible by 2025. Fines reach up to 4% of annual revenue for non-compliance. In the US, the ADA doesn’t specify technical standards. Courts reference WCAG guidelines in lawsuits. Companies like Target, Netflix, and Domino’s have faced million-dollar settlements over inaccessible apps. This isn’t some distant possibility — it’s happening right now.

The good news about common problems

The most common Flutter accessibility problems are simple to fix. An IconButton without a label? Silent to screen readers. You’ll fix that using Flutter’s Semantics and MergeSemantics widgets.

The Semantics widget

Think of the Semantics widget as an invisible layer of sticky notes for assistive technology. You wrap your existing UI and provide properties. These describe what the thing is (label, role). They show what it displays (value). They explain what it’ll do (hint). They communicate what state it’s in (flags like selected, hidden, header, button, enabled, liveRegion). You can expose actions (onTap, onLongPress, onScroll) so screen reader users can interact with your interface. You can group multiple visual widgets into a single logical unit.

You won’t use Semantics everywhere — Flutter’s smart about defaults for Material widgets. But you’ll add or override it when something’s silent, chatty, or missing important state information. The goal? Give just enough structured metadata so a user hears “Add to cart, button, selected” instead of a confusing jumble of unrelated text bits.

Giving a voice to silent icons

Here’s our first problem. You’ve got an IconButton that looks fine. For a screen reader, it’s a silent mystery. Wrap it with Semantics and give it a clear label (what it is) and optional hint (what happens when you tap it).

// Without Semantics: announces only "button" because the icon has no text.
IconButton(
  icon: const Icon(Icons.local_drink),
  onPressed: _incrementCounter, // Logs a glass but screen reader doesn't know.
);
// With Semantics: announces "Log water, button" then the hint on explore.
Semantics(
  label: 'Log water',              // What this control represents
  hint: 'Adds one glass to today\'s total', // What happens on activation.
  child: IconButton(
    icon: const Icon(Icons.plus_one),
    onPressed: _incrementCounter,
  ),
);

Keep labels short and specific. Don’t repeat role words like “button” — the system adds that for you. Use value when the visual text alone would be confusing out of context (like an isolated number that means nothing without context).

Understanding other semantic properties

Many other semantic properties solve specific accessibility problems. liveRegion makes dynamic content announce when it changes — perfect for status updates or form validation messages. The isHeader flag tells screen readers that text is a page or section heading. This helps users navigate by jumping between sections. We can’t cover every semantic property in one post. You’ll learn about these and others as we work through real examples. For the complete rundown, check out the official Semantics documentation.

Platform differences to watch

Not all semantic properties work the same way across platforms. Some platforms support certain properties. Others might behave differently. For example, headingLevel only works on Flutter web. Native iOS supports heading levels. Flutter doesn’t wire this through on iOS (there’s an open issue in the Flutter tracker). Android doesn’t even have the concept of heading levels.

Coming from Android development

Do you use Jetpack Compose? Flutter’s Semantics widget works like Compose’s semantics modifier. Both use the same basic idea — wrap UI elements and add metadata like contentDescription (Flutter’s label), role information, and state flags. The main difference is syntax. Flutter uses named parameters in a widget wrapper. Compose uses a modifier with lambda configuration.

Coming from iOS development

SwiftUI’s accessibility system maps to Flutter’s approach. Flutter’s label property is like SwiftUI’s .accessibilityLabel() modifier. hint maps to .accessibilityHint(). State flags like isHeader correspond to .accessibilityAddTraits(.isHeader). All three frameworks — Flutter, Jetpack Compose, and SwiftUI — follow the same core principle: decorate UI elements with semantic metadata. Once you get the concept, switching between platforms becomes easier.

Testing your semantics on device

Let’s see what happens when you run the IconButton example on an Android device with TalkBack enabled. The screen recording below shows the app running on an emulator and the Android Ally plugin in Android Studio. This gives you a real-time control of accessibility settings.

Android emulator with TalkBack and Android Ally plugin.

The double announcement problem

When you swipe through the interface with TalkBack (Android’s built-in screen reader), you’ll notice something weird. Both the Semantics wrapper and the underlying IconButton get announced as separate nodes. TalkBack first reads “Log water, button, Adds one glass to today’s total” from your custom semantics. Then it announces the icon button itself as a separate focusable element.

This creates a confusing experience for screen reader users. They hear the same control twice but with different information. The Android Ally plugin helps you catch these issues. It shows the accessibility tree structure alongside your app. You can grab it from Android Studio’s plugin marketplace to see how assistive technologies interpret your interface.

Using Accessibility Scanner

Google’s Accessibility Scanner app catches this exact problem. The scanner analyzes your app’s interface and flags accessibility issues. It finds duplicate content descriptions, missing labels, and poor contrast ratios. When you run it on our IconButton example, it spots the redundant semantic information. It suggests consolidating everything into a single, clear description.

You can download Accessibility Scanner from the Google Play Store. Run it on your device or emulator. It’s useful during development because it gives you the same feedback that real users with disabilities would get. You don’t have to enable TalkBack yourself.

Testing on iOS

On iOS, Apple’s Accessibility Inspector does the same thing. This built-in developer tool comes with Xcode. It lets you inspect the accessibility tree of your Flutter app running on iOS Simulator or a physical device. When you run the inspector on our problematic IconButton example, it reveals the same issue. You see duplicate semantic nodes that would confuse VoiceOver users.

You can find the Accessibility Inspector in Xcode under Developer Tools. Or launch it from your Applications/Utilities folder if you’ve got Command Line Tools installed. Unlike the Android tools, Accessibility Inspector works with Flutter apps in iOS Simulator. This makes it easy to catch accessibility issues during development without needing a physical device.

Why does this double announcement happen? You wrapped the IconButton without telling Flutter to treat them as a single semantic unit. Let’s fix this by learning how to group related elements.

Fixing double announcements with MergeSemantics

The solution to our double announcement problem is simpler than you might expect. We need to tell Flutter to merge the semantic information from our custom Semantics wrapper with the underlying IconButton. This creates a single focusable element. The MergeSemantics widget does this.

// Fixed: Now announces as a single element.
MergeSemantics(
  child: Semantics(
    label: 'Log a glass of water',     
    hint: 'Adds one glass to today\'s total', 
    child: IconButton(
      icon: const Icon(Icons.plus_one),
      onPressed: _incrementCounter,
    ),
  ),
);

When you wrap multiple widgets with MergeSemantics, Flutter combines all their semantic properties into a single accessibility node. Screen readers now announce “Log a glass of water, button, Adds one glass to today’s total” as one cohesive unit. They don’t treat each wrapper as a separate element.

The MergeSemantics widget is handy when you’ve got compound controls. Think of a button with an icon and text. Or a custom card with multiple interactive elements that should be treated as one logical unit. Without it, screen readers navigate to each semantic layer. This creates confusion for users who expect related elements to be grouped together.

Cross-platform grouping concepts

If you’re working with SwiftUI, this concept maps to the .accessibilityElement(children: .combine) view modifier. This merges accessibility information from child views into a single element. In Jetpack Compose, you get grouping using the mergeDescendants = true parameter in the semantics modifier. All three frameworks recognize that visual hierarchy doesn’t match logical accessibility structure. Multiple UI elements should be announced as one cohesive unit.

Testing the fixed implementation

Now when you test the corrected code with TalkBack or VoiceOver, you’ll hear a single, clear announcement. No more confusing double reading we had before. The screen recording below shows the same setup as earlier. The app runs with both the Android Ally plugin and Accessibility Scanner. This time it displays the clean, merged semantic structure.

MergeSemantics fixing the double announcement issue.

Notice how the accessibility tree now shows just one focusable element instead of those duplicate nodes you saw earlier.

Confirming results on iOS

On iOS, the Accessibility Inspector confirms the same clean result. When you run the corrected MergeSemantics code through Apple’s accessibility tools, the inspector shows a single, merged semantic node. No duplicate announcements or structural issues.

Both TalkBack and the Accessibility Scanner confirm that those redundant announcements are gone. This creates a much better experience for screen reader users.

For more details on semantic grouping options, check out the official MergeSemantics documentation and the broader Semantics class reference. These cover all available properties and grouping strategies.

What you’ve accomplished

You’ve now tackled the most common Flutter accessibility problems using the core toolkit. Silent controls like IconButton now speak with proper labels and hints. Those confusing double announcements? Cleaned up with MergeSemantics. Your app’s semantic structure makes sense to screen readers. You’ve got the tools to test and verify your changes work across both Android and iOS.

These basic semantic properties — solve the vast majority of the accessibility issues you’ll run into in Flutter apps. But there’s more to building inclusive experiences. In Part 2 of this series, you’ll dive into advanced interaction patterns like custom semantic actions for complex gestures.You’ll explore how to handle dynamic content announcements and make custom widgets accessible to assistive technologies.

Originally published at thedroidsonroids.com on November 7, 2025.

How to Create an IoT App in Kotlin Multiplatform

Karol Wrótniak — Sun, 05 Oct 2025 22:45:33 +0000

In this article, you’ll build a small multiplatform app for Android and iOS that blinks an LED on an IoT device. You’ll use Kotlin Multiplatform (KMP) for shared logic, Compose Multiplatform for the UI, and the Kable library for Bluetooth communication.

Kotlin Multiplatform provides the foundation for sharing application logic. Compose Multiplatform lets you create a fluid, native UI for both Android and iOS from a single codebase. For connectivity, you'll use Kable, a modern, coroutine-based library that simplifies Bluetooth Low Energy (BLE) communication. This stack helps you build high-performance, native IoT controller apps, reuse the most code, and improve your development workflow.

Introduction

In this tutorial, you'll create a simple IoT controller app for Android and iOS called "Bluno Blink Controller." The app will connect to a Bluno BLE device, let you select a number on a slider, and send it to the device. The Bluno will then blink its onboard LED the corresponding number of times. This project shows how to interact with hardware from a shared codebase.

The video below shows the final app controlling the Bluno device.

Bluno blink controller in action

And here's a video showing Bluno devices in action, blinking in response to commands from the app.

Bluno device blinking

The main reason to choose Kotlin Multiplatform for an IoT project is code sharing. IoT apps often have identical logic across platforms for managing connection states, defining communication protocols, and processing data. KMP lets you write this core logic once in a shared module, which reduces duplication and errors. This approach gives you a single source of truth for your app's logic while delivering a native experience on both Android and iOS.

While KMP is great for shared logic, you still need to handle platform-specific tasks like runtime permissions and enabling the Bluetooth adapter or location services. You do this in the native Android and iOS source sets. Once you complete the platform-specific setup, a library like Kable can manage BLE communication. Kable provides a unified, cross-platform abstraction for scanning, connecting, and exchanging data with BLE devices, which you'll use in the shared code.

The atack at a glance

You'll build the project on a stack where each layer has a clear role, from the user interface down to the hardware. The diagram below shows how these components fit together, with a shared core running on both Android and iOS.

Architecture diagram

Here’s a closer look at each component's role:

Kotlin Multiplatform: This is the core of your project. It lets you share the application's business logic between Android and iOS. You'll write all logic for managing connection state, handling BLE events, and preparing data for the Bluno device once in the commonMain source set.
Compose Multiplatform: You'll use Compose Multiplatform to build the entire UI from a single, shared codebase. The screen contains a connection button, status indicators, and a blink-count slider. You only need to define it once with composable functions that render natively on both Android and iOS.
Kable: This coroutine-based library is your tool for Bluetooth Low Energy communication. It provides a clean, modern API for scanning peripherals, establishing connections, and reading or writing data to device characteristics. Kable abstracts many platform-specific BLE complexities, letting you write the communication logic once in shared Kotlin code.
Bluno BLE Device: Your IoT app targets a Bluno device, an Arduino-compatible board with a BLE module.

Meet the hardware: The Bluno BLE device

Before diving into the code, it helps to understand the hardware you'll control. The Bluno is a microcontroller board based on the Arduino platform. An Arduino is a tiny, programmable computer that interacts with the physical world through sensors, motors, and LEDs. Hobbyists and professionals use it to build interactive electronic projects.

The Bluno is special because it has a built-in Bluetooth Low Energy (BLE) module. This lets it communicate wirelessly with devices like smartphones, making it a great choice for simple IoT apps. The logic on the Bluno runs a C++-based language, and you develop it using an environment like the Arduino IDE. For this project, the device runs a simple script (in arduino/BlunoBlinkController.ino) that listens for a number sent over BLE and blinks an LED accordingly.

This development model is different from mobile app development. Instead of an event-driven UI, Arduino programs run a continuous loop() function that contains the device's main logic. You also work with significant constraints. A microcontroller has a fraction of the memory and processing power of a modern smartphone, so the code must be efficient. Communication happens through a Serial interface. On a standard Arduino, this would be a USB cable. On the Bluno, the firmware bridges this Serial communication over its BLE connection, letting your mobile app send and receive data like a wired terminal.

For your KMP app to communicate with the Bluno, it needs the device's specific BLE "address." This isn't a physical address but a set of unique identifiers (UUIDs) for the services and characteristics the device exposes. A "service" is a collection of related functions, and a "characteristic" is a piece of data within that service. In our case, the Bluno exposes a serial port service that we can write to.

Here is the specific characteristic our app will target, defined in the shared Kotlin code:

// file: composeApp/src/commonMain/kotlin/pl/droidsonroids/kmpiotdemo/data/Constants.kt
internal val blunoSerialPortCharacteristic = characteristicOf(
    service = "0000dfb0-0000-1000-8000-00805f9b34fb",
    characteristic = "0000dfb1-0000-1000-8000-00805f9b34fb"
)

When you send the blink count from the app, you write to this exact characteristic. The Bluno's firmware listens for this write event, reads the number, and runs the blinking sequence.

Project setup

The project uses a standard Kotlin Multiplatform structure. The core logic and UI are in the composeApp module. The composeApp/build.gradle.kts file configures key dependencies, including Compose Multiplatform for the UI and Kable for BLE communication.

The most KMP-specific part of the configuration is the kotlin block, where you declare compilation targets. This project targets Android and multiple iOS architectures to support physical devices and simulators.

// file: composeApp/build.gradle.kts
kotlin {
    androidTarget()
    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach { iosTarget ->
        iosTarget.binaries.framework {
            baseName = "ComposeApp"
            isStatic = true
        }
    }
    //...
}

This configuration tells Kotlin to build a native Android app and an iOS framework from the same shared codebase.

Two important settings here are baseName and isStatic.

baseName = "ComposeApp": This sets the name of the compiled framework. The iOS app will use this name in its Swift code (import ComposeApp) to access the shared Kotlin code.
isStatic = true: This configures the framework as a static library. The compiled Kotlin code is linked directly into the final app executable at build time. This is a common way to integrate KMP into an iOS project.

BLE basics & the Kable Mental Model

At its core, BLE communication uses a client-server model. The peripheral device (your Bluno) is the server, which advertises its presence and data. The central device (your phone) is the client, which scans for and consumes that data. The peripheral exposes its features through a standard structure.

Peripheral: The IoT device itself (the Bluno).
Service: A collection of related functions. Our Bluno has a "Serial Port" service.
Characteristic: A specific piece of data within a service. A characteristic isn't just a value; it has properties that define how you can interact with it. You can write to it (send data), read from it (request its current value), or subscribe to notifications to have the peripheral push updates to you automatically when the value changes.

Kable provides a developer-friendly abstraction over this structure. It simplifies low-level platform details into a clean, coroutine-based API centered on the Peripheral object. This object represents the device you want to interact with.

The typical workflow for connecting and sending data looks like this:

Scan: Use a Scanner to find nearby devices. Kable lets you filter by advertising data, such as services, name, or manufacturer-specific data.
Connect: Once you find the target device's advertisement, you create a Peripheral instance from it and call connect().
Interact (Read/Write/Observe): After connecting, you can interact with the device's characteristics. Kable handles service discovery, so you can start making calls right away. You can write() to send data, read() for a one-time data request, or use observe() to listen for a stream of notifications.

In the project, BleRepository encapsulates this logic. The scanAndConnect function creates a Scanner that filters for Bluno's unique service UUID.

// file: composeApp/src/commonMain/kotlin/pl/droidsonroids/kmpiotdemo/data/BleRepository.kt
val scanner = Scanner {
    filters {
        match {
            services = listOf(blunoSerialPortCharacteristic.serviceUuid)
        }
    }
}
val advertisement = scanner.advertisements.first() // Find the first matching device

For this tutorial, you connect to the first device that matches the service filter. In a production app, you would probably scan for a few seconds, show a list of found devices, and let the user choose one.

Once the app finds the device, it creates a Peripheral and connects to it.

// file: composeApp/src/commonMain/kotlin/pl/droidsonroids/kmpiotdemo/data/BleRepository.kt
private suspend fun connectToAdvertisement(advertisement: Advertisement) {
    peripheral = Peripheral(advertisement)
    peripheral.connect().launch {
        _connectionStatus.value = ConnectionStatus.Connected
        _isReadyToSend.value = true
    }
}

The peripheral.connect() call returns a CoroutineScope that remains active for the connection's duration. If the device disconnects, this scope cancels automatically, giving you a structured way to manage connection-specific tasks. The UI observes the connection status, which is updated in a StateFlow.

The BleRepository uses two StateFlows to communicate its state to the UI:

connectionStatus: This flow tells the UI if the app is Idle, InProgress, or Connected. The UI uses this to change the button text (e.g., from "Scan & Connect" to "Disconnect"), show a progress indicator, and display controls only when connected.
isReadyToSend: This boolean flow controls the UI's interactivity. It enables the slider and "Send" button when the device is ready and disables them while a command is in flight. This prevents the user from sending multiple commands at once.

The BleViewModel exposes these flows, and the App composable collects them. This creates a reactive link between the back-end BLE logic and the front-end UI state.

Implementing the "Blink Count" feature

With the connection established, you can now implement the main feature: sending the blink count to Bluno. This process involves capturing user input, encoding it for BLE, writing it to the device, and waiting for a confirmation.

1. UI and state management

The BlinkControls composable provides a Slider to select a number and a "Send" button. The screenshot below shows the app's main screen when connected.

Blink Controller UI

When the user presses "Send," it triggers the onSend callback, passing the integer value to the BleViewModel. The ViewModel then calls the corresponding function in the BleRepository.

// file: composeApp/src/commonMain/kotlin/pl/droidsonroids/kmpiotdemo/BleViewModel.kt
fun sendBlinkCount(count: Int) {
    bleRepository.sendBlinkCount(count)
}

2. Sending data and awaiting confirmation

The BleRepository handles the logic for sending data and managing UI state. When sendBlinkCount is called, it sets isReadyToSend to false. This disables the "Send" button to prevent the user from sending a new command while the first one is running.

// file: composeApp/src/commonMain/kotlin/pl/droidsonroids/kmpiotdemo/data/BleRepository.kt
fun sendBlinkCount(count: Int) {
    _isReadyToSend.value = false
    peripheral.scope.launch {
        awaitBlinkConfirmation()
        _isReadyToSend.value = true
    }
    peripheral.scope.launch {
        writeData(count)
    }
}

You launch two independent coroutines in the peripheral's connection scope. The first one listens for the device's confirmation signal. The second one sends the data. This separation is important because writing the command and listening for the response are distinct, asynchronous operations.

3. Writing to the characteristic

The writeData function is where the app communicates with Bluno. It takes the integer, converts it to a ByteArray, and uses Kable's write function to send it.

// file: composeApp/src/commonMain/kotlin/pl/droidsonroids/kmpiotdemo/data/BleRepository.kt
private suspend fun writeData(value: Int) {
    peripheral.write(
        characteristic = blunoSerialPortCharacteristic,
        data = value.toString().encodeToByteArray(),
        writeType = WriteType.WithoutResponse
    )
}

Here, you use WriteType.WithoutResponse, a "fire-and-forget" write. The app sends the data but doesn't wait for a low-level acknowledgment from the BLE stack. This is fine for our use case because we implement our own application-level confirmation by listening for the "C" character.

4. Handling the device response

After the Bluno receives the number, it blinks its LED and sends a confirmation character ("C") back to the app to signal it is finished. The awaitBlinkConfirmation function catches this response.

// file: composeApp/src/commonMain/kotlin/pl/droidsonroids/kmpiotdemo/data/BleRepository.kt
private suspend fun awaitBlinkConfirmation() {
    try {
        peripheral.observe(blunoSerialPortCharacteristic).awaitConfirmation()
    } catch (_: IOException) {
        createPollingFlow().awaitConfirmation()
    }
}
private suspend fun Flow<ByteArray>.awaitConfirmation() = map(ByteArray::decodeToString)
    .first { it.contains(BLINK_DONE_TOKEN) }

It first tries to observe() the characteristic, which sets up a notification listener. It then waits for a ByteArray that contains the "C" token when decoded. Once it receives this confirmation, the coroutine completes, isReadyToSend becomes true, and the UI becomes interactive again.

The try-catch block handles a common hardware quirk. For BLE notifications to work, a characteristic must include a Client Characteristic Configuration Descriptor (CCCD) that the client app writes to. The Bluno firmware, however, doesn't expose this descriptor correctly. This is a known issue, especially on iOS, where the Core Bluetooth framework strictly follows the BLE specification and refuses to subscribe to a characteristic without a valid CCCD. This causes Kable's observe() call to fail.

To work around this hardware limitation, the code falls back to a manual polling flow. If the observe() call throws an IOException, the catch block repeatedly reads the characteristic's value until it receives the confirmation token. While less efficient than notifications, this polling strategy reliably gets the completion signal from this device. You can read more about this long-standing issue in this ble-serial GitHub thread.

Handling platform specifics

While most of your code is in commonMain, you still need to write some platform-specific code in the native Android and iOS source sets. Here, you handle system-level features like permissions and services before the shared code takes over.

Android

On Android, you must handle permissions, the Bluetooth adapter, and location services.

Android permissions

First, you declare the necessary permissions in composeApp/src/androidMain/AndroidManifest.xml. For an app targeting SDK 31 (Android 12) or newer, you need:

BLUETOOTH_SCAN
BLUETOOTH_CONNECT
ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION

You might wonder why location permissions are needed. On Android, discovering nearby BLE devices can infer the user's location. For this privacy reason, Google requires apps to have location permission to perform BLE scans. You cannot add the neverForLocation attribute to the scan permission for the same reason.

Android runtime checks

In MainActivity.kt, you implement the runtime logic to ensure all requirements are met before the user can connect. The code does the following:

Requests permissions: It uses ActivityResultContracts to launch the standard runtime permission dialogs.
Enables Bluetooth: If the Bluetooth adapter is off, it launches an intent with BluetoothAdapter.ACTION_REQUEST_ENABLE to prompt the user to turn it on.
Enables location: It checks if Location Services are enabled and directs the user to system settings if they are not.

The official Android documentation notes that intents for Bluetooth, location, and application settings may not always resolve. A device manufacturer might block or fail to implement them. The sample project handles this by falling back to the generic settings screen.

To keep the UI state synchronized, the app rechecks all permissions and service statuses in the onResume lifecycle method. This ensures that if a user enables Bluetooth in system settings and returns to the app, the UI correctly reflects the new state. Additionally, a BroadcastReceiver listens for ACTION_STATE_CHANGED (for Bluetooth) and PROVIDERS_CHANGED_ACTION (for location). This allows the app to react to these service changes in real-time.

iOS

On iOS, the platform handles more of the setup flow automatically, so you write less boilerplate code.

iOS permissions

For permissions, you only need to provide a usage description string in the iosApp/iosApp/Info.plist file.

<!-- file: iosApp/iosApp/Info.plist -->
<key>NSBluetoothAlwaysUsageDescription</key>
<string>This app uses Bluetooth to scan and connect to BLE devices</string>

The first time Kable attempts a BLE scan, iOS automatically detects the required permission, finds this string, and displays a standard system dialog.

iOS Bluetooth service

The flow for enabling Bluetooth is also system-managed. If a user tries to use the app with Bluetooth off, the Core Bluetooth framework automatically displays a system alert prompting them to enable it. This differs from Android, where you must manually create and launch an intent for a similar prompt.

Wrap-up

Real-world IoT is rarely as clean as this sample app. Platform-specific quirks, where devices don't conform to standards, are just one part of the challenge. You will encounter issues that can affect reliability and user experience. Remember that Bluetooth can be unreliable: connections drop, devices lose power, or users might turn off their devices or Bluetooth.

The current app's most critical flaw is its inability to handle unexpected disconnects. If the Bluno device loses power or goes out of range while the app waits for the blink confirmation, the UI will get stuck with a spinning progress indicator. Another issue is that the app will wait forever for a device during the initial scan. You can fix both problems by adding timeouts. After a reasonable period, such as 10 seconds, you can abort the scan or connection attempt and reset the UI to its Idle state, letting the user try again. For a better user experience, you could add a dedicated Error state to display a helpful message like "Device not found" instead of just returning to the idle screen.

You should now have a solid understanding of how to build a simple IoT app with Kotlin Multiplatform. The worlds of IoT and Kotlin Multiplatform are evolving quickly, so stay updated with the latest library versions and best practices.

Deep Diving Into AI_devs 3: What I Learned And How You Can Benefit

Karol Wrótniak — Sat, 22 Feb 2025 12:20:34 +0000

The AI_devs 3 course has provided an in-depth exploration of advanced concepts in artificial intelligence. It focuses on the integration and application of LLMs (Large Language Models) in real-world scenarios. This includes not only tools and techniques to enhance your understanding of AI development, but also data setup, working with LLMs, and building retrieval-augmented generation (RAG) systems. This article aims to summarize the key takeaways and insights gained from the course.

Disclaimer: The intention is purely to provide an unbiased, subjective opinion about the course. this article is not affiliated in any way by the company behind AI_devs. I received neither compensation nor a discount. You won’t find any referral links here. At the time of writing this article, the course is not purchasable. I receive no benefits from advertising or promoting AI_devs, or its authors. Moreover, I paid the same price for the course as everyone else.

How is the course organized?

The main training consists of five episodes, each containing five lessons. Every lesson appeared on a consecutive workday, so the main course lasted five weeks in total. There was also an optional, introductory pre-work week.

Almost every lesson ends with a task. You have to solve at least 80% of the tasks to get a certificate (here is mine). Note that these tasks involve communication via API. The API keys were separate for each participant. You have to write code (or instruct some LLM to write it for you) and execute it to pass. Code samples provided in the lessons are in JavaScript but you can use any programming language you are familiar with.

There were also extra tasks, for fun, that did not count towards the certificate. All the tasks (both normal and extra ones) used the CTF (Capture The Flag) form.

The most important concepts

Look at the course name suffix: agents.

That means it teaches how to use programming tools to solve problems automatically. Usually an agent uses many lower-level tools, such as some LLM via API and a database (not necessarily dedicated for AI).

It is important to handle unhappy scenarios gracefully. Giving up and showing an error to the user is better than presenting an incorrect or off-topic answer.

AI tools for development

There are a lot of tutorials and trainings on using LLMs and prompt engineering. In contrast, there is much less information about auxiliary utilities. These include powerful tools for monitoring and debugging AI applications, including specialized databases for vector storage, and utilities for web crawling. I’ll describe a few of them used in the course.

FireCrawl: Web content extraction

FireCrawl is a web scraper designed for AI applications. It focuses on extracting clean, structured content from web pages. It can filter out noise like ads, navigation menus, and irrelevant elements. This makes it useful for feeding high-quality web content into LLM-powered applications. The tool can handle modern JavaScript-heavy websites and maintains proper content hierarchy. All of this makes it a powerful component for building AI agents that need to understand web content.

LangFuse: Monitoring and debugging AI applications

LangFuse is a monitoring and debugging platform for LLM-powered applications. It provides insights into token usage and costs. It can also analyze latency, and the performance of AI interactions. The platform allows debug prompts, and analyzes how they behave in production.

There are other alternative tools for prompt debugging and analyzing. For example:

LangSmith — Developed by LangChain, offering comprehensive debugging and monitoring features.
Portkey — Focuses on prompt management and optimization with A/B testing capabilities.
Parea — Provides analytics and monitoring with emphasis on prompt version control.
Helicone — Offers LLM monitoring with cost tracking and caching features.
Arize — An observability and evaluation platform for AI.

Vector databases

Vector databases are data storage systems designed to handle high-dimensional vectors. They are essential for applications involving machine learning and AI. They enable efficient similarity searches and retrieval of data. You can use them for tasks such as recommendation systems and semantic search.

Qdrant is a vector similarity search engine. It enables storing and searching through high-dimensional vectors using embeddings. The database offers filtering capabilities and real-time updates.

Speech-to-text tools

Speech-to-text (STT) technology helps applications to convert spoken words into written text. There are several tools which can be helpful in that matter:

Whisper by OpenAI offers transcription across many languages. You can run it locally or via API.
AssemblyAI provides real-time transcription with advanced features like speaker diarization and content moderation.
Deepgram specializes in real-time transcription optimized for specific industries and use cases.
Happyscribe is another popular tool that offers transcription and subtitling services, providing an easy-to-use interface and API for seamless integration into various applications.

Text-to-speech tools

Text-to-speech (TTS) allows applications to convert written text into natural-sounding speech. This technology is essential for creating accessible applications and enhancing user experiences. There are tools for TTS as well:

OpenAI TTS provides high-quality voice synthesis with customizable options for tone and style.
ElevenLabs offers realistic voice generation with emotional intonation, making it suitable for storytelling and interactive applications.

Image generation

AI-powered image generation allows the production of high-quality visuals from textual descriptions or existing images.

ComfyUI is an intuitive user interface for interacting with various AI models related to art and image synthesis. It enables users to configure and run models without extensive programming knowledge.

Graph databases

Graph databases can efficiently store data structured as graphs, namely those consisting of nodes (entities) and edges (relationships). This structure makes graph databases suitable for applications that need deep connections between data points, such as social networks, recommendation systems, and knowledge graphs.

Neo4j is one of the most popular graph databases. It offers powerful querying capabilities through its Cypher query language.

Frameworks for agent creation

There are several frameworks which can help you create AI agents. For example CrewAI provides a straightforward interface for building agents that can interact with various APIs.

Vercel AI SDK, likewise, is a powerful framework for building AI-powered user interfaces. It provides streaming responses and React/Svelte/Vue components, and has built-in support for popular AI models like OpenAI, Anthropic, and Hugging Face. The SDK makes it easy to implement features like chat interfaces with real-time streaming responses. It also offers type safety and handles rate limiting and error handling out of the box.
LangGraph focuses on integrating language models with graph databases, enabling developers to create agents that leverage complex relationships within data.
Swarm (made by OpenAI, experimental at the time of writing) emphasizes collaborative agent behavior, allowing many agents to work together towards a common goal.
AutoGen offers tools for automating the generation of agent behaviors and interactions, streamlining the development process.

Code interpreters for AI

Code interpreters allow models to p erform complex tasks, such as web scraping or data processing. Tools like BrowserBase provide a user-friendly interface for automating browser interactions, making it easier to gather information from the web.

Similarly, Playwright offers powerful capabilities for browser automation, enabling developers to write scripts that can navigate web pages, fill out forms, and extract data.

Interesting techniques

The development of AI applications requires specific approaches and methodologies. They differ from traditional software development. Here are some key techniques that have proven effective when building AI-powered systems.

Function calling

Function calling enables structured communication between the model and external tools or APIs. You provide a schema describing available functions and their parameters. An LLM can decide when to use specific tools and generate the appropriate arguments on its own.

This creates a standardized way for models to interact with external systems. For example, it can help searching databases, or controlling smart home devices.

One prompt for one problem

A key principle in AI development is to break down complex tasks into smaller prompts, rather than trying to achieve many objectives in a single go. Each prompt should be focused to address one specific problem or subtask.

This approach improves reliability and makes it easier to debug issues. For example, instead of asking an LLM to both analyze a document and generate a summary in one prompt, it’s better to split this into two steps. First analyzing the content, then creating the summary based on that analysis. This technique also reduces token usage which leads to lesser costs.

Wrap-up

The AI_devs 3 course has provided valuable insights into building AI-powered applications. From basic concepts to advanced agent implementations.

However, it’s important to understand that the field of AI development is evolving. New models, tools, and techniques emerge all the time. For instance, the Deepseek R1 model wasn’t even available during that course. Now, it is a notable player in the field. This highlights why continuous learning is essential for AI developers.

Taking one course, even an excellent one like AI_devs 3, is the beginning of the journey. You need to stay updated with the latest developments, constantly experiment with new tools, and refine your skills.

Based on my experience with AI_devs 3, I can recommend it, especially if you are interested in practical AI development. I’m looking forward to participating in AI_devs 4 when it becomes available.

Originally published at https://www.thedroidsonroids.com on February 20, 2025.

10 Ways AI Can Speed Up your Mobile App Development

Karol Wrótniak — Thu, 19 Sep 2024 08:57:50 +0000

Introduction

Today, AI (Artificial Intelligence) technologies can speed up the mobile app development process. They can enhance mobile apps performance, and improve user experience. Developing AI powered apps is becoming more and more popular. From code generation and automated testing to user interface design and performance optimization, newer and newer app features depend on artificial intelligence and machine learning.

No matter if you’re an Android, iOS, Flutter, or Kotlin Multiplatform developer, this guide provides tips and examples to help you use the power of AI algorithms in your daily work.

My name is Karol, and I’ve been a mobile developer since 2011 (more about me in the bio below). I use AI tools every day in my work at Droids On Roids, primarily through GitHub Copilot, including chat. Moreover, I use Hemingway, ChatGPT, Claude Sonnet and Stable Diffusion.

In November 2023, I completed the AI Devs 2 course. It covered generative AI, programming AI assistants, and other exciting topics. In November 2024 I’ll attend the AI Devs 3 course. I’m excited to learn more about AI technology and how it can help me in my daily work. I want to share some popular AI tools that you’ll find valuable.

Basic concepts

There are several concepts you should understand before diving into the details of how to use AI in app development.

Large Language Models

Large Language Models (LLMs) can generate human-like text based on the input they receive. A Large Language Model (LLM) is an advanced type of artificial intelligence and machine learning. It can understand and generate human-like text based on the input it receives. These models are trained on extensive datasets, which contain a lot of text sources.

Such models can perform a variety of language-related tasks, like text completion, translation, summarization, and question-answering. LLMs leverage deep learning techniques, particularly transformer architectures, to capture the nuances and complexities of human language. This makes them powerful AI tools. GitHub Copilot and similar solutions use LLMs.

LLMs can also be embedded inside AI powered mobile apps. Current smartphones are powerful enough to handle a local LLM and the mobile apps using them do not even need to connect to the internet. If you want to read more about developing AI powered mobile apps, read my previous article: How to develop an AI app with a local model in Kotlin Multiplatform. It describes how to create a simple AI powered mobile app.

Generative AI

This type of AI technology can create new content, such as images, text, or music. It looks for patterns by analyzing user data. Generative AI can be used to create data for training machine learning models.

Generative Artificial Intelligence also enables the creation of virtual environments and simulations. It is useful for mobile apps, such as gaming and virtual reality. For example, Stable Diffusion can generate realistic images matching the text prompt.

Natural Language Processing

Natural Language Processing (NLP) is a field of artificial intelligence and machine learning. It focuses on the interaction between computers and humans through natural language. This involves algorithms that enable machines to understand human language. Natural Language Processing encompasses a variety of tasks, such as language translation, sentiment analysis, speech recognition, and text summarization, for example.

When it comes to AI powered mobile apps, Natural Language Processing can be used for the likes of voice-activated commands. In this case, they allow app users to perform tasks hands-free, but Natural Language Processing can also power chatbots and virtual assistants, helping AI powered mobile apps can provide instant customer support and personalized user experience.

Deep learning

Deep Learning (DL) is** a subset of machine learning*. It uses neural networks with many layers to model complex patterns by processing data. This creates many useful features and for mobile apps, such as **image and speech recognition, natural language processing, and autonomous driving*.

DL has revolutionized the mobile app development industry. It leverages machine learning algorithms to create AI apps that can perform complex tasks, including the aforementioned image recognition, as well as natural language processing, and predictive analytics. These models can enhance user experiences by providing personalized content and recommendations. For instance, AI apps can use DL to analyze user behavior and adapt the app’s functionality. Additionally, Deep Learning facilitates the development of advanced features, such as real-time language translation **and **augmented reality, making mobile applications more interactive and user-friendly.

How are developers using AI? Key stats

Let me share some interesting results regarding developer usage**. **According to the 2024 Stack Overflow Developer Survey, around 82% of developers are currently using AI tools for writing code. The next most popular uses include searching for answers, debugging, and documenting code. Interestingly, 46% of respondents want to start using AI for testing code. What’s more, nearly 40% are interested in leveraging AI for tasks like committing and reviewing code, predictive analytics, and even deployment and monitoring! Take a look at the popular uses of AI in the development according to Statista:

This highlights how AI’s role in software development is growing fast. For software houses, it’s key to stay on top of these trends and use AI in smart, responsible ways to deliver solutions that are both efficient and high-quality.

How can you use AI in mobile app development?

In this section, we will explore how you can integrate AI into mobile app development. I will cover various AI tools and virtual assistants that can enhance your app development process. Some ideas from my list overlap with the Stack Overflow survey results, but you’ll also find some unique insights. These come mainly from my own daily experiences working with AI tools. I hope you’ll find them helpful!

AI-powered code generation

When it comes to improving mobile app development, AI-powered code generation helps automate repetitive tasks and provide suggestions. Tools like GitHub Copilot offer automated code completion. They help app developers write code faster and with fewer errors.

Additionally, AI can generate boilerplate code, which is common in app development. In the case of mobile apps, it can be used when setting up a new project. It is also good at generating repetitive code fragments like subsequent form fields. Such tools can save developers a significant amount of time and effort. Codeium and Tabnine, for instance, provide smart code completions. They base their predictions on the context of the written code. Most of these tools are available as plugins for popular IDEs used by mobile app developers, like Android Studio or Xcode.

To get the most out of GitHub Copilot, use clear and descriptive comments. Look at the official article about tips, tricks, and best practices. It’ll guide the AI in generating relevant code snippets. Don’t forget to review the generated code and ensure it meets your project’s requirements and standards.

AI-assisted testing and debugging

AI-assisted testing and debugging tools automate various testing tasks and related work. There are test case generation solutions, such as Testim and Applitools, that use AI to create test cases, ensuring better coverage and reducing manual effort.

AI tools mentioned in the previous section can help in writing unit tests. They can also generate other types of tests written as code, such as integration and end-to-end tests.

Tools like DeepCode analyze code to identify potential bugs before they occur. They help developers fix issues early in the app development cycle, which can significantly reduce operational costs and the overall time spent on debugging.

AI-driven user interface design

Tools like Uizard and Sketch2Code generate UI elements based on design specifications. They can convert design mockups into functional code, reducing manual effort. AI can also optimize layouts for different screen sizes. Tools like Framer, for instance, use AI this way. It adjusts UI components to fit different screen dimensions.

Additionally, AI can suggest design improvements based on user experience data. It helps developers create more intuitive and user-friendly interfaces.

Tools like Stable Diffusion and MidJourney can generate realistic images. They do that basing on textual descriptions. Those tools can reduce the time spent on manual design tasks. This enables development team members to focus on the more creative aspects of mobile app development.

Uizard uses AI in its design-to-code feature. It can convert your design mockups into functional UI code. Additionally, its suggestions can optimize your layouts for different screen sizes and orientations.

To get the most out of Stable Diffusion, focus on crafting detailed, specific text prompts. They should precisely describe the desired output.

Natural Language Processing for app localization

Translation tools like Lokalise and Transifex have advanced Natural Language Processing capabilities nowadays. They can translate a mobile app’s content into many languages. Such translations are not only accurate but also culturally relevant. They can be used not only inside mobile applications but also for text in the app stores.

Tools like Phrase and Smartling also use Natural Language Processing. They consider the context in which the text appears. When using Smartling, integrate it early in the app development process. That way, it can capture content as it’s created

AI-powered performance optimization

AI technology helps in resource allocation and management. Tools such as Kubernetes can dynamically allocate resources based on current demand. This ensures optimal performance and cost efficiency.

Tools like Akamas, similarly, can determine the caching mechanisms to reduce load times. Then, they balance the loads across servers, helping to maintain a high responsiveness and prevent bottlenecks.

AI-enhanced security implementation

There are automated vulnerability detection and patching tools, such as Snyk and Mend.io. They can constantly scan codebases for app security vulnerabilities and apply patches automatically. Consequently, they reduce the risk of exploitation.

Auth0 by Okta provides Intelligent user authentication systems. It uses AI technology to analyze user behavior and implement adaptive authentication mechanisms. It can help ensure secure access while minimizing friction for legitimate users.

Threat analysis and prevention tools, such as Darktrace and Vectra, also use AI algorithms. They monitor network traffic and detect anomalies. They can help with proactive threat mitigation.

AI-driven user behavior analysis and personalization

Predictive user modeling tools, such as Mixpanel and Amplitude, analyze user behavior data. They can forecast future users’ actions and preferences. Automated A/B testing tools, like Optimizely and Google Optimize, use AI. They can run experiments, predict user actions and identify the most effective variations.

Content recommendation systems, like those provided by Recombee and Algolia, also utilize AI algorithms. They analyze users’ behavior, interactions and preferences to suggest relevant content. For example, let’s assume that a user watches several action movies. The AI will recommend other action movies or related genres in real-time. Or, let’s say that a user listens to music on their mobile device during the morning commute. The AI will suggest similar music during that time frame.

AI-assisted API integration and management

Tools such as New Relic and Dynatrace also use AI algorithms. They do this for API performance monitoring and optimization. They check API performance, detect anomalies, and provide actionable insights for optimization.

AI-powered asset management and optimization

Media compression tools, such as Cloudinary, use AI as well. They reduce file sizes without compromising quality. Akamai and Fastly utilize AI algorithms to manage versions of assets and cache them effectively. This can reduce server load and improve delivery speed.

AWS CloudFront use AI to analyze user behavior. It can then load the most relevant resources faster, resulting in optimized performance and user engagement.

AI-enhanced collaboration and project management

Asana and Trello use AI to assign tasks based on team members’ skills and availability. Monday and Jira, likewise, use AI to track project milestones. They generate real-time status reports, and provide insights into project health.

Deadline and resource management tools, such as ClickUp and Wrike, are other noteworthy examples. They employ AI to forecast project timelines, help identify potential bottlenecks, and suggest resource adjustments to meet deadlines.

Let’s sum up what we’ve discussed in this part:

Wrap-up

AI is revolutionizing mobile app development by enhancing various aspects of the process. It has become more and more popular in the mobile app industry. For example, AI-powered code generation tools like GitHub Copilot speed up coding, while graphic tools like Stable Diffusion generate the assets. AI can do more and more time consuming and repetitive tasks. This all leads to faster app development cycles and lesser costs. At Droids On Roids, we use AI tools such as GitHub Copilot and ChatGPT to accelerate software creation and reduce costs for our clients.

Tips & tricks

When using AI tools, it’s important to understand the problem you’re trying to solve. You should specify the desired outcomes. **The more precise you are, the better results you’ll get. **Carefully check the capabilities and limitations of each AI tool. Ensure it aligns with your requirements.

Don’t forget to check the terms and conditions. Some tools may use data you enter to train the models. If that data is confidential, check if you can disable such learning. Otherwise, your data may appear to other users of the given tool.

Sometimes you may need to buy a more expensive subscription to increase privacy. Always maintain human oversight and control to ensure responsible and ethical implementation. Additionally, be prepared to experiment, and iterate.

Originally published at https://www.thedroidsonroids.com on September 19, 2024.

How to develop an AI app with a local model in Kotlin Multiplatform

Karol Wrótniak — Fri, 30 Aug 2024 10:29:19 +0000

Kotlin Multiplatform (KMP) is a technology that enables you to write code once and run it on many platforms. It’s a great way to share code between Android and iOS apps (read also: Flutter vs Kotlin Multiplatform). With the addition of AI, which stands for artificial intelligence, apps can perform tasks that usually require human intelligence by themselves. In this article, I will show you how to create an AI app using Kotlin Multiplatform and a local AI model, with a technical focus specifically for developers.

Introduction

Kotlin Multiplatform supports mobile platforms like Android and iOS. It supports desktop and web apps as well but, in this article, I will only focus on Android and iOS. The app will use the Compose Multiplatform UI framework for the user interface. It’s like the Jetpack Compose widely used in native Android app development.

The AI in the app will classify whether entered texts are positive or negative. It will use a TensorFlow Lite model and MediaPipe libraries for this purpose. Despite the fact that the model itself is platform-independent, the MediaPipe libraries are not. Therefore, we need to write a little bit of platform-specific code.

Note that Compose Multiplatform for iOS is still (as of August 2024) in the beta stage. Kotlin Multiplatform itself is stable but is in very active development. AI is a rapidly evolving technology, however, so the code in this article may become outdated soon. Keep that in mind if you are reading this article a long time after the publication date.

Implementation

The app I’ll show you is very simple. It is rather a proof of concept than a production-ready product. The goal is to show you how to integrate an AI in a Kotlin Multiplatform app. In the real app, you would probably want to use a more sophisticated AI model. You should also take care about architecture, error handling, and performance.

UI

The app will have a text field where the user can enter some text. The app will then classify that text and show the results. The user will see a message indicating whether the entered text is positive or negative. The UI will look like this on Android:

And like this on iOS:

And here is the app in action:

All the UI code will be in the shared module, common for all the platforms. The UI will be defined in a composable function. The entire code looks like this:

    @Composable
    fun App() {
      MaterialTheme {
        Column(
          modifier = Modifier.padding(16.dp)
        ) {
          var text by rememberSaveable { mutableStateOf("") } // 1
          TextField( // 2
            modifier = Modifier.fillMaxWidth(),
            maxLines = 10,
            label = { Text(text = "Text to classify") },
            value = text, // 3
            onValueChange = { text = it }, // 4
          )
          if (text.isNotBlank()) { // 5
            Text("Category: ${classify(text)}") // 6
          }
        }
      }
    }

In the code above you have:

A state variable that holds the text entered by the user.
A text field composable that enables the user to enter text.
Synchronizing the text inside a field with the state variable.
Updating the state variable when the user enters text.
Showing the classification result only when the user has entered some text.
Classifying the entered text and showing the result.

The TextField is stateless, it does not hold the text entered by the user. It only provides the ability to set its value and a callback when that value gets changed. That's why you need a separate text variable to hold the state. It also serves as the source of data for the model.

Note the rememberSaveable and the mutableStateOf functions. You may ask why they are needed? Isn't it enough to just use a var variable? No, it's not. You need both of them.

You need to wrap the actual text (string) in a mutable state to make it observable by the Compose framework. It needs to know when the text changes to trigger the classification process. The plain variable is not observable. When the framework detects the change, it calls the affected composable functions again. By “affected” I mean those in which the change occurred, so the text variable will reset to the empty string.

This is why you need the rememberSaveable function. Its lambda gets called only once when the composable is first created. It remembers the value of the text during all the next updates (called recompositions). What is more, this function is saveable so it survives the process' deaths, such as when the app goes to the background and gets killed by the system to free up memory, for example.

The MaterialTheme and modifiers (padding and fill max width) are here t o make the UI look nice. The reason for the ten lines limit for the text field is similar. It prevents the text field from occupying too much of the screen. The label of the text field and the classification result prefix are hardcoded for simplicity.

In the real app, you would need a more sophisticated UI. You should use the localized string resources for labels (Compose Multiplatform supports that), so they can be translated to many languages. You would also need to handle the case when the user enters too much text. This could be done, for example, by displaying some character counters.

The Text composable shows the classification result. It gets recalculated in every typed character. It's not a problem for such a simple app. But in a real app with more complex models, you would want to add some debouncing mechanism to ensure the classification is not triggered too often.

For example, you may trigger it when the user stops typing for a half second. Such debouncing is a must-have if the model is not local but provided by a remote server. In such cases, you often pay for each token (which is roughly each word in English).

In the app from this article, the classification happens synchronously on the main (UI) thread. It may look seamless in this simple app but, in a real application, you should perform such heavy tasks asynchronously on the background threads. Otherwise, without it, the app may freeze for a moment. You may use the Kotlin Coroutines for that purpose.

Platform-specific code

The signature of the classify function from the previous snippet is as follows:

internal expect fun classify(text: String): String

Note the expect keyword. It means that the implementation of the function is platform-specific. You may have many implementations of the function in different platform-specific modules.

Android

Take a look at the Android implementation:

internal actual fun classify(text: String): String = textClassifier.classify(text) // 1
 .classificationResult() // 2
 .classifications() // 3
 .first() // 4
 .categories() // 5
 .maxBy { it.score() } // 6
 .categoryName() // 7

Note the actual keyword. It indicates the actual implementation of the expected function. This classification process uses the TextClassifier class from the MediaPipe library. The steps are as follows:

Passing the text to the model and getting the response. This is the most time-consuming step.
Getting the classification result from the response. Apart from the result, a response contains also the timestamp.
Getting the list of classifications from the result. The size of the list depends on the model. In this case, it’s always one.
Getting the first classification from the list.
Getting the list of categories from the classification. The categories depend on the model. In this case, there are only two: “positive” and “negative”.
Finding the category with the highest probability (score). Each classification contains a list of categories with their scores. The latter sum up to one (100%).
Getting the name of the category. The names are hardcoded in the model.

This simple app extracts only the name of the most probable category. In more complex models, there might be more than one classification result for a given input, as well as more than two categories for each classification. You may also use the scores to show the user how sure the result is.

The textClassifier is a singleton instance of the TextClassifier class. It's initialized in the following way:


    private lateinit var textClassifier: TextClassifier

    internal fun initClassifier(context: Context) {
     val baseOptions = BaseOptions.builder().setModelAssetPath("mobilebert.tflite").build()
     val options = TextClassifierOptions.builder().setBaseOptions(baseOptions).build()
     textClassifier = TextClassifier.createFromOptions(context, options)
    }

The initClassifier function is invoked from the initializer provided by the AndroidX App Startup library. This ensures that the model is always ready before the user can enter any text. Moreover, the initializer gets triggered only once when the app is started.

Note that the model is stored in the mobilebert.tflite file. It is inside the Android assets directory. The size of the model is about 25 MB. Loading such a big model may take a while. In the real app, you should perform the loading in the background. Keep in mind that the model files may be bigger. They may be even so big that they do not fit in the largest size of the application on the Play Store. In such cases, you may want to download the model from the server from inside the app.

The TextClassifier has to be closed when no longer needed to prevent memory leaks. You can do this by calling the close method. In this simple app it's not necessary because there is only one, singleton instance of the TextClassifier. In the real app, however, you should close the classifiers when they are no longer needed, especially when you have many classifiers.

iOS

Most of the iOS-specific code is written in Swift. On the Kotlin side, there is only a small bridge using the mentioned actual keyword:

    private lateinit var classifier: (String) -> String
    @Suppress("unused") // Called from Swift
    fun initClassifier(nativeClassifier: (String) -> String) {
     classifier = nativeClassifier
    }
    internal actual fun classify(text: String) = classifier.invoke(text)

The implementation in Swift is analogous to the Android one. Take a look at the code:


    let modelPath = Bundle.main.path(forResource: "mobilebert", ofType: "tflite")
    let options = TextClassifierOptions()
    options.baseOptions.modelAssetPath = modelPath!
    let textClassifier = try? TextClassifier(options: options)
    Classifier_iosKt.doInitClassifier { (text: String) -> String in
       (try? textClassifier?.classify(text: text).classificationResult.classifications.first?.categories.max {
           $0.score < $1.score
       }?.categoryName) ?? "unknown"
    }

The only significant difference is that both initialization and classification can throw errors. So, the function calls are wrapped in the try? operator and guarded by the safe calls (?.). In case of an error, the resulting category passed to the Kotlin falls back to "unknown".

Note that unhappy scenarios can also happen on Android. For example, when the model file turns out to be missing or corrupted. In such cases, the affected function call throws an unchecked exception and, as a result the app crashes. In the real app, you should handle such exceptions, especially when you use models downloaded from the internet.

Note the lateinit classifier variable. It is not possible to call the Swift function directly from the Kotlin code. But the opposite is possible. The Kotlin classes and top-level functions are visible in Swift. So, during initialization, the Swift code creates a callback. It is then stored on the Kotlin side and called when needed.

Model

The model used in the app is a MobileBERT model. It’s trained on the SST-2 (Stanford Sentiment Treebank) dataset, which contains movie reviews. The model is exported to the TensorFlow Lite format, which is optimized for mobile devices, so it can be used locally on the user’s phone, without the need to send any data to the internet! It may be important in terms of privacy and legal regulations. The model file is the same for both Android and iOS.

Although it is possible to create a model from scratch, it’s a very time-consuming process. Take a look at the below visualization of just part of the MobileBERT model:

Note the size of the scrollbars. The model is huge. You can explore it using Netron. In the real app, you would use some ready, pre-trained model.

Wrap-up

In this article, you learned how to create an AI-powered application using Kotlin Multiplatform. I demonstrated to you how to use the Compose Multiplatform UI framework. You can use it to build a user interface that works on both Android and iOS. I also showed you how to integrate a local TensorFlow Lite model in the app and how to use the MediaPipe libraries to classify text. With this knowledge, you can develop apps which don’t require an internet connection to perform data processing.

You should now have a rough understanding of how to build a simple AI app using Kotlin Multiplatform. Keep in mind that AI and Kotlin Multiplatform are rapidly evolving fields. So, always stay updated with the latest library versions and best practices.

If you’re looking for a tech partner to build your AI app, reach out to us and schedule a free consultation.

The full source code is available on our GitHub repository.

Originally published at https://www.thedroidsonroids.com on August 30, 2024.

Edge Cases to Keep in Mind. Part 1 — Text

Karol Wrótniak — Thu, 08 Aug 2024 17:32:39 +0000

No matter if you are a software developer, a copywriter or you’re just writing an e-mail, text has many traps you need to be aware of. Some may cause numerous issues, from bugs in your app through visual artefacts to even victims! Let’s take a look at how we can avoid them.

Background

Text (aka strings) exists in virtually all software projects, from one-liners like hello-worlds to enterprise systems containing billions of lines of code, regardless of the programming language, platform and so on. Texts are just sequences of characters, so this shouldn’t be rocket science, right? Let’s take a look what traps you can encounter!

Letter case

Some of the world’s alphabets (including English) are bicameral, which means they contain both upper and lower case letters.
For example: a is a lower case character and A is upper case. Conversion from one letter case to another is quite a common operation.

Casing might seem trivial — one character is just converted (mapped) to another one. It may even be a character unto itself if it is not a letter, such as 1 or + and so on. Additionally, this mapping can always be simply reversed, e.g. A->a and a->A. So, everything seems fine at first glance. Well, nothing could be further from the truth!

Casing errors may kill

This is not a joke and we are not talking about enraged grammar Nazis. As you can read in this article, a casing glitch caused 2 victims and put 3 more people in jail.

How did that happen? Well, in Turkish (and Azeri) we have 2 distinct i letters: dotted (closed) and dotless (open). In English and other Latin alphabets, lowercase letter is always dotted while uppercase - dotless. Everything is illustrated in Table 1. and online demo.

Table 1. Dotted and dotless i letters.

	Lowercase	Uppercase
English	i dotted	I dotless
Turkish	i dotted	İ dotted
Turkish	ı dotless	I dotless

As you can see, the casing change result depends on context, which further depends on the current language. It is important to use appropriate language when composing texts intended for humans. If you don’t care about this, your words may end up having a different meaning than intended.

On the other hand, machine readable texts like HTTP headers or JSON keys should be processed in language-neutral way. Otherwise, you may get non-ASCII characters in the output which may break application logic. That exact situation happened in GSON, a library used by thousands (or maybe millions) of projects.

The secrets of diacritics

Characters with diacritics can be precomposed like ó, or created by combining marks like ó. When reading this page, they both look like the same character. Yet, if look at the hexdump of the second one or even try to obtain its length programmatically, like in this demo, you will see that it consist of 2 individual characters: Latin small letter o and a combining acute accent. Similarly, each Hangul (Korean alphabet) syllable block can be precomposed or written as a combination of distinct jamos individual letters/characters.

Why are combining marks so important? Well, there are two ways of writing most of the characters with diacritics (for example from Polish, Hungarian or Czech alphabets). This makes operations like sorting, searching or text length measuring non-trivial. Usually, to achieve the best user experience, texts need to be normalized (converted to one of the normal forms). Otherwise, users may be confused when they see, for instance, multiple “different” logins or filenames that look the same. A great example of this is how Slack handles channel names. They are normalized before channel creation, so situations wherein the same name written in different ways cannot coexist.

Some characters are more equal than others

There are 2 levels of character equivalence. Canonical equivalence occurs when characters are assumed to have the same both meaning and appearance, e.g. the aforementioned ó and ó differ only by (technical) way of writing. On the other hand, compatibility means that characters may appear distinct but may have the same meaning. For example the ligature ﬃ is compatible with three distinct letters ffi but they are not canonically equal. More info about Unicode normalization can be found in the standard documentation.

While both the composed and decomposed forms for each 2 levels are standardized — so we have 4 normal forms in total — normalization is not always reversible. For example an angstrom sign Å is decomposed to the Latin capital letter A A plus combining ring above ̊, which are composed back to a Latin capital letter A with ring above Å, not to the angstrom sign from which it originated.

Combo normalization bugs cause adventures

It is also important that all the applications sharing a given text use the same normalization method. If they don’t, it may cause subtle errors and/or even silent data losses. Such bugs may be difficult to discover because each application works faultlessly, at least when running individually. Applications often do not “crash” in such cases but just send or receive data different to what it should, causing unintended consequences. One such examples is this bug in nettalk.

Aforementioned typographic ligatures are used to improve the visual appearance of certain characters which don’t look well separately adjacent to each other. Most users don’t need to worry about ligatures, since they are generated automatically from individual letters by software e.g. TeX produces ligatures by default. However, developers of such tools have to take into account that, in some cases, ligatures may be inappropriate and introduce errors.

Take a look at this: ﬁ. Is the second letter dotted or dotless? Turkish-speaking readers may be confused. Ligatures containing i should not be used in some contexts.

Where is my uppercase?

A few scripts (so-called bicameral) like Latin and Greek contain letters of two cases. Virtually all of the letters have lower and upper case. Virtually… but not absolutely all!
While the lowercase set is always present, it is not true for uppercase. So, if there are characters which have only lowercase, what happens if you try to convert them to uppercase? Would it be an error that causes the operation to fail? Would the character stay the same? The answer is nothing of that kind!

One of the most noticeable examples is the German sharp s — ß. It is a lowercase character and, when converted to uppercase, it becomes double S - SS. That transformation is not reversible - SS becomes ss. See it online. TL;DR Unicode 5.1 introduced ẞ (LATIN CAPITAL LETTER SHARP S) but it is not generally considered an uppercase of ß in terms of character mapping. It was recently (in 2016) added to the German orthography ruleset as an equally valid form of SS.

Many other lowercase ligatures do not have their corresponding precomposed uppercase forms. The complete list can be found in the Unicode Special Casing documentation.

The double or triple problems

Some uppercase characters are missing, so what? Ligatures can consist of 2 or even 3 characters, so uppercased text may be 3 times longer than the original lowercase. This is fact is extremely important where the resulting text length is limited. For example, in avatars or initials generators, like in this bug on bitrise.io.

The myσteriouς third case

The Greek alphabet contains the Sigma letter which looks like this in uppercase: Σ. What is its lowercase form? Well, it depends! Usually, it is σ (non-final) but, at the end of the words, it's ς (final). However, if a Sigma is the only letter or the word is written in all caps then a non-final version is always used, even at the final position. See interactive example.

Yet another edge case

What is the lowercase of a Latin capital letter i with tilde Ĩ? As you may have guessed, the answer is not so trivial. A corresponding lowercase form exists. Both forms are dotless but it is perfectly normal. Both i and j do not have dots if they have some diacritic(s) attached. So what is the problem here?

Apart from Turkish, Lithuanian ortographic rules are also exceptional in the case of the I letter. In the latter, the dot is preserved beneath the accent. This means, for example, that the aforementioned Ĩ, when lowercased in context of the Lithuanian language, becomes i̇̃. If you look carefully you can see that there are 3 characters: a Latin small letter i, a combining dot above and a combining tilde above. The length of the text has increased 3 times (again).

Keep plꜽing with ligatures and multigraphs

How can you write a word consisting of 7 letters, using only 6 characters? Just use precomposed ligatures and multigraphs (digraphs, trigraphs and so on)! Of course there is no precomposed character for each possible combination of joined letters. However, existent ones can be used to effectively increase text length limits. For example, a Silesian word dzbonek (a pot) consists of 7 letters but it can be written as ǳbonek using only 6 characters. See it online. Note that ǳ is a digraph, not a ligature.

Now you can, for example, tweet messages containing more than 140 characters! The list of precomposed Unicode digraphs and ligatures can be found here.

Little known ways to alphabetical order

The alphabetical order is usually taught at the beginning of primary school. A, B, C, D… and so on to Z. As easy as pie!

Unfortunately, alphabetical order depends on language. Even positions of the basic Latin letters (without diacritics) may be different. For example, in Estonian, the letter Z is between S and T.

The location of letters with diacritical marks is also not universal. There are several possible schemes:

Before the corresponding base letter, like in Maltese: W, X, Ż, Z.
After the corresponding base letter, like in Polish: A, Ą, B, C, Ć.
At the end of the alphabet, like in Swedish: Z, Å, Ä.
At the same position (for collation purposes) as the base letter, like in Hungarian: O=Ó.

Note that the same letter may be collated differently in various languages and may even differ in the same language, depending on context!. For example, in Slovak, an A with an umlaut is always located after A. However, in German, it may either have the same value as the non-umlauted version, be located after it or even be treated as A+E. More info about which way is used in which cases can be found here.

Bread, cash register and casino

It’s not only individual letters that are subject to collation. Multigraphs can also have their own rules. In Slovak, CH is collated between H and I. So, for example, the word chlieb (a bread) will be collated after hodina (an hour). On the other hand, in Polish that digraph is treated just like two separate letters - C and H - and thus have no special collation rules. See it online.

Hungarian even has double digraphs and each of them have their own collation rules. This leads to many complicated cases. Let’s consider one possible example. We have the SZ digraph. It is collated after S. Its doubled version (SZ + SZ) is a SSZ. This means that the word kaszinó (a casino) should be before kassza (cash register). Normally Z is after S but here we have: K A SZ I in the first word and (an equivalent of) K A SZ SZ in the second.

Furthermore, the same group of letters may or may not be a (double) digraph depending on the context. For example, aforementioned Slovak CH is treated as 2 separate letters C and H in some words e.g. viachlas (a polyphony). Normally, in Hungarian, NNY = NY + NY, like in the word mennybolt (a heaven). However, we also have a tizennyolc (eighteen) where NNY = N + NY, so there is a single letter N and a single digraph NY.

ΤНΙЅ ІЅ NОТ WНΑТ ΥОՍ ТНІNΚ ІТ ΙЅ

You may think that the headline above consist of only plain Latin letters. In fact, the vast majority of them are Greek, Cyrillic or Armenian capital letters. They are only the homoglyphs of some Latin letters.

So A (Latin capital A) is not the same thing as Α (Greek capital Alpha) nor А (Cyrillic capital A). Why is this important? Due to the fact that they are indistinguishable, they can be used in IDN homograph attacks. For example, the domain bank.com, only containing Latin letters, looks pretty much the same as bаnk.com, containing the Cyrillic small A instead of Latin small A. Such domains may be used for phishing.

Wrap up

Dealing with text may be tricky in some cases — especially if you work in a multilingual environment. As a rule of thumb, all configurations should be appropriate for the given context. For example, the user’s current language should be taken into account when processing texts visible to these users, while machine-readable ones should be processed in the language-neutral way (or using English if it is not possible). Selected collation settings should match actual usage as well. Text should be normalized when needed and the chosen normalization method should be consistent across all the system.
Want to know about more edge cases? Stay tuned, part 2 is on the way!

Edge Cases to Keep in Mind. Part 2 — Files

Karol Wrótniak — Thu, 08 Aug 2024 17:27:13 +0000

Did you know, that there may be a File which exists and doesn’t exist at the same time? Are you aware, that you can delete a file and still use it? Discover these & other files edge cases in software development.

In my previous article about edge cases in software development, I was writing about text traps and I gave you some suggestions, how to avoid them. In this blog post, I would like to focus on files and file I/O operations.

A File which is not a file

The java.io.File API provides, among others, these 3 methods:

One may think that, if it is pointed by a given path that exists, an object is either a file or a directory — like in this question on Stack Overflow. However, this is not always true.

It is not explicitly mentioned in File#isFile() javadocs, but file **there really means **regular file. Thus, special Unix files like devices, sockets and pipes may exist but they are not files in that definition.

Look at the following snippet:

import java.io.File

val file = File("/dev/null")
println("exists:      ${file.exists()}")
println("isFile:      ${file.isFile()}")
println("isDirectory: ${file.isDirectory()}")

As you can see on the live demo, a File which is neither a file nor a directory may exist.

To exist, or not to exist?

Symbolic links are also special files but they are treated transparently almost everywhere in (old) java.io API. The only exception is the #getCanonicalPath()/#getCanonicalFile() methods family. Transparency here means that all the operations are forwarded to the target, just like they are performed directly on it. Such transparency is usually useful, e.g. you can just read from, or write to, some file. You don’t care about the optional link path resolution. However, it may also lead to some strange cases. For example, there may be a File which exists and doesn’t exist at the same time.

Let’s consider a dangling symbolic link. Its target does not exist, so all the methods from the previous section will return false. Nonetheless, the source file path is still occupied, e.g. you cannot create a new file on that path. Here is the code demonstrating this case:

import java.nio.file.Files
import java.nio.file.Path
import java.nio.file.Paths

val path = Paths.get("foo")
Files.createSymbolicLink(path, path)
println("exists       : ${path.toFile().exists()}")
println("isFile       : ${path.toFile().isFile()}")
println("isDirectory  : ${path.toFile().isDirectory()}")
println("createNewFile: ${path.toFile().createNewFile()}")

And a live demo.

The order matters

In java.io API, to create a possibly non-existent directory and ensure that it exists afterwards, you can use File#mkdir() (or File#mkdirs() if you want to create non-existent parent directories as well) and then File#isDirectory(). It is important to use these methods in the mentioned order. Let’s see what may happen if the order is reversed. Two (or more) threads performing the same operations are needed to demonstrate this case. Here, we’ll use blue and red threads.

(red) isDirectory()? — no, need to create
(blue) isDirectory()? — no, need to create
(red) mkdir()? — success
(blue) mkdir()? — fail

As you can see a blue thread failed to create a directory. However, it was in fact created, so the result should be positive. If isDirectory() had called at the end, the result would always have been correct.

The hidden limitation

The number of files open at the same time by a given UNIX process is limited to the value of RLIMIT_NOFILE. On Android, this is usually 1024 but effectively (excluding file descriptors used by the framework) you can use even less (during tests with empty Activity on Android 8.0.0, there were approximately 970 file descriptors available to use). What happens if you try to open more? Well, the file won’t be opened. Depending on the context, you may encounter an exception with an explicit reason (Too many open files), a little bit of an enigmatic message (e.g. This file can not be opened as a file descriptor; it is probably compressed) or just false as a return value when you normally expect true. See the code demonstrating these issues:

package pl.droidsonroids.edgetest

import android.content.res.AssetFileDescriptor
import android.support.test.InstrumentationRegistry
import org.junit.Assert
import org.junit.Test

class TooManyOpenFilesTest {
    //asset named "test" required
    @Test
    fun tooManyOpenFilesDemo() {
        val context = InstrumentationRegistry.getContext()
        val assets = context.assets
        val descriptors = mutableListOf<AssetFileDescriptor>()
        try {
            for (i in 0..1024) {
                descriptors.add(assets.openFd("test"))
            }
        } catch (e: Exception) {
            e.printStackTrace() //java.io.FileNotFoundException: This file can not be opened as a file descriptor; it is probably compressed
        }
        try {
            context.openFileOutput("test", 0)
        } catch (e: Exception) {
            e.printStackTrace() //java.io.FileNotFoundException: /data/user/0/pl.droidsonroids.edgetest/files/test (Too many open files)
        }

        val sharedPreferences = context.getSharedPreferences("test", 0)
        Assert.assertTrue(sharedPreferences.edit().putBoolean("test", true).commit())
    }
}

Note that, if you use #apply(), the value will just not be saved persistently — so you won’t get any exception. However, it will be accessible until the app process holding that SharedPreferences instance is killed. That’s because shared preferences are also saved in the memory.

Undeads really exists

One may think that zombies, ghouls and other similar creatures exist in fantasy and horror fiction only. But… they are real in computer science! Such common terms refer to the zombie processes. In fact, undead files can also be easily created.

In Unix-like operating systems, file deletion is usually implemented by unlinking. The unlinked file name is removed from the file system (assuming that it is the last hardlink) but any already open file descriptors remain valid and usable. You can still read from and write to such a file. Here is the snippet:

import java.io.BufferedReader
import java.io.File
import java.io.FileReader

val file = File("test")
file.writeText("this is file content")

BufferedReader(FileReader(file)).use {
   println("deleted?: ${file.delete()}")
   println("content?: ${it.readLine()}")
}

And a live demo.

Wrap up

First of all, remember that we can’t forget about the proper method calling order when creating non-existent directories. Furthermore, keep in mind that a number of files open at the same time is limited and not only files explicitly opened by you are counted. And the last, but not least, a trick with file deletion before the last usage can give you a little bit more flexibility.

Originally published at www.thedroidsonroids.com on September 27, 2017.

Edge Cases to Keep in Mind. Part 3 — Time of Check to Time of Use Race Conditions in Android UI

Karol Wrótniak — Thu, 08 Aug 2024 17:18:05 +0000

In this article, we’ll show how race conditions affect Android runtime permission system.

If you are a developer you’ve probably heard about race conditions. They are often associated with concurrent background operations performed in the fractions of seconds. However, certain race conditions may also appear in UI and last for the infinite time. In this article, we’ll show how race conditions affect Android runtime permission system.

Race condition & Time of check to time of use — what does it mean?

Firstly, we need to explain some basic terms.

Race condition occurs if multiple operations occur at the same time and their order affects the result. A textbook example is two threads incrementing the same variable. It seems to be trivial, however, usually, we need to use special, thread-safe elements to implement it properly.

Time of check to time of use (TOCTTOU or TOCTOU, pronounced TOCK too) is a specific kind of race condition where a performed operation is preceded by state checking and that state is modified in the time between a check and actual execution. It is often illustrated by checking user privileges at the login time only. For example, if you are an administrator at the moment when you sign in and you can use your privileges until you sign out, even if your admin access is revoked in the meantime.

Android runtime permissions

Let’s also summarise Android runtime permissions basics.

Starting from Android 6.0 (API level 23) the most dangerous permissions has to be explicitly granted by a user at runtime rather than all at once on app installation time. The most noticeable element here is a system dialogue with DENY and ALLOW buttons like shown in figure 1.

Figure 1. Runtime permission dialog

After clicking on DENY button we receive PERMISSION_DENIED in onRequestPermissionsResult callback and we should disable the functionality that depends on this permission. According to the official snippet.

Additionally, user can also grant or deny permissions by using App permissions screen in application settings. You can see that screen in figure 2.

Figure 2. App permissions screen

Edge cases are everywhere

Most of you may think that runtime permission denial is a super simple feature and there is no element which can be broken. Well, nothing could be further from the truth!

A dialogue appears only if permission is not granted. So we have the time of check just before displaying a dialogue. And time of use when DENY button is clicked. A period between them can last forever - user can open a dialogue then press home or recent button to move the task with the app to background and return anytime later.

Let’s check if runtime permission dialogue is vulnerable to TOCTTOU. To do so, we can create a super simple activity which checks actual granted permissions after returning from the dialog. Note that apart from standard onRequestPermissionsResult arguments check we'll call Context#checkSelfPermission() to obtain current permission grant status. Don't forget to set targetSdkVersion to 23 or higher. The code should look like this:

class MainActivity : Activity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.main)
        requestPermissions(arrayOf(WRITE_EXTERNAL_STORAGE), 1)
    }

    override fun onRequestPermissionsResult(requestCode: Int, permissions: Array<out String>, grantResults: IntArray) {
        super.onRequestPermissionsResult(requestCode, permissions, grantResults)
        val checkResultTextView = findViewById<TextView>(R.id.grantResultTextView)
        val grantResultTextView = findViewById<TextView>(R.id.checkResultTextView)

        val checkPermissionResult = checkSelfPermission(WRITE_EXTERNAL_STORAGE).toPermissionResult()
        val grantPermissionResult = grantResults.firstOrNull()?.toPermissionResult()
        checkResultTextView.text = "checkSelfPermission: $checkPermissionResult"
        grantResultTextView.text = "onRequestPermissionsResult: $grantPermissionResult"
    }

    private fun Int.toPermissionResult() = when (this) {
        PERMISSION_GRANTED -> "granted"
        PERMISSION_DENIED -> "denied"
        else -> "unknown"
    }
}

Now we can perform a test. To do that we need a device or AVD with Android 6.0 (API 23) or newer. Test result is shown on figure 3.

Figure 3. Captured TOCTTOU

We can see that results differs. onRequestPermissionsResult argument is not valid. So DENY button is not denying anything! It simply does nothing with permission status but returns denied results to app.

Wrap up

It is important to keep timing into account when checking various things in the code. Caching check results may cause bugs and weird effects. TOCTTOU vulnerability does not depend on either platform or programming language so it has been classified as CWE-367.

You can check the full source code on GitHub.
The project also contains automated UI test demonstrating the issue.

Originally published at www.thedroidsonroids.com on December 14, 2017.

Edge Cases in App and Backend Development — Dates & Times

Karol Wrótniak — Thu, 08 Aug 2024 17:11:13 +0000

Introduction

You may think that dealing with dates and time is easy. We have a minute that lasts 60 seconds, an hour with 60 minutes, a day with 24 hours, a week with 7 days, a month with 28 to 31 days, and so on.

Surely no rocket science is required here…

Well, nothing could be further from the truth!

We will show the traps and pitfalls related to date and time that you may encounter during application and backend development.

Measurement units

Let’s start with the units of measurement, from the smallest ones to the largest.

Seconds and milliseconds

The smallest unit used everyday is a second. It is also the base of Unix time.

However, in some programming languages, such as Java, the most common unit is a millisecond (1/1000 of the second), as by the System.currentTimeMillis() method, for example.

That divergence may lead to many errors.

If you receive the numeric value from outside your system, it might not at first glance be clear what unit of measurement it uses, even after reading the documentation!

Look at the DATE field in the SMS and MMS content provider (database) columns. Both docs say only:

The date the message was received.
Type: INTEGER (long)

However, the SMS uses milliseconds while the MMS uses seconds. Surprised? Well, it may happen, especially if such APIs are designed by different people.

How can you deal with cases like these? And how can you avoid them?

Fortunately, we can formulate several general rules:

Always ensure the format of incoming data.
Check it in the wild because the documentation may be incorrect and/or outdated. It is usually very easy to spot an error, such as a date 50 thousand years too far in the future, when you look for it while developing. This result occurs when milliseconds are treated as seconds, for example.
If you have any influence on the side which is sending the values (eg. the system is being designed and nobody uses it yet), consider the standardized textual formats.
Here, I emphasize standardization (eg.ISO 8601) not some custom formats (we will broaden this topic later). After a few years, nobody from the original team may longer work for that project, and the textual format is straightforward to understand for new developers, as they don’t need to look at the docs.
Numerical formats may be better, however, in performance-critical appliances.
**Use dedicated classes for dealing with date/time/duration values rather than raw integers.
**In the Java world, we have a java.time package with a lot of useful classes like Instant or Duration. If there is an integer called eg. eventDuration, it is not known whether it stores seconds or milliseconds - or maybe even days?
If you must deal with raw values (integers, longs etc.) which you could not just wholly refactor, such as legacy code, include the unit of measurement with the variables/fields names.
For example,eventDurationSeconds is unambiguous.

Leap seconds

You’ve probably heard about leap years. They differ from “normal” ones by being an extra day longer. We also have leap seconds!

Are they longer than non-leap seconds?

Well, it depends!

First, let’s start with a little bit of theory. The Earth is slowing down; really it is not a philosophical statement but a scientifically proven fact. It is called delta-T.

OK, so what does this mean in practice for us? Well, our units of measurement for time have a standardized length. The base unit is a second, which is defined as:

The time duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the fundamental unperturbed ground-state of the caesium-133 atom. (source: bipm.org)

That duration is constant, and informs all other units derived from seconds eg. a minute consists of 60 seconds, an hour is 60 minutes (3,600 seconds) and so on.

However, if the Earth slows down (and the day gets longer), we have to somehow accommodate that slowdown to ensure the time measured by our units is consistent with reality. This is done by inserting extra seconds — the leap seconds.

There are only 2 available slots for leap seconds in the year: the very end of June and December. The very end means the last day (30th or 31st respectively) just after 23:59:59 UTC (so local time varies).

After those normally last seconds, the additional leap second is inserted before moving to the next day. So, we can have 23:59:60 (61 seconds in a minute — as we count from‌ 0).

Due to the fact that the slowdown is not constant, the leap seconds are inserted irregularly. The latest one (at the time of writing this article in April 2021) occurred in December 2016, which was more than 4 years ago. However, the penultimate one was in June 2015, with only a 1.5-year difference between the two.

In some of the places where we can set the time — like physical wall clocks or some framework APIs, there may be no ability to observe and/or set the time with the leap second.

For example the old-fashioned Date Java class supports even double leap seconds — the range spreads from 0 to 61, so 62 seconds are possible!

However, the modern Instant class from the java.time package does not expose leap seconds to programmers. Leap second is stretched equally over the last 1,000 seconds of the day (those seconds are longer).

Note that, in theory, the leap second can be also negative. But it has not happened so far.

This means that a minute could consist of 59 seconds, which may lead to huge issues. For example, if some action is scheduled to occur at 23:59:59.001 and it turns out that desired time does not exist…

Fortunately analogously to spreading the visible seconds may also be shrunk being completely transparent to programmers.

We know that the 61tst second can exist, but what about the 62nd? Well, the documentation says:

It is extremely unlikely that two leap seconds will occur in the same minute, but this specification follows the date and time conventions for ISO C.

Indeed, in the C specification we have a [0, 61] range. But why? The same question bothered Paul Eggert, the author of tzdata (timezone database) in 1992. As we can read in the archive:

*“Because there really were two leap seconds in one year (on separate days), and someone on the ANSI C committee thought that they came on the same day.” *— source groups.google.com.

That slight interpretation error, which occurred several decades ago, is visible still now because the new implementation needs to be backwards compatible with these standards.

Let’s go to other edge cases in app and backend development.

The days

The minutes and hours do not involve any unexpected cases so let’s jump to the days.

What is a day? It depends! You can say that it lasts 24 hours from 00:00:00 to 23:59:60 (including the leap second 🙂 ). Well, whether the latter is generally true, the day does not always last 24 hours, as it may be 23, 25 or even 21 and 27! Why those values? The answer is…

Daylight saving time

So-called DST or “summer time” advances the clocks in warmer months intended for reducing power consumption. Darkness begins later than in “regular” (non-DST) time. Nowadays, the necessity of DST is debatable because there are a lot of disadvantages. Some countries have even stopped observing DST recently (eg. Russia in 2014) due to them.

What are the problems with DST? Let’s see!

I won’t cover things like forgotten manual adjustments of wall clocks or delayed public transportation but, instead, I will focus on aspects related to backend and app development.

You may think that, in the summer time, we advance the clocks by 1 hour. This is not always the case! There are places in the world where the difference is 3 hours (like Casey) or 30 minutes (like Lord Howe Island).

Summer time, not exactly as the name suggests, can also cover some part of the spring or autumn but, generally, it is related to the warmer months. In turn, that depends on the hemisphere.

While in Europe there is a summer, in Australia there is a winter and vice versa. So, to put that in perspective, Australian summer time occurs during Europe’s winter!

What’s more, the definition of summer in terms of time depends on jurisdiction. In all the countries of the European Union, time is changed at the same moment so the time difference between Berlin and London, for example, is always 1 hour, no matter whether we are in summer or winter.

But let’s consider the time difference between Sydney and London. In this case, it depends on the day of the year! That’s because Sydney starts and stops observing DST at different dates than London.

Inspiration: timeanddate.com

For example, starting in January we have 10 hours difference. Sydney observes DST at that time but London does not. At the end of March, London starts observing DST, while the state in Sydney remains unchanged, so the difference reduces to 9 hours. Then in April, Sydney stops observing DST, so we have 8 hours. We have 3 different offsets. So the question about the time difference between Sydney and London has 3 answers!

Countries like the USA, EU members or Australia have, let’s say, stable jurisdictions with respect to DST. It is well known in advance when the transition occurs. However, it is not always the case, as some countries may change the laws unexpectedly. For example in 2020 in Fiji, the rules have changed with the announcement only arriving a few months before.

Even more complicated situations occur in some Islamic countries that officially observe Ramadan. If they also observe DST, the latter may be… suspended (for the period of Ramadan).

That means the DST transition may occur more than once (back and forth) and even a few times in a year. Furthermore, Ramadan is calculated according to the Islamic (lunar) calendar. Prediction is used to calculate Ramadan boundary dates and it may not be always accurate. For example, in Palestine in 2020, the prediction turns out to be short by about a week. Changes were applied only a few days in advance.

Most of the systems use the IANA Time Zone database as the source of DST transition moments. There are usually a few updates each year in that database.

Note that dealing with DST may have an impact on algorithms. Let’s consider a few typical scenarios.

If we have an alarm scheduled to a particular wall time (eg. 02:30) it may turn out that such a moment does not exist (when time is changed from 02:00 to 03:00 during DST transition) or it exists twice when the time is changed backwards. If, for example, the backup won’t be done or medicates won’t be given or will be given twice, then the consequences may be terrible.

Another common effect consists of cyclical triggering time changes if the user is located in the timezone observing DST. For example, if you schedule a build on bitrise.io to be fired at 10:00, it may suddenly start firing at 11:00.

This happens because the logic under the hood is not aware of DST and the time visible to the user is only calculated when rendering the UI. The absolute moment in time is always the same but the time visible to the user changes depending on DST. Usually, it is not what customers expect.

The weeks

What is the first day of the week? If you live in Europe, you would probably say Monday. In the USA it will be Sunday and in Arabic countries — Saturday. These facts may impact algorithm constructing and/or rendering calendars.

What about the week number in the year? You may think that everything starts from January 1st.

As you might have guessed, this is also not always the case!

According to the ISO standard, the 1st week of the year must contain Thursday. For example, in 2021 January 1st is on Friday so it belongs to the last week of the previous year. The first week of 2021 started on January 4th! Not all the locales use the same rule as the ISO standard in that matter, however.

The months

The Gregorian calendar used by most of the world has 12 months, from January to December. However, other kinds of calendar may have more months. For example the Hebrew calendar may have 13 months. The 13th one (in the IT world) is called Undecimber.

The years

Usually, the year lasts 365 days. However, each one divisible by 4 (eg. 2020, 2024 etc.) is a leap year which has 366 days (with 29 days in February instead of the normal 28). But, if it is divisible by 100 (2100, 2200 etc.) it is NOT a leap year. But 🙂 if it is divisible by 400 (2000, 2400 etc.) it is a leap year.

Fortunately, you don’t have to (and should not!) try to implement such distinctions yourself. You should use date classes/functions well known libraries of the given programming language.

There were many spectacular bugs in well-known services related to incorrect leap year calculations. There is even a term: Leap year problem.

The timezones

The local time depends on the longitude. While it’s noon in a particular location, it’s also midnight on the other side of the globe.

It is impractical to adjust the clocks continuously when traveling, so the globe was divided into zones which cover the areas having the same local official time.

Zone boundaries are usually equal to country boundaries in the case of small countries or some geographical regions in the biggest ones (like Australia, USA or Russia).

Source: timeanddate.com

Due to political and economical reasons in some places, the official time varies significantly from the “legitimate” one (taking only longitude/sun time into account). For example, in Spain, the zone is the same as in most of continental central Europe rather than the United Kingdom, which is closer according to the longitude.

Most time zones have integral offsets (the difference from UTC — a standard time) eg. in Berlin +1 hour (+2 in DST) or -3 h in Buenos Aires (Argentina, no DST). However, the offset may include halves of hours eg. in Mumbai (India) we have +5:30h (no DST).

If that wasn’t enough, quarters are also possible, as in Kathmandu (Nepal) we have +5:45h!

Fortunately, there are no more finer-grained offsets at the time of writing. However, they used to exist in the past, such as +0:20 in the Netherlands.

Due to the fact that we have 24 hours on the clocks, one may think that it is also a range of possible offsets. +12:00 and -12:00 combined together gives 24.

However, the farthest time distance between time zones is 26 hours!

This is possible because we have a +14:00 offset. It was adopted by several countries in Oceania as they are rather connected with Australia, so it is more practical to have a few hours difference than more than 20, which leads to another date in most cases.

Let’s consider a flight connection finder. In the case of round-trip flights, the users can choose both departure and return dates/times. It may be obvious that the return time must be after the departure.

Of course, this couldn’t be further from the truth!

Keep in mind that those times are in local time zones.

Take a look at this example:

Departure from Tokyo at 00:30 (offset +09:00) to San Francisco (offset -07:00)
Arrival in San Francisco at 18:00, the previous day in local time!
Return from San Francisco at 19:50 (still previous when relative to initial departure)

So, you can go somewhere and return yesterday. See this example:

Time zone naming

Another potential edge case in app/backend development you may face is connected to time zone naming.

You might notice that we can call a timezone by its offset eg. +01:00 or by its identifier eg. Europe/Berlin. Note that the latter notation gives multiple benefits: it carries information about DST transitions (Berlin has an offset +02:00 in the summer) and it also holds historical data.

For example, both the Europe/Warsaw and Europe/Berlin zones seem to be identical nowadays. They both have equal offsets all year, with DST transitions also always occurring at the same moments.

However, it was not always the case in the past! For example, in 1977 there was no DST in Berlin at all but Warsaw observed it from April 3th to September 25th (completely different from what we have today).

Note that timezone identifiers are built upon city names. This is intentional due to the fact that country boundaries are subject to change much more often than city names.

For example, the Crimea has in fact changed from Ukraine to Russia but the city names stay unchanged. The Europe/Simferopol zone can be used no matter if we need current or historical data.

Day vs nychthemeron, period vs duration

Let’s say that something lasts one day. So, if it starts at 09:15:00 AM then we can add 24 hours and to get the ending time (09:15:00 AM next day exclusively, in this case).

Well, it is not always so easy! Keep in mind that we can have a DST transition when the clock is artificially adjusted forward or backwards. This means the day usually lasts 24 hours but, occasionally, it may be 23, 25 or even more strange values like 27 or 23 and a half hours (do you remember Casey and Lord Howe?).

It is important to not blindly treat days as 24 hours when implementing business logic. You should use the appropriate date/time APIs for that. For example, in Java, we have distinct classes:

Period, which represents calendar days — perfect for things like subscription validity which is measured in days, months or years
Duration, which represents continuous time eg. 24 hours, no matter what the date in the calendar is. It’s perfect for measuring spans of actions, such as travel or the time since device/program start.

Some languages have distinct words for sunlit states (in English — day) and consecutive 24 hours (in English — nychthemeron, but it’s not commonly used).

Date/time representation:

Source: xkcd.com

When communicating with other systems, such as via REST API, it is important to agree about data formats. If you see a date displayed as 10/12/2021, it may be in either the US format (October 12th) or UK format (December 10th).

It is better to use some unambiguous representation!

For date and time, we have the ISO 8601 standard. Note that not only absolute date/times are standardized, but also periods. It is also important to use the proper type — local (for representing data like alarm clock triggering times or dates of birth) or zoned (for representing moments in time, like event starts or taking pictures).

Custom, non-standardized formats usually lead to confusion and bugs, so avoid them.

When displaying the date and time in the UI, you have to take the user’s locale into account. The displayed format depends on the language and region. Look at the following examples which all refer to the same date:

4/18/21 — US English
18/04/2021 — UK English
18.04.2021 — Romanian
١٨‏/٤‏/٢٠٢١ — Saudi Arabia, Arabic with Eastern Arabic numerals

There are predefined format types provided by date/time libraries, such as FormatStyle in java.time. Use them if possible. Otherwise, you can construct more customized formats using standardized pattern symbols. See the CLDR documentation for more details.

It is worth noting that, in the case of months, quarters, and days of weeks, there are also standalone variants. They are meaningful only in some languages (not in English). In Polish, for example, April is called kwiecień — this is a standalone version. However, if it connected with a day (eg. April 18th) the text becomes 18 kwietnia.

Wrap up

Dealing with dates and time is not straightforward. However, if you follow the standards described above and use proper types, you can avoid huge mistakes.

I hope my insight on dates and time edge cases will be useful in your projects. Good luck!

Originally published at https://www.thedroidsonroids.com on April 26, 2021.

How to Duplicate a Git Repository? Step-by-step Guide

Karol Wrótniak — Mon, 05 Aug 2024 16:55:20 +0000

Learn how to mirror a git repository in a few simple steps

Background

Before I describe how to duplicate a git repository, let me explain you the context. At Droids On Roids, we prefer using our own tools for CI/CD, VCS hosting and other processes. All our developers know them well, which speeds up development in comparison to using separate clients’ tools for each individual project.

Usually, it doesn’t matter what we are using internally. However, regarding the repository, clients may want to store the code on servers controlled by them. It’s perfectly understandable, since they usually also purchase the intellectual property, so they own the entire code.

Sometimes that hosting on the client side may be not perfect.

For example, it may use a different provider eg. GitLab instead of GitHub, which we use on a daily basis. Or it may even be a self-hosted Git server without any web interface accessible using only a single key.

How can we perform a code review process or setup webhooks for CI on something like that? Let’s see what we can do!

The cases

Firstly, the necessity to store the code in a particular place does not mean that it is the only location.

We can still use our favorite GitHub for daily development and only duplicate (mirror) the code to the client’s repository.

To do that efficiently, let’s first answer a few questions.

Do we need to mirror everything, or only the particular branches and/or tags?
What is the trigger for the mirror operation?

Usually, the client is only interested in some milestones/releases, rather than all the intermediate work. In such a case, we usually want to mirror only the main branch and maybe some tags.

Note that we are not taking any legal issues into account here. Check if there are no restrictions regarding the storage location in the contract. Sometimes it may be forbidden to push the code to public clouds.

The scope

Mirroring everything is possible but keep in mind that the target hosting configuration has to be compatible with the source.

For example, branches containing force pushed commits on the source must not be protected on the target. Pushing some constructs not used on the target side may also produce errors or warnings eg. Gerrit creates references (which are not necessarily pointing to branches or tags) which may not be understood by the likes of GitHub.

The trigger

Mirroring is often triggered when some milestone is reached, such as at the end of the iteration/sprint or just on the regular basis eg. weekly or daily. I would recommend doing that operation on a separate CI build, not the one which you even can have by occasion.

For example, even if you have a “sprint” build releasing the product, you should not add mirroring as one of its stages/steps. Why?

Well, you have no control over the target repository. If a repo becomes unreachable, someone revokes the key or pushes the same tag you want to push, then your mirroring will fail, even if the artifact was released successfully.

Moreover, the local copy used to build the product may not checkout a branch you want to mirror, but instead checkout a particular commit as a detached HEAD.

For example, on Bitrise CI a trigger associated with a push (to branch) action checks out the pushed commit. It was on the top of the branch at the point of triggering but at the time of building (cloning), new commits may appear after it, because there might be pushes in the meantime.

The code

Let’s start coding! Mirroring itself consist of 2 operations:

Cloning (or preparing an already cloned copy).
Pushing.

Getting access to the repositories by activating SSH keys, for example, is out of the scope but, if needed, it has to be performed before accessing the particular repository.

In case of the (recommended) fresh build, cloning looks like this for a single branch:

git clone --bare --single-branch --no-tags --branch=<branch name> <source url> .

Or like this for the entire repository:

git clone --mirror <source url> .

Where <branch name> is the name of the branch you want to clone, and <source url> is the source (not the target!) repo URL. Note the trailing dot! It means the current directory.

Make sure that it is empty. Some CI platforms may create some temporary files there or set the initial directory to something usually not empty, such as $HOME. In such cases, execute this command beforehand: pushd $(mktemp -d).It will create a temporary folder (with a unique, not occupied name) and change the current directory to it (like cd command).

Note also the --bare and --mirror options. They ensure no working directory is created. As a result, no head is checked out (it is useless when we don’t need to work directly on the repository content). That’s why the bare clone operation is faster than the normal clone. If you want to also push the tags, just remove the --no-tags option.

In order to send the changes to the target repository, you can use the git push command. In the case of a single branch, omit the –tags option if you don’t need to push the tags:

git push --tags <target url> <branch name>

Or for mirroring the entire repo:

git push --mirror <target url>

Be careful that such a push will also (try to) replicate all forced pushes and branch deletions! Some data may be practically lost after that operation. Restrictions enforced by hostings like protected branches or the inability to delete the default branch will still be held.

Make sure that the user on behalf whom the push is performed has the appropriate permissions. They must be able to write to the repo but should not have admin privileges!

Wrap up

Requirement to store the code in your client’s repository does not always mean you have to use their repository. You can simply synchronize your internal repo with your client’s one, using a few lines of the shell script.

Keep in mind that the push may fail (which should not affect the rest of your workflow) or irreversibly overwrite the data. I hope thanks to this article you will know how to duplicate a git repository. Good luck!

The post appeared first on Droids On Roids.

What does GDPR mean for Mobile App Owners? – 12 Use Cases

Karol Wrótniak — Mon, 05 Aug 2024 11:53:11 +0000

In this article, you will find 12 useful GDPR Use Cases for App Owners, Product Owners and everyone who wants to develop a mobile app. You will also read about the basics of GDPR – What it is, Who it’s directed to, How high penalties are and – the most important question – What does it mean for App Owners? Let’s check if your app is GDPR-compliant!

Article co-authored by Krzysztof Werner.

INTRODUCTION – BASICS ABOUT GDPR

What is GDPR?

The General Data Protection Regulation (GDPR) (EU) 2016/679 is a regulation in EU law on data protection and privacy. Its aim is to give explicit control over personal data to its subjects. The Regulation was adopted on April 27th, 2016 and it becomes enforceable from May 25th, 2018, after a two-year transition period.

So, May 25th, 2018 is a red-letter day for many companies. It’s a major change regarding data privacy.

Who is GDPR directed to?

Citizens of the entire EU, as well as Norway, Iceland, and Liechtenstein, will become the subjects of GDPR but the regulations will have a global impact for organizations.

If you are a company owner who processes the personal data of EU citizens or citizens of the aforementioned countries, GDPR applies to you. Even if your company is registered outside of the EU, Norway, Iceland, or Liechtenstein.

This means that you need to understand GDPR and start working on a plan to meet its requirements.

Controller, Processor, Data Subject & Data Protection Officer – definitions

Let’s explain a few definitions used in the GDPR world.

Controller (or administrator) – a natural or legal person which uses the data to achieve business goals. In our case, it is usually the application owner.
Data processor – a natural or legal person which processes the data on behalf of a controller. For example, 3rd party services like Google, Amazon, Fabric, HockeyApp and so on are all data processors. Sometimes collaborating/outsourced development companies may also be considered data processors.
Data subject – a natural person whose data is processed. Basically, in our case, it is an app user.
Data protection officer – a natural person designated by the controller or processor to help them and their users with GDPR compliance. This is only required if the amount of processed personal data is significant and/or such data is sensitive.

GDPR Penalties

The controller and processor are subject to administrative fines if they infringe the provisions laid out in the GDPR, even if the infringement is not intentional. There are two fine tiers.

a) Up to 10,000,000 EUR or up to 2 % of the annual turnover of the preceding year (whichever is higher) – for the controller, processor, monitoring body and certification body who infringe their obligations.

b) Up to 20 million EUR or up to 4% respectively – ** ** for a controller who infringes the principles of personal data processing. For example, personal data processing without user consent, data subjects’ rights infringements or transferring personal data to a non GDPR-compliant recipient in a third country.

You can find more details about these fines in Article 83 of the GDPR.

LET’S TALK ABOUT YOUR APP

We’re 100% office based team with 7-years’ experience

in mobile & web app development

Estimate project

WHAT GDPR MEANS FOR APP OWNERS

Never before have the needs of application users in this area been so strongly and comprehensively protected. This is why we have to take a fresh look at the way we plan and developing an app in order to fully meet GDPR requirements.

Note that the regulation itself does not contain any exact step-by-step guidelines. It only gives us a list of the general rules that we must keep in mind when creating software.

With this in mind, we can expect a legal approach based on precedents that will occur in the future and which we are not able to predict at this point. Until the first decisions of the courts appear in this matter, we can only presume in which direction the final interpretation of the regulations EU judges will take.

You must also be aware that the lack of adequate security of personal data may result in the outflow of users from your applications. What’s more, the appropriate protection of this need may be a magnet that will additionally attract users and customers.

So, this means that taking the appropriate preparation to meet GDPR standards becomes an added value for your business and can be reflected in future revenues. We hope that our guidelines, which you can read below, will help you to take advantage of these upcoming law changes.

We’ve analyzed several common use cases related to personal data processing in mobile app development and have prepared some guidelines for you. Let’s check them out!

USE CASES

1. I only have access to pseudonymous data from my app, for example, installation ID and other metrics on Google Analytics or similar tools.

What exactly do I have to do to become GDPR compliant?

Personal data are any pieces of information about a natural person or any personally identifiable information about that person which gives you the ability to identify them. You should always keep this in mind when you are planning your app development. It doesn’t matter whether the information is directly and closely related to a given person but it’s crucial if they have the ability to identify the person or not.

If the de-anonymization requires manpower and resources which are disproportionate to the information obtained, your solutions meet GDPR requirements.

2. I have an app where users can create content e.g. write comments or chat. They might put some personal data there. Does this matter in terms of GDPR?

Yes, it matters, and this should be taken into account during your app planning & development because, according to GDPR guidelines, each user has the right to request the deletion of personal data that could lead to his or her identification.

You have no influence whether your app’ users place someone’s else personal data within your application. Subjects whose personal data was published without their permission should have the opportunity to contact your Data Protection Officer (or the controller directly if there is no DPO). In such a case, they can send a request to delete such data from your system and you are obligated to provide them with such an option.

3. I use Google Analytics, Firebase, Crashlytics or HockeyApp as a 3rd party solution to support my development. Are they GDPR compliant?

You need to be sure that any 3rd parties solutions you use are GDPR compliant. You can confirm this in their Terms Of Service. For example, at the time we’re writing this post, Fabric claims to be ready for GDPR by May 25th, 2018.

GDPR resolution guidelines impose an obligation on us to check whether the services we use have security certificates in line with GDPR assumptions. According to regulations, we are jointly responsible for the leakage of personal data from third parties.

4. Am I obligated to have a written contract with every 3rd party that processes the data?

A written contract is not obligatory. The Regulations offer a certain amount of freedom here and also introduces a broader concept of “another legal act”.

What needs to be done to ensure that the contract or another legal act meets the requirements for GDPR? It’s simple. Check whether the provider whose services you will use has a certificate of compliance with GDPR. Certification is voluntary, but if you want to be sure whether the service provider is prepared to meet the requirements of GDPR, check whether it has such a certificate.

5. Do I need to have a Data Protection Officer on board?

No, you don’t have to. GDPR provides a certain freedom of choice in this regard.

The Data Protection Officer can be either an employee of the Controller or the Processor, as well as a person from outside the group of employees. This gives us some freedoms with our options and the ability to reduce costs.

The outsourcing model, based on a contract for the provision of services, can be adapted to our needs and scale. When it comes to the number of hours of cooperation, they can be significantly limited.

To sum up, you don’t have to create a DPO position in your company. You can engage a DPO from outside in accordance with your needs.

6. My application uses only emails and logins (without a first and last name). Does this count as personal data?

Yes, they do. There is no easy method of mass verification to see if e-mail address do or do not contain personal data. However, we use nicknames on many portals and it is possible to link them to other data.

We must remember that, whenever we are not sure if the elements of the application can help identify the user, we should assume that this is what can happen.

7. In the application, we log in with Facebook, Google etc. The app sends a token to the backend, which automatically reads the user’s ID (or e-mail address), but not the first and last name.

During the validity period of a token (30 min) I can theoretically use it to manually extract personal data. Does this violate assumptions laid out in the GDPR?

The answer to this question is very difficult. There will be no clear-cut answer.

We must accept, as in the first case, that any piece of information about a user which gives you the ability to identify a natural person may violate GDPR rules. On the other hand, we can also assume that this data must be obtained with reasonable expenses and costs, which slightly softens the tone of the previous rule. At present, we are unable to determine how the authorities will approach this.

8. I have a store app where personal data is needed for shipping. What should I include in my terms of service?

Store app terms of service must contain a clause indicating that all information about the subject that the consumer enters in the app (name/surname/phone number/address/e-mail and other), are protected. What’s more, the terms of service should also include a full list of user’s rights, such as the right to access, edit & delete their personal data, for example.

Moreover, you must have the user’s consent to process his or her personal data for the purposes of application functionality. So, in every app, there must be a simple way for the user to confirm their acceptance of these regulations. Furthermore, you have to be simple and clear about the regulations the users are accepting.

9. I have a bug reporting system in the app (like Crashlytics or HockeyApp) and personal information can be found there. Does it matter?

First of all, you need to be sure that your bug reporting service provider meets GDPR requirements.

What’s more, it is important what kind of data is included in the reports and who has access to them. With this in mind, we will be able to identify several different answers. Let’s consider 3 cases:

a) The people who view reports already have legitimate access to all the data (e.g. the company has its own development team) – bug reporting is irrelevant.

*b) Reported data is anonymous or pseudonymous *(so much so that, in a reasonable time and with sensible means, they cannot be de-anonymized). This way of reporting bugs is the best way to provide all the necessary data for the QA team and it meets the requirements of GDPR.

c) Reports contain personal data and we outsource the development team. In this case, the external company must become an entity that processes personal data, as defined by GDPR, or the reports must be filtered and possibly anonymized before transferring them.

10. Are my development team and QA team obligated to have any certificates or training on personal data protection?

No, they do not have to. The only person who is required to have specialist knowledge on this subject is the Data Protection Officer. As we mentioned above, he or she doesn’t even have to be a team member.

Of course, it will be highly advantageous for your business if your Dev and QA team have some knowledge about GDPR, as they can deliver compliant products faster and without violating GDPR rulings.

11. My app processes personal data (not specific data outlined in Article 9) but, on the basis of analytics or crashy reporting, it can be determined that a user is likely to have some dysfunction (e.g. he or she uses large text sizes, so they probably have poor eyesight).

Does Article 9 (processing of specific categories of personal data) apply to me?

No, it doesn’t. We are not dealing here with data that has been given, but with the assumption that it is so. In order to fully determine this, we would have to use significant work and resources, which means you are not in violation of the GDPR rules.

12. I’ve had a personal data leak in my system. What should I do?

You should report such a leak to the supervisory body within 72 hours after having become aware of it, unless you can prove that said leak doesn’t violate the rights or freedoms of natural persons. ** ** When the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.

This is one of the most significant changes that GDPR introduces. You can read more about it in Article 33.

LET’S TALK ABOUT YOUR APP

We’re 100% office based team with 7-years’ experience

in mobile & web app development

Estimate project

WRAP UP

GDPR is a major change regarding data privacy. It will have a significant impact on mobile applications owners.

On one hand, it introduces new, strict rules to abide by and brings changes to the app planning & development process. On the other hand, the appropriate protection of personal data can be a magnet for attracting app users & giving them a greater sense of security.

*In short, undertaking the appropriate preparation to meet GDPR standards can become an added value for your business. * We hope that our use cases will help you to take advantage of these upcoming law changes.

If you have any questions, leave a comment Good luck!

P.S. Stay tuned for the next article about GDPR which will be dedicated to development teams.

The post What does GDPR mean for Mobile App Owners? – 12 Use Cases appeared first on Droids On Roids.