Progressbar 사용하기(feat. timer)

프로그래스 바를 이용해서 제한시간 막대를 만들어야했다. 결과물을 먼저 보고, 거기까지 가는 여정을 적어보겠다

ProgressBar 만들기

우선 프로그래스바의 xml에서 세팅을 먼저 보자.

<ProgressBar
            android:id="@+id/quiz_daily_progress_bar"
            style="@style/CustomProgressBar"
            android:layout_width="0dp"
            android:layout_height="24dp"
            android:layout_marginHorizontal="20dp"
            android:layout_marginBottom="4dp"
            android:max="1500"
            android:progress="1500"
            app:layout_constraintBottom_toTopOf="@id/quiz_daily_tv_time"
            app:layout_constraintEnd_toEndOf="parent"
            app:layout_constraintStart_toStartOf="parent" />

 

max 값을 1500으로 하고, 차감되는 모습을 보여주기 위해 초기 progress 값을 1500으로 했다.(1500으로 한 이유는 뒤에 서술하겠다.)

style은 커스텀해서 만든 걸 넣었다.

<!--  ProgressBar Style  -->
<style name="CustomProgressBar" parent="android:Widget.ProgressBar.Horizontal">
    <item name="android:progressDrawable">@drawable/custom_progress_bar</item>
</style>

 

가로 막대인 ProgressBar.Horizontal을 상속받아 만들었고 프로그래스 바에 사용될 drawable 파일을 지정했다.

custom_progress_bar.xml 파일을 보자.

<?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:id="@android:id/background">
        <shape>
            <solid android:color="@color/White_01" />
            <corners android:radius="5dp" />
        </shape>
    </item>

    <item android:id="@android:id/progress">
        <scale android:scaleWidth="100%">
            <shape>
                <corners android:radius="5dp"/>
                <solid android:color="@color/Blue_01"/>
            </shape>
        </scale>
    </item>
</layer-list>

 

막대 색을 파란색 배경색을 흰색으로 지정하기 위해 layer-list를 사용했다. 제일 중요한 부분인데, 모양을 지정하기 전에 scale 태그로 묶는다. 검색 결과에서 나온 블로그들은 clip을 사용하거나, 그냥 shape를 사용하는데, 그렇게 하면 progressbar가 max일때는 지정한 corners가 잘 작동하지만 max가 아니면 줄어들거나 늘어나는 부분이 일자로 잘려서 나온다. clip이 틀렸다는 말이 아니라 내 경우에 맞지 않는 방법이었다.

Clip vs Scale

클립은 원본 이미지가 있으면 그걸 clip양에 따라 잘라서 보여주는 방법이고, scale은 비율을 지켜서 보여주는 방법이다. 검색결과에는 배경색을 따로 지정해뒀기에 clip으로 해도 상관이 없는 결과만 나왔으나, 내 경우에는 주어진 피그마 디자인에서 프로그래스바 배경색이 없었기 때문에 clip을 사용하면 안됐다.

다음은 clip을 사용한 예시다.

<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:id="@android:id/background">
        <shape>
            <solid android:color="@color/White_01" />
            <corners android:radius="5dp" />
        </shape>
    </item>
  
    <item android:id="@android:id/progress">
        <clip>
            <shape>
                <corners android:radius="5dp" />
                <solid android:color="@color/Blue_01" />
            </shape>
        </clip>
    </item>
</layer-list>

 

clip으로 구현하면 증감부분의 막대가 일자로 잘려서 나온다. scale로 구현하면 비율을 지키기 때문에 이 문제를 해결할 수 있다.

scale은 현재 레벨을 기준으로 다른 드로어블의 크기를 변경하는, XML에 정의된 드로어블인데, 조절할 요소로는 gravity, height, width 세개를 보면된다.

 

android:scaleHeight는 세로 비율을 조절하는 것으로, 100%면 전체를 의미하고 비율이 줄어들 때 1:1로 줄어들게 된다. progress 1만큼 줄어들면 scale도 1비율 만큼 줄어들게 되는 것이다. android:scaleWidth 가로도 마찬가지다. 100%보다 작게 설정하면, progress가 1만큼 줄어들 때 scale은 1보다 작게 줄어들게 된다. 반대로 크면 더 많이 진행된다.

이제 골치아픈 UI를 해결했으니 코드로 넘어가면 된다.

Timer vs Coroutine, withContext

구현 목표는 15초동안 progressbar를 모두 줄어들게 하는 것이었는데, coroutine으로 구현해보니 delay와 progress비율을 정해도 15초가 아니라 16.3초 정도로 나왔다. 먼저 해당 코드를 보자.

fun ProgressBar.initProgressBar(detailText: TextView, submitIncorrect: () -> Unit): Job {
    var totalProgress = 1500

    detailText.text = context.getString(R.string.quiz_daily_time, totalProgress / 100)
    return  CoroutineScope(Dispatchers.IO).launch {
        while (totalProgress > 0) {
            delay(100)
            totalProgress -= 10
            withContext(Dispatchers.Main) {
                progress = totalProgress
                detailText.text = context.getString(
                    R.string.quiz_daily_time,
                    ceil(totalProgress.toDouble() / 100).toInt()
                )
            }
        }
        submitIncorrect()
    }
}

 

delay거는 부분을 IO쓰레드에서 하고, withContext를 이용해 Main쓰레드로 UI로 보냈다. 이런 오차가 발생하는 이유는 delay이후에 연산할 때 생기는 시간 때문이라고 추론된다. delay값을 95ms 정도로 줄이니 15초에 근사하긴했으나 뭔가 찜찜해서 다른 방법을 찾다 발견한 게 Timer다.

Timer

사용하게 될 Timer는 java.util에 속한다. kotlin에 특화된 라이브러리가 있다면 교체할 생각이 있다.(kotlin.concurrent.timer가 있다는 건 인지하고 있다.)

import java.util.Timer
import java.util.TimerTask

 

Timer객체를 만들어서, TimerTask로 제어를 하게 된다. Timer-TimerTask 조합보다 추천하고 있는 것이  ScheduledThreadPoolExecutor인데, 멀티스레드를 허용하고 TimerTask를 사용하지 않아도 된다고 한다. 간단한 구현만 하면 되기에 Timer-TimerTask를 선택했다. Timer클래스는 TimerThread를 사용해 큐를 넣고, 제거하는 방식으로 작동한다.

 

이전 코루틴으로 작성한 코드를 다시 보면, 15초 동안 일정간격(delay를 사용해)으로 값이 줄어들고, 그걸 textview.text로 상태를 넣어준다. 이제 이 작업을 Timer로 바꾸면 아래와 같다.

fun ProgressBar.initProgressBar(detailText: TextView, submitIncorrect: () -> Unit): Timer {
    var totalProgress = 15000
    val timer = Timer()

    detailText.text = context.getString(R.string.quiz_daily_time, totalProgress / 100)

    timer.scheduleAtFixedRate(object : TimerTask() {
        override fun run() {
            if (totalProgress > 0) {
                totalProgress -= 1
                progress = totalProgress/10

                detailText.post {
                    detailText.text = context.getString(
                        R.string.quiz_daily_time,
                        ceil(totalProgress.toDouble() / 1000).toInt()
                    )
                }
            } else {
                timer.cancel()
                submitIncorrect()
            }
        }
    }, 0, 1L)

    return timer
}

 

withContext에 해당하는 부분이 detail.post{}이고, run이 코루틴에 대응한다. timer 객체를 만들어서, 외부 상호작용에 따라 timer를 큐에서 지우기 위해 반환타입으로도 뒀다. 지금 코드에서 사용된 scheduleAtFixedRate 메서드를 보자.

public void scheduleAtFixedRate(TimerTask task, Date firstTime,
                                long period) {
    if (period <= 0)
        throw new IllegalArgumentException("Non-positive period.");
    sched(task, firstTime.getTime(), period);
}

 

Timer객체, 시작 시간, 양수인 Long타입으로 된 간격을 파라미터로 받는다(단위는 ms다). sched는 period가 0이면 일회성 작업을 실행하고, 아니면 period 주기로 반복 실행하는 메서드로, 여기서 sched는 주기의 상태를 확인하지않기 때문에 가독성을 위해 따로 빼둔 느낌이었다.

 

timer.cancel()을 먼저 보자. TimerTask에도 cancel이 있고 Timer에도 cancel이 있는데, Timer객체를 매번 생성해서 사용하기 때문에 위 코드에서는 task를 cancel하는게 아닌 현재 timer를 cancel해야한다.

public void cancel() {
    synchronized(queue) {
        thread.newTasksMayBeScheduled = false;
        queue.clear();
        queue.notify();  // In case queue was already empty.
    }
}

 

Timer의 cancel은 큐를 비워서 작업을 중지한다. 이제 withContext에 대응하는 것으로 보이는 post를 살펴보겠다.

detailText.post {
                    detailText.text = context.getString(
                        R.string.quiz_daily_time,
                        ceil(totalProgress.toDouble() / 100).toInt()
                    )
                }

 

post는 runnable을 파라미터로 받는다. 이 말은, 람다로 처리가 가능하다는 의미로 위 코드에서 표현한 것과 같다.

public boolean post(Runnable action) {
    final AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null) {
        return attachInfo.mHandler.post(action);
    }
  
    getRunQueue().post(action);
    return true;
}

 

message queue를 사용하는 방식으로, 이 runnable action은 UI Thread에서 돌아간다.(처리량이 많다면 ANR에 걸릴 수 있다) 이때 mAttachInfo의 정보를 살펴보니 API28 이하를 타겟팅하는 앱에서만 액세스 가능하다고 적혀있다. UI쓰레드에서 돌아가니 textview의 text를 바꾸는 것과 같은 ui작업이 가능한 것이다.

---

참조:

https://developer.android.com/guide/topics/resources/drawable-resource?hl=ko#Clip

https://developer.android.com/guide/topics/resources/drawable-resource?hl=ko#Scale

"댓글, 공감 버튼 한 번씩 누르고 가주시면 큰 힘이 됩니다"