WebRTC のサービスが動かない?そんな時確認したいリスト
たまにいざサービスを体験しよう、動かしてみようとした時に「あれ?」ってなることがあるのでまとめておきます。
僕自身の体験をベースに書いています。
今後も自分が体験した項目の追加と、スクリーンショットを追加をしていくつもりです。
目次
まず確認したいところ
困った時にはまず以下を確認していきます。
物理的に接続ができているかどうかはあるあるなのでまず確認したいところです。
接続しただけでなく、認識しているかどうかが次に確認したいところになります。
ハード観点での確認
カメラやマイクの物理的な接続はちゃんとできてますか?
- パソコンや端末にきちんと接続できているか確認してみる
- USBカメラであればちゃんとケーブルが刺さっているかどうか
- 接続後にパソコンや端末がカメラを認識できたか確認してみる
- パソコンや端末にきちんと接続できているか確認してみる
カメラやマイクは問題なさそうなのに映像がでない場合、ネットワークを確認してみましたか?
- 無線に接続できているか確認してみる(普段使ってないパソコンや端末だとあったりします)
- 有線ケーブルが抜けてないか確認してみる(普段使ってないパソコンや端末だとあったりします)
ソフト観点での確認
他アプリ(標準搭載でOK)を起動してみて、マイクが機能していることを確認できましたか?
- カメラアプリや FaceTime など環境によって確認できるアプリは異なりますが、できるだけデフォルトで入っているもので確認してみます
カメラやマイクは問題なさそうなのに音声や映像がでない場合、権限を確認してみましたか?
- 他のアプリでカメラを掴んでないか確認してみる(カメラ一つで同時に使えるアプリは一つです)
- 利用しようとしているブラウザでカメラとマイクが許可されているか確認してみる
- 利用しようとしているアプリがカメラとマイクの許可がされているか確認してみる
ここまで大丈夫そうなことが確認できているのに解決しない場合
トラブルシュートを使ってみます。 test.webrtc.org
STARTを押してしばらく待つとこんなふうに結果が出てきますので、NGだったところをチェックしていきます。
マイクがダメそうだった
おそらくトラブルシュート実行前の確認で大丈夫になっているはず。
もしNGだった場合接続をもう一度確認してみると良さそうです。
カメラがダメそうだった
おそらくトラブルシュート実行前の確認で大丈夫になっているはず。
もしNGだった場合接続をもう一度確認してみると良さそうです。
ネットワークがダメそうだった
それでも解決しなさそうだった
ここまできて発見できていないと解決は困難です。
環境依存、ハード固有、様々な可能性があります。
自分が困ったときに解決した物などをピックアップして書いておきます。
カメラもマイクも問題ないはずなのに映像や音声がでない
- 利用したいアプリ以外でマイクやカメラを使用していないか確認してみる
- ブラウザで権限が許可されているか確認してみる
- マイクが ON/OFF のついてるタイプで OFF になってないか確認してみる
以上です。
少しやり方を変えることにした
これは何か
これまでのやり方から変えてみようってお話です。
いわゆるポエムです。
なぜやってきたか
勧められるままはじめてみたのがきっかけで、自己満足にちかい感覚でやってきました。
なぜ変えるか
以下のような理由で変えるべきと判断しました。
- 自己満足ではあるんだけど惰性に感じる。
- 読んで書いたことに満足だけしてしまっている感覚がある。
- もう少ししっかりとした力に繋がって欲しい。
- (当たり前だけど)変えていかないとそこまでじゃ
ここまでで何が得られたのか
継続できるってのを自分できちんと認識できることができた。
アウトプットしていくというものに対するハードルもだいぶ落ちたので他に活かせそうな自信ができた。
どうしていくか
少し前にこの本を読みまして、これを参考に少し考えてみました。
しばらくは試行錯誤をしながら、分野を決めてガツガツと理解したものを書き記していく形にしようかなと。
あまり変わらないんですけど、意識が高くても続かないだけなので....
余談
- 1日1つだけ強くなる
最近の自分のロールを棚卸しして、1日1つ強くなったことをまとめています。
書きやすい場所を模索してるけど、最終的に一番身近なデバイスであるiPhoneのメモにまとめることになりそう。
- 読んだ本とか
内容をどこまで書くのか?の線引きが難しいので思ったことの感想だけに留めることが多いです。
- Ghost of Tsushima
誉れだけでは蒙古に打ち勝つことができないように変わらねば脅威に打ち勝っていくことはできない。
本当に得たいものは何かを考えることこそ肝要。
そんな感じでした。
Reactガイドを読んでいくその310
これは
Reactのガイドを読んでいく記事です。
ガイドのリンク
サスペンスを使ったデータ取得(実験的機能)
サスペンスと競合状態
競合状態はコードが実行される順番について誤った前提を置くために発生するバグ
useEffect フックやクラスの componentDidUpdateを使うとよく起こる。
以下の例を見ながら明日それぞれデータ取得方を見ていく。
function getNextId(id) { // ... } function App() { const [id, setId] = useState(0); return ( <> <button onClick={() => setId(getNextId(id))}> Next </button> <ProfilePage id={id} /> </> ); }
今日はここまで。
Reactガイドを読んでいくその309
これは
Reactのガイドを読んでいく記事です。
ガイドのリンク
サスペンスを使ったデータ取得(実験的機能)
早期から取得を開始する
データ取得ライブラリを使うのであればレンダーより前に取得を開始することが大切。
// Start fetching early! const resource = fetchProfileData(); // ... function ProfileDetails() { // Try to read user info const user = resource.user.read(); return <h1>{user.name}</h1>; }
readの呼び出しは開始ではなく、取得最中の物を読み込みできないか試みているだけのものになる。
コメントにもあるように最初に開始されている。
サスペンスの仕様はまだ検討中のもので、仕組みは柔軟で制約は多くないとはいえ、まだどうすべきか開発側が検討しているらしい。
Reactコミュニティってどういう感じなんだろうか。そちらに興味が出てきた。
今日はここまで。
Reactガイドを読んでいくその308
これは
Reactのガイドを読んでいく記事です。
ガイドのリンク
サスペンスを使ったデータ取得(実験的機能)
アプローチ 3: Render-as-You-Fetch(サスペンスを使用)
これまではsetStateを呼び出す前にデータの取得が必要だった。
サスペンスをつかうと、データ取得の開始後、取得完了を待たずにレンダーを開始することができる。
codesandbox.io サンプルを見ると確かに、完了を待たずに描画を開始している。
以下のような順番で処理が行われているらしい。
1.レンダー時点で fetchProfileData() を使ってリクエストがスタートしています。この関数は Promise ではなく特殊な “リソース (resource)” を返します。現実的な例では、Relay のようなデータ取得ライブラリのサスペンス連携機能を使うことになります。 2.React は <ProfilePage> のレンダーを試みます。子要素として <ProfileDetails> と <ProfileTimeline> が返ります。 3.React は <ProfileDetails> のレンダーを試みます。内部で resource.user.read() が呼び出されます。データはまだ何も取得されていないので、このコンポーネントは “サスペンド (suspend)” します。React はこのコンポーネントを飛ばして、ツリーの他のコンポーネントのレンダーを試みます。 4.React は <ProfileTimeline> のレンダーを試みます。内部で resource.posts.read() が呼び出されます。今回も、まだデータがありませんので、このコンポーネントは “サスペンド” します。React はこのコンポーネントも飛ばして、ツリーの他のコンポーネントのレンダーを試みます。 5.レンダーを試みるべき他のコンポーネントは残っていません。<ProfileDetails> がサスペンドしたので、React はツリーの直上にある <Suspense> フォールバックを表示します:<h1>Loading profile...</h1>。ひとまずこれで終わりです。
resource オブジェクトがいずれロードされるであろうデータを表す。
readを呼び出すとデータかコンポーネントがサスペンドされる。
今日はここまで。
Reactガイドを読んでいくその307
Reactガイドを読んでいくその306
これは
Reactのガイドを読んでいく記事です。
ガイドのリンク
サスペンスを使ったデータ取得(実験的機能)
アプローチ 1: Fetch-on-Render(サスペンス不使用)
現状Reactではeffectを使用してデータを取得する。
// In a function component: useEffect(() => { fetchSomething(); }, []); // Or, in a class component: componentDidMount() { fetchSomething(); }
画面上にコンポーネントがレンダーされた後までデータ取得が始まらないので、このアプローチをfetch-on-renderと呼称している。
ウォーターフォールという問題を引き起こしてしまう。
レンダー時にデータを取得するコードではウォーターフォールはよく発生する。
修正することは可能とはいえ、プロダクトが成長するにつれて多くの人はこの問題を解決しづらくするような手法を使うようになる。
今日はここまで。