Realtime Database の接続切断

Question

Firebase でチャットアプリを試験的に作成しています。

無料枠には、接続数の制限があるので、一定時間動きがなければ切断したいと考えているのですが、意図した動作をしません。

ちょっとかっこ悪いソースですが、抜粋したものを晒します。

var firebase_task = [];

$(document).ready(function () {
	firebase.initializeApp(config);
	var baseRef = firebase.database().ref('HOGE');
	firebase_task[0] = baseRef.on('child_added', function (data) {
		console.log(data.key, data.val());
	});
	firebase_task[1] = baseRef.on('child_removed', function (data) {
		console.log(data.key, data.val());
	});
	firebase_task[2] = baseRef.on('child_changed', function (data) {
		console.log(data.key, data.val());
	});
});

function disconnect() {
	var baseRef = firebase.database().ref('HOGE');
	baseRef.off('child_added', firebase_task[0]);
	baseRef.off('child_removed', firebase_task[1]);
	baseRef.off('child_changed', firebase_task[2]);
	}
});

.off() を適当なタイミングで呼んでやると切れると思っていたのですが、開発ツールで WS の通信状況を見ると、接続が残っているようです。管理画面の接続数でもカウントされているので、Simultaneous connections に数えられている認識です。こちらをカウントから外すにはどのように切ればよいでしょうか？

ご存じの方、ご教示いただけると幸いです。

Answer 1

【Interface: Database  |  Firebase】
https://firebase.google.com/docs/reference/js/firebase.database.Database?hl=ja

firebase.database().goOffline();

これとか？

Comments

[退会済みユーザー]

これは、発想の転換ですね！

ドキュメントは見ていたのですが、ちょっと使用用途が違っているように思えたので試してませんでした。

今、挙動を見る限り、うまく行っているように見えます。
もう少し検証してみます。

ありがとうございます。

[kei344]

> 使用用途

（リンク先）> The client automatically maintains a persistent connection to the Database server, which will remain active indefinitely and reconnect when disconnected. However, the goOffline() and goOnline() methods may be used to control the client connection in cases where a persistent connection is undesirable.
（Google翻訳）>クライアントはデータベースサーバーへの永続的な接続を自動的に維持します。データベースサーバーは無期限にアクティブのままで、切断されたときに再接続します。 ただし、永続的な接続が望ましくない場合に、goOffline（）およびgoOnline（）メソッドを使用してクライアント接続を制御できます。

上記部分を読むと、「接続し続ける仕様」のように読めます。全てのイベントを外しても明示的に切断しない限り接続し続けるのでは。

[退会済みユーザー]

そのようです。英語のまま見ていたので、中途半端に理解していました。
（ローカル作業をキューに貯めるモードへの移行と認識していました）

接続数のカウントを確認していますが、通信を見る限り成功しているように思います。
後は時間が経ったら確認完了なので、もう少し様子を見てみます。
大変助かりました。

[退会済みユーザー]

意図した動作が確認できました。少し諦め気味だったので大変助かりました。

Answer 2

わたしはFirebaseをiOSでメインで使っており、JavaScriptの方は使い込んでいるわけではないのですが、回答させていただきます。

https://firebase.google.com/docs/database/web/retrieve-data#detach_listeners

こちらのドキュメントの「リスナーのデタッチ」では、『.off()には引数無しで渡す』と書いてありますので、そちらの方法で試してはいかがでしょうか？

iOS版からの想像になってしまいますが、「firebase_task[0]」的なものは引数で渡さずとも、'HOGE'に関連する接続は全て削除される挙動になると思います。

Comments

[退会済みユーザー]

アドバイス、ありがとうございます！
baseRef.off();
で試してみたのですが、やはり、開発ツールで見る限り接続が残ってしまいます。

https://firebase.google.com/docs/reference/js/firebase.database.Query#off
> If a callback is not specified, all callbacks for the specified eventType will be removed. Similarly, if no eventType or callback is specified, all callbacks for the Reference will be removed.

とあるので、
baseRef.off('child_added');
baseRef.off('child_removed');
baseRef.off('child_changed');
こちらも試したのですが、やはり残ってしまいます。

iOS版では、接続は任意のタイミングでうまく切断することができるということですよね？それがわかっただけでも、非常にありがたいです。

学習中なもので、なにか前提条件を見落としている気がします。些細な点でも気がついた点があれば、ご指摘いただけると幸いです。。。

[退会済みユーザー]

detach で検索かけると、
baseRef.off();
で行けそうなんですけど、私の環境では、意図した動作になっていないです。
もう少し悩んでみます。

detach をキーワードに検索をしていなかったので助かりました。

[kanemotos]

英語サイトだと.offに引数を渡すサンプルがありますね。失礼しました。

Databaseの'HOGE'監視を削除しても、'HOGE'の子供を監視するものまでは削除されない仕様だとは、書いてありますが、そこの所は見落とされてないんじゃないかなとは思います。

iOS版ではうまく切断できる実装が出来ましたが、わたしは接続が残るかどうかという確認までは行いませんでした。
.onメソッドに相当する部分にログを吐くようにして、.offするとログが出なくなったことを以て確認しました。
開発ツールで確認されていると聞いて、もしかしたらhttpセッションレベルでは次も使いまわせるように一定時間のあいだ接続が残るような仕様になっていたりするのではないかとの推測が頭をよぎりました。

試験実装であればそこまで神経質に気にする必要はないのかななんて思います。
本番運用するようになって100を超えるようであれば、何のサービスなのかによるとは思いますが25$/monthですし、嬉しい悲鳴と思ってお金を払うくらいの気持ちで良いんじゃないかと思います。私はそういう心持ちで使っています。

[退会済みユーザー]

kei344 さんが指摘してくれていますが、なんらかのセッションレベルで残ってる可能性が高そうです。

> 本番運用するようになって100を超えるようであれば、何のサービスなのかによるとは思いますが25$/monthですし、嬉しい悲鳴と思ってお金を払うくらいの気持ちで良いんじゃないかと思います。

そうですね＾＾仕様上の確認がしたかったという面が強いので、多分アップグレードはすると思います。

アドバイス、ありがとうございます。

[kanemotos]

うまく解決できたようで良かったです。
たぶん.offはcallbackを止めるだけの仕様で、接続面では何がしかが残っているようですね。
私も接続が切れるものだと思っていたので勉強になりました！！

[退会済みユーザー]

> たぶん.offはcallbackを止めるだけの仕様で、接続面では何がしかが残っているようですね。
ですね。個人的には切れよ！って感じですが、何か意図があるのだと思います。
貴重な情報の共有、ありがとうございました。