andy
Check out Part 1 of the series if you missed it.
At the heart of this project lies a core idea: this isn’t another alarm app; it’s about augmenting existing apps with enhanced functionality and better content for the alarms. But before delving into the details, the foremost concern is the actual viability of the concept.
In contemplating feasibility, it’s crucial to consider not only technical possibility but also the practicality of execution. Can I hack together an MVP in a week during the holiday break? Otherwise, it’s not worth my time.
My approach begins with a pragmatic brick-and-mortar proof of concept. I aim to manually simulate the entire flow to identify potential issues. This isn’t about perfection; it’s more about holding the pieces together with scotch tape and move them just enough see when they fall apart. Is there any gold in this river?
Breaking down the solution into phases, I identify some potentially critical elements:
- Gathering information from diverse sources (integrations are never easy).
- Steering the process via personalized settings (retrieval-augmented generation, prompt engineering).
- Generating content and transforming it into audio (generative AI, text-to-speech).
- Setting the audio as the alarm (event-driven messaging).
Research into available APIs for weather, news, Google Calendar, and Google Tasks suggests that most steps are viable. APIs for weather (openweathermap looks good) and news (the Guardian) are abundant, and Google’s APIs seem to function smoothly.
The next phase involves inference using a language model, fine-tuning via retrieval augmented generation (RAG), and text-to-speech generation. In a more serious setting I would have ran my own inference in a private setup. For this proof of concept, OpenAI’s APIs seem robust enough to serve these needs.
However, the hurdle emerges when considering setting the generated audio as the alarm without user intervention. The idea of creating a new “Alarm manager” app seems redundant given the multitude of existing apps, their limitations, and reliability issues.
Instead, I explore leveraging the default alarm app on my device—in this case the Samsung Clock app, but the concept really applies to any other manufacturer. This prompts a less ortodox idea—it’s always been possible to set one’s own audio files as ringtone or alarm. What if I could manipulate a custom audio file to dynamically change the alarm content?
My nostalgia for the days of MP3 players leads me to consider using a custom MP3 file as the alarm sound, dynamically replaced by my backend whenever needed.
Let’s say I choose a file named “not-an-alarm.mp3” as my alarm sound. It doesn’t really matter from which alarm app I do that, but let’s say I do it from the default clock app on my phone. Theoretically, once I selected a file (or really, a file path), the alarm app should not have a clue if I go and dynamically replace that file with another one. As long as the file path exists, everything should keep working without issues.
That would be too good to be true, of course. What I notice almost immediately is that Android (or at least my Samsung Galaxy) copies the audio files you use for ringtones and alarms to a predefined folder. Good architectural choice, I guess, they wanted to prevent you from deleting your ringtone by mistake, which slightly complicates my plan.
After tinkering and delving into Android’s file system, well, the answer was really in front of my eyes all along. Turns out the folder where they copy the audio file (“Internal storage/Alarms”) isn’t some forbidden system owned location, it can be accessed and apparently modified by a simple mock application that I built just for this purpose. That means I can simply place my generated alarms there, if the files are already there then Android just keeps them there.
And with a few lines of code, I manage to replace the alarm right under the app’s nose. It’s the breakthrough moment—a signal that the entire flow could function.
So enough with the boxes and arrows on a piece of paper (or Miro board, nowadays). It’s time to get our hands dirty!
1 thought on “Not-An-Alarm – Part 2/5 – Solution and feasibility”