JamBubble
by team DAYOFF.
そばにいても、
離れていても、
私たちで作る、
私たちだけの音楽体験
Jambubble
OfficialSite
このプロジェクトのオフィシャルサイトを作ってみました。
よければご覧ください。
Enter
複数人でドライブに出かける際、車内の音楽は多くの場合、運転席の人が選択する。
助手席や後部座席の人は、その選曲を受け取る立場になりやすい。
流れている曲が参加者の好みに合えば、車内の雰囲気は自然と良くなる。
一方で、好みと異なる場合には、特に問題があるわけではなくても、
どこか退屈さを感じる時間になることがある。
「次は何を流す？」というやり取りがあっても、
実際に選曲を担うのは結局一人に偏りがちだ。
同じ空間で同じ時間を共有しているにもかかわらず、
音楽の体験だけは一方向的な形になりやすいという状況がある。
音楽は、日常のさまざまな場面で流れています。移動中、作業中、人が集まるとき。けれど、その体験をよく見てみると、音楽は「共有されているようで、実は一方向」なことが多いです。
誰かが選び、他の人は、それを聴くだけ。同じ時間や空間を共有していても、音楽への関わり方には差が生まれます。
本来、「何を聴くか」を選ぶ過程も、音楽体験の一部のはずです。しかし、選ぶ人と聴く人に分かれた瞬間、体験は個人のものになってしまいます。
さらに場所が離れると、その分断はより大きくなります。同じ音楽を聴いていても、「一緒に体験している」感覚は失われていきます。
私たちは考えました。音楽を、「流すもの」ではなく、「みんなで関わる体験」のできないのだろうか？と。
私たちの音楽体験。
私たちで作る、
私たちは、
「選ぶ・共有する」という音楽体験にフォーカスしました。
一つのプレイリストを、複数人で動的に作り、
それぞれが音楽をリクエスト。
アプリでも、Webでも、
同じセッションに参加するだけで、
誰でも音楽体験に加われる。
このような仕組みを考えました。
機能① セッションを作成する
音楽体験のはじまり
アプリからセッションを作成すると、専用のプレイリストが生成されると同時に、参加用のWebリンクやQRコードが発行され、そのセッションを共有できる状態になります。
機能② 音楽をリクエストする
誰でも、すぐに参加できる
参加者はリンクやQRコードからアクセスし、セッションに参加することでWeb上で曲を選んでリクエストできます。アプリのインストールやログインをする必要はなく、スマートフォン一つで選曲に加われます。
機能③ 音楽を再生・共有する
体験として、音楽がつながる
リクエストされた音楽は、セッションに参加しているアプリユーザーの端末で再生されます。再生する端末が一つでも、複数の端末でも、同じプレイリストを共有した音楽体験が成立します。
No Content...
7.Blazor Server
SSRのSPA
サーバーリソースを見せずに使用
JamBubbleでは、ゲスト参加者向けのWebインターフェースにBlazor Serverを採用しています。 音楽セッションでは、ホスト（Android端末）とゲスト（ブラウザ）が同じプレイリストをリアルタイムで共有し、誰かが曲を追加したり再生操作を行うと、即座に全員の画面に反映される必要があります。この「みんなで同じ画面を見ている」体験を実現するために、Blazor ServerとSignalRの組み合わせが最適でした。 通常のWebアプリでは、JavaScriptを使ってクライアント側で動作するSPA（Single Page Application）を作るか、サーバー側でHTMLをレンダリングする従来型の構成を選ぶことになります。しかしJamBubbleには、もう一つ重要な要件がありました。Spotify APIのキーをクライアントに露出させないことです。 Blazor Serverはサーバー側でC#コードが実行され、SignalRを通じて画面の更新だけをブラウザに送信します。つまり、APIキーなどの機密情報はすべてサーバー内に留まり、バックエンドとフロントエンドの境界を意識することなく安全に外部APIを呼び出せるのです。
マルチプラットフォーム向きから
Androidネイティブへ。
当初は .NET MAUI Blazor Hybrid を使って、 Web技術ベースでモバイルアプリを開発していました。 UIの開発スピードは速かったのですが、 Spotify SDK を使う段階で問題が発生しました。 OSごとのネイティブ SDK を組み込むための Gradle などの設定を、柔軟に行えなかったためです。 そこで、Android ネイティブでの開発に切り替える判断をしました。
Android では UI に Jetpack Compose を採用しました。
関数をネストして UI を構築するスタイルには最初苦労しましたが、
UI と状態を一体で管理できる点は、このアプリに適していました。
理想の技術構成だけで進めるのではなく、 制約や実装可能性を踏まえて判断することの重要性を学びました。 また、 音楽体験という抽象的なテーマを、 具体的な機能や仕組みに落とし込む難しさと面白さを実感しました。
今後は、 より多くの人が自然に参加できるよう、 体験の流れや UI の改善を進めていきたいと考えています。 また、 利用シーンを広げるための機能追加や、 安定したセッション管理にも取り組んでいく予定です。