Opening hook
The silence in the mosque was absolute, save for the soft, rhythmic recitation of the congregants. I was kneeling, focused on the prayer, when a harsh, metallic notification ping echoed through the hall. It was loud, unexpected, and undeniably mine. My face burned with embarrassment as I reached into my pocket, fumbling to kill the sound. I had arrived in a hurry and completely forgotten to toggle my phone's profile. That specific, sinking feeling of being the source of a public disruption is what triggered my journey into building Muffle.
The problem
We live in a world of constant digital interruption. We carry our phones everywhere, yet our sound profiles are notoriously static. We manually toggle Silent, Vibrate, or Do Not Disturb modes throughout the day, yet we are human—we forget. Whether it is a lecture hall, a meeting room, or a place of worship, the friction of remembering to silence a device is a universal pain point. Existing solutions often felt bloated or relied on heavy, cloud-based triggers that ate battery life for breakfast. I wanted an experience where my phone felt like an extension of my intent rather than a loud, buzzing nuisance. The issue isn't just that phones are loud; it is that they lack the context of where we are and what we are doing. I needed a way to automate this context without the phone dying by noon. I didn't want a system that queried GPS coordinates every thirty seconds; I wanted a robust, battery-efficient engine that could handle location-based sound triggers silently in the background.
The technical decision / implementation
When I started building the geofencing component for Muffle, the immediate temptation was to write a background service that listened to LocationManager updates. That is a trap. Requesting high-accuracy GPS fixes continuously is the fastest way to decimate a user's battery life and get your app killed by the Android system. Instead, I pivoted to the GeofencingClient within the Google Play Services Location API. This API is designed specifically to offload the heavy lifting of location monitoring to the OS level. By defining circular regions (geofences), the system handles the proximity calculations at the hardware abstraction layer rather than at the application level.
To make this work reliably, I had to be extremely careful with how I registered these geofences. I opted to use a PendingIntent to handle the transition events. This allows the system to wake up my application only when a boundary is crossed, rather than forcing my app to stay active in the background. Here is the simplified structure of how I register these triggers:
kotlin
val geofence = Geofence.Builder()
.setRequestId(id)
.setCircularRegion(lat, lng, radius)
.setTransitionTypes(Geofence.GEOFENCE_TRANSITION_ENTER or Geofence.GEOFENCE_TRANSITION_EXIT)
.setExpirationDuration(Geofence.NEVER_EXPIRE)
.build()
geofencingClient.addGeofences(request, geofencingPendingIntent)
.addOnSuccessListener { /* Logged locally */ }
This architecture shifted the power consumption from my code to the system's specialized hardware sensors. By setting setExpirationDuration to NEVER_EXPIRE, I ensured that the geofence persists even if the device reboots, provided I handle the BOOT_COMPLETED broadcast. The trade-off here was precision versus power. By using a slightly larger radius, I allowed the system to trigger the event even if the GPS signal was somewhat imprecise, which is far better for a user than having the silent mode fail to activate because of a three-meter margin of error in a dense urban environment.
What surprised you / what you'd do differently
What surprised me most during development was the sheer volatility of how different Android manufacturers handle background processes. I assumed that a ForegroundService with a persistent notification would be enough to keep the engine running, but I was wrong. Some OEMs have aggressive battery optimization layers that kill everything, including foreground services, if the app hasn't been opened in a specific timeframe. My early implementations failed on older devices because the geofencing service would simply vanish after the phone sat idle for a few hours. I learned that you cannot rely on a single mechanism.
I had to implement a watchdog pattern that checks for the existence of active routines every time the system fires a wake-up event or when the user interacts with the app. Another major surprise was how GPS behaves indoors. I initially set the geofence radius to 50 meters, thinking it was precise enough. In practice, due to signal bounce in concrete buildings, the trigger would fire intermittently. I had to increase the radius to 150 meters and implement a 'debounce' logic in the state manager. If I were to build this again from scratch, I would move away from relying purely on GPS for all location types. I would integrate Wi-Fi SSID monitoring as a secondary trigger. A GPS signal is often garbage inside a large office building, but detecting the office Wi-Fi network is rock-solid. Combining the two would have saved me weeks of debugging location 'flickering' where the phone would toggle between normal and silent as it thought I was walking in and out of a 50-meter circle.
Practical takeaway
If you are working on location-aware features, my biggest advice is to respect the hardware limitations. Don't fight the operating system; work with the APIs that the OS provides for power management. The Android GeofencingClient is there for a reason, and trying to build your own location listener using standard GPS coordinates is a recipe for user frustration and battery drain. Always prioritize user intent over pure technical accuracy. A slightly wider geofence that works reliably is infinitely better than a high-precision geofence that fails when the user is in a parking garage.
Focus on modularity. By keeping your trigger logic separated from your sound management logic, you can swap out providers—like moving from GPS to Wi-Fi SSID—without having to rewrite your entire state management system. This modular approach is exactly how I built Muffle, allowing it to handle everything from prayer times to standard calendar events without breaking a sweat. If you are curious about how the final implementation looks in production, you can see how I structured these components at https://play.google.com/store/apps/details?id=com.muffle.app. Remember, the best automation is the kind that the user never has to notice because it just works.
Top comments (0)