Background audio in iBooks Widgets

Exporting & Previewing iBooks
1

Hi Johnathan,

Just wanted to say thanks again for your help – removing that code worked like a charm!

If you don’t mind, I realize I’ve come across another question related to the behavior of these widgets, and I have not had any luck finding any online threads on the issue.

The question may be more of an iBooks author problem, but do you mind if I run it by you in case you have any ideas? Here is the issue:

When I first created the iBook (that these widgets were built for) the behavior was exactly what I wanted by default, which is this: – on a given page, a button triggers an audio file, and on the same page is placed an interactive widget. If a user pressed the audio button, the audio file would play as expected.

However, if the audio file was triggered first, and then the widget on the page was tapped while the audio was playing, the widget would open and run, while the audio file would continue playing in the background. This is the behavior that used to be built-in, and it’s the behavior I’d love to be able to accomplish in this update.

It seems now by default, opening a widget now stops any background audio from playing. I’d like to try and counteract this and make it such that opening a widget does not stop background audio from playing, but rather lets the audio play to the end of the track.

Do you think it’s possible to accomplish this by adding some JavaScript either in the widget or somewhere in iBooks? It seems to me the issue is likely on the iBooks end of things, which might make it harder, or impossible, to customize this behavior. Do you have any thoughts on whether or not this is even possible to do?

Thanks so much!

2

So the audio was a non-Hype Audio element? Or it was a separate widget from the widget you just opened (which stops the audio)? Just trying to figure out what you're interacting with.

It would not surprise me if an update to iBooks would be a bit more aggressive about reducing the amount of media playing at different times. Having audio run in the background is going to tax the available memory a bit.

3

Hi Daniel,

Yes, the audio is a non-Hype Audio element. They are short .m4a audio files that were placed directly into iBooks. If that audio file is triggered, it used to play in the background while a widget could be open and running. Now, opening a widget stops any audio that is playing.

Since the audio is added directly to iBooks, it seems it might need an iBooks fix rather than anything that can be done on the widget’s end (which I’m not sure is possible). Any ideas on how I might get this to work? Many thanks!

4

I don’t think this is something that Apple would like Book creators to control. I think this is expected behavior: you’re leaving the area where you originally pressed play, and opening a new frame that blocks whatever audio element you had originally played. Since this also improves the responsiveness of widgets I can see why this behavior was implemented. Sorry it’s disrupting your book!

5

Thanks Daniel,

I agree, it seems like a constraint that Apple would not like folks to have the ability to mess with. Thankfully, I have found a good workaround in the form of enhancing the interactivity of the widget (so that when the sound is cut off as the widget launches, there is lots of obvious stuff to do in it’s place). With this workaround, the design now feels sensible and intentional (actually better than before). So, perhaps it’s all for the best.
Thanks again for the input!

1 Like