- Client
- RE-AK Technologies, a neurotechnology company in Quebec
- Engagement
- Project delivery: DEVSFLOW owned the Android app end to end, then handed it over to RE-AK's engineer
- Product
- Vizia Mobile, the Android app for the Nucleus-Kit research kit
- Platform
- Native Android (Kotlin)
| Before | After |
|---|---|
| No mobile app for the research kit | One Android app records EEG, wristband, video and GPS together, in the field |
| An empty repository | Researchers recording real sessions within a month |
| Sessions of one to four hours, phone in a pocket | Recording keeps running with the screen off, with every stream on one clock |
| A new codebase built by an outside team | Handed over; RE-AK's engineer kept most of the code and keeps extending it |
< 1 monthfrom an empty repository to real research sessions
4 sourcesrecorded together, screen off, for 1–4 hours
Most code keptby RE-AK's engineer after the handover
“Great job Zawar Nadeem, I'm a very satisfied customer, thank you for making the Vizia Mobile app.”
The brief
RE-AK's Nucleus-Kit records how people respond in real-world settings, combining an EEG headset, a wristband, a point-of-view camera and the phone's GPS.
RE-AK asked for one Android app a researcher could take into the field: four sources recording at once, sessions of one to four hours with the phone in a pocket, and every session delivered to their cloud.
What was at stake
- A device that drops without the app noticing produces a session that looks fine and isn't.
- If Android stops the app mid-session, that participant's session can't be repeated under the same conditions.
- Field networks are unreliable. A failed upload can't mean a lost session.
Vizia Mobile screens
Our approach
Decision 01Give every device an explicit connection state
- Context
- With several devices connecting and dropping independently, ad-hoc status flags drift out of sync with reality.
- Decision
- One state machine per device as the single source of truth for connected, reconnecting and failed, read by every screen.
- Tradeoff
- More structure up front for each new device type, in exchange for one place to reason about connection behaviour.
Decision 02Serialize every Bluetooth operation
- Context
- Android Bluetooth fails quietly when operations overlap, and with two devices streaming at once, overlaps are constant.
- Decision
- Route every Bluetooth operation through a single queue.
- Tradeoff
- Slightly slower device setup, in exchange for removing a class of failures that are very hard to reproduce.
Decision 03Design for the screen being off
- Context
- Android stops background work whenever it can, and a session runs with the phone in a pocket.
- Decision
- Treat screen-off recording as the normal case from day one, not a feature added later, with one clock across all streams.
- Tradeoff
- More platform work early on, in exchange for sessions that survive real field conditions.
How we worked with the team
- End-to-end ownership. We took the app from an empty repository to field use, including integration with the headset from its hardware specification.
- Built to be handed over. Clear layers and conventional Android architecture, so someone else could own the code.
- A clean handover. RE-AK's engineer took the app over, kept most of the code and has continued to extend it.
For your tech lead
The technical patterns behind this work are written up in our own engineering notes, without client detail:
Next step
Building a hardware-connected product that needs a mobile app engineered properly from the start? Tell us about the device and the data.
Book a 30-minute technical callor email info@devsflow.ca