移动产品基础模块设计规范之应用更新

2018-04-01    阅读次数:43    APP升级更新

并不是之前的文章有了什么问题,而是要扩展之前的应用更新范围,将 Android 这个复杂的环境考虑进去。当然,看标题也比较清楚了。

我想,当你和这片文章有缘时,一定是你也遇到了和我类似的问题,并且在寻找更好的解决方案。那么,我把我自己近期的思考整理出来,我们一起探讨下。

这次面对的是两个问题

1. Android 应用分渠道设置更新;

2. Android 应用分地域设置更新;

为什么会面对这两个问题呢?

在利益面前,一些阻碍都需要也必须被跨过!嗯!(嗯,是自言自语的(oo))

比如,应用想在某些渠道发布的时候,一些功能,比如广告、网赚等,该渠道是不允许出现的,甚至连关闭功能后(后端/后台控制),但有对应的 SDK 也不被允许。

再比如,一些城市中,对一些功能也是比较敏感的,例如帝都;再再比如,和一些城市的某些公司合作过程中,不希望让这些合作公司知道自己做了某些功能。等等,还有哪些问题,等待你的发现哦。

感觉,是不是很神奇?!

接下来,讲讲,如何解决上述的问题呢?

其实,主要的并不在升级管理自身,而是在控制或者说配置的逻辑上。我会分两部分来描述,一部分针对应用升级,另一部分针对控制(我暂且叫它控制,不清楚大家各自的工作中,这部分会起什么有趣的名字呢?来,感兴趣的也给我留言和评论吧,一起聊聊~)

第一部分 应用更新

这部分会细化开篇提到的很久之前的文章,调整之前的一些逻辑,并补充不足。这部分先讲下新增的部分——渠道列表,后面会介绍一些应用升级相关的规划和策略等逻辑。

1. 渠道管理 

原因:应用推广使用,面对频率较高的新增渠道,比如新增应用市场、新增应用市场活动包、新增推广包等等,这些都需要频繁的新增渠道,总是由后端来搞太复杂,效率也比较低。 

优势:有了这个表,能够让运营相关人员轻松搞定,并且还能协调渠道、开发配合完成工作;这个表在控制部分也会用到,后面我会具体介绍。真是一举多得的好办法。 

思考:其实这是在应用版本升级策略中,后端/后台开发过程中必然会用到的,渠道表在后台开发中,实现成本也比较低。 

规划:见下图渠道管理 

1渠道管理.png

渠道管理

逻辑:并不复杂,通过后台新增渠道记录,在后台展示,并能够控制该渠道是否启用。当然会有一些状态,比如:第一次添加,列表中不存在,如何提示;再次添加,列表中已存在,如何提示;第一次添加成功后,如何提示等等的处理逻辑。看,简单吧~相信,你和我一样,也能考虑到。再看看,是不是还有哪些没考虑到的问题呢?比如操作者,谁添加、停用/启用的,方便后端查看记录,已确定责任人(这是产品很成熟,组织很完善的时候考虑的;初创团队没必要这么搞,太耗精力体力和时间了。)其他,请自行思考补充,放到自己的小本本上呗。

2. 应用更新

这部分更多的是对文章《移动产品基础模块设计规范之应用更新》中涉及选择更新版本以及是否强制更新的补充和修正。

补充修正之一:原文章中在选择更新版本的设置上,过于死板,不灵活。新的版本更新将待更新版本的选择变为填写,并且可以跨版本以区间的方式进行设置。 

补充修正之二:对是否强制更新的调整上,新版本采用“更新频率”的方式取而代之,并可在“每次启动提示”、“每天启动提示”以及“每周启动提示”中做选择,灵活性和可控性可见一斑。 

补充修正之三:新增了渠道选择,这是之前并未考虑到的。针对渠道设置更新版本,是针对不同渠道政策的应对方式。 

规划:见下图添加新版本

 

2添加新版本.png

添加新版本

逻辑:除了以下需要着重强调的两个新增的逻辑之外,在之前的文章以及本文以上的内容中,基本上都有涉及。这里我们强调以下两个位置:

1)包名。相比之前的文章,新增包名的选择。目的是针对不同的包名——针对渠道以及版本——做对应的升级策略。至于好处嘛,你猜猜看?

2)版本号(整数值)。其实大多数安卓的应用市场会按照应用的整数值版本号,来区别在对应的市场中决定是否提示升级的。而版本号只是在对应的位置做显示用的值而已,不作为判断在对应的市场决定是否升级的。

3. 版本更新列表

版本更新列表见下图:

 

3 版本更新列表.png

版本更新列表

其实就是“应用更新”新增并确定之后生成的记录列表。这里需要注意的是,这里的逻辑与之前文章中不同。在“应用更新”中,如果多选渠道,将在版本更新列表中根据所选渠道的数量,生成对应数量的记录,方便后期针对单一渠道进行调整。

第二部分 控制

这部分是新增的部分,是近一年多的新发现,也会有新的感受。针对对应的渠道或者地域,对内容或者功能进行控制,也是不可或缺的。

其实不管是根据渠道控制,还是地域,主要是看对应的渠道和地域,不允许或者由于合作关系不能出现什么功能,来做对应的处理的。原因我在本文开始的时候提过了,大家在这部分也要格外注意。

1. 添加渠道控制和地域控制 

 

4添加渠道控制.png

添加渠道控制

 

5添加地域控制.png

添加地域控制

在渠道控制中,我们发现本文开始提到的渠道管理终于出现了。看吧,只要在渠道管理中添加了,这里就能同步获得了,很方便吧(得意)!

对比渠道控制和地域控制,不同的是地域控制除了地域之外,只需要考虑包名,原因是某一地域一旦需要控制对应的内容和功能,基本上不需要区分版本,只需要针对包名做处理就可以了。(请自行脑补,这么处理的原因是什么?)

2. 渠道控制和地域控制列表

 

6渠道控制列表.png

渠道控制列表

 

7地域控制列表.png

地域控制列表

这里同样有一个地方的逻辑需要注意,在对应的控制列表中,由于添加的时候会选择多个渠道或者地域,在对应的列表中会显示多条记录。这个逻辑和版本更新列表与添加版本更新的逻辑是类似的,这样操作会灵活很多。

以上,就是对之前文章《移动产品基础模块设计规范之应用更新》的补充和修正了。希望能够在这一部分,给大家一定的启发和引导。如有不当之处,还请提出来,感谢!

题外话,最近可能要认真的梳理下之前写的文章了,因为发现之前的文章存在很多不足以及严重的逻辑问题。也感谢,在文章下留言评论的小伙伴,是因为他们的留言评论,我才又重新读了自己之前的文章,也看到了自己当时的不足(有种自我升级的感觉,不是么,笑)。也感谢你们,那样不仅有了新的文章,更有了全新的我。已经是最后了,我的思路和逻辑一定还存在不足和缺陷,希望大家多评论交流,那样才能相互进步。谢谢!

相关阅读:https://mp.weixin.qq.com/s?__biz=MzI0MDI0ODIxMw==&mid=2649512820&idx=1&sn=c54a8ecadb5478cd68cff6181809e404&scene=21#wechat_redirect

来源:pmcaff

  028-8453-1500