Android如何實現(xiàn)時間線效果(下)
1、前言
上回Android如何實現(xiàn)時間線效果 說到,小莊吭哧吭哧的擼完了需求,雖然功能上可以應(yīng)付過去了,但他總覺得什么地方還可以再優(yōu)化一下,可以搞一個較為通用的組件,順便還能鍛煉一下自己的編碼設(shè)計能力,豈不美哉!一起看看他今天又要搞什么幺蛾子唄?
2、分析
2.1提出功能

這回小莊自己當(dāng)上產(chǎn)品了,他上上下下的看了幾遍這個時間線,親自提出了幾點不滿可以優(yōu)化的地方:
- 最好可以根據(jù)位置決定顯示什么東西,比如第一個/最后一個一般最重要,要跟別的不一樣!
- 我要把圓點改成圖片,根據(jù)狀態(tài)展示不同的圖片!
- 不,我要圓點和圖片交錯著來,就像某寶物流信息那樣!
產(chǎn)品小莊被程序員小莊關(guān)了小黑屋。程序員小莊覺得這幾點需求就暫時夠了,可以先著手嘗試一下了
2.2需求分析
- 從需求上來看,變的主要都是圓點(以下稱結(jié)點)的部分,畫線的部分應(yīng)該不會有什么改動,可以沿用
- 結(jié)點部分不僅會變,還會變的多種多樣,千奇百怪,這里的靈活性要求較高
- 原來只有根據(jù)狀態(tài)決定結(jié)點樣式,現(xiàn)在還要根據(jù)位置,也要加入考慮
2.3方案設(shè)想
是什么讓我們可以實現(xiàn)代碼復(fù)用(線),又可以實現(xiàn)靈活定制(結(jié)點)呢?是繼承呀?。ó?dāng)然也可以考慮組合)綜合考慮,畫線的部分可以放在父類中,畫結(jié)點的部分則可以設(shè)計一個抽象方法,交給子類自由實現(xiàn)
3、編碼
重構(gòu)的過程很快樂(不是),但是步子太大卻容易拉胯。小莊打算先改動代碼結(jié)構(gòu),并保持原來效果可以運行
3.1第三版
說干就干,小莊決定抽取一個drawNode抽象方法,讓子類去畫圓點,而在父類中繼續(xù)保留畫線的操作。
- 子類圓點的顏色其實可以復(fù)用父類中原本的color屬性,但是以防萬一,我們還是重新定義一個dotColor屬性
- 但是由于父類現(xiàn)在不畫結(jié)點了,它怎么知道,現(xiàn)在結(jié)點寬度是多少呢?整個軸線的x坐標(biāo)在哪里呢?不知道這些,沒法畫線呀
- 為解決這個問題,小莊決定再定義一個nodeWidth屬性,用來設(shè)置結(jié)點的寬度還有一個問題,不知道結(jié)點的高度,就不知道上線應(yīng)該在什么y坐標(biāo)停,下線應(yīng)該從什么y坐標(biāo)開始
嗯?你說一條線從頂部畫到底部?這也太粗暴了,如果圓點是空心的就暴露了呀,為解決這個問題,小莊只能再定義一個nodeHeight屬性,用來設(shè)置結(jié)點的高度。現(xiàn)在這個類里面的屬性越來越多了,小莊感覺這離自己追求的優(yōu)雅相去甚遠
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坐標(biāo)
// 畫上線和下線...//-->這里有修改,用nodeHeight參與計算
}
// 子類畫結(jié)點!
drawNode(c, parent, state)
}
// 由子類實現(xiàn)
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,不復(fù)用父類
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)
}
}
}
運行起來完全沒問題!不過觀眾姥爺們肯定發(fā)現(xiàn)了一個致命問題,那就是:為什么在父類和子類里都要各自做循環(huán)呢??這是妥妥的代碼重復(fù)呀!哎,不著急,為了解決這個問題,我們需要重新設(shè)計一下drawNode方法。
你可能會想,把drawNode直接放進循環(huán)里不就行了嗎?的確,但是在那之前,我們先來看一下【不重要的變量】里都有哪些變量:
// 獲取當(dāng)前的itemView val itemView = parent.getChildAt(i) // 當(dāng)前項的x坐標(biāo),整個軸線的x坐標(biāo)都是相同的 val xPosition = (nodeWidth / 2 + paddingLeft).toFloat() // 當(dāng)前項的真正位置 val adapterPosition = parent.getChildAdapterPosition(itemView) // 當(dāng)前項的數(shù)據(jù)源 val item = data[adapterPosition]
子類中是不是真的都需要父類傳給它這些變量呢?讓我們來研究一下:
itemView:子類中畫結(jié)點需要確定自身的位置等信息 --> 需要xPosition:雖然子類可以自己計算,但是由父類傳給子類豈不是更能保證它們都在同一條直線上?--> 需要adapterPosition:需求中說到要根據(jù)位置繪制結(jié)點 --> 需要item:子類自然要根據(jù)數(shù)據(jù)的狀態(tài)來判斷畫什么 --> 需要
其實說來說去,這些變量子類中都可以計算得到,之所以要由父類傳給子類,大致有以下幾個理由:
- 減少重復(fù)代碼量,遵循DRY原則(Don't repeat yourself)
- 防止父類和子類的數(shù)據(jù)獲取有出入,子類不按照父類的規(guī)則來計算
- 某一天又要改規(guī)則了,只需改動父類就可以了,無需改動多處
至于一個方法這么多個參數(shù)真的好嗎?這~我暫時也無能為力啦。修改后的代碼如下:
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) {
// 【重要的變量】...
// 畫上線和下線...
// 子類畫結(jié)點!
drawNode(c, parent, state, xPosition, item, itemView, adapterPosition)
}
}
// 由子類實現(xiàn)
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)
}
}
搞了好大一圈,才只是實現(xiàn)了原本的功能而已,由于效果都是一模一樣的,我就不貼圖了。但是接下來我們就可以隨心所欲對父類進行擴展啦
不知道有沒有小伙伴有疑問,這不是也類似于Java中的模板模式嗎?你怎么不用上一章說的kotlin的函數(shù)類型啦?
的確用函數(shù)類型可以幫我們減少這些子類的數(shù)量,使用時只要新建一個ItemDecoration,并且設(shè)置drawNode屬性怎么畫就可以了,想想就美滋滋。然而我不這么做至少有兩個理由:
- 實現(xiàn)一個DotTimeline,可以復(fù)用,不至于每個要用到的地方都寫一遍drawNode的內(nèi)容(當(dāng)然也可能目前只有一處用到,但是未來是很長的~)
- 使DotTimeline的使用者關(guān)心的事情更少,職責(zé)更單一(其實我也是寫一半才想起的,也許并沒有人有這個疑問吧哈哈哈)
3.2第四版
第四版基于第三版的父類,實現(xiàn)個圖片的需求~
- 類似于之前提到的
color屬性,這里我們也定義一個drawableRes屬性,用它來設(shè)置圖片選擇策略 - 同時我們還可以用
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()
)
}
}
在使用的時候,要設(shè)置一下drawableRes屬性(記得也要設(shè)置color屬性,這個屬性現(xiàn)在代表線的顏色)
picTimeline.drawableRes = { item ->
when (item.status) {
1 -> R.drawable.ic_checked
else -> R.drawable.ic_uncheck
}
}
rv_timeline4.addItemDecoration(picTimeline)
然后就可以運行一下看看效果~

是真的!可以誒!小莊在成功的大路上豬突猛進!
至于圖片和圓點交錯的效果,現(xiàn)在看起來也就比較簡單了,只要把第三版的圓點和第四版的圖片中的代碼混搭在一起就可以了。這邊就不貼代碼了,萬一有感興趣的朋友可以到代碼倉庫中查看。直接來看看效果如何吧

還可以還可以
3.3最終版
其實小莊還有很多功能想實現(xiàn)的,但是好像沒必要再寫下去了,無非就是一些屬性的修修改改罷遼。而且實際項目中可能也用不到這么多功能,沒有實際需求指導(dǎo),越擴展反而越復(fù)雜、越難用。
最后放一張全家福,有需要的朋友可以參考一下我的思路,或者選取合適的部分代碼食用,每一個版本的示例代碼都在這里!

如圖,最后三個是最終的版本。在最終版中,我又實現(xiàn)了:
- 時間線的左右位置
- 圓點的類型:實心和邊框
- 結(jié)點的不同大小
- 線的寬度
- item的間距(贈送的)
并且在顏色color/圖片drawableRes選擇策略中加入adapterPosition參數(shù),可以根據(jù)位置進行設(shè)置策略啦
到此這篇關(guān)于 Android如何實現(xiàn)時間線效果(下)的文章就介紹到這了,更多相關(guān) Android時間線效果內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Android開發(fā)之ScrollView的滑動監(jiān)聽
這篇文章主要介紹了Android開發(fā)之ScrollView的滑動監(jiān)聽,非常不錯,介紹的非常詳細,具有參考借鑒價值,需要的朋友可以參考下2016-08-08
Android SeekBar控制視頻播放進度實現(xiàn)過程講解
這篇文章主要介紹了Android SeekBar控制視頻播放進度實現(xiàn)過程,文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)吧2023-04-04
Android自定義View實現(xiàn)搜索框(SearchView)功能
這篇文章主要為大家詳細介紹了Android自定義View實現(xiàn)搜索框SearchView功能,具有一定的參考價值,感興趣的小伙伴們可以參考一下2017-11-11
Android App開發(fā)中ViewPager組件的入門使用教程
這篇文章主要介紹了Android App開發(fā)中ViewPager組件的入門使用教程,ViewPager主要用來實現(xiàn)通過滑動來切換頁面的效果,需要的朋友可以參考下2016-03-03
Android 自動判斷是電話,網(wǎng)址,EMAIL方法之Linkify的使用
本篇文章小編為大家介紹,在Android中 自動判斷是電話,網(wǎng)址,EMAIL方法之Linkify的使用。需要的朋友參考下2013-04-04
Unity同步/異步調(diào)用Android的方法實例
unity在Android端開發(fā)的時候,免不了要調(diào)用Java,下面這篇文章主要給大家介紹了關(guān)于Unity同步/異步調(diào)用Android的相關(guān)資料,文中通過示例代碼介紹的非常詳細,需要的朋友可以參考下2021-08-08
Android編程之?dāng)?shù)據(jù)庫Sql編程實例分析
這篇文章主要介紹了Android編程之?dāng)?shù)據(jù)庫Sql編程,實例分析了Android操作Sqlite數(shù)據(jù)庫的相關(guān)技巧,非常具有實用價值,需要的朋友可以參考下2015-04-04

