那如果要 实现未注册的用户都能看到呢 好比微博广场那样 或者我想实现可以看到附近的 诸如此类
像微博广场那样的数据,其实不在任何人的 timeline 里面,使用单独的表来存储是最合适的。
如果一定要用 Status 接口,那就需要用「匿名用户」来做了。具体文档可以看这里:Android 开发文档 和 iOS 开发文档
我觉得在这方面 LC可以修改下吧 毕竟这种需求还是挺大的 即使是微博 我没关注你或者不是你的粉丝 我也应该可以看到你发的内容的 我觉得你们这种设计更像是朋友圈的概念 必须是好友才能看到 不过又有不同点 毕竟朋友圈我加了你为好友 你历史的发过的状态我也是应该能看到的 感觉LC目前设计的应用内社交 太过于局限了 希望以后能再这方面有更多的扩展 既然是为了方便用户而设计出来的 虽然那些功能自己建表可以实现 但是如果要把粉丝和广场结合的话就这样就会把复杂性交回给用户处理了
btw 还有文档和API有时会让人误解 https://leancloud.cn/docs/status_system.html#自定义Status这部分我看自定义status 发送的是自定义状态 查询的是收件箱 AVStatus.INBOX_TYPE.TIMELINE个人理解是不是相当于发送私信给所有人 AVStatus.INBOX_TYPE.PRIVATE发送私信给一个用户
还有匿名用户 会自动在_User表插入一条数据?那这样会产生大量无用数据
匿名用户会在用户注册的时候,自动转变成注册用户,所以基本上会让你的 User 表大小等同于实际的用户规模(包括注册与非注册用户)。
嗯,是这样的,发送自定义状态基本上就等同于往任意用户的某种类型的信箱里面投递状态,然后每个用户都可以打开自己的信箱收到别人希望他看到的状态。所以基本上你这个需求,对于未注册用户,使用我们的「匿名用户」来做,是比较合适的。
以后会支持广场/附近/推荐 状态功能吗 还是让用户自己去扩展?如果会的话我就打算沿用_Status 如果不会我还是自己建表啊
以后会支持广场/附近/推荐 状态功能吗 还是让用户自己去扩展?如果会的话我就打算沿用_Status 如果不会我还是自己建表啊.
对于广场、附近、推荐这些 tab 的内容展示,因为是全局性的数据,不会在我们应用内社交里面来做,你还是自己建表吧。
广场、附近、推荐 还有 关注的 是让两种表结合着用吗?
如果广场、附近、推荐 还有关注的好友功能都有 是让两种表结合着用吗?这样会不会引入复杂性
每个人的 status,你先推给 TA 的粉丝。然后把这条 Status 存到一张独立的表里面(譬如表名为A,记得带上地理位置信息)。这样直接按照时间先后读取 A 里面的数据,就是“广场”;根据当前用户的位置,找 xx KM 以内的信息,就是“附近”。
你意思是用两个表吗?一个_Status 一个 A .如果是这样 那么删除时也要删除两个表 评论点赞可以都relation同一个表
哦,那可以直接使用 Status 表啊。
_Status给我带来最大的不便之处就是 新用户不能阅读旧的功能 我个人觉得你们这设计有点不太科学吧 我发的TIMELINE 后来新注册的用户就看不了了?
市面上应该没有任何一款社交应用或者论坛是这样设计的啊?即使是微博 我未登录或者我不是你的粉丝也能看到你发的微博 就算是朋友圈 我加你好友后 我也能看到你的历史记录啊
1,使用云引擎,在用户注册成功之后,把所有全局的 Status 发到他名下;请问这个是 使用云代码 没注册一个用户遍历_Status 然后逐一sendPrivateStatusInBackgroud(发私信)吗?这样数据庞大性能很低啊
让广场数据直接从 Status 表读取,就不需要这样做了。