Flutter application
Accounts, saved routines, powernaps, playback controls and responsive state across Android and iOS.
TECHNICAL CASE STUDY / CXR STRATEGIES LLC
The mobile layer
of a connected
sleep system.
A Flutter application that coordinates audio, timed routines and wearable device controls across Android and iOS.
ROLEMobile Application Developer
PERIODJune 2023 to present
SCOPEMobile application and device integration
01 / ENGINEERING PROBLEM
APPLICATION + DEVICE + AUDIOKeeping several systems
in sync.
A sleep routine spans three domains: what the person hears, what the device does, and what the application shows.
Those domains advance on different clocks. Audio has playback and lifecycle state; Bluetooth has connection and notification state; a routine has phases and saved settings. The practical challenge is to make them behave as one coherent interaction, including when a device disconnects or a user changes a setting during a transition.
This is an engineering account of the mobile implementation. It does not make claims about clinical efficacy or measured sleep outcomes.
02 / SYSTEM MODEL
One product.
Three coordinated layers.
Timers, streams and state
Reactive state management and Dart streams coordinate routine phases, UI updates, audio and device commands.
Bluetooth protocol
GATT discovery, characteristic writes and notifications carry commands and device state.
FIREBASE / AUTHENTICATION + STORED ROUTINESAUDIO / BACKGROUND PLAYBACK + LIFECYCLE
03 / MY CONTRIBUTION
JUNE 2023 TO PRESENTApplication ownership
from interface to integration.
I developed the mobile application functionality: authentication and user settings, connected device flows, saved routines, evening and morning sequences, powernaps, audio controls and app side firmware update flows. I collaborated with hardware engineers on command behaviour and device integration. Firmware and hardware programming were outside my role.
Bluetooth communication
Implemented scanning and device filtering, GATT service and characteristic discovery, write mode selection, notification subscriptions and reconnection behaviour. Connection state feeds the application so controls reflect device availability.
Routine orchestration
Built timed phases that adjust audio, light intensity, lens tint and volume together. Interpolation produces gradual transitions while pause and manual overrides preserve user control.
State and persistence
Used reactive state management and Dart streams to synchronise UI updates, device state and asynchronous application workflows. Firebase Authentication and user scoped Firestore data support accounts and stored routines.
Device commands and updates
Encoded settings into device specific byte commands, mapped values to supported ranges and avoided redundant writes during transitions. Implemented the application side of firmware update workflows.
04 / INTERACTIVE EXPLANATION
A routine as a
coordinated sequence.
Select a phase to see the relationship between playback, application timing and device controls.
ROUTINE PHASEWind downAudio + light + tint
EXPLORE THE SEQUENCE
Audio and device settings transition together as the routine begins.
CONCEPTUAL DIAGRAM / NOT A LIVE DEVICE CONNECTION05 / DEVICE CONTROL DEMOS
From app interaction
to device response.
Recorded product demonstrations showing the Flutter application controlling connected SleepSanity hardware in real time. Each clip documents an application level device interaction.
01 / CONNECTION
Connected device control
Mobile controls send state changes to the connected hardware.
02 / SETTINGS
Live routine controls
Interface adjustments drive device settings during a session.
06 / ENGINEERING EVIDENCE
DIAGNOSTIC TOOLINGMake device behaviour
observable.
I built separate Flutter tooling for accelerometer and gyroscope characterisation before gimbal PCB integration. The application lets the team compare sampling frequencies and measurement ranges, inspect raw BLE packets and count received notifications over timed windows.
The purpose was to identify suitable sensor settings while distinguishing acquisition rate from transport throughput. Configurable ranges, including accelerometer settings from ±2g to ±16g, gave the team a way to examine motion sensitivity and dynamic range alongside BLE delivery behaviour.
Explore the sensor characterisation project →TECHNICAL PERSPECTIVE
A reliable interface depends
on the systems beneath it.
The substantive work was not a single screen or feature. It was the coordination of device commands, background audio, timed phases, persistent settings and application state into a usable mobile product.
CASE STUDY / CXR STRATEGIES LLC / AAZIQ ALI SHAHCONTACT / AAZIQ ALI SHAH OPEN TO MOBILE ROLES
Build something
that works.
Flutter, connected devices and the interfaces between them. If that fits what your team is building, I would be glad to hear from you.