システム開発部のTです。前編の続きです。 前回のあらすじ ブラウザでBGMを再生するための実装を検討したが、iOS版のブラウザ全般で思ったような再生ができなかった。結局、iOSでの純粋な自動再生は出来そうにないので、別の方法を検討するのだった・・・。 前回のおさらい 前回の記事にて、iOS版での挙動を見ていくと、以下のようなイメージでした。 上記を見てみると、A画面、およびB画面においては、次画面から戻ってくるときに各画面のBGMが再生されます。想定ですが、A画面からB画面に遷移するときにボタンタップしますが、その作用で再生許可された扱いとなり、次画面から戻ったときのdidPopNext()での再生処理で再生されていると思います。 結局は、初回での自動再生は厳しいようです。これを踏まえて、対応を検討していくのが本章の議題になります。 自動再生っぽく手動再生 初回での自動再生・・・つまりライフサイクルをトリガーとした自動再生は厳しいと判断し、手動での再生を検討します。しかし、次画面に遷移したあと、ユーザー自身にいちいち再生ボタンをタップしてもらうのも面倒な思いをさせることになります。 そこで、以下のイメージを検討してみました。 ようするに、前画面で画面遷移するときのタップイベントを利用し、前画面でBGMを再生させるというものです。こうすることで、各画面ではユーザー側としても自動的に再生されているように感じてもらえるかと思います。この手法で処理を組んでみようと思います。 Playerクラスの実装 BGMを再生させるためのPlayerクラスの実装です。以前の実装では、画面ごとにPlayerクラスのインスタンスを生成していましたが、本件を実現するために、アプリ起動時のタイミングでインスタンスを生成し、それを各画面で利用するようにしていきたいと思います。そのため、以前の実装とは異なります。 main.dartの変更 main.dartのmain関数にて、アプリ開始時にProviderでBgmPlayerのインスタンスを保持するように変更。 BaseStateクラスの変更 Baseクラスのコンストラクタの自動再生処理を破棄し、Bgmのdisposeをアプリ終了時のみ実行するように変更しました。 InitPageクラスの変更 最初に呼び出す画面クラスになります。実装自体は前回の記事の内容と大差ありませんが、「画面Aに進む」ボタン押下時にBGMロード処理が実行され、その後、画面AのBGMの再生、画面Aに遷移という流れで処理します。 画面A〜Bの画面クラスの変更 基本的にInitPageと同様の変更になります。画面遷移前に、遷移先のBGMを再生する処理を実装するだけです。画面Cについては、以前の記事の内容と同様になります。 動作確認 ここまで実装し、動作確認してみましょう。いかがでしょうか。今度は画面ごとにBGMが再生されたかと思います。自動再生ではなく、手動再生ですが、なんとなく自動再生っぽく出来ているかと思います。 以上が、iOS版も含めたブラウザでのBGM再生についての記事でした。 注意事項 本件のBGM再生に対して、注意事項がございます。タップイベントをトリガーとして再生処理を実施することに変わりありませんが、以下のコード例では再生処理されません。 上記と同様、Future()での通知でも同様です。この辺を考慮して実装していかないと、再生されないことになりますので注意してください。 まとめ Webブラウザには制限の多い中、本件で取り上げたBGMの自動再生については、正直苦労しました。他のOSでは問題なくても、iOSは本当に自動再生には頑なに厳しく扱っているということがわかりました。 業務アプリでは、画面ごとにBGMを再生する・・・ということはほとんど無いうえに、WebかつFlutterで・・・というのも過去の記事なかったので、今回はJavascriptで自動再生を実装されている方の記事なんかを参考にして、ここまでやれました。 あまり、ゲーム的なBGMの利用手段で実装する機会は無いとは思いますが、Flutterでこうやった的なものとして、参考程度に見ていただければと思います。 前回の記事のリンクも貼っておきますので、参考にしていただければ幸いです。 Flutterでアプリ開発・画面にBGMを奏でる Flutterでアプリ開発・ブラウザでBGMを奏でる（前編）

Read more of this post