官方为什么不给回应呢?
小程序更新之问上周微信更新6.7.2版本,从大家对微信小版本更新的反应来看,用户端可以算是无感知更新,但是在开发者群体中,可谓是怨声载道。 微信版本更新附带小程序基础库更新,而这次更新,带来了诸多问题,暂时发现的有: 更新到6.7.2小程序内嵌webview,顶部标题栏自定义失效 安卓 WebView position:fixed 错位问题 getBackgroundAudioManager 接口为什么无法后台播放音频了 微信小程序跳转返回,onshow监听到的APPID问题 微信6.7.2测试版getImageInfo这个方法不能得到本地图片的数据 小程序头部系统栏目在tabBar置顶的情况下 位置互换(微信6.7.2)版本 等等 从上面来看主要是web-view和音频API的调整(如果忽略了其它还请提醒),对于不内嵌web-view和不使用音频的小程序来说,本次更新可以忽略,可惜还是有不少小程序躲过了初一,没躲过十五,我司的小程序就不幸属于其一。 在此不讨论技术上的问题,因为怎么实现这些调整是微信的事,我只想问微信小程序团队几句: 你们进行小程序调整的根据在哪儿?有没有在用户群体和开发者群体进行调研? 你们调整之前有没有在开发者社区进行公示或者告知? 你们内部有没有开发流程规范?包括从开发者工具、开发规范调整、文档更新、社区运营一整套的流程。 基础库更新上线之后,如果出现大面积问题,你们的补救措施在哪儿? 以上几个问题,希望能够有官方人员给予解答。 微信小程序和小游戏带来了一大波红利,这点是毫无置疑的,甚至连微博如此的流量巨兽都做起了小程序。但是从今年开始,微信的更新逐渐暴露出问题,重大调整在社区(甚至是文档更新人员)毫不知情的情况下进行,导致许多小程序团队都要进行临时调整,紧急上线。 我们在意的并不是更新带来的问题,而是更新的流程规范。下面的几个截图是从开发者社区截取的 [图片] [图片][图片] 可以看到,开发者完全不知道,也并不理解本次更新的意义,而对于开发者提出的质疑,官方也并未解答,只是单纯地贴出文档。而这个文档,也是在微信更新大面积铺开,社区和用户之间发现大量问题之后才进行更新的。 众所周知,W3C的规范制定流程每一个都耗时巨久,而耗时带来的则是稳定性,一旦标准成为规范,几乎不太可能会被撤销或者再次修改。而在每一个阶段,规范都将向社区展示,社区则可以进行反馈,最终决定一个一致的方案。 W3C技术报告开发流程 发布第一份公开工作草案(First Public Working Draft) [可选]发布几份修订公开工作草案(revised Public Working Drafts) 发布候选建议书(Candidate Recommendation) 发布提议建议书(Proposed Recommendation) 发布W3C建议书(W3C Recommendation) [可选]发布编辑建议书(Edited Recommendation) 我们希望小程序团队能够制定出一套类似W3C的规范,在每一个阶段对社区进行公示,听取社区反馈意见,综合之后再进行调整,并及时更新文档。这样无论对于微信想要打造的小程序生态,还是开发者和用户来讲,都大有裨益。
2018-08-24同问!有同样的需求!从小程序引导用户去 自己公司的公众号,在客服消息里发送二维码来 关注公众号
小程序引导用户关注同主体下的公众号- 需求的场景描述(希望解决的问题) 小程序模板消息,在之前的提问中已经说到,实现不了消息提醒其他非表单交互的人员(比如,报修提醒工程人员、客户下单提醒客服人员等很多)。 所以就只能用到公众号模板消息。这样就存在一个需求,需要打通两边的用户,这个也没问题了。 但关键是为了要达到无缝的体验效果,能让用户在使用小程序时,可以方便地关注公众号,或者引导。 - 希望提供的能力 1、小程序能打开同主体下已关联的公众号,没关注的则打开关注页面。 2、关注后能返回code或者openid最好了。
2018-08-21代码片段:wechatide://minicode/XvhlSJmV7I1g
【紧急bug】实例化动画执行,在开发者工具有效,手机无效[图片] [图片] [图片] 一个“爱心”,先隐藏,点击显示,scale(2),定时器再scale(0);开发者工具很正常,手机上不行(第一遍执行,后面再点就没反应)
2018-08-17