The atmosphere in the room was dense, the kind where every whisper echoes.
I was sitting in the third row of a local community center during a Friday prayer session, my head bowed in reflection.
Suddenly, a high-pitched, synthetic ringtone shattered the silence.
My pocket vibrated violently, sending a jolt of anxiety through my chest.
I scrambled to silence it, but the damage was done; a dozen heads turned in my direction.
I wasn't just embarrassed; I was frustrated with myself for the thousandth time for forgetting the simple task of toggling a silent switch.
This wasn't an isolated incident.
I found myself constantly caught in a cycle of human error.
I would arrive at the office, launch into a deep-work sprint, and realize two hours later that my phone had been chirping with notifications through three separate meetings.
Then, I would leave the office and forget to turn the ringer back on, missing urgent calls from family throughout the evening.
The friction wasn't in the hardware; it was in the expectation that a human should perfectly manage a state machine that they interact with hundreds of times a day.
I realized that my phone was intelligent enough to track my location, calculate prayer times, and sync my schedule, yet it remained stubbornly passive regarding its own audio profile.
Most existing automation tools were either too heavy, draining the battery within hours, or relied on cloud-based triggers that failed the moment I lost signal.
I wanted something that lived on the device, respected the user's privacy, and handled the transition between 'Silent', 'Vibrate', and 'Normal' states without me ever needing to touch the screen.
The goal was simple: build a background service that watches the world and adjusts the phone's volume automatically.
I needed an architecture that could handle geofencing, calendar events, and time-based triggers without turning the device into a space heater.
When I started building the geofencing engine for Muffle, the immediate temptation was to use with constant .
I quickly realized that was a recipe for a battery disaster.
Instead, I pivoted to the API from Google Play Services.
This API is purpose-built to offload the heavy lifting to the system.
By defining a with a set of objects, I could delegate the monitoring to the OS level.
The OS uses a combination of Wi-Fi, cell towers, and GPS to track the device, batching events so my application code only wakes up when a boundary is crossed.
However, the standard wasn't enough on its own because of how aggressive Android's Doze mode has become.
If the system kills my process, the broadcast receiver that listens for geofence transitions might never fire.
I had to implement a that stays alive even when the app is swiped away.
The challenge was ensuring that the service didn't consume excessive memory while remaining responsive to these transitions.
I structured the interaction like this: kotlin val geofenceRequest = GeofencingRequest.Builder().apply { setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER) addGeofences(geofenceList) }.build() geofencingClient.addGeofences(geofenceRequest, geofencePendingIntent) .addOnSuccessListener { /* Successfully registered / } .addOnFailureListener { / Handle registration error */ } By keeping the logic lightweight, I ensured that when a transition occurs, the app wakes up, executes the commands, and goes back to sleep almost instantly.
The key technical tradeoff was between accuracy and battery life.
I leaned heavily toward battery efficiency, acknowledging that a 50-meter variance in a geofence trigger is a fair price to pay for a device that lasts through a full day of usage.
I used to prevent rapid fire toggling when a user is sitting right on the edge of a boundary, which would otherwise flicker the sound profile like a strobe light.
What surprised me most during this process was how unreliable GPS can be inside high-density urban environments.
I originally assumed that if I drew a tight circle a