- Client
- CLEIO, a health technology company that builds companion applications for EEG headsets
- Engagement
- Embedded: one senior Android engineer inside CLEIO's team. CLEIO owns the roadmap and technical direction
- Status
- Ongoing
- Platform
- Native Android (Kotlin)
| Before | After |
|---|---|
| Device hardware not yet available to the team | Device features built and tested weeks before hardware arrived |
| A crash mid-study put a multi-day recording at risk | No study lost to an app crash since the crash-safe lifecycle shipped |
| Data missed during disconnections | Missed data detected and recovered automatically |
Weeksof device work done before the hardware arrived
No studies lostto app crashes since the crash-safe lifecycle shipped
2–3 daysper recording, protected against crashes and dropouts
“…a dependable, communicative, and professional consultant…integrated smoothly into the project team, ramped up on the project context efficiently, and consistently delivered against the cadence set by the client.”
The brief
CLEIO was building a tablet companion app for a wearable EEG device, used to run clinical recordings that last two to three days.
CLEIO's Android team needed another senior engineer who could work in Bluetooth and hardware-connected code from the first week, inside their existing process.
What was at stake
- A crash on day two of a three-day recording can mean bringing the patient back and starting again.
- Gaps in a clinical EEG recording can make it unreadable for the clinician reviewing it.
- Without hardware, every device feature would wait on the device.
Our approach
Decision 01Simulate the hardware before it exists
- Context
- The device wasn't available yet, and every device feature needed something realistic to run against.
- Decision
- A realistic simulator behind the same interface the app uses for the real device, able to replay real data and inject faults such as dropouts. QA can run scenarios without touching code.
- Tradeoff
- A second component to maintain, kept in step with the device protocol.
Decision 02Make the study's state explicit and durable
- Context
- A multi-day recording passes through several stages, and a crash at any point must not lose its place.
- Decision
- One state machine for the study, saved on every transition, so the app resumes exactly where it stopped.
- Tradeoff
- Every new feature has to declare which states it is valid in. In return, the whole app agrees on where the study is.
Decision 03Treat missing data as normal
- Context
- The tablet and the device will sometimes be apart during a multi-day recording.
- Decision
- Detect gaps and recover them from the device, instead of assuming a continuous stream.
- Tradeoff
- More moving parts in the data path, in exchange for gaps that are visible and recoverable instead of silent.
How we worked with the team
- Inside CLEIO's process. Their repository, two-week sprints, standups and code review. CLEIO kept the roadmap and technical ownership.
- Small, reviewable changes. Single-purpose pull requests, each through static analysis and review.
- Raised the team's bar. Introduced pull request templates, so every change states what changed, why and how it was tested, and added coding standards to the team's guidelines.
- Tools the whole team uses. The simulator, and a switch between simulated and real hardware with no rebuild.
- Ongoing. The engagement continues inside CLEIO's team.
For your tech lead
The technical patterns behind this work are written up in our own engineering notes, without client detail:
Next step
Need a senior engineer who can work in Bluetooth and hardware-connected code from the first week? Tell us about your team and the device.
Book a 30-minute technical callor email info@devsflow.ca