Most location apps are built around persistence.
Always-on.
Always-visible.
Always-running.
When I started building WIN RAK, I wanted the opposite.
Not because continuous tracking is technically bad.
But because most real-world location needs are temporary.
Short.
Situational.
Human.
That changes the architecture completely.
The Traditional Model
Most apps work like this:
User A opens the app.
User B is visible.
Simple.
But under the hood:
- background location stays active
- battery drains continuously
- privacy stays permanently exposed
- backend receives constant updates
This creates a heavy system.
And often an unnecessary one.
WIN RAK Uses Request-Based Sessions
WIN RAK works differently.
Instead of constant presence:
it uses temporary live sessions.
Flow:
Request → Approval → Live Session → Session End
That means:
location only exists when needed.
This makes everything lighter.
Real-Life Example: “I’m Almost There”
Everyone knows this one.
Your friend says:
“I’m almost there.”
But he just woke up.
Still in bed.
Not moving.
With WIN RAK:
you send a location request.
He accepts.
You instantly know.
No guessing.
No fake ETA.
No argument.
Just reality.
Flutter Architecture Challenges
This model creates specific technical problems.
Unlike passive apps:
WIN RAK must be extremely fast.
That means:
- fast notification delivery
- fast approval path
- fast GPS lock
- fast map rendering
Everything must happen in seconds.
Not minutes.
Handling Contact Discovery Efficiently
One challenge was contact recognition.
WIN RAK scans contacts and detects which ones already use the app.
This improves onboarding dramatically.
Instead of manually adding everyone:
the app suggests them automatically.
That required:
- normalization
- local snapshots
- delta sync
- efficient server reconciliation
All while keeping memory low.
Battery Matters
A lot.
This is one of the biggest reasons I chose request-based architecture.
If no request exists:
WIN RAK does almost nothing.
That means:
- less CPU
- less network
- less GPS
- less wakeups
This is healthier for devices.
Especially older phones.
Why This Model Scales Better
Temporary sessions scale better socially.
Not just technically.
Because they respect relationships.
Your partner doesn’t need your location all day.
But maybe:
they worry when you’re late.
Or you’re working.
Or unreachable.
That’s where WIN RAK fits.
Not surveillance.
Coordination.
That distinction is the foundation of everything.
WIN RAK is still evolving.
But one thing is clear:
location sharing should be event-driven.
Not permanent.
Top comments (0)