It happened during a quiet midday prayer. The mosque was silent, the atmosphere heavy with focus, and then—the unmistakable, high-pitched trill of a ringtone ripped through the air. Everyone turned. I felt my face flush crimson as I fumbled for my device, frantically hitting the side button to silence it. It was a standard, generic notification, but in that space, it felt like a siren. I had been meaning to silence my phone for an hour, but the busyness of the morning had completely pushed the thought out of my head. That was the moment I realized the manual approach to phone management was broken.
We live in an age where our devices are supposed to be smart, yet they consistently fail at the most basic context-aware tasks. We rely on calendar apps that require sync, or location tools that ping cloud servers constantly, creating a dependency chain that fails the moment you step into a basement or lose data coverage. The problem isn't just that we forget to hit a mute switch; it is that the current ecosystem forces us to treat our devices as active participants in a network-dependent loop. If the server is down or the signal is weak, the automation breaks. For something as sensitive as a place of worship, a courtroom, or a medical clinic, that latency or failure is unacceptable. I needed a system that functioned entirely on-device, independent of any external ping, cloud heartbeat, or API authorization token.
When I started building Muffle, I decided that the core logic had to reside entirely within the sandbox of the user's device. For geofencing, this meant avoiding third-party mapping SDKs that often require heavy network handshakes for tiles or search results. I utilized the native GeofencingClient from the Google Play Services location library, but I had to wrap it in a custom logic layer to ensure it respected my offline-first constraints. The challenge was not just triggering the event, but managing the state transitions when the device enters or exits a defined radius. I had to handle the PendingIntent triggers while ensuring the AudioManager service could perform the volume switch even when the screen was off and the app was in the background.
kotlin
val geofencingRequest = GeofencingRequest.Builder().apply {
setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER)
addGeofence(geofence)
}.build()
geofencingClient.addGeofences(geofenceRequest, geofencePendingIntent).run {
addOnSuccessListener { /* Geofence added locally / }
addOnFailureListener { e -> / Handle registration failure */ }
}
By leveraging the BroadcastReceiver pattern to listen for the Geofence.GEOFENCE_TRANSITION_ENTER intent, I was able to trigger my AudioManager calls without a single network request. The difficulty here lies in the Android Doze mode and app standby buckets. If the OS decides to kill the background process to save battery, the geofence transition might be delayed or ignored. I had to implement a ForegroundService to keep the context alive, which ensures that the OS treats the app as an active participant. This is a deliberate architectural tradeoff: I am choosing to use a small amount of extra battery to ensure that the phone actually silences when it is supposed to. In my testing, I found that relying on standard background work managers often resulted in a 30-to-60-second delay, which is an eternity when you are walking into a meeting room.
What surprised me most during this development cycle was how fragile the LocationManager and the underlying FusedLocationProvider can be when you strip away the network-assisted location (NLP). I initially assumed that GPS would be enough. I was wrong. If you are indoors, GPS often fails to lock, and without Wi-Fi scanning enabled for location, the geofence simply wouldn't trigger. I had to build a fallback mechanism that checks for passive location updates and uses the last known location if the active scan times out. It wasn't in the documentation, but I realized that users often have varying levels of location permissions granted or restricted. My app had to handle the 'permission denied' state gracefully rather than crashing or hanging in a waiting loop.
Another non-obvious hurdle was the conflict resolution. What happens if a user sets a location-based routine and a time-based routine that overlap? I spent an entire weekend debugging a loop where the phone would switch to silent, then immediately back to vibrate because the system clock triggered a routine that hadn't finished its cycle. I had to implement a priority integer for every routine. If a routine is currently 'active,' it locks the volume state until it is explicitly finished, even if a lower-priority routine tries to fire. It is essentially a Mutex for your phone’s volume settings. I would definitely change how I handle the 'Emergency Bypass' contacts in the future. Currently, it is a static list, but I would love to integrate it with the Android NotificationChannel importance settings to allow for more granular control over which notifications 'punch through' the silence.
If you are building an offline-first tool, your biggest enemy is the assumption that the system APIs will always behave in a predictable, linear fashion. They won't. You have to write defensive code that assumes the location signal is dead, the battery is being throttled by the OS, and the user has just changed their phone settings under your feet. The goal is to move the complexity away from the user and into your handling logic. It is much better to fail silently and retry than to prompt the user with an error message in a quiet room. The beauty of local-only storage is that it respects the user's privacy and keeps the app functional regardless of their data plan or regional connectivity. It is a cleaner, more respectful way to design software.
When I look at the app today, I see a solution that fixes that initial embarrassment I felt in the mosque. By keeping the logic local and the triggers robust, I have created a tool that I personally use every single day to manage my own sanity. If you are interested in how these routines look in practice or want to try the implementation for yourself, you can find the project here: https://play.google.com/store/apps/details?id=com.muffle.app. It is a work in progress, but it has definitely changed the way I interact with my device in public spaces.
Top comments (0)