作者归档:wwang

请所有用户尽快完成实名认证的通知

尊敬的用户,您好

根据国家《网络安全法》的要求,使用 LeanCloud 服务的用户必须进行实名认证(个人或者企业认证):

第二十四条 网络运营者为用户办理网络接入、域名注册服务,办理固定电话、移动电话等入网手续,或者为用户提供信息发布、即时通讯等服务,在与用户签订协议或者确认提供服务时,应当要求用户提供真实身份信息。用户不提供真实身份信息的,网络运营者不得为其提供相关服务。

为了协助大家尽快完成信息认证,我们预留了一个月的过渡期(6/25-7/25)。从即日起,对于未进行实名认证的账户,我们将禁止其创建或者激活应用,并禁止应用转移以及数据导入导出等操作,应用内具体的 API 请求不受影响;过渡期后我们会完全停止为尚未提交认证信息的账户提供服务。

登录 LeanCloud 控制台 后,在 账号设置 – 实名认证 的页面即可完成操作,请未进行实名认证的开发者尽快完成认证,感谢大家的理解和配合。

谢谢!

关于 LeanCloud 国内域名解析问题的情况更新(6 月 21 日)

各位 LeanCloud 的用户大家好,我是 LeanCloud 的联合创始人江宏。

大部分用户都已经知道我们的两个域名目前无法解析,具体的情况我们昨天给大家发了邮件和博客说明,今天又再次发了短信通知。虽然这件事还没有解决,但本着对事件处理过程透明的原则,我想向大家更新一下最新进展,以及我们已经采取的措施。

由于在域名被禁用前没有事先通知我们,所以昨天我们在事情发生一段时间之后也不知道具体的原因。后来经过和阿里云各相关消息渠道一段时间的沟通后得知是因为某违规应用被查封,所以该应用访问的域名受到牵连。我们到目前为止没有看到有关函件的内容。根据应用名判断,我们已经于一个月前就清查和处理过这个应用,禁用了相关账号,这次不知因什么原因仍然被该应用影响导致两个域名被设为 ClientHold。我在今天下午拜访了有关部门,递交了我们的处理情况说明、申诉和保证,仍需要等待确认才可以解禁。很抱歉目前原有域名的恢复时间取决于政府部门之间的沟通进展,我们也无法给用户准确的估计。

在我们可控制的范围内,我们针对这件事已经完成的应对措施有:

  • 为可以替换域名的用户提供可用的替代域名,说明见博客
  • 我们 iOS、Android、JS、Unity 等 SDK 都做了紧急更新,以避免国际版的应用受国内域名的影响。
  • 为避免在解决问题过程中出现其它问题,华北和华东节点暂停新开发版应用的创建。如果您有需要可以用邮件联系我们创建,或者使用国际版。
  • 华北节点提供了自助绑定 API 自定义域名的功能,自定义域名可用于访问数据存储、云函数、短信、推送以及即时通讯服务。你可以在控制台的「存储 -> 设置 -> 自定义 API 服务域名」中提供一个已备案的域名(如需开启 HTTPS 还需提供对应的证书)来自助绑定。详细的自定义域名的配置和使用文档参见另一篇博客

我们还有一些正在实施的措施,既为了应对目前情况,也为了在更长期能把特殊国情带来的特殊风险限制在尽量小的范围。我们也会把后续的和有关部门的沟通结果同步给用户。有一些用户因为域名解析问题无法联系我们,请注意我们的各个线上联系渠道有的使用了临时域名:

很多用户在此次事件的沟通中给予了我们宝贵的宽容、支持和信任。我想特别向我们的用户表达感谢,并将继续尽我们所能克服未来可能遇到的困难,服务好用户。

华北节点支持绑定 API 自定义域名

现在华北节点支持绑定 API 自定义域名。你可以在控制台的「存储 -> 设置 -> 自定义 API 服务域名」中提供一个 已备案 的域名(如需开启 HTTPS 还需提供对应的证书)来自助绑定。

自定义域名目前可用于访问以下 API 服务:

  • 数据存储
  • 短信
  • 推送
  • 云函数

自定义域名不适用以下 API 服务:

  • 即时通讯的 web socket(绑定自定义域名后仍旧使用 avoscloud.com

另外,以下服务使用独立的自定义域名:

  • 云引擎网站托管
  • 文件存储服务

换句话说,如果之前在这两个服务上绑定过自定义域名,现在想绑定 API 自定义域名,那么需要在 API 上绑定另一个域名(包括不同的子域名)。

具体绑定及配置方法见 API 自定义域名绑定指南

Android 推送 SDK(精简版)发布|五月汇报

产品动态

7 月 1 日起即时通讯和推送 REST API 将开启请求频率限制

2019 年 7 月 1 日起,我们将对推送和即时通讯服务中调用 REST API 进行消息操作开启频率限制(请注意,客户端通过 LeanCloud SDK 产生的行为不受此限制的约束),以此来提升服务质量和鼓励用户更合理的使用服务。在限制正式生效之后,单位时间内超限的 REST API 请求会被云端拒绝,并返回 429 错误码。因此,请您注意检查应用逻辑,并就最大限制做好相关的适配工作。接口详情请参考博客

为什么要增加这一限制呢?推送服务我们之前基本是免费使用的,后来虽然把它加入到了商用版套餐中,但是对于用量还是没有任何限制,这样导致的问题就是平台实际成本非常高,而开发者使用上毫无节制还会让平台峰值压力比均值高出百倍以上,直接影响服务的整体稳定性。因此我们现在才需要对使用方式进行一些限制,通过经济手段来引导大家合理的使用公有云的服务。商用版应用如有合理的需求希望突破此限制,请联系 support@leancloud.rocks 了解相关的付费方案。

关于限制门槛以及付费的阶梯方案,根据我们的统计数据来看,对 97% 的商用版用户来说都没有实质影响,而剩下的 3% 用户,也可能通过技术的平滑处理让请求频率降到限制之下,从而不需要额外付费。不管怎样,开发者都可以享受到更稳定的服务,这也能让系统峰值压力有所减缓,让服务提供方的成本有所降低,这实际上是一种「双赢」,是为了业务稳定和可持续发展而不得不进行的转变,希望开发者可以理解并支持我们,谢谢!

云引擎定时任务功能升级

我们重新设计了云引擎的定时任务功能,新的定时任务是接下来会发布的「云队列(Cloud Queue)」的一部分,它兼容之前的绝大部分用法,还添加了一些新特性:

  • 新的定时任务将不再有个数限制。
  • 新的定时任务可以向云函数传递自定义的参数(JSON 形式),可以配置在超时情况下的行为(重试或放弃)。
  • 新的定时任务在控制台界面上会显示上次运行结果和下次运行时间。
  • 新的定时任务被触发时会在云引擎日志中打印日志(包括执行结果)。
「云队列」功能预告

云引擎发布以来,经常会有用户跟我们提出「任务队列」一类的需求,在此之前我们都是推荐大家使用云缓存 Redis 的「Pub/Sub」功能来自己实现,现在考虑到需求的一般性和队列服务的高可靠性要求,我们决定在平台层面提供「云队列」的服务。「云队列」基于云引擎已有的云函数概念实现了重试、去重、结果查询、延时任务、定时任务等功能,是对云函数功能的一个补充。尚未运行的任务会以一种可靠的方式暂存在云队列,即使你的云引擎实例因部署、过载、崩溃而重启,任务也不会丢失,云队列会等待你的云引擎实例恢复正常后继续运行它们。

具体进展和使用方法,可以关注我们的博客和论坛公告。

Swift SDK 即时通讯功能(正式版)发布

本月我们发布了 Swift SDK 即时通讯功能的正式版(16.0.0),在 3 月份 beta 版基础上增加了本地缓存的功能,提升了效率和稳定性。同时,我们也同步推出基于新 SDK 开发的全新 Chat 应用,Chat 应用支持最新的 iOS 系统以及最近的三个 OS 大版本,它以开源 Demo 的形式推出,其主要目的是展示如何使用 Swift SDK 来实现各种聊天功能。

Android 推送 SDK(精简版)发布

LeanCloud 已经发布了一个标准版本的推送 SDK: LeanCloud Push SDK ,该 SDK 除了推送服务之外,还支持即时通讯和 LiveQuery 服务(共享同一个 WebSocket 长链接),并且由于即时通讯中对文件、图片、音视频消息等功能的支持,它还必须依赖于 LeanCloud 核心 SDK,因此整体上体积会稍大一些。

对于那些只使用我们推送服务的客户来讲,其实只需要提供设备注册(AVInstallation 存储)和消息接收(PushService)的相关操作即可,标准版 SDK 中大部分功能可能反而显得冗余。现在,我们有一些 VIP 客户正在优化产品移动端体验,安装包大小和启动时间是评测中的重要指标,为了协助他们做好优化,我们专门推出了这一精简版 SDK。

与标准版 SDK 相比,精简版 SDK 在体积和启动时间上的优化效果如下:

内容分享

每天我有多少时间可以写代码?

11

大家好,我是老王,程序员一枚,也是 LeanCloud 团队家属。家属因为工作原因,经常以调研(diao cha)为由咨询(shen wen)我一些问题,这次问题是「每天实际有多长时间是用来写代码的」。

常见问题

【推送】同一个账号在两个设备登录过,两个设备都会收到推送信息吗?

推送的时候是根据推送查询条件,在 _installation 表中查找符合条件的目标设备来推送。只要查询条件能包含这两个设备,则两个设备都能收到推送。

如果是登录即时通讯系统,如果没有开启单点登录,用户在登录两个设备后,如果用户不在线会尝试给这两个设备都发离线消息推送。

【推送】Android 非混合推送,控制台推送记录中显示推送成功,但 Android 设备实际没有收到推送,是什么原因?

对于 Android 非混合推送设备,当返回的记录成功数为 1 时,表示一定收到了 SDK 确认收到该消息的回应。即此条推送消息一定是到达了设备。
建议检查推送是否使用了自定义 Receiver 功能(消息中是否有 action 字段),消息到达后 SDK 会直接将消息转交给自定义 Receiver,由自定义 Receiver 完成推送提醒。这种情况需要检查自定义 Receiver 实现逻辑排查消息到达后为什么没有弹出提醒。

【云引擎】新推出的 LeanDB 是什么产品,是用来做什么的?

这是一项新推出的功能,为了满足应用对关系型数据库的需求。目前 LeanDB 提供了 mysql 数据库,可以使用任何支持 mysql 的库来访问它。

接入文档请参考:LeanDB MySQL 使用文档

》》更多使用疑问请点击这里

每天我有多少时间可以写代码?

大家好,我是老王,程序员一枚,也是 LeanCloud 团队家属。家属因为工作原因,经常以调研(diao cha)为由咨询(shen wen)我一些问题,这次问题是「每天实际有多长时间是用来写代码的」。

于是,我对自己的日常工作内容进行了一些梳理。

早上七点半起床洗洗刷刷偶尔刮胡子,风驰电掣的穿好鞋,八点出门。挤地铁换乘,一般需要一个半小时到达公司,偶尔遇到特殊情况会在地铁楼梯台阶上改半个小时的代码。上班花费时间约 2 小时。

我每天会开很多会,开发需求跟产品开会、项目方案沟通会、新人转正评审会、出了故障要开总结会、小组周会、部门周会、团队分享会等若干会议。一天中会议一般会占用 3-6 小时。

每天我还需要一些时间在日常沟通上:

「Hi, 可以帮我看看,这个问题是什么情况吗?」

「王 x,现在有时间吗?新功能什么进度了」

「王 x , 约的面试的人到了」

中午,食堂,便利店,还是外卖,纠结吃什么也会花掉一些时间。排队,找座位,边吃边跟同事聊聊最近热门的游戏,1 个小时也就过去了。

为了避免出现加班加点做大量无用功,产品下需求必须要花一些时间了解,遇到疑问还会与产品反复沟通,这部分工作大约也需要 1 小时。

到晚上,花半小时解决下晚饭,没有意外情况的话,一般会在 21 点下班,十点半到家。回家后打开电脑再花半小时写日报跟工作总结。收拾洗个澡,十二点关灯睡觉,除去 7.5 小时的睡眠时间(在没有半夜突发故障的情况下),一天实际花在写代码上的时间大约为 4 个小时。

忘记提,作为一个十分讲究的程序员,以前我还要花半小时在每天穿什么的问题上,格子衫因为被黑太多不敢穿了,优衣库的卡通短袖又不符合我稳重的开发者气质,感觉衣柜里缺了一件不需要思考万能百搭的短袖。

于是家属给我推荐了她厂新款:LeanCloud 10x 程序员 T 恤。

10x 程序员
搭配

纯棉透气,百搭任意色系长短裤型,自此,我每天写代码时间又多出来了半小时。据说新款上架,购买就送 10x 程序员笔记本一本,活动截止至 6 月 10 日。

点击此处直接购买

以上人物时间均为虚构,如有雷同纯属巧合。

从 React Native 到 Flutter,移动跨平台方案的真相

作者:LeanCloud 工程师郑鹏

2018 年 12 月,Google 发布了 Flutter 1.0 正式版,似乎再次点燃了人们对移动跨平台开发的热情。上一次出现类似的情况,是在 15 年年初,Facebook 发布 React Native 的时候。四年不到的时间里,有两家大公司相继推出了自己的移动跨平台方案(当然还有 16 年的时候,微软收购了 Xamarin,不过没有前两个那么引人注目罢了),同时这些方案也受到了市场的追逐。这些现象,似乎预示着,跨平台开发才是移动开发的未来,或者说,跨平台开发才是一种更好的开发方式。

既然它是热点,那肯定有可以讨论的地方。不过,在说 React Native 和 Flutter 之前,我觉得要先谈一谈「跨平台开发」。

移动跨平台方案

那什么是「跨平台开发」呢?

通常意义上来说,如果你想在 iOS 以及 Android 系统里,提供有相同内容的 App,那么使用 Apple 提供的构建工具,开发一个 App,然后上架到 AppStore,同时使用 Google 提供的构建工具,开发一个 App,然后上架到 Google Play。这两个 App 的实现,除了使用的工具不同之外,大部分业务逻辑是相同的。你可以发现,在这个过程中,产生了「重复」。

在重构时,如果项目里有大量的重复代码,或者重复逻辑,我们一般会将这些代码或逻辑以函数,模块或库的形式做封装,这个过程最大化的消除了重复的代码,最终达到简化项目的代码这一目的。

所以在我看来,「跨平台开发」也是基于这个思想而产生的,人们想要一套减少甚至不用写重复逻辑的解决方案,然后市场给予了人们期望的方案。跨平台方案的最大特点,可以用 Sun 当年在推广 Java 时,所使用的一句口号:」Write once, run anywhere」 作为总结。这一句话,也被如今的 React Native 以及 Flutter 引用或继承。

React Native

React Native 是由 Facebook 所主导的跨平台方案,得益于 Javascript 以及 ReactJS 的流行,React Native 在推出时,便受到了大量的追捧。除了跨平台的特性,React Native 最大的特点就是,可以使用 Javascript 来构建移动应用,并且最终应用的表现形式,可以做到和使用原生开发套件开发的应用相差无几。

React Native 能做到这些的核心原理就是 JavaScriptCore,一个 JavaScript 虚拟机。通过 JavaScriptCore,Javascript 能和其它语言互相转义,同时 JavaScriptCore 能运行在 iOS,Android 以及其它平台上,这些可能性放在一起,就成为了 React Native 的基底。有了这个基底之后,Facebook 便在这个基础之上,封装了各平台的应用层接口,定义了 Javascript 和封装后的接口之间的通信协议,最终,实现了使用 JavaScript 在不同平台开发具有原生体验的应用。

从实现原理以及架构上来看,React Native 似乎是一个不错的跨平台方案,只要封装好各平台的 API,那么我们有理由去相信,人们能够使用 React Native 开发出品质优秀的应用。但是事实上,理想和现实,还是有差距的。在 18 年,Airbnb 以及 Udacity 相继发表了博文,声明全面放弃 React Native,转向原生应用的开发。他们在文章中,提到的最多的就是,React Native 是一个不成熟的方案,虽然它有许许多多的优点,但是这些并不足以去弥补它的缺点带来的损失。AirBnB 以及 Udacity 可能是因为各种预期的理由而放弃了 React Native,不过在我看到 Discord 团队发表的 Why Discord is Sticking with React Native 博文后,算是彻底打消了我在生产环境使用 React Native 的念头。整篇文章看下来,让 Discord 团队仍然继续使用 React Native 的最大原因,似乎就是项目已经使用了它,骑虎难下了。

JavaScriptCore 的局限性,Facebook 在项目管理上的不成熟,以及不断出现的放弃声明,最终让人们发现,React Native 是一个有趣的方案,但并不是一个成熟稳定的方案。

Flutter

就在 React Native 的人气不断下跌的时候,Google 在一个恰到好处的时机,推出了一套跨平台方案:Flutter,将人们的目光再次聚集到跨平台开发上面。

Flutter 使用 Dart 这门较为冷门的语言来做开发,底基引擎主要由 Skia 和 Dart runtime 构成。Flutter 通过 Skia 和各平台的底层图形库对接,同时提供丰富的基于 Skia 的控件,来实现跨平台的开发。React Native 采用的方式是封装各个平台的应用层接口,而 Flutter 则直接打造了一套跨平台的应用层的开发套件。对这两种不同的方式,我们可以有一个直觉上的判断,Flutter 在性能上是要优于 React Native 的。因为 Flutter 的这种实现方式,其实早已被大量并广泛的使用了,最明显的例子就是游戏引擎。

种种对比和迹象表明,似乎 Flutter 是一个比 React Native 更好的跨平台方案。目前 Flutter 仍旧处于一个上升的势头,也有如阿里巴巴这种大厂给 Flutter 背书,颇具野心的底基框架让开发者有理由相信,只要投入足够的人力,Flutter 可以做到和原生开发一样好。

然而,Flutter 的缺点,也是源于它自行打造了框架,在很多平台特性上,诸如密码管理,选择光标等,Flutter 目前并不能支持,未来能否支持也要打上大大的问号,平台的特性可能和原生组件深度绑定,且目前没有其它接口,所以 Flutter 在现在这种状态下,只能是放弃这些特性的支持。需要提一点的是,React Native 在这方面没有太大的问题。

尽管有一些问题,不过 Flutter 表现出的潜力,还是让人们觉得,这是一个值得一试的方案,只要 Google 给予足够的支持。所以 Google 会吗?

结语

那么,我该选择哪种方案呢?答案:It depends on you.

事实上就是,没有一个完美的方案,任何方案都有利弊和取舍。想使用 Javascript 开发应用,那么就使用 React Native;想构建高性能的跨平台应用,Flutter 是个不错的选择;想最大化平台特性,那自然是原生的开发方式。

除了跨平台方案之间的比较之外,跨平台方案也在和原生开发方式竞争,而且这种竞争往往是不平等的,跨平台方案在新特性的支持上,始终要慢于原生开发方式,所以在市场占有率方面,原生开发方式就有天然的先发优势,这种差距很难被抹平。最终,你可能会发现,也许原生开发方式才是最合适的,因为除了「重复」外,原生开发方式相比跨平台方案,没有其它缺点了。

附记:之前我在 2019 年 3 月的 RTC Dev Meetup 北京站交流过上面的想法,感兴趣的读者可以查看演讲视频和 slide。

题图:Chris Sabor

如何能够保证自己应用数据的安全?|四月汇报

产品动态

应用归档自助激活

为了节省后端数据库的存储空间,我们会自动对近期(最近 30 天内)无数据 API 访问的应用进行归档,开发者要再次使用该应用,则需要联系技术支持进行手动激活。现在,我们在应用控制台上线了「自助激活」的功能,以方便大家使用。

如果有应用被归档了,打开控制台,会看到如下新的变化:

开发者可以点击「激活」按钮,并按照提示完成操作。一般而言,恢复一个归档应用大约需要 10-30 分钟,稍作等待之后您就可以正常使用了。

云引擎支持 MySQL 数据库

LeanCloud 云引擎作为一个带运维的托管平台,其实可以完成很多功能。现在我们计划让云引擎支持 MySQL 数据库,在底层数据存储上与 LeanCloud 存储服务解耦合,使之可以适用更多的业务场景,譬如自定义的业务后台、开源的 CMS 系统,等等。

使用方式上,增加一个 MySQL 数据库实例,其操作流程与云缓存类似:

MySQL 数据库的支持会首先在华北节点上线,之后会逐步扩大到其他节点,以后我们还会支持 MongoDB 数据库,敬请期待。

推荐内容

2019 前端框架对比及评测

测评名单中有没有你正在使用的框架,来看看它的成绩吧!

微信小程序 unionid 登录解决方案

如何在小程序中支持 unionid 登录,既能得到 unionid 登录机制的灵活性,又保留一键登录功能的便利性。

如何保护您的服务器免受黑客攻击

虽然我是一名经验丰富的开发人员,但在注册服务器两周后却遭到了黑客入侵。

常见问题

【数据安全】如何能够保证自己应用数据的安全?

最灵活的保护应用数据安全的方式是通过访问控制列表(Access Control List),通常简称为「ACL 机制」。ACL 背后的机制是将每个操作授权给一部分 用户(User)或者 角色(Role),只允许这些用户或角色执行这些操作。对 ACL 机制和数据安全方面更详细的解释可以参考文档:数据和安全

【控制台】控制台创建应用时,有两种应用计费方式:开发版与商用版。我该怎么选择创建何种应用?

开发版是针对开发测试阶段的项目或个人项目的解决方案。由于开发版是免费的,所以不提供数据备份恢复服务,在集群的设计上是不对可用性和数据的可靠性做保证的。

商用版应用底层使用的是高性能、高可用的基础设施,有更好的冗余和 SLA 保证。除了性能和稳定性方面的保证外,商用版用户还将免费得到工单技术支持、域名备案和绑定、自助数据恢复、自定义 SSL 证书、云引擎性能管理等增值服务。

综上,个人开发或者测试阶段可以选择「开发版」应用,商用项目建议选择「商用版」应用。

【绑定域名】文件不绑定自定义域名有什么影响?云引擎服务不绑定自定义域名有什么影响?

如果没绑定自定义域名,使用 LeanCloud 提供的公用域名,由于受到网络法规的管控与限制,我们无法 100% 保证该公用域名随时可用。为确保您的应用体验不会受到影响,请前往控制台 > 存储 >设置 >文件 设置好自定义文件域名。在控制台 > 个人中心 > 账号设置 > 域名绑定 中绑定云引擎域名。

点击查看更多 LeanCloud 用户常见问题解决办法

2019 前端框架对比及评测

Jacek Schae 原作,授权 LeanCloud 翻译。

我们将基于 RealWorld 示例应用对比前端框架。RealWorld 示例应用的特点:

  • RealWorld 应用

    比待办事项类应用更复杂。通常待办事项类应用不足以传达足够多的知识见解构建实际应用。

  • 标准化

    项目遵循特定规则。提供后端 API、静态标记语言、风格、API 规范。

  • 专业人士编写、审阅

    理想情况下,会是高一致性、高真实度的项目,由使用该技术的专业人士编写或审阅。

比较的库和框架

撰写本文时,RealWorld 示例应用仓库共包括 18 个 Conduit(Medium.com 克隆应用)实现。

本文不考虑框架的流行程度,RealWorld 仓库中列出的前端框架皆纳入对比范围。

RealWorld 前端框架

测度

性能

应用显示内容、可以使用需要花多久?

尺寸

应用有多大?我们只比较编译后的 JavaScript 文件大小。所有应用使用同样的 CSS 样式文件,CSS 文件加载自 CDN。所有应用使用的 HTML 也是一样的。这些框架都支持编译或转换为 JavaScript,所以我们仅仅测量 JavaScript 文件大小。

代码行数

根据规范创建 RealWorld 应用需要多少行代码?公平地说,某些实现的功能要略微多一点,但这应该没有什么显著的影响。我们仅仅测量每个应用的 src/ 目录。

性能

我们将使用 Chrome 的 Lighthouse Audit 测试性能。Lighthouse 返回 0 至 100 间的评分。0 为最低分。
继续阅读

Swift SDK 即时通讯功能(beta 版)发布|三月月报

产品更新

Swift SDK 即时通讯功能(beta 版)发布

3 月份我们发布了新版本的 Swift SDK(v16.0.0-beta),该版本包含了即时通讯的绝大部分常用功能,已经可以满足多数应用场景的需求,大家可以通过 CocoaPods 安装使用:

# Podfile sample
platform :ios, '10.0'
use_frameworks!

target 'YOUR_APP_TARGET' do # 替换 YOUR_APP_TARGET 为你的应用名称。
    pod 'LeanCloud'
end

下个月我们计划发布正式版,在 beta 版基础上会增加本地缓存、安全签名、黑名单和用户权限管理功能。同时,我们也会同步推出基于新 SDK 开发的全新 ChatKit 应用,新 ChatKit 会支持最新的 iOS 设备以及最近的三个 OS 大版本,它不会再以库的方式集成,而是以开源 Demo 的形式推出,其主要目的是展示如何使用 Swift SDK 来实现各种聊天功能。

除了即时通讯之外,Swift SDK 接下来也会加入 LiveQuery 功能,以及支持 Carthage 和 Swift Package Manager 两种集成方式,敬请期待。

vivo 混合推送(beta 版)发布

这一次我们采用了源码配 demo 的形式来公开这一功能:

vivo 混合推送 SDK 源代码:可参照这里
vivo 混合推送 demo:可参照这里
具体接入的流程可参考文档:vivo 混合推送

欢迎感兴趣的开发者试用,也期待大家给我们更多的反馈。

发票申请变化

从 2019 年 4 月 1 日起,我们将为普通发票申请额在壹万元以下的(含壹万元)用户开具增值税电子普通发票,超过壹万元的开具增值税纸质普通发票,电子发票将默认发送到用户信息中的邮箱。如果您有特殊要求(如必须要纸质发票或者发送到其他指定邮箱),请在申请发票备注栏里写明。

内容推荐

游戏出海技术指南:海外网络实践及优化专场

4 月 20 日,围绕海外市场趋势及网络优化等问题,一起来现场听听他们的实践经验。

 

七款酷炫的 Mac 屏保

你的桌面屏保是什么?

常见问题

【推送】为什么我收不到离线消息推送,该如何排查原因?

消息推送收不到的排查步骤如下:

  • 检查消息是否正常发送到服务器
  • 检查接收者用户是否离线,是否在 _Installation 表中有关联的设备记录
  • 检查是否有设置推送内容
  • 使用控制台推送在线发送工具实际发推送给目标设备查看推送是否出错,比如 iOS 证书不匹配,设备 Token 过期,设备 Token 和推送环境不匹配等

排查问题更具体的细节可以参考文档:为什么我收不到离线消息推送

【在线参数】统计服务下线以后,有办法给我单独开启在线参数功能吗?

作为统计服务的一个附属功能,在线参数已经和统计服务一同下线了。但为了不影响客户的线上业务,我们云端还支持在线参数的读取(4 月底才彻底下线)。

我们建议自行切换到存储服务里面来继续使用在线参数的功能,并且建议应用数特别多的时候将所有应用的在线参数合并到一个应用中,通过不同的名字或属性区分,这样可能最多也只需要开通一个商用版应用了。

如果不能短时间内完成迁移,可以走付费延长「在线参数」这一功能的方案,有此需求的用户可以发邮件至 support@leancloud.rocks 与我们联系,我们会对符合条件的应用重新开放在线参数的访问入口。

点击查看更多常见问题

安卓混合推送升级|二月刊

产品动态

游戏解决方案(Play)

二月份我们的游戏服务迎来了更多的开发者,同时也经历了他出生之后的第一次春节流量考验,虽然出现了临时扩容的紧张与慌乱,但所幸结果一切顺利,没有在全国人民面前掉链子,也让我们倍感欣慰。

实时对战 JavaScript SDK 支持 Promise 方式

前两天我们发布了 JavaScript SDK v0.18.0 正式版本,将异步调用的处理方式进行了一次升级,在原来的事件回调基础上,增加了 Promise 方式。例如在老版本 SDK 里用户连接至实时对战服务器的过程为:

// 发起请求
client.connect();

// 响应连接成功事件
client.on(Event.CONNECTED, () => {
  console.log('on joined lobby');
});

现在可以直接这样实现:

client.connect().then(()=> {
  // 连接成功
  console.log('on joined lobby');
}).catch((error) => {
  // 连接失败
    console.error(error.code, error.detail);
});

新版本完全遵循 ES6 Promises 标准,相信可以让大家开发起来更加方便。

游戏开发教程

应广大开发者的要求,我们工程师小姐姐还专门录制了四期直播课程,介绍游戏开发中的一些小窍门,有兴趣的朋友可以访问官网的学习页面或通过以下地址直接观看:

安卓混合推送升级

华为 HMS 推送增加 IntentUri 支持

对于华为的 HMS 推送,之前我们支持的版本缺少通知栏点击的自定义动作支持(推送请求的 IntentUri 参数),本月我们服务端上线了这一功能,现在开发者使用 v4.7.0 以上版本的混合推送 SDK,就可以使用这一功能,具体用法可以参考文档:HMS 推送接入指南

新功能预告

我们计划在 3 月份增加对 VIVO 推送支持,但是因为我们自己客户端数量有限,怕测试不完全,所以我们会推出一个 early-bird 版本,邀请大家参与前期测试。欢迎感兴趣的开发者通过发送邮件或者在项目 repo 下直接报名参与,谢谢。

Share

使用 Leancloud 实现 React Native App 的消息推送 – Android 篇

在 React Native 开发过程中征服的一个小小领域:消息推送。

【游戏开发】如何实现手游中的账户系统

这篇文章以 Unity 游戏引擎中的 C# 语言为示例,主要讲解如何实现几种主流的登录方式,包括游客登录、游客账号升级、手机号验证码登录、用户名密码注册及登录。

常见问题

【存储】怎么存储和获取音频/视频文件的时长 ?

AV.File 的 metaData 属性,可以用来保存和获取该文件对象的元数据信息。可以在上传音频文件时获取音频长度然后通过 metaData 方法手动添加文件时长。

【即时通信】对话查询如何区分单聊还是群聊?

SDK 层面不区分单聊和群聊。可以使用会话的成员数量做区分。「会话成员数量为 2」即是单聊,大于 2 即可看作群聊。

【即时通信】语音消息如何标记消息是否已经播放,类似微信语音消息标记是否已读的小红点,可以提供一些思路吗?

因为一个群里可能有很多人,每个人对一条消息都有一个「是否已播放」的状态,所以建议在客户端维护这个「未播放」状态。

做法之一是可以在客户端维护一个「收到了但是没有播放的音频文件」列表,然后拿到消息文件对比一下客户端是否已经播放过。

【即时通信】使用 where 查询条件查询某用户的会话列表,为什么查询结果是系统内所有用户的会话?

当没有添加任何 where 查询条件时,query 会使用默认查询条件 where={"m":{"$in":["client ID"]}},即查询成员含有此 client ID 的对话;当添加了任意 where 查询条件时,query 会严格按 where 条件来查询,即覆盖默认的 where 查询条件。

以 Objective – C 举例,添加了自定义的 where 查询条件时,如果想查询含有此 client ID 的对话,使用 [query whereKey:@"m" containedIn:@[@"client ID"]] 增加一个查询条件即可。