Explain state and the next action
The Android app had to remain timely and useful without pretending it owned connector or order truth.
Android Engineering · TAU EV charging
EV charging state the driver can trust.
A complete Android client for station discovery, connector reservations, queues, payment-method enrolment and a guided physical charging lifecycle.
SpecialtyAndroid Engineering
Formal role or capacitySole Android Engineer
Personal scopeAndroid client from initial implementation through the final product iteration
SystemREST · GraphQL · polling · local timers
01 · context
The backend controls a physical process.
A connector can be busy, a reservation can expire, another driver can be ahead, and the station decides when charging actually starts.
Authoritative business state
Queue position, order transitions, plug detection and charging status remain server-controlled.
02 · ownership
One Android engineer, one complete driver journey.
The scope extends from discovery and profile management through payments, charging completion and production monitoring.
Find the right connector
- Custom map and list
- Connector and service filters
- Private/fleet locations
- Station details and ratings
Reserve or queue
- Future slots
- Connector queue
- Payment-method enrolment
- Cancellation and expiry
Guide charging
- Start order and insert plug
- Backend confirmation
- Progress and time left
- Completion and feedback
03 · system
Different transitions need different synchronisation mechanisms.
The backend stays authoritative while the client combines polling, subscriptions and local timers for responsive foreground behaviour.
5-second polling
Queue turns and terminal order states are refreshed against backend truth.
→
GraphQL subscription
Order-status transitions arrive through a WebSocket-backed subscription.
→
Local timers
Reservation and charging timers update locally between authoritative server events.
04 · decisions
Design the failure paths as part of the journey.
Charging is not one optimistic request. Each stage can expire, reject, disconnect or require recovery.
Restore active queues and orders
Application restarts must not erase a physical session already known by the backend.
Separate local time from business truth
Timers keep UI responsive, while server state decides transitions.
Guide the physical next action
Station and EVSE identifiers, plug instructions and progress reduce ambiguity at the charger.
Encrypt payment fields on device
Card fields were encrypted client-side using BlueSnap’s integration before submission to the backend.
Keep the backend boundary explicit
The final backend authorisation, capture, settlement, and refund rules are not claimed because the Android evidence does not establish them.
05 · evidence
The product flow is visible in authentic Android screens.
Approved screenshots were cleaned only for debug/private presentation noise; no product behaviour was invented.
06 · outcome
An end-to-end Android client for a backend-controlled physical journey.
The Android client covered station discovery, reservations, queues, payment-method enrolment, charging progress, completion, and recovery paths.
OWNERSHIP
Android application from first implementation through the final product iteration.
TECHNICAL DEPTH
Maps, queues, mixed synchronisation, payments and physical-state failure handling.
BOUNDARY
Backend state and other platforms remained collaborator-owned.
Evidence & NDA boundaryThis case uses approved public visuals and a sanitised technical narrative. Private source, endpoints, credentials, configuration, customer data, and proprietary schemas are excluded. The original work-group video and audio are also excluded.
Work together
Explore a role or project
Target role · Staff Mobile Engineer (Android + Flutter)
Worldwide remote · English / Russian
Novi Sad, Serbia · hybrid possible