钉钉从产品在自身的角度上讲做好自己就行,不需要刻意讨好这些给差评的学生,因为一个产品的核心是看自己的消费人群,在市场上找准自己的定位即可,我觉得这次钉钉差评事件恰恰是证明钉钉核心竞争力的体现,在全国这么多学生一起上课的压力下,钉钉顶住了这么高的峰值流量,没有让服务器崩溃,还是非常的难能可贵的。现在就钉钉展开三个方面的讨论。
1从开发者的角度出发。开发者需要做的是保证这么大的用户量在同时使用的时候保证APP不会存在崩溃,众所周知如果用户的流量过大,服务器承载的负荷是异常重大的,很多时候会导致APP不能够很好的使用,对于开发者来说他们的终极目的是保证该APP正常的运行。
2从公司的角度出发。本身我觉得阿里巴巴笑开了花,这个事件也确实是阿里走向更宽广市场的一个契机,可能很多从阿里的角度会觉得应该讨好这部分的用户,也就是这么多的学生,我觉得这是非常不可取的,阿里现在需要做的就是老老实实的把这个产品做好,不用刻意的声明或者发生,对于学生们给差评这个问题其实不需要回应,做好自己就行。
3从产品本身的角度出发。钉钉在这个特殊的时期火了,无疑让阿里火了一把,这个APP的初衷还是主要面向的对象是公司对于员工的管理。所以学生根本不是他们的面向对象,等疫情过去之后一切就会归于平静,哪里来的回哪里去,所以产品本身不需要针对于学生做出什么样的改变,按照老板们的用户需求正常升级迭代即可。
综上所述,钉钉这个产品不需要刻意讨好任何人,按流程开发升级即可。
成功后示例开发前准备:
1,开放平台注册申请权限
2,选择钉钉应用类型,创建应用,获取AppKey,AppSecret,CORP_ID
3,准备开发环境 静态页面、JS,CSS放在ngnix,本地接口用tomcat。(这个我在想flutter 如何能够放到里面不是太理解)
4,调试:钉钉的H5微应用调试只能“真机”调试,所以 建议 调试的时候使用 内网穿透工具 ;
5,JSAPI免登授权码 获取当前钉钉登录用户的账号信息,需要通过免登授权码换取 (这个需要后端api进行辅助 前端和后端才能进行通信)
在开发者后台添加完大概就这样了, 其他信息:如 回调URL(在服务端搭好之后填写), 首页地址等, 后续可以修改
1 相关配置参数可参照上面 应用基础信息 那张图来一 一对应
2 所有的关键信息 是存储在服务端的, 如我们的suiteKey/suiteSecret/suiteTicket/aesKey/token;
3 所以和钉钉相关的数据交互都是在服务端,后台完成的, 除了获取免登授权码;
4 我们的前端和我们的服务端交互过程中, corpId 由前端获取 , 传递给我们;
5 服务端和钉钉交互所使用的accessToken , 可以每次都去钉钉重新获取, 但是更建议在有效期内, 后端获取一次, 然后存储在前端, 每次的数据交互将token 传递给后端;
6 钉钉向我们服务器发送请求, 也就是钉钉应用里面的回调地址;
7 钉钉的所有消息都是通过回调通知我们的, 而且消息的结构是一致的;
根据上面的相关说明将服务端放置在自己的公网服务器也好,或者使用相关的 内网穿透工具 也好 (自行解决)
总之, 现在要有一个可以 访问我们 服务端项目的 公网地址
确保你自己的服务器可以使用公网地址访问到,并且成功返回数据;
同时确保:
必须有回调地址借口用来接收钉钉发送的消息; (本文示例地址:/ding/callback)
必须有一个接收免登授权码和企业corpId 来返回用户信息的接口; (本文示例地址:/ding/login )
公网可以访问的服务端地址, 接收钉钉发给我们的消息(回调地址)如:>
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)