batsalee의 작은바지

WorkManager

batsalee — Tue, 7 Jul 2026 20:37:23 +0900

1. WorkManager란?

어플리케이션 프로세스가 현재 실행되는지와 상관없이 수행해야하는 백그라운드 작업을 처리하는 API

그래서 즉시 실행하지 않아도 괜찮지만, 언젠가는 꼭 실행되어야하는 작업에 사용

2. 특징

1) 실행 보장

- 앱이 꺼지거나 시스템이 재시작되어도 설정된 작업이 취소되지 않고 나중에라도 반드시 실행

2) 조건부 실행

- 와이파이가 연결됐을때만, 충전중일때만 같은 특정 조건 충족될때 작업이 시작하도록 할 수 있음

3) 체이닝

- 여러 작업을 순차적/병렬로 연결해서 복잡한 작업흐름을 만들 수 있음

3. 구성 요소

1) Worker / CoroutineWorker

- 백그라운드 스레드에서 동기적으로 작업을 수행하는 클래스

- doWork() 함수 내에 할 일 작성

- 비동기적으로 작업하고 싶다면 CoroutineWorker 사용

2) WorkRequest

- 작업의 실행 조건 정의

- OneTimeWorkRequest : 한번만 실행되는 WorkRequest

- PeriodicWorkRequest : 일정 주기로 반복 실행되는 WorkRequest

3) WorkManager

- WorkRequest를 큐에 넣고 관리하는 클래스

4. 주의사항

주기적으로 수행해야 하는 작업을 맡기는 경우 간격을 적절히 둬야 함(최소 15분 이상)

1) 원인

- 스마트폰을 사용하지 않으면 배터리 절약을 위해 Doze모드(절전모드)에 진입하는데 이 때 불필요하게 계속 기기가 깨어나게 됨

- 여러 앱의 백그라운드 작업을 모았다가 한꺼번에 처리하는 방식인데, 이렇게되면 네트워크 연결같은 동작을 한번 하고 작업을 몰아서 할 수 있지만 계속 작업을 하면 네트워크 연결같은 작업도 계속 반복해야 함

- 내부적으로 API24의 JobScheduler를 사용하는데 JobScheduler가 15분보다 짧으면 실행 안하게 되어있음

2) 15분보다 자주 실행하려면?

- Foreground Service나 AlarmManger 활용

5. 사용 방법

1) Dependency 추가

- 꼭 2.8.1 버전이어야 하는건 아니고 최신버전 나오면 바꿔도 됨

implementation("androidx.work:work-runtime-ktx:2.8.1")

2) Worker 구현

- Worker 혹은 CoroutineWorker를 상속받고 doWork를 오버라이딩한다

class MyWorker(ctx: Context, params: WorkerParameters) : CoroutineWorker(ctx, params) {
    override suspend fun doWork(): Result {
    
    	// do something...
        
        return withContext(Dispatchers.IO) { // 코루틴을 어느 Dispatcher에게 맡길지
            return@withContext try {
                // do something...
                Result.success()
            } catch (throwable: Throwable) {
                Result.failure()
            }
        }
    }
}

3) WorkManager 구현 및 WorkRequest

private val workManager = WorkManager.getInstance(context)

fun enqueue() {
    val workerBuilder = OneTimeWorkRequestBuild<MyWorker>() // 한번만 실행하는 WorkRequest일 때
    val workerBuilder = PeriodicWorkRequestBuild<MyWorker>() // 일정 주기로 실행하는 WorkRequest일 때
    workManager.enqueue(workerBuilder.build())
}

4) 체이닝 사용 방법

- CleanupWorker -> BlurWorker -> SaveImageToFileWorker순으로 체인을 만들어 실행함

private val workManager = WorkManager.getInstance(context)

fun enqueue() {
    var continuation = workManager.beginWith(OneTimeWorkRequest.from(CleanupWorker::class.java))
    // continuation에는 WorkContinuation 객체가 들어가며 체인의 첫번째 작업 요청이 있는 WorkRequest 체인의 시작점이 된다.
    
    val blurBuilder = ~~
    continuation = continuation.then(blurBuilder.build())
    
    val save = OneTimeWorkRequestBuilder<SaveImageToFileWorker>().build()
	continuation = continuation.then(save)
    
    continuation.enqueue() // 작업 시작
}

이어서 작성중....

※ 참고 문헌

- android basics with compose

- https://developer.android.com/courses/android-basics-compose/course?hl=ko

안드로이드 빌드 환경

batsalee — Tue, 30 Jun 2026 22:22:57 +0900

1. gradle

빌드 자동화 도구
C++로 비유하면 CMake, Make, vcpkg 같은걸 다 합쳐놓은 개념
빌드의 주체같은 느낌인데 소스코드를 컴파일러에게 전달하고, 리소스(다국어 등)를 챙기고, 외부 라이브러리를 가져와서 최종적으로 앱으로 만들어내는 모든 과정을 자동화해주는 도구

안드로이드의 4대 컴포넌트

batsalee — Tue, 30 Jun 2026 22:07:20 +0900

본격적인 안드로이드 공부 시작...

추가 확인 필요한 사항
- 서비스 라이프사이클(foregroud, background, bound)

안드로이드 4대 컴포넌트

- Activity, Service, Broadcast Receiver, Content Provider
- 안드로이드 앱의 필수적인 구성요소이며, 각각은 시스템이나 앱에 들어올 수 있는 진입점
- 각 컴포넌트는 독립적으로 존재, 고유의 기능을 수행하며, 인텐트를 통해 상호작용한다.
- 모든 컴포넌트는 메인스레드(UI스레드)에서 실행된다.

1. Activity

- 사용자와 상호작용을 담당하는 인터페이스

- 사용자에게 실제로 보이는 화면을 의미

- 액티비티는 두개 이상 동시에 보일 수 없음

- 어플리케이션은 반드시 하나 이상의 액티비티가 있어야 함

- 앱을 실행할땐 앱 전체를 호출한다기보다는 앱의 액티비티를 호출하는 것
- 액티비티는 인텐트를 통해 다른 어플리케이션의 액티비티 호출 가능
- 액티비티는 한개 이상의 view(텍스트/버튼/이미지) or ViewGroup(레이아웃)을 포함

- 액티비티 내에 프래그먼트를 추가해서 화면을 분할시킬 수 있음

2. Service

- 주로 background에서 어떠한 작업을 처리하기 위해 사용

- 액티비티는 사용자와 상호작용한다면 Service는 내부에서 동작
- 다만 항상 그런건 아니고 foreground service/background service로 나뉨

1) foreground service

- foreground service는 사용자에게 잘 보이는 작업이고, 서비스가 수행하는 동작을 사용자에게 알릴때 사용

- 사용자가 앱과 상호작용하지 않을때도 계속 실행

- 활성화된 액티비티와 동일한 우선순위

다만 애초에 서비스의 주목적이 백그라운드니까 foreground service 동작은 WorkManager를 쓰는게 더 좋다

2) backgroud service

- background service는 사용자에게 직접 보이지 않는 작업(주로 서비스를 이 용도로 사용)

- 다만 우선순위가 낮아서 시스템 리소스가 부족하면 강제종료될 수 있음

- 그러므로 즉각적인 실행이 필요하면 foreground service/WorkManager 사용
- 어플리케이션이 종료되어도 이미 시작된 서비스는 background에서 계속 동작한다.
- 예를들어 타이머 앱은 타이머 시작 후 앱을 종료해도 시간이 계속 흘러간다

- 또는 어플리케이션을 사용하면서 파일을 다운로드 받을때 서비스를 사용
- 네트워크와 연동 가능
- 현재 비활성화된 Activity보다 우선순위가 높다.

Activity와 Service는 메인스레드(UI스레드)에서 실행된다

그러므로 서비스에서 일 시키려면 다른 쓰레드 생성해서 일 시켜야한다.

3) bound service

- bound service는 IBinder 인터페이스로 서버-클라이언트 관계처럼 서비스와 상호작용

- 여러 프로세스에서 Bound Service에 바인딩해서 작업 수행

- 바인딩된 컴포넌트 모두 소멸되면 해당 Bind Service도 소멸

3. Broadcast Receiver

- 안드로이드 OS로부터 발생하는 각종 이벤트와 정보를 받고 핸들링하는 컴포넌트
- 대부분 UI는 없고 안드로이드 장비상황을 OS가 감시하다가 이벤트가 발생하면 Broadcast Receiver에게 전달하고, 해당 이벤트에 맞는 동작을 Broadcast Receiver가 수행
- 대부분 UI가 없긴한데 상태표시줄 알림을 생성해서 사용자에게 이벤트가 발생했다고 알리는 동작은 가능

- 안드로이드 OS가 보내주는 Broadcast를 받는 방법은 안드로이드 라이브러리에 BroadCastReceiver라는 클래스가 추상클래스로 구현되어 있는데, 이걸 상속받아서 onReceive(context, intent) 함수 오버라이딩하면 된다.

- onReceive() 내에서 if (intent.action == "com.abc.def") 라면 어떤 동작을 한다처럼 인텐트마다 동작 구현할 수 있다.

- BroadCastReceiver를 상속받아 구현한 브로드캐스트 클래스를 AndroidManifest.xml에 receiver로 등록하고, 그 receiver내에서 어떤 인텐트들을 받을지 나열해두면 운영체제가 broadcast 보낼 때 해당 앱에서 그 인텐트를 받는지 보고 동작을 수행한다.

4. Content Provider

- 안드로이드에서는 각 앱이 자신만의 샌드박스를 가지기 때문에 A앱이 B앱을 절대 읽을 수 없다

- 그래서 데이터 공유를 하려면 공식적인 창구가 필요하고 그게 Content Provider

- 즉, 어플리케이션 간 데이터 관리 및 다른 어플리케이션의 데이터를 제공하는데 사용되는 컴포넌트

- 작은 데이터는 intent로 어플리케이션간 공유할 수 있지만, 음악/사진같은 용량 큰 파일을 Content Provider로 공유
- 데이터 관리는 SQLite DB/Web/파일 입출력 방식으로 관리하며 read/write는 권한이 있어야 접근 가능해서 현재 실행중인 어플리케이션에 접근 못하게 하거나, 원하는 일부 데이터만 접근 허용하는 등의 동작 가능

앱 처음 설치할때 전화, 사진에 접근 권한 요청 이런거 뜨는게 이게 Content Provider가 접근해야해서 그렇다.

클라이언트-서버 구조처럼 사용하며 Content Provider(서버)가 데이터를 가지고 있는 DB의 역할이고 Content Resolver(클라이언트)가 데이터를 요청하는 앱이 된다

요청은 uri를 사용한 쿼리로 한다.

코드상 구현

uri에 content://로 시작하는 문구를 넣고 쿼리를 날린다.

ContentProvider 클래스를 상속받아서 onCreate, query, insert, update, delete 등의 함수를 오버라이딩해서 사용한다.
진짜 db에 뭐 요청하는 느낌처럼 쓸 수 있다.

A앱에서 뭔가 insert하고 다른데서 query로 get하는 모양새가 된다.
보통 insert하는 앱을 Data Provider, query로 get하는 앱을 Data Consumer라고 한다.

정확하게는 Content Provider가 데이터를 보관하는건 아니다.

A앱에서 본인의 데이터를 가지고 있고, 그 데이터에 접근할 수 있는 인터페이스를 uri 형태로 만들어 진입로를 Content Provider에 저장해두는 것이다.

- 진입로는 "content://com.abc.def"같은 형태

그럼 B앱에서 "content://com.abc.def"로 query 호출하면 안드로이드OS가 A앱의 프로세스를 띄워서 데이터를 가져다가 B앱에 준다

코드 사용 예시 insert하는쪽과 query하는 쪽 둘 다 좀 적어두면 좋을 듯

5. Intent

- 컴포넌트간에 통신 수단

- 컴포넌트에 Action, Data 등을 전달
- 주로 가장 많이 사용되는건 화면전환
- Intent로 다른 어플리케이션의 컴포넌트를 활성화 시킬 수 있음

- Intent이름은 "VIT_" 형태의 문자열이나 "com.abc.dce"같은 역순uri같은 문자열로 주로 쓴다

단순한 문자열은 아니고 Intent의 멤버변수들이 있다.

- action : "com.abc.def"같은 문자열이며 무엇을 할 것인가를 의미하는 함수명같은 개념
- data : content://contacts/people같은 어떤 데이터를 대상으로 할 것인가의 개념
- category : 문자열 리스트를 전달하면 되고 어떤 환경에서 실행되어야 하는가의 개념

앱 목록에 노출할지, 웹브라우저에서 실행가능하게 할지
- extras : String-Object 형태의 map이며 intent와 함께 전달할 매개변수들을 넣는 곳

val intent = Intent("com.abc.def")
intent.putExtra("name", "abc")
intent.putExtra("width", 10.5)
sendBroadcast(intent)

//위처럼 보내고 onReceive에서 아래처럼 사용

if (intent.action =- "com.abc.def") {
    val name = intent.extras?.getString("name")
    val width = intent.extras?.getDouble("width")
}

안드로이드 액티비티의 생명주기(Life Cycle)

- Activity는 클래스다.
- 액티비티는 안드로이드 4대 컴포넌트 중 하나
- UI와 가장 밀접한 관련
- 앱은 하나 이상의 액티비티가 서로 연결된 형태로 구성

1. 액티비티 예시

- 카카오톡 실행 시 처음 나오는 카카오톡 로고가 하나의 액티비티
- 그 후 진입되는 친구목록이나 채팅목록 화면도 별도의 하나의 액티비티
- 카카오톡을 내리고 유투브를 켜면 유투브 액티비티가 보이게 됨
- 이렇게 액티비티가 전환될때마다 각자 생명주기에 따라 호출되는 함수가 있음

2. 액티비티 함수

- onCreate() : 최초 앱 실행 시 단 한번만 호출, 주로 초기화 관련 작업 수행
- onStart() : 액티비티가 화면에 표시되기 직전에 호출(화면에 진입할때마다 호출되어야 하는 작업 구현)
- onResume() : 액티비티가 화면에 표시된 직후에 호출(액티비티가 포커스된 상태)
- onPause() : 액티비티가 보여지지 않은 직후에 호출(포커스를 잃은 상태), 저장해야하는 데이터가 있다면 여기서 저장(단 다른 액티비티가 보여지게 되므로 너무 무거운 작업하면 안됨)
- onStop() : 액티비티가 완전히 보이지 않게 됐을때
- onDestroy() : 액티비티가 종료/앱 프로세스가 종료됐을때

- onRestart() : onStop() 상태인데 해당 액티비티로 전환되서 보여지게되면 onRestart() 호출하고 바로 onStart()호출

다른 액티비티(불투명하고 화면 꽉채우는게)가 올라오게되면 onPause()랑 onStop() 연달아서 둘 다 호출된다.
그러니까 onPause()만 호출하고 onStop() 호출 안하는 케이스는 투명한 새로운 액티비티 호출하면 된다.

3. 다이얼로그

다이얼로그는 액티비티의 일부이다.
그래서 액티비티 위에 다이얼로그가 올라와서 화면 가려지면 onPause가 호출되어야할것같지만 액티비티가 다른 액티비티로 가려진게 아니라서 호출되지 않는다.

4. 프래그먼트

- 이건 일단 개념은 보긴 할건데 우리 프로젝트는 프래그먼트 일부러 안쓰고 액티비티만 쓰게 구현해놔서... 차후 확인 예정
- 앱 UI의 재사용 가능한 부분(모듈성/재사용성)
- 자체 레이아웃 정의/관리하고 자체 생명주기를 가지며, 자체입력이벤트 처리 가능
- 단독으로 실행불가능하고 액티비티나 다른 프래그먼트에서 호스팅해야함
- 액티비티가 onStart 상태에 있는 동안 프래그먼트를 추가/교체/제거할 수 있다.

Kotlin 기본 문법 정리

batsalee — Sun, 24 Nov 2024 18:57:57 +0900

1. 변수, 상수

1) 선언 방식

// 자료형이 예측 가능하다면 생략 가능
var r = 1
val l = 1

// 혹은
var r : Int = 1
var l : Int = 1

2) 변수, 상수

- var : 변수(변경 가능)

- val : 상수(변경 불가)

fun main() {
    var r : Int = 1
    val l : Int = 1
    r = 2
    l = 2  // 오류발생
}

2. 조건문

1) if

- C++과 완전히 동일

- if문법 뿐 아니라 !으로 not 걸거나, ==으로 비교하는 등 모두 같다.

2) when

- C++의 switch문과 대응되는 방식

- 값 -> 행동 으로 작성하며, default 값의 경우 else -> 행동 으로 작성

fun main() {
    var r = 1
    when(r) {
        1 -> print(1)
        2 -> print(2)
        else -> print(0)
    }
}

3) 표현식

- 값 자체를 if-else를 이용해서 지정할 수 있다.

fun main() {
    var r = 1
    var result = if(r == 1) 1 else if(r == 2) 2 else 0
    print(result)
}

stash(스테이시)

batsalee — Sun, 10 Nov 2024 17:38:00 +0900

1. 스테이시란?

- 작업이 아직 완료되지 않은 상태에서 다른 브랜치로 체크아웃 하고 싶을 때, 결과물을 스테이시 영역에 잠시 보관할 수 있다.

2. 사용 방법

- git stash : 스테이시에 보관

- git stash list : 스테이시 목록 조회

- git stash pop : 저장내용을 현재 브랜치에 적용 후 stash 목록에서 drop

- git stash apply : stash에 저장된 내용을 브랜치에 적용하되 목록에서 drop하지는 않음

- git stash drop stash@{O} : stash에 저장된 내용을 삭제

switch와 checkout의 차이점

batsalee — Sun, 10 Nov 2024 17:34:25 +0900

1. 공통점

- Git 브랜치를 전환하귀 위해 사용하는 명령어

2. checkout

- 브랜치 전환, 파일 체크아웃, 커밋으로 돌아가기 등 다양한 용도

- 하나의 명령어로 여러 기능을 수행할 수 있으므로 혼란을 줄 수 있음

3. switch

- 오직 브랜치 전환에서만 사용

- 명령어 사용이 더 단순명확하다.

결국 요약하면 브랜치 전환 목적에서만 보면 둘 다 사용 가능하고, checkout은 다른 용도로도 사용할 수 있다.

cherry-pick

batsalee — Sun, 10 Nov 2024 17:31:18 +0900

1. 체리픽이란?

- 다른 브랜치에 있는 커밋을 내 브랜치에 적용시킬 때 사용하는 명령어

- merge나 rebase의 경우 다른 브랜치의 모든 내용을 현재 브랜치에 반영하게 되지만 체리픽은 원하는 특정 커밋만 가져와서 반영할 수 있다.

- 다만 체리픽은 같은 내용의 커밋을 여러개 생성하므로 꼭 필요할 때만 사용하기

2. 사용 방법

위와 같은 상황일 때 feature/#1 브랜치의 커밋 중 34b4cab와 13f03ab 커밋을 master 브랜치에 적용하고 싶다면 아래와 같이 사용한다.

# git cherry-pick {커밋 해시}
git cherry-pick 34b4cab
git cherry-pick 13f03ab

# 또는 
git cherry-pick 34b4cab 13f03ab

# 연속적인 커밋일 경우
git cherry-pick 34b4cab..fe834e9
// 단 연속 커밋의 경우 내가 적용하고자 하는 커밋의 다음 값을 지정해야 한다.

충돌 발생 시

1) 충돌난 코드 수정

2) git add {충돌난 코드 경로}

3) git cherry-pick --continue

cherry-pick 중단 시

- git cherry-pick --abort

3. 소스트리에서 사용 방법

1) 병합받고자 하는 브랜치로 체크아웃

2) 체리픽 해올 커밋의 브랜치로 가서 해당 커밋 우클릭 후 체리 픽

문자열로 된 2진수값을 쉽게 10진수로 변환하는 법

batsalee — Sat, 12 Oct 2024 17:16:32 +0900

https://www.acmicpc.net/problem/11179

위 문제를 풀면서 10진수와 2진수간 변환을 좀 더 편하게 할 방법이 없을까 싶어서 코파일럿에게 물어본 결과

stoi를 이용해서 2진수 문자열을 10진수로 쉽게 변환하는 방법이 있었다.

stoi(binary, nullptr, 2); 라고 하게 되면 nullptr은 기본값이라 10진수로 출력하게 되며, 2는 2진수->10진수를 의미한다.

2를 8로 바꾸면 8진수로 인식해서 8진수 -> 10진수로 변환한다.

#include <bits/stdc++.h>
using namespace std;

int main()
{
	ios::sync_with_stdio(false); cin.tie(NULL);

	int N;
	cin >> N;

	string bs = bitset<8 * sizeof(N)>(N).to_string();
	string binary = bs.substr(bs.find_first_not_of('0'));
	reverse(binary.begin(), binary.end());

	cout << stoi(binary, nullptr, 2);

	return 0;
}

enum / enum class

batsalee — Tue, 1 Oct 2024 16:25:55 +0900

enum

enum은 내부적으로 int와 동일하게 사용되며, 값을 지정하지 않으면 가장 첫 값부터 0으로 시작해서 1씩 증가한다.

그러므로 아래처럼 Red라고 사용하면 그냥 0과 동일하게 사용되며, WaterMelon::Black처럼 어느 enum의 값인지 명시할 수도 있다.

문제점

- 서로 다른 enum에 같은 이름을 중복해서 사용할 수 없다.

- 또한 int와 같게 처리되므로 암시적으로 실수가 발생할 여지가 있다.

- 예를들어 서로 다른 enum의 값간에 대소비교

- 공간복잡도 최적화 상황에서 1 ~ 2바이트로도 충분한 경우의 효율문제

#include <iostream>
using namespace std;

void main() 
{
	enum WaterMelon
	{
		Red,   // 0
		Green, // 1
		Black  // 2
	};

	enum PineApple
	{
		Yellow, // 0
		// Green   // 1, 다른 enum 멤버의 이름과 중복될 수 없음
	};

	int a = Red;
	int b = WaterMelon::Black;
}

enum class

Modern C++ 11에 추가됐다.

기존의 enum에 더 강한 제약을 두면서도 더 명확한 의미를 갖게 하여 enum의 문제점들을 해결했다.

#include <iostream>
using namespace std;

void main() 
{
	enum class WaterMelon
	{
		Red,   // 0
		Green, // 1
		Black  // 2
	};

	enum class PineApple
	{
		Yellow, // 0
		Green   // 1
	};

	WaterMelon a = WaterMelon::Red;
	WaterMelon b = WaterMelon::Green;
	PineApple c = PineApple::Green;

	// int d = Red; // 오류
	// int e = WaterMelon::Red; // 오류
	int f = static_cast<int>(WaterMelon::Red);
}

enum과의 차이점

1) 클래스명을 반드시 같이 적어줘야 한다.

- Red처럼 사용 불가능하고 WaterMelon::Red처럼 명확히 사용해야 한다.

2) 서로 다른 enum class에 같은 이름의 값을 사용할 수 있다.

- WaterMelon과 PineApple 양쪽 모두 Green이 있지만 문제없다.

3) 내부적으로 int로 처리하지 않고 다른 자료형으로 처리하게 만들 수 있다.

enum class Color : char {
    RED,
    GREEN,
    BLUE
}

4) 먼저 선언만 해두고 나중에 정의할 수 있다.

- 선언만 해두고 나중에 정의하거나, 헤더에 선언만 해두고 cpp에 정의하는 식으로 구현 가능하다.

enum class PineApple; // 선언

enum class WaterMelon
{
	Red,   // 0
	Green, // 1
	Black  // 2
};

enum class PineApple // 정의
{
	Yellow, // 0
	Green   // 1
};

제약이 추가된 이유

개발자가 실수할 수 있는 부분에 제약을 추가해서 버그를 방지하기 위한 목적도 있지만 사용이 더 불편해진것 또한 사실이다.

다만 다른 언어들은 enum을 C++의 enum class와 유사하게 사용하기 때문에 언어간의 통일성 및 표준화를 위한 목적도 있다고 한다.

결론

결국 본인이 enum을 여러개 정의해야해서 변수명이 겹칠것 같거나, 실수할 여지가 있다면 enum class를 선택하면 된다.

그냥 갑작스럽게 enum class로 정의된 코드를 만났을 때 이해만 할 수 있으면 되겠다.

Intro sort 기준

batsalee — Thu, 12 Sep 2024 02:43:32 +0900

데이터 16개 이하 : 삽입정렬

함수 스택 2 * log(N) 이하 : 퀵정렬

함수 스택 2 * log(N) 초과 : 힙정렬