Factory Pattern

• 객체 생성 로직을 캡슐화하는 디자인 패턴
• Factory function은 Factory pattern을 구현하는 방법 중 하나

Factory Function

• 객체를 생성해서 반환하는 함수
• 생성자를 직접 호출하지 않고 함수로 감싸서 생성
• 예: () => ViewModel(useCase: getIt())

Factory Pattern 사용 예시

기본 클래스 정의

// UseCase: 비즈니스 로직을 수행하는 클래스
class GetUserDataUseCase {
  final UserRepository repository;

  GetUserDataUseCase({required this.repository});

  Future<User> execute(String userId) async {
    return await repository.getUser(userId);
  }
}

// ViewModel: 화면의 상태와 로직을 관리하는 클래스
class UserProfileViewModel {
  final GetUserDataUseCase useCase;
  User? user;
  bool isLoading = false;

  UserProfileViewModel({required this.useCase}) {
    loadUser(); // 생성자에서 데이터 로드
  }

  void loadUser() async {
    isLoading = true;
    user = await useCase.execute('123');
    isLoading = false;
  }
}

Factory Pattern 사용 안 할 때

// user_profile_page.dart 파일
final repository = UserRepository();
final useCase = GetUserDataUseCase(repository: repository);
final viewModel1 = UserProfileViewModel(useCase: useCase);

// user_detail_page.dart 파일에서도 ViewModel이 필요하면?
final repository2 = UserRepository();  // 똑같은 코드 반복!
final useCase2 = GetUserDataUseCase(repository: repository2);  // 똑같은 코드 반복!
final viewModel2 = UserProfileViewModel(useCase: useCase2);

// user_settings_page.dart 파일에서도?
final repository3 = UserRepository();  // 또 반복!
final useCase3 = GetUserDataUseCase(repository: repository3);  // 또 반복!
final viewModel3 = UserProfileViewModel(useCase: useCase3);

// 문제점:
// - 생성 로직이 여러 파일에 분산됨 (user_profile_page.dart, user_detail_page.dart 등)
// - UseCase와 ViewModel 생성 코드가 파일마다 중복됨
// - UseCase 생성 방식 변경 시 모든 파일을 수정해야 함
// - 테스트 시 Mock UseCase로 교체하려면 각 파일마다 수정해야 함

Factory Pattern 사용할 때

// di_setup.dart 파일 (한 곳에만 작성)
getIt.registerSingleton<UserRepository>(UserRepository());
getIt.registerSingleton<GetUserDataUseCase>(
  GetUserDataUseCase(repository: getIt()),
);

getIt.registerFactory<UserProfileViewModel>(
  () => UserProfileViewModel(
    useCase: getIt<GetUserDataUseCase>(),  // UseCase는 Singleton에서 가져옴
  ),
);

// user_profile_page.dart 파일
final viewModel1 = getIt<UserProfileViewModel>(); // 간단!

// user_detail_page.dart 파일
final viewModel2 = getIt<UserProfileViewModel>(); // 간단! (새로운 인스턴스)

// user_settings_page.dart 파일
final viewModel3 = getIt<UserProfileViewModel>(); // 간단! (또 다른 새로운 인스턴스)

// 장점:
// - 생성 로직이 di_setup.dart 한 곳에만 있음
// - 각 화면 파일에서는 getIt<Type>()만 호출하면 됨
// - UseCase 생성 방식 변경 시 di_setup.dart만 수정하면 됨
// - 테스트 시 di_setup.dart에서 Mock UseCase로 한 번만 교체하면 모든 화면에 적용
// - 매번 새로운 ViewModel 인스턴스 생성 → 각 화면이 독립적인 상태 유지

GetIt이란?

GetIt은 Flutter/Dart용 의존성 주입(Dependency Injection) 컨테이너 라이브러리다.

주요 기능

• 객체 생성을 중앙에서 관리
• Singleton, Factory 등 다양한 생명주기 지원
• 의존성을 자동으로 주입
• 테스트 시 Mock 객체로 쉽게 교체 가능

기본 사용법

final getIt = GetIt.instance;

// 객체 등록
getIt.registerSingleton<UserRepository>(UserRepositoryImpl());
getIt.registerFactory<UserProfileViewModel>(
  () => UserProfileViewModel(useCase: getIt()),
);

// 객체 가져오기
final repository = getIt<UserRepository>();
final viewModel = getIt<UserProfileViewModel>();

GetIt의 registerFactory

getIt.registerFactory<UserProfileViewModel>(
  () => UserProfileViewModel(
    useCase: getIt<GetUserDataUseCase>(),
  ),
);

• Factory function을 등록
• getIt<UserProfileViewModel>() 호출 시마다 새 인스턴스 생성
• Singleton과 달리 매번 새로운 객체 반환

왜 ViewModel은 Factory를 사용해야 하나?

// 만약 Singleton으로 등록했다면?
getIt.registerSingleton<UserProfileViewModel>(
  UserProfileViewModel(useCase: getIt()),
);

// 화면1에서
final viewModel1 = getIt<UserProfileViewModel>();
viewModel1.user = User(name: 'Alice');  // user 상태 변경

// 화면2에서 (같은 인스턴스!)
final viewModel2 = getIt<UserProfileViewModel>(); 
print(viewModel2.user?.name);  // 'Alice' 출력! (화면1의 상태와 공유됨)

// 문제: 화면1의 상태가 화면2에도 영향을 줌 ❌

Factory를 사용하면:

• 각 화면마다 새로운 ViewModel 인스턴스 생성
• 화면1과 화면2가 서로 독립적인 상태 유지 ✅
• 생성자에서 loadUser() 호출 → 각 화면이 독립적으로 데이터 로드

실제 사용 사례

1. Singleton Pattern

getIt.registerSingleton<UserRepository>(UserRepositoryImpl())
getIt.registerSingleton<GetUserDataUseCase>(
  GetUserDataUseCase(repository: getIt()),
)

• Repository, UseCase 등 앱 전체에서 하나만 필요한 경우
• 데이터를 공유하거나 재사용해야 하는 경우

2. Factory Method Pattern

getIt.registerFactory<UserProfileViewModel>(
  () => UserProfileViewModel(useCase: getIt()),
)

• 화면별로 독립적인 ViewModel이 필요한 경우
• 각 화면이 독립적인 상태를 가져야 하는 경우

3. Observer Pattern

class CartNotifier extends ChangeNotifier {
  void addItem() {
    notifyListeners(); // 상태 변경 알림
  }
}

• UI 업데이트를 위한 상태 관찰

4. Dependency Injection

• GetIt으로 의존성 자동 주입
• 테스트 시 Mock 객체로 교체 용이

Factory vs Singleton in GetIt

핵심 정리

1. Factory Function: 객체 생성 함수
2. Factory Pattern: 생성 로직 캡슐화 디자인 패턴
3. Factory vs Singleton: 생명주기 차이로 구분
4. GetIt: Factory는 지연 생성, Singleton은 즉시 생성 가능
5. 언제 사용?: 매번 새 인스턴스가 필요한 경우 → Factory 사용

_TypeError (type 'Address' is not a subtype of type 'Map<String, dynamic>' in type cast)

JSON 직렬화/역직렬화 과정에서 중첩된 객체가 제대로 변환되지 않을 때 발생함.

문제 원인

@JsonSerializable() 어노테이션에 explicitToJson: true 옵션이 없어서, 중첩된 객체들이 JSON으로 제대로 직렬화되지 않음.

예제: 중첩 객체 직렬화 문제

예제 모델 구조

// Address 모델
@JsonSerializable()
class Address {
  final String street;
  final String city;

  Address({required this.street, required this.city});

  factory Address.fromJson(Map<String, dynamic> json) => 
      _$AddressFromJson(json);
  Map<String, dynamic> toJson() => _$AddressToJson(this);
}

// User 모델 (Address를 포함)
@JsonSerializable()  // ❌ explicitToJson: true 없음
class User {
  final String name;
  final int age;
  final Address address;  // 중첩 객체

  User({required this.name, required this.age, required this.address});

  factory User.fromJson(Map<String, dynamic> json) => 
      _$UserFromJson(json);
  Map<String, dynamic> toJson() => _$UserToJson(this);
}

문제가 있는 생성된 코드

explicitToJson: true가 없을 때 생성되는 user.g.dart:

Map<String, dynamic> _$UserToJson(User instance) => <String, dynamic>{
  'name': instance.name,
  'age': instance.age,
  'address': instance.address,  // ❌ Address 객체가 그대로 저장됨
};

문제 발생 시나리오

1. 직렬화 (toJson)

   final user = User(
     name: '홍길동',
     age: 30,
     address: Address(street: '강남대로', city: '서울'),
   );
   
   final json = user.toJson();
   // 결과: {'name': '홍길동', 'age': 30, 'address': Address 객체}
   // ❌ address가 Map이 아니라 Address 객체 그대로

2. 저장/전송

   // 로컬 스토리지나 API에 저장
   await storage.save(json);
   // 실제로는 Address 객체가 직렬화되지 않은 상태로 저장됨

3. 역직렬화 (fromJson) - 에러 발생

   final savedJson = await storage.load();
   final user = User.fromJson(savedJson);
   // ❌ 에러 발생
   // Address.fromJson()이 Map<String, dynamic>을 기대하지만
   // Address 객체가 들어와서 타입 캐스팅 실패

에러 메시지

_TypeError (type 'Address' is not a subtype of type 'Map<String, dynamic>' in type cast)

해결 방법

1. explicitToJson: true 추가

수정 전:

@JsonSerializable()  // ❌
class User {
  final Address address;
  // ...
}

수정 후:

@JsonSerializable(explicitToJson: true)  // ✅
class User {
  final Address address;
  // ...
}

2. 수정 후 생성된 코드

explicitToJson: true를 추가한 후 재생성된 user.g.dart:

Map<String, dynamic> _$UserToJson(User instance) => <String, dynamic>{
  'name': instance.name,
  'age': instance.age,
  'address': instance.address.toJson(),  // ✅ 제대로 직렬화됨
};

3. 올바른 동작

1. 직렬화 (toJson)

   final user = User(
     name: '홍길동',
     age: 30,
     address: Address(street: '강남대로', city: '서울'),
   );
   
   final json = user.toJson();
   // 결과: {
   //   'name': '홍길동',
   //   'age': 30,
   //   'address': {'street': '강남대로', 'city': '서울'}  // ✅ Map으로 변환됨
   // }

2. 역직렬화 (fromJson) - 정상 동작

   final savedJson = await storage.load();
   final user = User.fromJson(savedJson);
   // ✅ 정상 동작
   // address가 Map<String, dynamic>이므로 Address.fromJson()이 정상 실행됨

다양한 중첩 구조 예제

예제 1: 리스트에 중첩 객체

@JsonSerializable(explicitToJson: true)  // ✅ 필수
class Order {
  final List<Item> items;  // 리스트 안에 중첩 객체

  Order({required this.items});
  // ...
}

예제 2: 다중 중첩

@JsonSerializable(explicitToJson: true)  // ✅ 필수
class Company {
  final Address address;  // 1단계 중첩
  // ...
}

@JsonSerializable(explicitToJson: true)  // ✅ 필수
class Employee {
  final Company company;  // 2단계 중첩
  // ...
}

예제 3: 옵셔널 중첩 객체

@JsonSerializable(explicitToJson: true)  // ✅ 필수
class Profile {
  final Address? address;  // 옵셔널이어도 필요
  // ...
}

적용 규칙

중첩 객체가 있는 모든 모델에 explicitToJson: true 추가 필요:

• ✅ 객체를 필드로 가지는 경우
• ✅ 리스트에 객체가 포함된 경우
• ✅ 옵셔널 객체를 가지는 경우
• ✅ 다중 중첩 구조인 경우

코드 재생성

모델 수정 후 다음 명령어 실행:

flutter pub run build_runner build --delete-conflicting-outputs

주의사항

1. 기존 데이터: 이미 잘못된 형식으로 저장된 데이터가 있다면 삭제하거나 마이그레이션 필요.

2. 모든 중첩 레벨: 중첩이 여러 단계라면 각 단계의 모델 모두에 explicitToJson: true 추가 필요.

3. 빌드 실행: 모델 수정 후 반드시 build_runner 실행하여 generated 파일 업데이트 필요.

요약

• 문제: @JsonSerializable()만 사용하면 중첩 객체가 JSON으로 변환되지 않음
• 해결: @JsonSerializable(explicitToJson: true) 추가
• 결과: 중첩 객체가 자동으로 toJson()으로 변환되어 올바르게 직렬화됨

📋 목차

1. List (리스트)
2. Set (셋)
3. Map (맵)
4. 비교표
5. 언제 무엇을 사용할까?
6. 시간 복잡도 (Big O)

List (리스트)

정의

• 순서가 있는 요소들의 컬렉션
• 중복 요소 허용
• 인덱스로 접근 가능 (0부터 시작)

문법

// 타입 명시
List<int> numbers = [1, 2, 3, 4, 5];

// 타입 추론
final numbers = <int>[1, 2, 3, 4, 5];

// 빈 리스트
final emptyList = <int>[];

주요 특징

• ✅ 순서 보장 (삽입 순서 유지)
• ✅ 중복 허용
• ✅ 인덱스 접근 가능 (list[0])
• ✅ 동적 크기 조절 가능

주요 메서드

final list = <int>[1, 2, 3];

// 추가
list.add(4);                    // [1, 2, 3, 4]
list.addAll([5, 6]);            // [1, 2, 3, 4, 5, 6]
list.insert(0, 0);              // [0, 1, 2, 3, 4, 5, 6]

// 삭제
list.remove(3);                 // [0, 1, 2, 4, 5, 6]
list.removeAt(0);              // [1, 2, 4, 5, 6]
list.clear();                    // []

// 접근
final first = list[0];          // 첫 번째 요소
final last = list.last;          // 마지막 요소
final length = list.length;      // 길이

// 검색
final contains = list.contains(2);  // true/false
final index = list.indexOf(2);      // 인덱스 반환

// 순회
for (int i = 0; i < list.length; i++) {
  print(list[i]);
}

for (final item in list) {
  print(item);
}

사용 예시

// 쇼핑 리스트 (순서 중요)
final shoppingList = ['우유', '빵', '계란'];

// 점수 목록 (중복 허용)
final scores = [85, 90, 85, 88];

// 메뉴 항목 (인덱스로 접근)
final menuItems = ['홈', '검색', '프로필'];
final firstItem = menuItems[0]; // '홈'

Set (셋)

정의

• 중복 없는 요소들의 컬렉션
• 순서 보장 안 함 (일부 구현체는 순서 유지 가능)
• 인덱스 접근 불가

문법

// 타입 명시
Set<int> ids = {1, 2, 3, 4, 5};

// 타입 추론
final ids = <int>{1, 2, 3, 4, 5};

// 빈 Set
final emptySet = <int>{};

주요 특징

• ✅ 중복 자동 제거
• ✅ 빠른 검색 (O(1) 평균)
• ❌ 인덱스 접근 불가
• ❌ 순서 보장 안 함 (LinkedHashSet은 순서 유지)

주요 메서드

final set = <int>{1, 2, 3};

// 추가
set.add(4);                     // {1, 2, 3, 4}
set.addAll([5, 6]);             // {1, 2, 3, 4, 5, 6}
set.add(3);                     // {1, 2, 3, 4, 5, 6} (중복 무시)

// 삭제
set.remove(3);                  // {1, 2, 4, 5, 6}
set.clear();                     // {}

// 검색
final contains = set.contains(2);  // true/false (O(1) - 매우 빠름!)

// 집합 연산
final set1 = {1, 2, 3};
final set2 = {2, 3, 4};

final intersection = set1.intersection(set2);  // {2, 3} (교집합)
final union = set1.union(set2);                // {1, 2, 3, 4} (합집합)
final difference = set1.difference(set2);      // {1} (차집합)

// 순회
for (final item in set) {
  print(item);
}

사용 예시

// 북마크 ID (중복 방지)
final _ids = <int>{2, 4};

// 고유한 태그 목록
final uniqueTags = {'한식', '양식', '중식', '일식'};

// 저장된 사용자 ID
final savedUserIds = <int>{1, 3, 5, 7};
if (savedUserIds.contains(3)) {  // 빠른 검색!
  print('이미 저장됨');
}

Map (맵)

정의

• 키-값 쌍(key-value pair)을 저장하는 컬렉션
• 키는 중복 불가, 값은 중복 가능
• 키로 값을 빠르게 찾을 수 있음

문법

// 타입 명시
Map<String, int> scores = {
  '철수': 85,
  '영희': 90,
};

// 타입 추론
final scores = <String, int>{
  '철수': 85,
  '영희': 90,
};

// 빈 Map
final emptyMap = <String, int>{};

주요 특징

• ✅ 키-값 쌍 저장
• ✅ 키로 빠른 검색 (O(1) 평균)
• ✅ 키는 중복 불가, 값은 중복 가능
• ❌ 인덱스 접근 불가 (키로만 접근)

주요 메서드

final map = <String, int>{
  '철수': 85,
  '영희': 90,
};

// 추가/수정
map['민수'] = 88;                // {'철수': 85, '영희': 90, '민수': 88}
map['철수'] = 90;                // {'철수': 90, '영희': 90, '민수': 88} (수정)

// 접근
final score = map['철수'];       // 90
final score2 = map['없는키'];    // null

// 안전한 접근
final score3 = map['철수'] ?? 0; // 값이 null이면 0 반환

// 삭제
map.remove('민수');              // {'철수': 90, '영희': 90}
map.clear();                     // {}

// 검색
final hasKey = map.containsKey('철수');  // true
final hasValue = map.containsValue(90);  // true

// 키/값 목록
final keys = map.keys;           // {'철수', '영희'}
final values = map.values;       // {90, 90}

// 순회
for (final entry in map.entries) {
  print('${entry.key}: ${entry.value}');
}

for (final key in map.keys) {
  print('$key: ${map[key]}');
}

map.forEach((key, value) {
  print('$key: $value');
});

사용 예시

// 사용자 이름-점수
final userScores = <String, int>{
  '철수': 85,
  '영희': 90,
  '민수': 88,
};

// 레시피 ID-북마크 시간
final bookmarkTimes = <int, DateTime>{
  2: DateTime(2024, 1, 15),
  4: DateTime(2024, 1, 20),
};

// 설정값 저장
final settings = <String, dynamic>{
  'theme': 'dark',
  'language': 'ko',
  'notifications': true,
};

비교표

언제 무엇을 사용할까?

List를 사용하는 경우

✅ 순서가 중요한 경우

final shoppingList = ['우유', '빵', '계란']; // 구매 순서

✅ 중복이 허용되어야 하는 경우

final scores = [85, 90, 85, 88]; // 같은 점수가 여러 번

✅ 인덱스로 접근이 필요한 경우

final menuItems = ['홈', '검색', '프로필'];
final firstItem = menuItems[0]; // '홈'

✅ 순차적으로 처리하는 경우

for (int i = 0; i < items.length; i++) {
  print('${i + 1}. ${items[i]}');
}

Set을 사용하는 경우

✅ 중복을 방지해야 하는 경우

final _ids = <int>{2, 4}; // 북마크 ID - 같은 ID를 여러 번 저장하면 안 됨

✅ 빠른 검색이 필요한 경우

final savedIds = <int>{1, 3, 5, 7};
if (savedIds.contains(3)) { // O(1) - 매우 빠름!
  print('이미 저장됨');
}

✅ 고유한 값들만 관리하는 경우

final uniqueTags = {'한식', '양식', '중식', '일식'}; // 태그는 중복되면 안 됨

✅ 집합 연산이 필요한 경우

final set1 = {1, 2, 3};
final set2 = {2, 3, 4};
final intersection = set1.intersection(set2); // {2, 3}
final union = set1.union(set2); // {1, 2, 3, 4}

Map을 사용하는 경우

✅ 키로 값을 찾아야 하는 경우

final userScores = <String, int>{
  '철수': 85,
  '영희': 90,
};
final score = userScores['철수']; // 85

✅ 각 항목에 추가 정보가 필요한 경우

final bookmarks = <int, BookmarkInfo>{
  2: BookmarkInfo(time: DateTime.now(), note: '맛있어요'),
  4: BookmarkInfo(time: DateTime.now(), note: '추천!'),
};

✅ 설정값이나 캐시를 저장하는 경우

final settings = <String, dynamic>{
  'theme': 'dark',
  'language': 'ko',
  'notifications': true,
};

시간 복잡도 (Big O)

List

Set

Map

성능 비교 예시

100만 개의 데이터에서 검색:

결론: 자주 검색하는 데이터는 Set이나 Map을 사용하는 것이 훨씬 효율적입니다!

요약

• List: 순서 있고 중복 허용, 인덱스 접근 가능
• Set: 중복 없음, 빠른 검색, 고유한 값 집합
• Map: 키-값 쌍, 키로 빠른 검색, 관련 데이터 저장

각 컬렉션 타입은 고유한 특성과 용도가 있으므로, 상황에 맞게 선택하는 것이 중요합니다! 🚀

안녕하세요! 오늘은 제가 사용하려고 개발한 FCM 푸시 메시지 테스트 서버를 소개하려고 합니다.

🎯 이런 분들께 추천합니다

• 모바일 앱 개발 중 푸시 알림 기능을 테스트하고 싶은 개발자
• FCM 메시지 포맷을 빠르게 실험해보고 싶은 분
• 대량의 푸시 메시지 발송 테스트가 필요한 분
• 간단한 웹 인터페이스로 푸시를 보내고 싶은 분

💡 왜 만들었나요?

앱 개발 중 푸시 알림 기능을 테스트할 때마다 매번 코드를 작성하거나 복잡한 툴을 사용해야 하는 번거로움이 있었습니다. "그냥 토큰만 입력하면 바로 푸시를 보낼 수 있는 간단한 도구가 있으면 좋겠다"는 생각으로 이 프로젝트를 시작했습니다.

✨ 주요 기능

1. 심플한 웹 인터페이스

별도의 클라이언트 설치 없이 브라우저에서 바로 사용할 수 있습니다.

2. 다중 토큰 지원

여러 디바이스에 동시에 푸시를 보낼 수 있습니다. 각 토큰당 원하는 개수만큼 메시지를 발송할 수 있어 부하 테스트에도 유용합니다.

3. 메시지 커스터마이징

JSON 형식으로 푸시 메시지를 자유롭게 커스터마이징할 수 있습니다.

• Notification (제목, 내용)
• Custom Data (key-value 형태의 커스텀 데이터)
• Android/iOS 특정 설정

4. REST API 지원

웹 인터페이스뿐만 아니라 REST API로도 사용할 수 있어 CI/CD 파이프라인이나 자동화 테스트에 통합하기 쉽습니다.

🚀 사용하기

정말 간단합니다! 필요한 건 딱 두 가지:

1. Firebase 서비스 계정 JSON 파일 Firebase 서비스 계정 키(JSON 파일) 발급 방법 Firebase Console에 접속 프로젝트 선택 프로젝트 설정 > 서비스 계정 탭으로 이동 "새 비공개 키 생성" 클릭하여 JSON 파일 다운로드 JSON 파일을 안전하게 보관

2. FCM 디바이스 토큰 모바일 환경에서 Firebase SDK 를 통해 각 Device 별로 부여되는 FCM Token

# 설치
npm install

# 환경 변수 설정 (.env 파일)
FIREBASE_SERVICE_ACCOUNT_PATH=./your-firebase-service-account.json

# 실행
npm start
이제 http://localhost:3000에 접속하면 바로 사용할 수 있습니다!

🌟 특징

쉬운 설정: 복잡한 설정 없이 Firebase 서비스 계정 파일만 있으면 됩니다 실시간 결과: 각 토큰별 발송 성공/실패 여부를 실시간으로 확인 대량 테스트: 토큰당 최대 100개까지 메시지를 동시에 발송 가능 사용자 친화적: 직관적인 UI와 JSON 유효성 검사 기능

🔧 기술 스택

Backend: Node.js, Express.js Push Service: Firebase Admin SDK Frontend: Vanilla JavaScript (의존성 없음!)

📦 GitHub에서 확인하기

더 자세한 내용은 GitHub 저장소에서 확인하실 수 있습니다: 👉 https://github.com/stevey-sy/push_test_server

💬 마치며

개발하면서 제가 필요했던 기능들을 담아 만든 도구입니다. 푸시 알림 테스트로 시간을 낭비하시는 분들께 조금이나마 도움이 되었으면 좋겠습니다. 😊

🚨 문제 상황

Android 앱 개발 중 다음과 같은 상황을 경험해보셨나요?

• 디버그 모드가 아닌 일반 실행 상태인데도 "Waiting for Debugger" 메시지가 표시
• 앱이 무한 대기 상태에 빠져 정상적인 테스트 불가
• adb kill-server 및 adb start-server로 ADB를 재시작해도 문제가 지속

🔍 원인 분석

이 현상은 이전에 adb shell am set-debug-app 명령어로 설정된 디버그 앱 설정이 제대로 해제되지 않아 발생합니다. 시스템이 해당 패키지를 여전히 디버그 대상으로 인식하고 있어, 디버거 연결을 기다리는 상태가 지속되는 것입니다.

✅ 해결 방법

다음 ADB 명령어를 실행하여 문제를 해결할 수 있습니다:

adb shell am clear-debug-app

명령어 설명

• clear-debug-app: 이전에 set-debug-app으로 설정된 디버그 앱 설정을 완전히 제거
• 시스템에서 특정 패키지를 디버그 대상으로 인식하지 않도록 초기화

💡 예방 팁

1. 디버그 세션 종료 시: 디버그 작업 완료 후 명시적으로 clear-debug-app 실행
2. 빌드 변경 시: Release 빌드로 전환할 때 디버그 설정 확인
3. 디바이스 변경 시: 새로운 테스트 디바이스 사용 전 디버그 설정 초기화

이 간단한 명령어 하나로 개발 생산성을 크게 향상시킬 수 있습니다. 비슷한 문제를 겪고 계시다면 한 번 시도해보세요! 🚀

레퍼런스

https://jinryua.tistory.com/8 https://developer.android.com/tools/adb?hl=ko

✨ 문제 설명

자연수 n이 주어졌을 때,

n을 3진법으로 변환하고,

3진법 숫자를 뒤집은 뒤,

그 결과를 다시 10진법으로 변환해서

리턴하는 함수를 작성해야 합니다.

📌 제한사항

n은 1 이상 100,000,000 이하인 자연수입니다.

🧠 문제 접근

이 문제는 다음 3단계를 이해하면 쉽게 풀 수 있습니다:

✅ 1. 10진법 → 3진법 Kotlin에서 n.toString(3)을 사용하면 간단하게 3진법 문자열로 바꿀 수 있습니다.

✅ 2. 문자열 뒤집기 reversed()를 사용해서 문자열을 뒤집으면 됩니다.

✅ 3. 3진법 문자열 → 10진법 문자열.toInt(3)으로 3진법 문자열을 다시 10진수로 변환할 수 있습니다.

✏️ 예제 풀이 예제 1) text 복사 편집 입력: 45

1. 3진법으로 변환 → 1200

2. 문자열 뒤집기 → 0021

3. 10진법으로 변환 → 7 예제 2) text 복사 편집 입력: 125

4. 3진법으로 변환 → 11122

5. 문자열 뒤집기 → 22111

6. 10진법으로 변환 → 229 ✅ 최종 코드 (Kotlin) kotlin 복사 편집

   class Solution { fun solution(n: Int): Int {

    val reversedBase3 = n.toString(3).reversed()
    return reversedBase3.toInt(3)

   } }

📚 참고: 진법 변환 요약 목적 Kotlin 코드 10진수 → 3진법 문자열 n.toString(3) 3진법 문자열 → 10진수 "22111".toInt(3) 문자열 뒤집기 "abc".reversed()

💬 마무리 이 문제는 Kotlin의 내장 함수만 잘 사용하면 한 줄로도 풀 수 있는 깔끔한 문제입니다. 진법 변환 로직을 직접 구현할 수도 있지만, 코딩테스트에서는 내장함수를 적극 활용하는 것도 전략입니다 💡

val array = intArrayOf(-1) 이거는 가능함.

여기서 각 자리 수의 합을 구하려면

• x.toString().toCharArray() .map{it.toString().toInt()} .sum()

• Char 에서 toInt() 는 없음. String 에서 toInt() 는 있음.

for (i in a.indices) 는 불가능해.

for (i in 1 until n) 은 가능해.

까먹지 말자 쫌!

val name = arrayOf("may", "kein")
val yearning = intArrayOf(5, 10)

// 아래 코드 오류 발생
val map = name.zip(yearning) // ❌

✅ 이유: IntArray는 Iterable이 아님

• zip() 함수는 Iterable 타입을 요구함
• IntArray는 기본형 배열 (primitive) → Iterable 아님 → 사용 불가
• List<Int>는 객체형 컬렉션 → Iterable 구현 → 사용 가능

✅ 해결 방법

val map = name.zip(yearning.toList()) // ✅ OK

• IntArray를 toList()로 변환하여 zip() 가능

✅ 비교 정리

✅ 결론

• zip(), map() 등 고차 함수 사용 시 → IntArray.toList() 필요
• 실수 줄이려면 List<Int> 중심으로 사용하는 습관도 👍

먼저 예시에 사용된 프로젝트는 Google 공식 샘플 앱인 nowinandroid 의 아키텍처를 채용하고 있는 점 참고부탁드립니다.

• MVVM 아키텍쳐
• Multi Modules

🎯 구현 목표

책 리스트 화면 -> 상세 화면으로 전환 시, 책 표지 이미지가 자연스럽게 전환되도록 Shared Element Transition 구현.

📝 구현 포인트 (딱 이것만 기억합시다.)

✅ 1. 전체 UI를 SharedTransitionLayout으로 감싸기

✅ 2. 공유할 요소에 sharedTransitionScope, animatedVisibilityScope 전달

✅ 3. 요소마다 고유 key와 애니메이션 효과 설정

📝 구현 과정

1. 애니메이션 적용할 전체 부분을 SharedTransitionLayout 로 씌우기.

본 예시의 경우, 두 개의 화면이 존재합니다.

• 리스트 화면(SearchBookScreen),
• 상세 화면(SearchBookDetailScreen).

그리고 화면 이동 시 공유될 element 가 있습니다.

• 리스트 화면 item의 이미지 (element A)
• 상세 화면의 이미지 (element B)

리스트 화면의 item 을 클릭했을 때, 상세 화면으로 이동하며 가 공유됩니다.

먼저 애니메이션 적용할 전체 부분은 Navigation Graph 에 적용했습니다.

// MainActivity
 SharedTransitionLayout {
   NavigationGraph(navController = navController, sharedTransitionScope = this)
 }

2. 애니메이션을 주고자 하는 각 element 에 sharedTransitionScope, animatedVisibilityScope 전달하기.

각 Screen -> element 까지 sharedTransitionScope을 전달합니다. sharedTransitionScope은 SharedTransitionLayout 에서 받아올 수 있습니다.

// MainActivity
@SuppressLint("UnusedSharedTransitionModifierParameter")
@OptIn(ExperimentalAnimationApi::class, ExperimentalSharedTransitionApi::class)
@Composable
fun NavigationGraph(navController: NavHostController, sharedTransitionScope: SharedTransitionScope) {
    NavHost(
        navController = navController,
        startDestination = MY_LIBRARY_ROUTE
    ) {
        myLibraryScreen(
            onNavigateToSearch = { navController.navigateToSearch() }
        )

        searchBookScreen(
            sharedTransitionScope = sharedTransitionScope,
            onNavigateBack = { navController.popBackStack()},
            onNavigateToDetail = { isbn, cover ->
                navController.navigateToSearchBookDetail(isbn, cover)
            }
        )

        searchBookDetailScreen(
            sharedTransitionScope = sharedTransitionScope,
            onNavigateBack = { navController.popBackStack() }
        )
    }
}

// 
@OptIn(ExperimentalSharedTransitionApi::class)
fun NavGraphBuilder.searchBookScreen(
    sharedTransitionScope: SharedTransitionScope,
    onNavigateBack: () -> Unit,
    onNavigateToDetail: (isbn: String, cover: String) -> Unit,
) {
    composable(SEARCH_ROUTE) {
        SearchBookScreen(
            sharedTransitionScope = sharedTransitionScope,
            animatedVisibilityScope = this,
            onNavigateBack = onNavigateBack,
            onNavigateToDetail = onNavigateToDetail,
        )
    }
}

이번에는 animatedVisibilityScope 를 전달합니다. animatedVisibilityScope 은 composable로 부터 받아올 수 있습니다.

SearchScreen 의 매개변수로 sharedTransitionScope, animatedVisibilityScope 을 넘겨주었습니다.

3. 각 element 에 key 제공, 애니메이션 효과 적용하기

이제 넘겨받은 sharedTransitionScope, animatedVisibilityScope 변수를 원하는 element 에 연결해줍니다.

### SEARCH BOOK SCREEN
@OptIn(ExperimentalMaterial3Api::class, FlowPreview::class, ExperimentalSharedTransitionApi::class)
@Composable
fun SearchBookScreen(
    sharedTransitionScope: SharedTransitionScope,
    animatedVisibilityScope: AnimatedVisibilityScope,
    onNavigateBack: () -> Unit,
    onNavigateToDetail: (isbn: String, cover: String) -> Unit,
    viewModel: SearchViewModel = hiltViewModel(),
)
... 화면 구성..

### SEARCH BOOK SCREEN
        with(sharedTransitionScope) {
            SubcomposeAsyncImage(
                model = book.cover,
                contentDescription = null,
                modifier = Modifier
                    .sharedElement(
                        rememberSharedContentState(key = "image/${book.cover}"),
                        animatedVisibilityScope = animatedVisibilityScope,
                        boundsTransform = {initial, taget -> tween(durationMillis = 1000)}
                    )
                    .size(width = 90.dp, height = 140.dp)
                    .padding(start= 10.dp, bottom= 10.dp)

마찬가지로 SearchBookDetailScreen 의 매개변수로 sharedTransitionScope, animatedVisibilityScope 을 넘겨주었습니다.

### SEARCH BOOK DETAIL SCREEN
@OptIn(ExperimentalMaterial3Api::class, ExperimentalSharedTransitionApi::class)
@Composable
fun SearchBookDetailScreen(
    isbn: String,
    cover: String,
    onNavigateBack: () -> Unit,
    viewModel: SearchDetailViewModel = hiltViewModel(),
    sharedTransitionScope: SharedTransitionScope,
    animatedVisibilityScope: AnimatedVisibilityScope
) {
... 화면 구성 소스

### SEARCH BOOK DETAIL SCREEN
 with(sharedTransitionScope) {
         SubcomposeAsyncImage(
            model = cover,
            contentDescription = "책 표지",
            modifier = Modifier
            .sharedElement(
                rememberSharedContentState(key = "image/$cover"),
                animatedVisibilityScope = animatedVisibilityScope,
                boundsTransform = {initial, taget -> tween(durationMillis = 1000)}
            )
            ... 

저의 경우에는 애니메이션을 적용할 sharedElements는 SubcomposeAsyncImage 였습니다.

애니메이션이 공유될 두 가지의 elements 에 with(sharedTransitionScope) {} 블럭으로 SubcomposeAsyncImage 을 감쌉니다.

그러면 modifier.sharedElement() 속성을 사용할 수 있게됩니다.

.sharedElement() 안에는 이제 unique 한 key 값을 넣어야 합니다. 그리고 animatedVisibilityScope 속성에는 매개변수로 받아온 변수를 세팅합니다.

마지막으로 원하는 애니메이션 효과를 적용합니다. 이 부분은 생략해도 기본 boundsTransform 애니메이션이 적용되었습니다.

더 자세한 소스는 아래 링크에서 확인 가능합니다. https://github.com/stevey-sy/odok-compose

더 자세한 동작 원리와 효과들은 공식 가이드에서 확인 가능합니다. https://developer.android.com/develop/ui/compose/animation/shared-elements

상태를 담는 상자: StateFlow는 "항상 최신 값을 담고 있는 상자"라고 생각하면 돼요. 예를 들어, 학교 게시판에 최신 공지사항이 항상 붙어 있는 것처럼, StateFlow는 항상 최신 상태(값)를 기억해요.

바뀔 때마다 알려줌: 이 상자의 내용이 바뀌면, 그 변화를 보고 싶어하는 사람(예: 앱의 화면)이 바로 업데이트를 받을 수 있어요.

StateFlow를 사용하지 않으면 어떤 점이 불편할까? 직접 갱신해야 함: 만약 단순한 변수를 사용한다면, 그 값이 바뀌었을 때 매번 직접 찾아서(또는 알려줘야) 업데이트해야 해요. 예를 들어, 게임의 점수를 화면에 보여주려면, 점수가 바뀔 때마다 누군가가 "이제 점수가 이렇게 바뀌었어!"라고 알려줘야 해요.

업데이트 누락 위험: 만약 값이 바뀌었는데 그 변화를 제대로 전달하지 못하면, 화면에 오래된 정보가 남아 있을 수 있어요. 예를 들어, 여러분이 점수를 기록하는데, 점수가 바뀌어도 화면에 그 변화가 바로 나타나지 않는다면 게임이 제대로 진행되지 않겠죠?

관리 복잡도 증가: 여러 곳에서 데이터를 직접 관리하고 업데이트해야 하므로, 코드가 복잡해지고 실수가 생길 확률도 높아져요.

정리하면

StateFlow는 "항상 최신 상태를 자동으로 관리해주는 도구"예요.

사용하면: 데이터가 바뀔 때마다 자동으로 최신 정보를 화면에 보여줄 수 있어서 편리하고 안전해요.

사용하지 않으면: 최신 정보를 직접 관리해야 하므로, 업데이트가 늦어지거나 빠뜨리는 문제가 생길 수 있어요.

이런 이유로 StateFlow는 앱에서 데이터의 최신 상태를 유지하고, 그 변화를 자동으로 반영하는 데 큰 도움이 됩니다.

LiveData 방식도 충분히 잘 동작하고 널리 사용되는 패턴입니다. 다만, StateFlow를 사용하면 다음과 같은 몇 가지 장점을 얻을 수 있어요:

코루틴과의 자연스러운 통합

LiveData는 Android Lifecycle에 맞게 설계되어 있지만, StateFlow는 코루틴 기반이기 때문에 suspend 함수나 다른 Flow 연산자들과 함께 사용하기가 더 쉽습니다. 그래서 비동기 처리를 할 때 코드가 더 간결해질 수 있어요.

항상 최신 값 유지

StateFlow는 항상 최신 상태를 보관하기 때문에, 구독자가 새롭게 연결되었을 때 즉시 최신 값을 받을 수 있어요. LiveData도 최신 값을 유지하지만, StateFlow는 코루틴 환경에서 더 예측 가능한 방식으로 동작합니다.

테스트 용이성

코루틴과 Flow를 기반으로 하기 때문에, 단위 테스트나 통합 테스트를 할 때 상태 흐름을 제어하고 검증하기가 더 쉽습니다.

불필요한 observeForever 방지

LiveData를 observeForever로 관찰하면 Lifecycle의 도움을 받지 못해 메모리 누수 위험이 있습니다. 반면, StateFlow는 LifecycleScope나 repeatOnLifecycle 같은 코루틴 기반 함수를 사용하여 안전하게 구독할 수 있어요.

즉, 기존의 LiveData 방식도 충분히 잘 동작하지만, 코루틴을 적극적으로 사용하고자 할 때는 StateFlow가 더 깔끔하고 관리하기 쉬운 선택이 될 수 있습니다. 어떤 방식을 선택할지는 프로젝트의 요구사항과 팀의 선호도에 따라 달라질 수 있습니다.

1. 기존 비동기 작업: 콜백 기반

콜백(callback) 방식의 구조 콜백 방식은 비동기 작업이 끝난 후 실행될 코드를 함수로 전달하는 방식입니다. 하지만 작업이 많아질수록 콜백 지옥(Callback Hell)이라고 불리는 문제가 발생합니다. 코드가 중첩되면서 읽기 어렵고, 디버깅도 힘들어집니다.

예제: 네트워크 요청 후 데이터 처리 아래는 콜백 기반으로 두 개의 네트워크 요청을 순차적으로 실행하는 예입니다.

kotlin

fun fetchData(callback: (String) -> Unit) {
    // 네트워크 요청 A
    simulateNetworkRequest("Request A") { resultA ->
        // 네트워크 요청 B (A의 결과를 이용)
        simulateNetworkRequest("Request B based on $resultA") { resultB ->
            // 최종 데이터 처리
            callback(resultB)
        }
    }
}

fun simulateNetworkRequest(data: String, callback: (String) -> Unit) {
    Thread {
        Thread.sleep(2000) // 네트워크 요청 시뮬레이션 (2초 대기)
        callback("$data - Response")
    }.start()
}

fun main() {
    fetchData { finalResult ->
        println("최종 결과: $finalResult")
    }
}

문제점

콜백 안에 콜백을 정의하다 보면 코드가 오른쪽으로 점점 밀리면서 복잡해집니다. 요청이 3개, 4개로 늘어나면 가독성이 더 떨어집니다.

에러 처리 어려움. 에러가 발생했을 때, 어떤 요청에서 발생했는지 파악하기 어렵습니다. 에러 처리를 하려면 각각의 콜백마다 에러를 처리하는 코드를 추가해야 합니다.

2. 코루틴으로 개선된 비동기 작업

코루틴은 비동기 작업을 동기식 코드처럼 작성할 수 있도록 도와줍니다. suspend 함수를 사용하면 중첩된 콜백 없이 작업의 흐름을 순차적으로 작성할 수 있습니다.

코드 예제: 동일한 작업을 코루틴으로 구현 kotlin

import kotlinx.coroutines.*

suspend fun fetchData(): String {
    val resultA = simulateNetworkRequest("Request A")
    val resultB = simulateNetworkRequest("Request B based on $resultA")
    return resultB
}

suspend fun simulateNetworkRequest(data: String): String {
    delay(2000) // 네트워크 요청 시뮬레이션 (2초 대기)
    return "$data - Response"
}

fun main() = runBlocking {
    val finalResult = fetchData()
    println("최종 결과: $finalResult")
}

개선된 점 코드 가독성:

작업 순서를 동기식 코드처럼 직관적으로 작성할 수 있습니다. 네트워크 요청 A → B → 결과 처리의 흐름이 명확합니다. 에러 처리 간편화:

try-catch를 사용하여 에러를 처리할 수 있습니다. 어떤 작업에서 에러가 발생했는지 쉽게 파악 가능합니다.

3. 에러 처리 예제

콜백 기반의 에러 처리 에러 처리를 추가하려면 각 콜백마다 별도의 에러 처리 로직을 추가해야 합니다.

kotlin

fun fetchData(callback: (String?, Throwable?) -> Unit) {
    simulateNetworkRequest("Request A") { resultA, errorA ->
        if (errorA != null) {
            callback(null, errorA)
            return@simulateNetworkRequest
        }
        simulateNetworkRequest("Request B based on $resultA") { resultB, errorB ->
            if (errorB != null) {
                callback(null, errorB)
                return@simulateNetworkRequest
            }
            callback(resultB, null)
        }
    }
}

fun simulateNetworkRequest(
    data: String,
    callback: (String?, Throwable?) -> Unit
) {
    Thread {
        try {
            Thread.sleep(2000)
            callback("$data - Response", null)
        } catch (e: Exception) {
            callback(null, e)
        }
    }.start()
}

코루틴 기반의 에러 처리 코루틴에서는 try-catch로 간단하게 처리할 수 있습니다.

kotlin

suspend fun fetchData(): String {
    return try {
        val resultA = simulateNetworkRequest("Request A")
        val resultB = simulateNetworkRequest("Request B based on $resultA")
        resultB
    } catch (e: Exception) {
        "에러 발생: ${e.message}"
    }
}

suspend fun simulateNetworkRequest(data: String): String {
    delay(2000)
    if (data.contains("Error")) throw Exception("네트워크 오류!")
    return "$data - Response"
}

결론

기존의 콜백 기반 비동기 작업은 중첩 문제와 복잡한 에러 처리 로직으로 인해 코드 가독성이 떨어지는 단점이 있었습니다. 반면, 코루틴은 비동기 작업을 동기식 코드처럼 작성할 수 있게 해주어 가독성, 유지보수성, 디버깅 측면에서 훨씬 유리합니다. 실제 프로젝트에서는 코루틴을 사용해 효율적으로 비동기 작업을 관리하는 것이 권장됩니다. 😊

1. 코루틴 스코프란?

코루틴 스코프는 코루틴이 실행되는 공간을 의미합니다. 코루틴을 실행하고 관리하며, 모든 작업이 완료되면 스코프는 자동으로 정리(clean-up)됩니다. 여러 비동기 작업을 안전하게 실행하고, 필요할 경우 취소하거나 관리할 수 있습니다.

코루틴 스코프의 주요 역할: 작업 관리: 여러 코루틴을 하나의 스코프 안에서 실행. 자동 정리: 스코프 내 모든 작업이 끝나면 자원을 정리. 구조적 동시성: 비동기 작업을 구조적으로 관리해 코드 복잡도를 줄임.

코루틴 스코프 예시:

fun main() {
    runBlocking { // 코루틴 스코프
        launch { // 코루틴 실행
            val result = fetchData()
            println(result)
        }
        println("다른 작업을 실행 중입니다!")
    }
}

runBlocking: 코루틴 스코프를 생성하고 블록 내의 작업이 모두 끝날 때까지 실행을 유지합니다. launch: 코루틴을 실행합니다. 코루틴은 비동기로 작동하므로 다른 작업과 동시에 실행됩니다.

1-1. 비유: 요리사와 레스토랑

코루틴 스코프는 레스토랑의 주방과 같아요.

주방에서는 여러 요리사가 동시에 요리를 준비할 수 있어요. 각각의 요리사는 자기 요리를 하다가, 재료가 준비될 때까지 기다리거나 다른 요리를 도와줄 수 있어요. suspend 함수는 요리사가 잠깐 멈추고 기다리는 것과 같아요.

요리사가 물을 끓이는 동안 물이 끓을 때까지 기다리면서 다른 요리를 준비하거나 쉬어요. 하지만 기다린다고 해서 주방이 멈추는 건 아니에요. 다른 요리사들은 계속해서 요리를 준비하니까요.

2. 코루틴의 역할

프로그래밍에서도 "기다려야 하는 일"이 자주 생겨요. 예를 들어:

인터넷에서 책 정보를 가져오는 일. 파일을 다운로드하는 일. 게임에서 상대방의 행동을 기다리는 일. 기다리는 동안 프로그램이 멈추면 사용자가 불편하겠죠? 코루틴은 프로그램이 멈추지 않고 다른 일을 계속할 수 있도록 도와줘요.

3. 코루틴과 suspend 함수의 장점

효율적인 작업 처리: 시간이 오래 걸리는 작업(예: 네트워크 요청, 파일 읽기 등)을 기다리는 동안 다른 작업을 처리할 수 있습니다. 코드 가독성: 콜백(callback) 중첩 없이 비동기 코드를 동기식 코드처럼 작성할 수 있습니다. 사용자 경험 개선: 메인 스레드를 블로킹하지 않기 때문에 앱이 더 부드럽게 작동합니다.

3-1. suspend 함수의 역할 비유

suspend 함수는 코루틴에서 특별히 멈추고 기다릴 수 있는 함수예요.

예를 들어, 인터넷에서 데이터를 가져오는 함수는 시간이 걸려요. 이런 함수는 suspend로 만들어져야 코루틴에서 사용자가 기다리는 동안 다른 일을 할 수 있어요.

kotlin

suspend fun boilWater(): String {
    // 물을 끓이는 데 시간이 걸린다고 상상해봐요
    delay(3000) // 3초 기다리기 (코루틴에서만 사용 가능)
    return "물이 끓었어요!"
}

delay(3000)은 3초 동안 기다리라는 의미인데, 이 3초 동안 다른 작업이 멈추지 않도록 코루틴이 알아서 처리해줘요.

4. 코루틴 스코프란?

코루틴 스코프는 코루틴을 실행하는 공간이에요. 요리사의 주방처럼요.

예를 들어, 레스토랑에 요리사가 여러 명 있고, 각각의 요리사가 코루틴이라고 생각해요. 주방(코루틴 스코프)은 요리사들이 일을 하다가 끝나면 깨끗이 치워주는 역할을 해요.

코루틴 스코프 만들기 kotlin

fun main() {
    runBlocking { // 코루틴 스코프
        launch {
            val result = boilWater()
            println(result)
        }
        println("다른 작업을 하고 있어요!")
    }
}

runBlocking: 주방을 열고 코루틴을 실행해요. launch: 요리사 한 명이 일을 시작해요. 프로그램은 물이 끓을 동안(3초) 다른 작업(println)도 처리해요.

5. 왜 코루틴과 suspend 함수가 좋은 걸까?

효율적이에요!: 오래 걸리는 작업(인터넷 요청, 파일 다운로드 등)을 기다리는 동안 다른 작업을 할 수 있어요. 간단해요!: 복잡한 코드를 깔끔하고 읽기 쉽게 만들 수 있어요. 다른 프로그램을 멈추지 않아요!: 사용자는 앱이 끊기지 않고 부드럽게 작동하는 걸 느낄 수 있어요.

6. 핵심 요약

코루틴 스코프는 여러 일을 동시에 할 수 있게 도와주는 작업 공간이에요. suspend 함수는 잠깐 멈춰야 하는 함수인데, 멈춰도 프로그램 전체가 멈추지 않게 해줘요. 코루틴 덕분에 복잡한 비동기 작업을 더 쉽고 깔끔하게 처리할 수 있어요.

7. 실제 예제

예를 들어, 사용자가 버튼을 눌러 데이터를 가져오는 동안, 메인 스레드는 UI를 업데이트하거나 애니메이션을 실행할 수 있습니다.

코드 예제 kotlin

import kotlinx.coroutines.*

fun main() {
    runBlocking { // 메인 스레드를 차단하지 않는 코루틴 스코프
        launch {
            // 2초 동안 데이터를 가져오는 작업
            println("데이터 가져오기 시작")
            val data = fetchData()
            println("가져온 데이터: $data")
        }

        // 동시에 다른 작업도 실행 가능
        launch {
            repeat(5) { i ->
                println("UI 작업 중... $i")
                delay(500) // 0.5초 대기
            }
        }
    }
}

suspend fun fetchData(): String {
    delay(2000) // 데이터를 가져오는 데 2초 소요
    return "데이터 가져오기 성공"
}

실행 결과 위 코드를 실행하면 다음과 같은 결과를 볼 수 있습니다:

데이터 가져오기 시작
UI 작업 중... 0
UI 작업 중... 1
UI 작업 중... 2
UI 작업 중... 3
UI 작업 중... 4
가져온 데이터: 데이터 가져오기 성공

첫 번째 코루틴: 데이터를 가져오는 데 2초 걸립니다. 두 번째 코루틴: 0.5초마다 "UI 작업 중..."이라는 메시지를 출력합니다.

이 두 작업이 동시에 실행되며, 2초가 지나기 전에 UI 작업이 5번 출력됩니다. 메인 스레드의 역할 위에서 UI 작업 중... 메시지는 메인 스레드가 처리할 수 있는 작업을 예로 든 것입니다.

실제 앱에서는:

화면을 렌더링 (예: 리스트를 스크롤하거나 애니메이션 실행). 사용자 입력 처리 (예: 버튼 클릭, 스와이프 동작 등). 네트워크 요청 대기 중에도 앱이 부드럽게 작동.

요약

코루틴의 suspend 함수는 작업을 잠깐 멈출 수 있지만, 메인 스레드는 멈추지 않고 계속 실행됩니다. 이로 인해 UI 작업과 비동기 작업을 동시에 처리할 수 있어, 사용자 경험이 크게 향상됩니다.