概述
1、前言
上回Android如何实现时间线效果 说到，小庄吭哧吭哧的撸完了需求，虽然功能上可以应付过去了，但他总觉得什么地方还可以再优化一下，可以搞一个较为通用的组件，顺便还能锻炼一下自己的编码设计能力，岂不美哉！一起看看他今天又要搞什么幺蛾子呗？
2、分析
2.1提出功能
这回小庄自己当上产品了，他上上下下的看了几遍这个时间线，亲自提出了几点不满可以优化的地方：
- 最好可以根据位置决定显示什么东西，比如第一个/最后一个一般最重要，要跟别的不一样！
- 我要把圆点改成图片，根据状态展示不同的图片！
- 不，我要圆点和图片交错着来，就像某宝物流信息那样！
产品小庄被程序员小庄关了小黑屋。程序员小庄觉得这几点需求就暂时够了，可以先着手尝试一下了
2.2需求分析
- 从需求上来看，变的主要都是圆点（以下称结点）的部分，画线的部分应该不会有什么改动，可以沿用
- 结点部分不仅会变，还会变的多种多样，千奇百怪，这里的灵活性要求较高
- 原来只有根据状态决定结点样式，现在还要根据位置，也要加入考虑
2.3方案设想
是什么让我们可以实现代码复用（线），又可以实现灵活定制（结点）呢？是继承呀！（当然也可以考虑组合）综合考虑，画线的部分可以放在父类中，画结点的部分则可以设计一个抽象方法，交给子类自由实现
3、编码
重构的过程很快乐（不是），但是步子太大却容易拉胯。小庄打算先改动代码结构，并保持原来效果可以运行
3.1第三版
说干就干，小庄决定抽取一个drawNode抽象方法，让子类去画圆点，而在父类中继续保留画线的操作。
- 子类圆点的颜色其实可以复用父类中原本的color属性，但是以防万一，我们还是重新定义一个dotColor属性
- 但是由于父类现在不画结点了，它怎么知道，现在结点宽度是多少呢？整个轴线的x坐标在哪里呢？不知道这些，没法画线呀
- 为解决这个问题，小庄决定再定义一个nodeWidth属性，用来设置结点的宽度还有一个问题，不知道结点的高度，就不知道上线应该在什么y坐标停，下线应该从什么y坐标开始
嗯？你说一条线从顶部画到底部？这也太粗暴了，如果圆点是空心的就暴露了呀，为解决这个问题，小庄只能再定义一个nodeHeight属性，用来设置结点的高度。现在这个类里面的属性越来越多了，小庄感觉这离自己追求的优雅相去甚远
abstract class ThirdVerTimeline<T> : RecyclerView.ItemDecoration() {
// 不重要的属性...
var color: (item: T) -> Int = { _ -> Color.GRAY }
var nodeWidth = 30
var nodeHeight = 30
override fun onDraw(c: Canvas, parent: RecyclerView, state: RecyclerView.State) {
super.onDraw(c, parent, state)
val count = parent.childCount
for (i in 0 until count) {
// 【不重要的变量】...
val xPosition = (nodeWidth / 2 + paddingLeft).toFloat() //-->这里有修改，用nodeWidth计算x坐标
// 画上线和下线...//-->这里有修改，用nodeHeight参与计算
}
// 子类画结点！
drawNode(c, parent, state)
}
// 由子类实现
protected abstract fun drawNode(c: Canvas, parent: RecyclerView, state: RecyclerView.State)
override fun getItemOffsets(outRect: Rect, view: View, parent: RecyclerView, state: RecyclerView.State) {
super.getItemOffsets(outRect, view, parent, state)
outRect.left = paddingLeft + paddingRight + nodeWidth //-->这里有修改，用nodeWidth计算item的偏移量
}
}
class DotTimeline<T> :ThirdVerTimeline<T>(){
// 这里是子类自己的paint，不复用父类
private val paint = Paint(Paint.ANTI_ALIAS_FLAG)
val radius = 10f
var dotColor: (item: T) -> Int = { _ -> Color.GRAY }
override fun drawNode(c: Canvas, parent: RecyclerView, state: RecyclerView.State) {
val count = parent.childCount
for (i in 0 until count) {
// 【不重要的变量】...
// 画圆点！
paint.color = dotColor(item)
c.drawCircle(xPosition, itemView.top + offset + radius, radius, paint)
}
}
}
运行起来完全没问题！不过观众姥爷们肯定发现了一个致命问题，那就是：为什么在父类和子类里都要各自做循环呢？？这是妥妥的代码重复呀！哎，不着急，为了解决这个问题，我们需要重新设计一下drawNode方法。
你可能会想，把drawNode直接放进循环里不就行了吗？的确，但是在那之前，我们先来看一下【不重要的变量】里都有哪些变量：
// 获取当前的itemView val itemView = parent.getChildAt(i) // 当前项的x坐标，整个轴线的x坐标都是相同的 val xPosition = (nodeWidth / 2 + paddingLeft).toFloat() // 当前项的真正位置 val adapterPosition = parent.getChildAdapterPosition(itemView) // 当前项的数据源 val item = data[adapterPosition]
子类中是不是真的都需要父类传给它这些变量呢？让我们来研究一下：
itemView：子类中画结点需要确定自身的位置等信息 --> 需要xPosition：虽然子类可以自己计算，但是由父类传给子类岂不是更能保证它们都在同一条直线上？--> 需要adapterPosition：需求中说到要根据位置绘制结点 --> 需要item：子类自然要根据数据的状态来判断画什么 --> 需要
其实说来说去，这些变量子类中都可以计算得到，之所以要由父类传给子类，大致有以下几个理由：
- 减少重复代码量，遵循DRY原则（Don't repeat yourself）
- 防止父类和子类的数据获取有出入，子类不按照父类的规则来计算
- 某一天又要改规则了，只需改动父类就可以了，无需改动多处
至于一个方法这么多个参数真的好吗？这~我暂时也无能为力啦。修改后的代码如下：
abstract class ThirdVerTimeline<T> : RecyclerView.ItemDecoration() {
// 不重要的属性...
var color: (item: T) -> Int = { _ -> Color.GRAY }
override fun onDraw(c: Canvas, parent: RecyclerView, state: RecyclerView.State) {
super.onDraw(c, parent, state)
val count = parent.childCount
for (i in 0 until count) {
// 【重要的变量】...
// 画上线和下线...
// 子类画结点！
drawNode(c, parent, state, xPosition, item, itemView, adapterPosition)
}
}
// 由子类实现
protected abstract fun drawNode(c: Canvas, parent: RecyclerView, state: RecyclerView.State,
xPosition: Float, item: T, itemView: View, adapterPosition: Int)
// getItemOffsets...
}
class DotTimeline<T> :ThirdVerTimeline<T>(){
private val paint = Paint(Paint.ANTI_ALIAS_FLAG)
private val radius = 10f
override fun drawNode(c: Canvas, parent: RecyclerView, state: RecyclerView.State,
xPosition: Float, item: T, itemView: View, adapterPosition: Int) {
// 简简单单画圆即可
paint.color = color(item)
c.drawCircle(xPosition, itemView.top + offset + radius, radius, paint)
}
}
搞了好大一圈，才只是实现了原本的功能而已，由于效果都是一模一样的，我就不贴图了。但是接下来我们就可以随心所欲对父类进行扩展啦
不知道有没有小伙伴有疑问，这不是也类似于Java中的模板模式吗？你怎么不用上一章说的kotlin的函数类型啦？
的确用函数类型可以帮我们减少这些子类的数量，使用时只要新建一个ItemDecoration，并且设置drawNode属性怎么画就可以了，想想就美滋滋。然而我不这么做至少有两个理由：
- 实现一个DotTimeline，可以复用，不至于每个要用到的地方都写一遍drawNode的内容（当然也可能目前只有一处用到，但是未来是很长的~）
- 使DotTimeline的使用者关心的事情更少，职责更单一（其实我也是写一半才想起的，也许并没有人有这个疑问吧哈哈哈）
3.2第四版
第四版基于第三版的父类，实现个图片的需求~
- 类似于之前提到的
color属性，这里我们也定义一个drawableRes属性，用它来设置图片选择策略 - 同时我们还可以用
nodeWidth和nodeHeight用来控制图片的大小，毕竟我们并不是总能找到尺寸合适的图片
class PicTimeline<T>(private val context: Context) : ThirdVerTimeline<T>() {
lateinit var drawableRes: (item: T) -> Int
override fun drawNode(c: Canvas, parent: RecyclerView, state: RecyclerView.State,
xPosition: Float, item: T, itemView: View, adapterPosition: Int) {
// 从图片选择策略中获得bitmap
val bitmap = BitmapFactory.decodeResource(context.resources, drawableRes(item))
val src = Rect(0, 0, bitmap.width, bitmap.height)
val left = xPosition - nodeWidth / 2
val top = (itemView.top + offset).toFloat()
val dst = RectF(left, top, left + nodeWidth, top + nodeHeight)
// 画图片
c.drawBitmap(bitmap, src, dst, Paint()
)
}
}
在使用的时候，要设置一下drawableRes属性（记得也要设置color属性，这个属性现在代表线的颜色）
picTimeline.drawableRes = { item ->
when (item.status) {
1 -> R.drawable.ic_checked
else -> R.drawable.ic_uncheck
}
}
rv_timeline4.addItemDecoration(picTimeline)
然后就可以运行一下看看效果~
是真的！可以诶！小庄在成功的大路上猪突猛进！
至于图片和圆点交错的效果，现在看起来也就比较简单了，只要把第三版的圆点和第四版的图片中的代码混搭在一起就可以了。这边就不贴代码了，万一有感兴趣的朋友可以到代码仓库中查看。直接来看看效果如何吧
还可以还可以
3.3最终版
其实小庄还有很多功能想实现的，但是好像没必要再写下去了，无非就是一些属性的修修改改罢辽。而且实际项目中可能也用不到这么多功能，没有实际需求指导，越扩展反而越复杂、越难用。
最后放一张全家福，有需要的朋友可以参考一下我的思路，或者选取合适的部分代码食用，每一个版本的示例代码都在这里！
如图，最后三个是最终的版本。在最终版中，我又实现了：
- 时间线的左右位置
- 圆点的类型：实心和边框
- 结点的不同大小
- 线的宽度
- item的间距（赠送的）
并且在颜色color/图片drawableRes选择策略中加入adapterPosition参数，可以根据位置进行设置策略啦
到此这篇关于 Android如何实现时间线效果（下）的文章就介绍到这了,更多相关 Android时间线效果内容请搜索靠谱客以前的文章或继续浏览下面的相关文章希望大家以后多多支持靠谱客！
最后
以上就是时尚鱼为你收集整理的Android如何实现时间线效果（下）的全部内容，希望文章能够帮你解决Android如何实现时间线效果（下）所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复