📌 SYSTEM INSTRUCTIONS — IMPLEMENT LIVE SOS LOCATION
You are working in an existing production codebase.
Context
Backend: Python (FastAPI-style), SQLAlchemy, existing SOS + FCM logic
Mobile: Flutter (Android primary)
SOS currently stores static lat/lon and uses polling + FCM
Goal: add Life360 / Google Maps–style live location sharing
Constraint: NO new cloud services, NO new databases, NO polling
Transport: WebSockets
Persistence: DB only for incident lifecycle, not live motion
Backend Tasks (MANDATORY)
Add a WebSocket endpoint
Path: /ws/sos/{incident_id}
Auth: reuse existing auth (bearer / session)
Reject if incident is not status == "open"
Connection lifecycle
On connect:
register socket under incident_id
On disconnect:
remove socket safely
Use in-memory structure:
Dict[incident_id, Set[WebSocket]]
Message contract (JSON)
{
"lat": float,
"lon": float,
"h3": string,
"accuracy": float,
"timestamp": ISO-8601 string
}
Broadcast logic
DO NOT write each update to SQL
Simply rebroadcast message to:
all responders
incident originator
Drop message if incident is closed/cancelled
Optional (safe) persistence
At most once per 60–120 seconds:
update SOSIncident.lat/lon/last_activity_at
Never persist full trails
Error handling
Silent drops on bad payloads
Never crash the server loop
Mobile (Flutter / Android) Tasks (MANDATORY)
Foreground Service
Start when SOS becomes active
Stop on cancel / auto-close
Required to survive screen lock
Socket lifecycle
Open WebSocket when _created != null && status == open
Close when SOS ends
Reconnect with backoff if network drops
Location update policy
Send update if:
moved > 25–30 meters OR
5–10 seconds elapsed
Include GPS accuracy
Viewer behavior
Nearby responders:
subscribe to socket
animate marker smoothly
maintain short breadcrumb trail (last ~20 points)
NO polling
Disable _refreshNearby() while socket is active
FCM remains only for:
SOS started
responder joined
SOS cancelled
Explicit Constraints (DO NOT VIOLATE)
❌ Do NOT add Redis, SignalR, Pub/Sub, Kafka
❌ Do NOT store raw location streams in DB
❌ Do NOT introduce new cloud resources
❌ Do NOT increase backend polling
❌ Do NOT send location via FCM
Acceptance Criteria
Live marker moves smoothly like Google Maps
Works with screen locked (Android)
Server memory usage stable
No increase in DB write rate
Existing SOS + FCM logic remains untouched
Deliverables
Backend WebSocket implementation (clean, isolated)
Flutter service + socket client
Minimal changes to SOS screen UI
Comments explaining lifecycle decisions
Tone
Write production-grade code.
Prefer clarity over cleverness.
Assume this system handles real emergencies.
📌 SYSTEM INSTRUCTIONS — IMPLEMENT LIVE SOS LOCATION
You are working in an existing production codebase.
Context
Backend: Python (FastAPI-style), SQLAlchemy, existing SOS + FCM logic
Mobile: Flutter (Android primary)
SOS currently stores static lat/lon and uses polling + FCM
Goal: add Life360 / Google Maps–style live location sharing
Constraint: NO new cloud services, NO new databases, NO polling
Transport: WebSockets
Persistence: DB only for incident lifecycle, not live motion
Backend Tasks (MANDATORY)
Add a WebSocket endpoint
Path: /ws/sos/{incident_id}
Auth: reuse existing auth (bearer / session)
Reject if incident is not status == "open"
Connection lifecycle
On connect:
register socket under incident_id
On disconnect:
remove socket safely
Use in-memory structure:
Dict[incident_id, Set[WebSocket]]
Message contract (JSON)
{
"lat": float,
"lon": float,
"h3": string,
"accuracy": float,
"timestamp": ISO-8601 string
}
Broadcast logic
DO NOT write each update to SQL
Simply rebroadcast message to:
all responders
incident originator
Drop message if incident is closed/cancelled
Optional (safe) persistence
At most once per 60–120 seconds:
update SOSIncident.lat/lon/last_activity_at
Never persist full trails
Error handling
Silent drops on bad payloads
Never crash the server loop
Mobile (Flutter / Android) Tasks (MANDATORY)
Foreground Service
Start when SOS becomes active
Stop on cancel / auto-close
Required to survive screen lock
Socket lifecycle
Open WebSocket when _created != null && status == open
Close when SOS ends
Reconnect with backoff if network drops
Location update policy
Send update if:
moved > 25–30 meters OR
5–10 seconds elapsed
Include GPS accuracy
Viewer behavior
Nearby responders:
subscribe to socket
animate marker smoothly
maintain short breadcrumb trail (last ~20 points)
NO polling
Disable _refreshNearby() while socket is active
FCM remains only for:
SOS started
responder joined
SOS cancelled
Explicit Constraints (DO NOT VIOLATE)
❌ Do NOT add Redis, SignalR, Pub/Sub, Kafka
❌ Do NOT store raw location streams in DB
❌ Do NOT introduce new cloud resources
❌ Do NOT increase backend polling
❌ Do NOT send location via FCM
Acceptance Criteria
Live marker moves smoothly like Google Maps
Works with screen locked (Android)
Server memory usage stable
No increase in DB write rate
Existing SOS + FCM logic remains untouched
Deliverables
Backend WebSocket implementation (clean, isolated)
Flutter service + socket client
Minimal changes to SOS screen UI
Comments explaining lifecycle decisions
Tone
Write production-grade code.
Prefer clarity over cleverness.
Assume this system handles real emergencies.