聊天应用中的Firebase实时数据库结构
"messages"
"-KezmqXSdKCNFFA432Uc___-KfCEwklG_y3naRDIUiY"
"messageDate": "20170620"
"messageTime": "18:44"
"message": "Hi"
"-KezFDSAADFASFFS3221___-KASDF32324SDFASD1FS"
"messageDate": "20170620"
"messageTime": "22:23"
"message": "How are you?"
谢了！
共有1个答案
如果您执行类似以下的结构：
-chats
- chatUID
- members
- userUID
- lastMessageSent:messageUID
- ... more properties
-chatMessages
- chatUID
- messageUID
- sentBy: userUID
- messageDate:""
- messageTime:""
- message:""
-userChats
- userUID
- chatUID
您可以将一个侦听器附加到/userchats/useruid，它将显示活动的聊天，并将一个侦听器附加到/chatmessages/chatuid，它将获取特定聊天对话的所有聊天消息。
这种方式更容易设置firebase安全规则，用户将只接收他们分开的聊天消息。
-
我正在开发一个Android聊天应用程序，似乎我需要通过FCM发送每条消息，还需要保存到实时数据库。 我使用Firebase realtime DB存储和发送消息。我仍然需要发送每个消息（或至少消息id）也通过FCM。我担心如果我不这样做，并且只在应用程序在后台时发送FCM，用户可能会错过一些传入的消息。 将侦听器放在服务上似乎不够可靠（如果android干掉了服务怎么办？直到我重新启动它，我可能
-
我很难弄清楚如何正确地构造多用户聊天室体系结构。 基本上，该应用程序支持用户之间的私人消息（可以是两个用户之间的消息，也可以是多个用户之间的消息）。如果只在2个用户之间，数据结构真的很容易。 我试图降低成本（我不希望当当前登录的用户正在与某人聊天，而观察者正在获得与该特定聊天无关的所有消息时），并正确地构造数据。如果只有2个用户，我总是可以在当前用户ID下添加受体，并只查询该节点。但是有多个用户（
-
我们正在构建一个聊天应用程序，一对一聊天是该应用程序的主要目的，所以目前，消息传递速度是我们的第一要务。我们需要一个后端解决方案，我们最初计划使用Firebase实时数据库。但后来Firestore出现了，从那以后，我们看到了Firebase团队对实时数据库Firestore的许多建议。 我们已经使用了实时数据库和Firestore，所以我们非常了解两者的功能和查询能力。对于我们的用例，就特性而言
-
我正在构建一个使用Firestore存储大多数数据的应用程序。该应用程序具有聊天功能，我正在考虑使用实时数据库。使用Firebase Firestore vs Realtime Database实现此聊天功能有哪些好处？如果没有区别，我应该什么都使用Firestore吗？ 附言：我已经阅读了两个https://firebase.google.com/docs/database/rtdb-vs-fi
-
我希望基本上在我的应用程序内翻拍Kik。对于我在firebase聊天应用程序上看到的大多数指南，都有一个主要的消息节点，然后在该节点下面有一个扇出，每个用户都有引用主列表中消息的消息。 根据目前我的Firebase的布局方式，实现类似以下内容会更容易： 因此，当用户向对方发送消息时，我会更新发送者和用户下面的“聊天消息”节点。 有什么理由不这样做吗？我看到每个人都按照我描述的第一种方式进行，但我看
-
我试图用firebase实时数据库做一个聊天应用程序。我将2个用户之间的聊天存储为Firebase中的JSON数组。 最初我当用户用来发送消息时，我用来设置整个聊天数组。但我很快意识到这不是一个好主意，因为阵列将会增长。 相反，在使用push后，我得到的是： 实现我想要的最好的方法是什么？