Can you hear it now?

Image for Can you hear it now?

When I was initially approached about fixing an auto-play audio defect for the Koshland Science Museum Extreme Event game, I didn’t think that it would be such a difficult task. That was until I learned that it used to work—but none of the code had changed. Nothing made sense.

I remembered a past issue that involved the inability to auto-play video on iOS devices (this was done to prevent users connected to a cellular network from using up their data plans without an interaction from them). My suspicion was correct: Apple had made the same requirement for audio files: in order for any audio to play, some sort of user interaction must initiate it. However, when the facilitator of the Extreme Event game sends a tip or a challenge to a participant, there is no user interaction required to play the sound. OK, I thought, this seems to have just gotten more complicated.

But wait… this used to work? How could that be? Does it matter? (Hint: yes, it does matter.) I have to figure out how to get this to work. How could it have possibly worked in the past without a user interaction?

Let’s get back on track: how do we make the audio play? The answer is a little tricky. Once a user initiates the action to play an audio or video file in iOS, it can be played again at any time. This is the key to “auto-playing” the audio, but we needed to figure out how to make a user play the sounds without actually playing the sounds. This is the tricky part, and it took a little bit of clever thinking to make it work.
Since the Extreme Event game is a single-page Angular web app, it was actually slightly easier. When the user joins the game, they have to tap a button to join. This is the user interaction we have been looking for. On this button tap, we load, play, and then immediately pause all of the sound effects that the user will hear during the game. In JavaScript, we inject the files into a hidden section of the app that will persist across all views, and since we are doing this on a user interaction, we can also play them. But we don’t want the sound yet! That’s fine, we will just pause the sounds immediately. Then they are ready to go whenever the facilitator triggers the sound, because they were already loaded and “played” by a participant’s interaction. Then we simply triggered the play for each sound effect at the appropriate time and we have an audio indicator in our game play! Problem solved, right?

Not so fast.

Remember when I mentioned that this used to work? Well, now I needed to figure out what caused it to break, because we definitely didn’t want it to break again. Finding a solution took a lot of reading and researching. Eventually I stumbled across the answer—an answer that was much simpler than I expected.

When testing the Extreme Event game internally, the site was saved to the device’s home screen. Apparently, when you save a website to your home screen as an app, iOS no longer restricts auto-play events on audio files, so our testing scenarios never experienced the silent challenge screen.

I thought that there was no way that this could be true, so I reverted my changes and rebuilt the app. I opened Safari and tested it—no sound. Now I saved the page to my home screen and tested it again. Magic. The sounds played without any user interaction. Now that I had solved the last piece of the puzzle, all that was left was to rebuild the app with the participant interaction to load the sound effects and make sure it still worked. Voila! Koshland Science Museum Extreme Event: now with sound in your browser and when saved to your home screen.

About the Author

Image of Ryan Dudek