Technote

홀의 6개 다 작업해야 검사를 시작할 수 있는 것이 아니라 홀은 1개, 몇 개만 뚫어도
각 홀이 자신의 공차역의 들어왔는지만 확인하면 되기때문에 부분적으로 작업해도 검사가 가능하다.

BCD가 하나의 숫자로 나타날 수 없다는 것 때문에 많은 사람들이 BCD에 +-공차로 바꿔서 말한다고 착각하기도 한다.

하지만, 기본 치수랑 위치도의 조합으로 규정한 홀의 센터, 공차역은 각 홀마다 한 개씩 공차역이 생기는 거기 때문에 BCD 통째로 공차를 어떻게 두어야 한다. 이런 이야기가 빠져있어 BCD를 +-공차로 컨버팅 할 수 없다.

위치공차를 사용하지 않으면 공차역은 어떤 모습일까?

일단 그림상 BCD의 공차는 나와있지만, 아쉽게도 이렇게 나오면 해석이 불가능하다.

홀의 종류

좌측에서부터 1 ~ 5

1,2	깊이만 빼고 같은 홀, 막힌 홀 = BLIND HOLE
3	관통된 홀 = THRU HOLE
4	BLIND HOLE / Counterbored Hole (카운터 보링)
5	BLIND HOLE / Countersunk Hole (카운터 싱킹)
4,5	볼트 머리가 튀어나오지 않게 하기 위한 디자인

홀의 표기법

깊이 정보가 확인되지 않는 경우에 홀 직경 뒤에 깊이정보 (기호+숫자)를 명시한다.
관통형일 경우 THRU를 붙임
즉, 홀표기 = 직경기호 + 직경값 + 깊이기호 + 깊이값

홀의 깊이값

홀 깊이값은 드릴 팁 부분을 포함하는 것이 아닌 원통형 부분만을 이야기 하는 것이다.

(ASME Y14.5 2018 4.5.10 Round Holes)

드릴팁 끝까지의 치수가 중요하다면, 치수를 명시하여 관리해도 무방함

모든 홀깊이의 표기는 표면을 기준으로 한다.

그리고 깊이 정보를 다른 뷰에서 확인 가능한 경우, 굳이 중복으로 써주지 않아도 된다.

1, 2번 홀의 경우 2번은 잘못된 도면 형상이다.

카운터보어, 카운터 싱킹 기호

카운터 보어 / 카운터 싱킹 기호

카운터 보어 예시

측면도를 가지는 도면을 측면도 없이 중간 도면처럼 명시할 수 있다.

카운터 싱킹 예시

P.S

깊이 기호 대신 DP, 카운터 보어 기호 대신 CB, 카운터 싱킹 기호 대신 CS로

표기되어 있는 경우도 있다.

(ASME Y14.5 규정에는 정의되어 있지 않은 표현)

(표준에 없는 기호를 별도로 정의해서 써도 무방하다고 표준에는 나와있긴 하다.)

Youtube TeleV2 신입사원 도면강좌 36~37

모양공차(선/면 윤곽도), ○,◎, U 모디파이어

bumjae — Wed, 25 Dec 2024 17:16:12 +0900

윤곽도

기하공차 중 가장 독특한 기하공차라고 한다.

데이텀을 붙여도 되고 안붙여도 되는 특이한 기하공차 (물론 의미는 달라짐)

진원도 (2D)	원통도 (3D)
원주 흔들림 (2D)	온 흔들림 (3D)
진직도 (2D)	평면도 (3D)
선 윤곽도 (2D)	면 윤곽도 (3D)

선 윤곽도는 공차역이 깊이 값이 없는 평면 형태(면적)로 생기고
면 윤곽도는 공차역이 부피 값을 가지는 형태(공간)로 생긴다.
윤곽도에는 MMC/LMC 모디파이어 사용 불가 (데이텀 MMB/LMB는 가능)
윤곽도는 외형선 따라서 만들어지는 기하공차이기 때문에 별, 하트 등 다양한 모양이 가능하다.

면 윤곽도

윤곽도의 적용을 받는 치수는 기본치수로
- 외형선 자체가 윤곽도 공차역의 기준으로 쓰이므로 기본치수로 쓰임
형상이 이 폭이 3mm인 공차역 부피 공간 안에 들어오면 합격
현재, 데이텀 참조가 없으므로 공차역의 위치가 공간상 구속되어 있지 않기 때문에 공차역을 움직일 수 있음
- 움직여서 공차역 공간안에 들어오는지를 판단 가능
면 윤곽도는 이 하나의 공차역(공간) 안에 모든 형상(점)이 다 들어와야 함

선 윤곽도

선 윤곽도의 공차역은 깊이가 없는 영역
각 단면에서의 공차역이 독립적이다 = 매번 새로 도출된다.

위처럼 모든 단면이 각각 다 공차역 면적 안에 들어오면 합격

이전 공차역이 이후 공차역(뒤 새로운 단면)을 검사할때 영향을 미치지 않는다.

선 윤곽도, 면 윤곽도 차이

극단적인 예시로 위 형상은 면 윤곽도일 경우 불합격이지만 선 윤곽도 공차일 경우 합격이다.

데이텀이 있는 경우 윤곽도

위치를 규정하기 위해 데이텀을 사용

(형상 높이 10)

해석) 10.0, 4.3의 위치에서 가로 9.5, 세로 8.5, 높이 10 크기 형상의 폭이 3.0인 공차역(분홍선)을 가지는 홀 형상의 윤곽도
외형과 관련되어있는 치수들은 윤곽도 때문에 기본 치수를 표시해야 함
위치가 어디인지 확인하기 위해 데이텀을 참조함

윤곽도 기호

○ (All Around)

윤곽도 화살표에 사용된 원의 의미

하나에 국한되는것이 아니라 전체 면에 다 적용된다.

All around 적용시 아래와 같이 공차역이 생성된다.

◎ (All Over)

All around의 기호에서 원하나가 더 있을시 모든 면 전체 형상(3D)으로 적용된다.

All over 적용시 그림과 같이 공차역이 생성된다.

면 윤곽도 예시에 All over 적용시 높이 치수를 기본치수로 변경해야하고

공차역은 아래 오른쪽 그림과 같이 전체 모든 면의 형상을 가지는 공차역을 가지게 된다.

All Around와 All Over 차이점

All around는 사용한 특정 면 기준에 대해 형상을 제어하고,

All over를 사용하면 전체 면(정면, 배면, 평면, 저면, 좌측, 우측면)에 대해 형상을 제어한다.

U 모디파이어

Unequally - disposed의 약자로 뜻은 불평등한 배치? 처리이다.

윤곽도 지정시 양측으로 공차를 주는데 서로 다른 공차를 부여한다.

ASME Y14.5 - 2018 11.3.1.2

재료가 추가되는 방향으로 공차역을 부여한다.

External Feature(밖으로 튀어나온 형상)의 경우 바깥으로 먼저 부여,

Internal Feature(안으로 들어간 형상)의 경우 안으로 먼저 부여

3.0 ⓤ 2.0

3.0의 폭을 가진 공차역을 생성할때 바깥(재료가 추가되는 방향)으로 2.0 안으로 1.0의 공차역을 할당

윤곽도와 다른 모양공차의 차이점

위 사진에서 형상이 원이면 윤곽도와 진원도/원통도랑 차이가 없다고 생각할 수 있지만 차이점이 있다.

진원도 / 원통도 = 공차역의 크기가 정해져있지 않음(내원과 외원 사이의 간격만 일정하면 그만이기 때문)
윤곽도 = 공차역의 크기가 정해져있음
그렇기 때문에 모양공차에서 진직/평면/진원/원통에 있는 공차역을 기본공차로 설정하고 싶다면 윤곽도 공차로 변경하면 된다.

Youtube TeleV2 신입사원 도면강좌 34~35

흔들림 공차(원 흔들림, 온 흔들림)

bumjae — Wed, 25 Dec 2024 15:41:04 +0900

흔들림 공차

회전체에 특화된 기하공차

진원도 + 1차원 = 원통도

진직도 + 1차원 = 원통도

원주 흔들림 + 1차원 = 온 흔들림

파이 기호 쓰지 않음
무조건 데이텀을 참조한다.
사이즈는 치수에 따라 23~27
공차역의 직경은 고정되지 않는다.
기본 치수 쓰지않음
모디파이어 쓰지 않음

원주 흔들림은 이전 검사와 다음 단계 검사와의 관계가 독립적이다.

1씩 공차역이 옮겨가며 모두 만족하면 합격

(이전 공차역의 직경은 무시가 되고 새롭게 공차역의 직경을 찾아야 한다.)

온 흔들림은 경사면이나 곡면이 있는 형상의 경우 온 흔들림 공차가 적용될 수 없다.

원주, 온 흔들림 공차와 진원도, 원통도의 가장 큰 차이점

= 데이텀 참조 유무

또한, 흔들림 공차는 위 그림처럼 회전축에 수직인 면에도 적용 가능하다.

그리고 치수 공차의 크기보다 큰 값 부여가 가능하다.

수직면 공차 주입, 원주 흔들림 / 온 흔들림

면 사이의 공차역 안에 형상이 들어오면 합격

Youtube TeleV2 신입사원 도면강좌 33

자세공차(평행도,직각도,경사도), 기본치수

bumjae — Mon, 23 Dec 2024 10:57:09 +0900

간단히 설명하면
직각도(수직도) 공차는 90도에 대한 내용
평행도는 0도에 대한 내용
경사도는 모든 각도에 대한 내용

자세공차의 특징

축을 데이텀 삼아 다른 축과 면을 관리, 반대로 면을 데이텀 삼아 다른 축과 면을 관리할 수 있다.
자세공차를 안 쓰면 처음 제작의 어려움이 있을 수 있다.
항상 기준이 되는 데이텀을 참조해야 한다. (데이텀이 없으면 틀린 도면)
자세공차는 평면도의 역할을 동시에 하고 있으면서 방향을 추가한 것이다.
공차역의 위치는 고정 되어있지 않다.
공차역의 방향만 구속 되어있다. (마음대로 공차역을 움직일 수는 있으나 각도는 유지하며 움직임)
직각도(수직도)랑 평행도는 기본치수를 쓰지 않는다.
경사도는 예외적으로 경사를 알려주는 각도치수가 쓰이기는 한다.

예시

직각도(수직도)

데이텀 A 면에 대해 수직인 상태의 직경과 폭 0.12의 공차역이 생기고

이 공차역 안에 홀 센터가 모두 들어와야 합격

평행도

데이텀 A 면에 평행한 폭이 0.12인 두평면 사이의 공차역이 생긴다.

이 공차역 안에 면이 모두 들어와야 합격

경사도

데이텀 B면의 30도 만큼 키울어진 폭 0.12의 두평면 사이의 공차역이 생긴다.

이 공차역 안에 면이 모두 들어와야 합격

경사도를 그냥 각도+공차로 관리하면 안될까?

위 처럼 공차를 적용할 경우 도합 0.4도의 부채꼴 형태의 공차역이 나올것이다.

제품이 엄청나게 긴 상황이 있으면 뒤로 갈수록 공차역이 점점 커질것이다.

제품이 엄청 불규칙해도 전부 0.4도 폭의 공차역에 들어와 통과될 것이다. (관리가 안된다.)

기본치수

기본치수: 이론적으로 정확한 치수 (숫자에 네모로 채워진 형태)
→ 중요! 형상의 위치와 방향을 알려주는 치수가 아니라 공차역의 위치와 방향을 알려주는(구속하는) 치수다.

기본치수 필요유무

공차종류		기본치수 필요유무
모양공차	진원도,원통도,진직도,평면도	X
모양공차	선/면 윤곽도	O
자세공차	직각도,평행도	X
자세공차	경사도	△ (방향을 나타내는 기본치수만 필요)
흔들림 공차	원 흔들림, 온 흔들림	X
위치공차	위치도	O
위치공차	동심도,대칭도	X

Youtube TeleV2 신입사원 도면강좌 31~32

MMB

bumjae — Mon, 23 Dec 2024 09:19:37 +0900

기존 RFS 개념

RFS (Regardless of Reature Size) / 형체치수무관계

꼬다리의 크기와 관계없이 공차역의 크기는 항상 0.4 파이이다.
최대 축간 거리 = 두 축이 최대한 떨어질 수 있는 거리 (몸통 축과 꼬다리 축이 최대한 떨어질 수 있는 거리)
최대 축간 거리 = 공차역의 절반

AT MMC 개념

AT MMC

꼬다리의 크기에 따라 공차역의 크기도 변경된다.
최대 축간 거리 = 공차역의 절반

AT MMB

MMB는 기준(몸통의) 크기에 따라 바뀜
몸통크기에서 증가 감소된 수치의 절반만큼 축간 거리가 증가함
공차역의 크기가 늘어나지 않는다.
공차역의 시프팅(Shifting : 이동하는 것)을 허용하기 때문에 축간 거리가 늘어남

MMC vs MMB 비교

좌측 MMC : 공차역의 크기가 커짐 / 우 MMB : 공차역의 크기가 일정함

아래 그림같은 경우 MMB이기 때문에 합격이 가능하다.

(최대 축간 거리 1.2까지 허용, 공차역의 크기 일정하며, 시프팅 가능)

실제 몸통을 스캔해서 나온 축을 데이텀으로 삼는 것이 아니라 실제하지 않는 MMB의 축을 데이텀으로 삼겠다는 것이다.

MMB 예시

즉, MMB의 사용 이유는 제작자 입장에서 편함, 검사를 용이하게 해줌

AT MMC, AT MMB 동시 사용

꼬다리 크기에 따라 공차역 크기도 변경되고 몸통 크기에 따라 축간거리도 변경된다.

데이텀 시프팅이란?

MMB 바운더리의 중심축을 데이텀으로 삼아 MMB를 이동시켜도 공차역의 크기는 일정한 상태

AT MMB

MMB는 몸통의 크기에 따라 최대 축간 거리가 변경됨
위 도면에서 몸통은 19~21까지 가능
즉, MMB는 21파이의 사이즈를 가짐
최대 축간 거리 = 0.2 + (MMB - 실제 몸통의 외경) / 2
하지만 공차역의 크기는 변하지 않음
왜냐하면 데이터 시프팅이 가능하기 때문

3D 형태

위 그림처럼 몸통의 중심축이 아닌 MMB 바운더리의 중심축을 데이텀 A로 삼게 됨

여기서 MMB는 21파이, 공차역이 0.4파이인데

MMB를 어디로든 이동시켜도 공차역도 같이 움직이기 때문에 공차역의 크기는 일정함

MMC, LMC, MMB 모디파이어를 사용하는 이유는 제작, 검사를 편하게 하기 위해 사용

Youtube TeleV2 신입사원 도면강좌 27~30

모양공차 (진원도,원통도,진직도,평면도), 모양공차 오답 케이스

bumjae — Mon, 23 Dec 2024 01:19:32 +0900

진원도, 원통도

진원도는 축에 수직 한 단면이 원형형상인 곳에 붙일 수 있다.

원형 단면이 얼마나 제대로 된 "원"인지 관리해 주는 게 진원도이다.

진원도를 붙일수 있는 형상

축에 수직 한 단면을 쳤을 때 원형이기만 하면 진원도로 컨트롤이 가능하다.

원통도를 붙일수 있는 형상

하지만 원통도는 오직 원통형인 물체에만 사용이 가능하다.

기하공차 종류에서 모양공차의 진직도, 평면도, 진원도, 원통도는 데이텀이 필요 없는 기하공차이다.
또한, 공차값 앞에 Ø(파이)를 붙이지 않는다.

이것들의 사용이유는? (설계자의 의도는 무엇인가)

= 사이즈는 크거나 작아도 상관이 없는데 만들 거면 단면 쳤을 때 좀 예쁜 원으로 만들어라

진원도, 원통도 예시

제작자를 편하게 해주고 싶어 공차를 60 +- 20으로 크게 줌

실제로 이렇게 만들어온 경우

위 경우에서 공차에 맞게 제작했기 때문에 제작자는 잘못이 없다.

이를 방지하기 위해 진원도 / 원통도를 사용한다.

진원도

주의 : 표면에 직접 찍어야 한다.

진원도 1.0 : 두 동심원이 만든 폭 1.0짜리 띠 영역 (공차역)

공차역의 센터는 꼭 제품의 축 위에 놓일 필요는 없다.

진원도 표시 결과

원 다운 원이 생성된다.

진원도에서 축이 틀어진 예시

진원도의 경우 제품의 형상 자체에만 관심이 있기 때문에

다른 것 대비 기울어지거나 편심이 생긴 것은 고려하지 않는다.

진원도 : 각 단면마다 매번 공차역이 새로 생김

그렇기 때문에 "모두가 일치해야 한다" 싶을 때 원통도를 사용한다.

원통도 : 한 번 생긴 공차역 안에 모든 것이 다 들어와야 만족한다.

그렇기 때문에 원통도의 경우 검사도 몹시 철저하다.

공차가 만약 60+-20이 아니라 60+-0.1이면 의미가 없다.

그렇기 때문에 무조건 사이즈 공차보다 진원도 공차의 폭이 작아야 한다.

진직도

진원도를 한 차원 확장하면 원통도

진직도를 한 차원 확장하면 평면도

~~간단히 하면 진직도, 평면도의 관계는 진원도, 원통도의 관계와 같다.~~

예시1) 표면에 직접 붙인 타입

예시2) 치수 밑에 붙인 타입

진직도는 간단히 보여도 상당히 까다로운 기하공차이다.

모두 모양공차로 데이텀 참조 안 하며 Ø기호 역시 사용하지 않는다. (예시 1 에만 해당)

진직도는 기하공차를 표면에 바로 붙이냐 / 관련 치수 밑에 붙이냐에 따라 의미가 크게 달라짐

예시 1 안에서도 뷰의 방향에 따라 규제의 방향이 달라짐

진직도 Type1 - 표면 위 각 직선 성분의 편차를 관리

진직도 타입 1은 방향성이 있다.

모두 같은 투상이지만 정면도 우측면도에 따라 진직도의 길이가 다르게 설정되어 있다.

진직도는 데이텀을 참조하지 않는다.

기울어진 예

제품의 표면이 기울어져 있어도 폭이 0.1인 공차역에 가둘 수만 있다면 진직도로써 만족한다.

만약 진직도가 없다면?

이런 모양의 제품을 받을 것이다.

즉, 진직도는 제품을 제작하기 전에 한번 더 걸러주는 정제(Refinement)의 역할을 해준다.

진직도 역시 진원도처럼 무조건 사이즈 공차의 폭보다 진직도 공차의 폭이 더 작아야 의미가 있다.

진직도 Type1에서 가능한 최악의 케이스

원통형에 진직도를 명시할 경우

아래는 합격가능한 최악의 케이스의 모음들이다.

타입 1에서는 위처럼 어떠한 최악의 경우에도 MMC boundary를 넘어서지 못한다. (넘으면 불량)

(AME의 축을 사용)

ASME 14.5 / 5.8.1 Rule #1

어떤 형상이든 그 형상이 FOS면 MMC 바운더리를 넘어설 수 없다.

하지만, 타입 2에서는 가능하다.

진직도 Type2 : FOS(Feature Of Size)의 치수에 붙인 경우

공차역이 더 이상 표면이 아니라 축 근처에서 도출된다.

median line을 먼저 찾은 뒤 그걸 감쌀 수 있는 0.1 파이의 공차역을 찾는다

Median Line이 원통형 공차역 안에 들어오는지를 본다.
타입 2는 원통형 공차역을 가지므로, Ø기호를 기입한다.
타입 2는 제품의 형상이 MMC boundary 밖으로 나갈 수 있다.
위 그림의 OB(17.1)가 MMC(17.0) 보다 큰데 상관없다.
타입 2는 사이즈 공차의 폭보다 큰 진직도 공차값도 넣어줄 수 있다.
MMC/LMC 모디파이어도 붙일 수 있다.

AT MMC

AT MMC / VC

직경	진직도 공차역
Ø16.8	Ø0.3
Ø16.0	Ø1.1
Ø15.0	Ø2.1

진직도는 "단위길이당" 컨트롤이 가능

단위 길이당 컨트롤 / 임의의 25mm 당 0.1 (그냥 검사자 마음대로 아무데나 25mm 끊은 구간)

너무 휘지 않았음 하는 경우

전체 길이 규제 (윗줄)

단위길이 규제 (아랫줄)

평면도

평면의 고르기를 관리하는 기하공차

예시

데이텀 참조 불가
Ø 사용 불가
편차 0.5 이내일 것

해석

해당 평면을 구성하는 모든 점들이 0.5의 갭을 가진 나란한 두 평면 사이의 공간에 전부 들어오게 해라

공차역

데이텀과 기본치수가 없기 때문에 합격시키기 위해서 공차역을 기울여도 무방하다.

데이텀을 참조하지 않아 공차역이 공간상 구속되어 있지 않기 때문

기울어진 공차역

공차역이 기울어져 있다.
평면도 공차역의 크기(0.5)는 치수공차역(+-1 = 2.0) 보다 작아야 한다. (0.5 < 2.0)

평면도 주의사항

표면에 직접 붙이는 방식 (type1)	가리키고 있는 표면의 편차를 0.5 이내로 관리 MMC 영역을 벗어날수 없음
치수 아래에 붙이는 방식 (type2)	중심평면의 편차를 0.5 이내로 관리 MMC 영역을 벗어날 수 있음

OB (Outer Boundary) : 21.5 (20+1+0.5)
치수 아래에 붙이는 방식은 폭(Width) 치수에만 가능함

단위면적당 요건 부여 가능

전체면적 0.3 안에 들어와야 한다.
25 X 25 단위 면적당 0.05 안에 들어와야 한다.
즉, 전체는 여유 있게 / 단위는 타이트하게

전체규제 없이 단위면적당 요건만도 부여 가능

모양공차 오답 케이스

모양공차 사용 중 오답들을 하나씩 지우면서 진행

CASE 1 : 모양공차에 데이텀 사용 X

CASE 2 : 모양공차 Ø 사용 불가
(진직도 Type 2 예외)

진직도 Type 2 / 대상이 아니라 공차역의 생김새가 원통형일 때 붙이는 것

CASE 3 : 기본치수 사용 불가

기본치수 : 형상의 위치가 아니라 공차역의 위치를 특정하는 치수

CASE 4 : 치수공차역 > 기하공차역 관계
(진직도, 평면도 Type2 예외)

모양공차에서 치수공차역 > 기하공차역 관계여야 한다.
+-0.1인데 기하공차는 0.3이므로 0.1 미만의 값이어야만 성립된다.

전부 수정한 도면

모양공차 간단 정리

데이텀 사용 X
Ø 사용 X (진직도 Type 2 예외)
기본치수 사용 X
치수공차역 크기 > 기하공차역 크기 (진직도, 평면도 Type2 예외)

사용 이유

제작할 때의 공정에서 제작자가 편해진다.

제작자 입장에서는 공차가 작을수록 제작이 어렵다.

예시 1

예시 1의 치수공차의 15.99 ~ 16.01 직경 범위보다

모양공차를 넣어 예시 2처럼 치수공차를 0.5로 설정하고 기하공차를 0.02를 넣어

직경의 편차만 0.02로 설정해 달라 하면 제작자 입장에서 상대적으로 쉬워질 것이다.

예시 2

예시 1	15.99 ~ 16.01 벗어나면 불량
예시 2	15.98 ~ 16.02 or 16.00 ~ 16.04 or 16.10 ~ 16.14 or... = 통과

Youtube TeleV2 신입사원 도면강좌 23~26

위치공차 (위치도,동심도,대칭도)

bumjae — Sat, 21 Dec 2024 13:53:34 +0900

기본치수 없이 쓰이는 위치도

CASE 1 : 형상에 수직 한 데이텀인 경우

C 기본치수가 없는 경우

바닥면(C)에 수직 한 상태를 유지하면서 공차역을 생성해라

CASE 2 : A 형상의 축에 B 형상의 축을 맞추는 경우

A 기본치수가 없는 경우

한쪽 축을 다른 쪽 축에 맞게 공차역을 생성해라

* 현실에서 두 축이 완벽히 일치할 수가 없음.

왼쪽 축 = 데이텀 (기준), 오른쪽 축 = 검사대상

오른쪽 축을 검사했을 때 왼쪽 축 중심을 참고하여 생긴 공차역에 들어오면 합격

CASE 3 : A 형상의 중심평면에 B 형상의 중심평면을 맞추는 경우

A 기본 치수가 없는 경우

데이텀 A, 마주 보는 두 면을 시뮬레이팅해서 찾아낸 중심평면에 맞춘 공차역에 들어오면 합격

위치공차는 반드시 FOS에만 붙일 수 있다.

FOS (Feature Of Size) - ASME Y14.5 1994
한 개의 원통형 표면, 구형 표면, 원형 형상, 두 개의 마주 보고 있는 평행한 라인이나 형상을 Feature Of Size라고 한다.

간단히 얘기하면 홀 표면, 핀 표면, 슬롯의 마주 보고 있는 표면 등 그런 것들을 FOS라고 부른다.

정리하면 위치공차는 이러한 형상의 센터가 공차역 안에 들어오도록 하자라는 의미

위치공차가 이상하게 명시되어 있어 도면 해석이 안 되는 경우

CASE 1 : FOS가 아닌 경우

위 같은 경우 기하공차 부분이 FOS가 아니다.
각 면 모두 오른쪽을 바라보는 형태이기 때문에 (마주 보고 있지 않는 형태) 공차역을 정의할 수 없기 때문에 해석이 안된다.

CASE 2 : 기하공차의 위치가 잘못된 경우

FOS는 맞으나 컨트롤 하고자 하는 형상은 홀의 형상
16X Ø5.0+-0.1 부분이기 때문에 해당 공차에 기하공차를 넣어야 한다.

CASE 3 : FOS가 아닌 경우

FOS(마주 보는 형상)가 아니기 때문에 해석이 안 되는 케이스이다.
위치공차를 쓰지 않고 그냥 아래 치수 공차로 (1.3 / 2= 0.65) 대체할 수 있다.

CASE 4 : 데이텀의 위치가 잘못된 경우

데이텀 A의 위치가 오른쪽에 있으면 안 된다.
오른쪽 축을 검사했을 때 왼쪽 축 중심을 참고하여 생긴 공차역에 들어와야 합격해야 하므로 데이텀 A는 왼쪽 축에 위치하여야 한다.

CASE 5 : 기본치수 오사용

굳이 진위치(True Position) 표현하는 기본치수를 사용해서 틀린 케이스

제대로 그려진 케이스

동심도, 대칭도

(ASME 2018에서 동심도, 대칭도가 표준에서 제외됨)
(ISO 에는 남아있다)

축, 중심평면

동심도와 대칭도를 알아보기 전 이전에서 계속 언급된 축이랑 중심평면이 무엇인지 알아볼 필요가 있다.

현실에서의 형상이 불규칙하다고 축과 평면도 그러한가? 아니다.
축 = 곧다, 중심평면 = 평평하다, 두 전제는 깔려있어야 한다. (ASME 규정)

보라색선 : AME

윗면 아랫면에 딱 붙으면서 완벽히 평행을 이루고 있는 평면이 점점 다가오면서 맞물리는 순간 더 이상 좁혀지지 못하는 경계선이 있다.

이것을 ASME에서 AME라 칭한다.

AME (Actual Mating Envelop)

멀리 떨어진 두 평면이 거리를 좁히면서 제품의 각 면의 돌출 된 세 점에 닿는 외관면 (보라색 선)
형상의 축이라는 것은 이 AME의 축이라고 일컫는다.

위치도 과정에서 공차역을 구해 이 AME의 축을 기준으로 합격, 불합격을 판명한다.

즉, 위치도는 "축 vs 축 / 중심평면 vs 중심평면"을 본다.

또한 축은 언제나 곧고 중심평면은 언제나 평평하다.

그렇기 때문에 위치도는 언제나 축(Axis)과 중심평면(Center Plane)의 개념을 사용하여 해석한다.

동심도, 대칭도가 위치도와 다른 결정적인 차이점은 축, 중심평면 대신 중심(Median Point) 개념을 사용한다.

하늘색 점들 : 미디언 포인트들이 많이 찍힌 모습 동심도 ❘ 대칭도

모든 점의 모든 Median Point를 다 구해야 한다.
한 점이라도 공차역 밖으로 나가면 불합격이다.

동심도는 축 vs MP, 대칭도는 중심평면 vs MP를 본다.

예시) 찌그러진 형상

위 예시의 경우 위치도일 경우에는 AME에 영향을 못 미쳐 합격한다.

하지만 동심도일 경우에는 축 vs MP이기 때문에 불합격된다.

즉, 위치도보다 동심도가 기준이 엄격하다.

예시) 양쪽 평행하게 찌그러트림

위 예시와 같이 찌그러짐도 평행하다면 MP가 중앙으로 잡혀 동심도 요건 만족 가능하다.

P.S

1. 동심도와 대칭도는 M L과 같은 모디파이어 사용이 불가능하다.

2. ISO에서는 위치도 공차도 Median Point를 통해 검사한다.

AME를 사용해야 할 경우 Evelop 모디파이어 사용

Envelop 모디파이어 기호

두줄 위치공차

패턴의 로케이션을 스케일 할 때 사용 (패턴 : 형상이 반복적으로 일어나는 것)
위쪽은 상하좌우 모두 움직임이 가능하나 아래쪽은 좌우만 움직일 수 있다.

윗줄은 전체적인 요건 (공차역이 큼)
아랫줄은 (디테일하게, 세심하게) 다듬는 요건 (공차역이 작음)

예시

패턴 : 5파이 홀 3개 (같은 형상 반복)

패턴 외부치수 : 76, 6.4

패턴 내부치수 : 20 (패턴 요소 사이의 관계를 규정짓는 것)

패턴해석

윗줄 해석

공간 상에 고정되어 있는 공차역을 도출
패턴 내부 및 외부 치수를 모두 사용하여 공차역을 도출

아랫줄 해석

공차역이 공간상에 고정되어있지 않다.
패턴 내부 치수만 사용하여 공차역을 도출

윗줄 공차역과 아랫줄 공차역의 교집합 안에 들어오면 합격, 아닐시 불합격

아랫줄의 위치도가 데이텀 A를 참조하고 있으므로 공차역은 데이텀 A에 수직함을 유지하면서 도출

Youtube TeleV2 신입사원 도면강좌 20~22, 27 (두줄 위치공차)

데이텀, 데이텀 참조 순서 영향, 기호 X (ASME)

bumjae — Sat, 21 Dec 2024 12:33:48 +0900

데이텀

기하공차를 지시하는 경우, 이들을 측정하기 위한 기하학적 기준이 되는 선 혹은 면

A로 지시된 도면 형상의 면이 데이텀?

제품의 표면은 데이텀이 될 수 없다.

그러므로 이것은 이 표면을 이용해 데이텀 A를 만들어 내라는 것이다.

즉, 데이텀 A를 만들어 내기 위한 "재료"로 쓰라는 것

그 "재료"를 Datum Feature라고 부른다.

데이텀은 결과물을 말하는 것이고 우리는 도면에 재료인 데이텀 피쳐를 달아주는 것이다.

이 데이텀을 만들어주는 데 사용하는 도구가 Datum Simulator이다.

ex) 세팅 잘해놓은 정반, 잘 깎아놓은 지그, 선반의 척 등을 이용하여 그런 도구가 재료에 닿으면서 데이텀이 발생

즉, Datum Feature (재료)에 Datum Simulator (도구)를 갖다 대어 Simulated Datum (결과물)을 도출한다.

p.s 데이텀 피쳐를 명시할 때 사용되는 영문자를 Datum Feature Symbol이라 부른다.

데이텀 피처를 명시하는 방법

A, B	표면
C	전체적인 표면을 가리킬때 형상 내부에
D	보이지 않는 뒷면
주의 E, F / 치수선과 나란한 것과 그렇지 않은 것은 서로 다른 데이텀을 도출함.
E	치수보조선 (세모 안채워도 상관없음)
F	치수선과 나란히 있어서 반대편 면까지 잡아서 그 중심면을 찾아냄
G	기하공차 쪽 데이텀

P.S

데이텀에서 I, O, Q는 사용하지 말 것 (ASME Y14.5 2009 3.3.2)

혼동의 여지가 있는 문자이므로 제외한다.

잘못된 데이텀 예시

데이텀 피쳐는 데이텀을 만들어내는 재료에 표시하는 것이기 때문에

물리적으로 존재하는 표면에다가 명시해야 함

데이텀 도출 종류

a	판 표면이 데이텀
b	(치수선과 나란히) 중심평면이 데이텀
c	구의 중심점
d	실린더의 표면에 찍었을 때 축이 데이텀
e	축과 점 모두 데이텀
f	면의 윤곽도 / 축과 중심평면
g	복잡한 모습/ 축, 점, 중심평면

데이텀 참조 순서에 따른 영향

A B : 먼저 A 참조, B 참조

B A : 먼저 B 참조, A 참조

데이텀을 참조한다 = 장비에 물린다, 갖다댄다

데이텀의 우선순위 = 장비에 물리거나 갖다 대는 순서

예시 1

A ❘ B

B ❘ A

위 사진처럼 데이텀을 물리는 순서에 따라 형상(여기서는 홀)의 공차역이 달라진다.

현실에서 제품은 완벽한 모습이 아니다.
데이텀 시뮬레이터가 서로 최대한 직각을 유지하면서 움직이기 때문이다.

예시 2

A 16파이 돌출부의 축 / B 평면

데이텀을 물리는 순서차이

참조 순서에 따른 영향을 알아볼 수 있다.

B \| A	3.1파이 홀은 플렌지와는 수직하지만 16파이 돌출부와는 평행하지 않게 됨
A \| B	3.1파이 홀은 16파이 돌출부와는 평행하지만 플렌지와는 수직함이 보장되지 않음

기호 X의 사용 (ASME 한정)

예시 1

예시 2

"X_" : 반복된 형상이 있을 때 깔끔하게 표기해 주는 용도 (뒤에만 띄어쓰기)
"_X_" : By의 역할, 가로 세로 (양옆 띄어쓰기)

모두 같은 의미

이 X의 사용은 미국 ASME 기준이며 KS와 ISO에서는 딱히 규정해 놓은 것은 없다.

Youtube TeleV2 신입사원 도면강좌 17~19

기하공차, VC(실효조건), M/L/S 모디파이어

bumjae — Fri, 20 Dec 2024 08:06:03 +0900

기하공차

치수와 치수공차만으로는 의사전달 수단이 부족해 도입된 공차

(모호함, 불명확함, 지저분함 해결)

예시) 노란별: 치수 공차 / 초록별 : 기하공차

기하공차는 일반적으로 해당되는 치수의 아래에 붙인다.

아닌 경우에는 빨간 별 부분처럼 직접 화살표로 찍어준다.

기하공차를 기입할 때는 기하공차의 종류, 공차역의 형태(∅)와 크기, 데이텀 순으로 기입한다.

기하공차의 종류

공차역 (Tolerance Zone)

어떤 기하공차를 해석하면 튀어나오는 공간상의 합격기준, 부피 또는 면적을 가진 영역

데이텀 (Datum)

기하공차를 지시하는 경우, 이들을 측정하기 위한 기하학적 기준이 되는 선 혹은 면

위치도 공차

가장 흔하게 만날 수 있는 기하공차, 가장 많이 사용
이 것을 먼저 숙지하면 다른 공차를 이해하는데 수월해진다.

예시 / 위와 같은 판재가 있고 구멍을 뚫으려 한다.

Q) 크기? A) 홀 크기 10에 +- 1이면 될 거 같다.
Q) 위치? A) 위치는 위에서 30, 왼쪽에서 50 위치
Q) 위치공차? A) 위치공차는 위 위치를 중심으로 반경 0.5안에 들어와야 한다.

홀 가공 정보
사이즈 정보	10
사이즈 공차	+-1
위치 정보	위로부터 30, 좌로부터 50
위치 공차	진위치로부터 반경 0.5 안 [진위치(True Postion) : 의도한 실제 위치]

아래 사진에서 좌측은 위치공차를 사용하지 않은 형태, 우측은 위치공차를 사용한 공차 형태이다.

위치공차 예시

좌측 형태의 경우 아래 그림처럼 공차역이 네모 모양이 되고 이것은 공차가 의도한 0.5를 벗어날 수도 있다.

따라서 공차역의 필요에 따라 다른 공차를 사용하여야 한다.

그래서 위 위치공차 예시 그림의 우측 형태처럼 위치공차를 사용하여 원래 의도했던 공차역의 형태로 가공을 하여야 한다.

30,50에 네모칸을 친 이유

기본치수 (Basic Dimension) : 진위치를 표현하기 위해 사용하는 치수
그러므로 위치공차 예시 그림의 우측처럼 치수공차는 지워지고 위치공차가 대신하게 된다.
또한 A,B와 같은 데이텀을 추가한다. (중요도 순서로 작성)

요약 : 작업 결과물(홀)의 센터가 진위치 중심 반경 0.5안에 들어와야 합격영역

→반경 0.5 = 직경 1.0 = 공차역의 크기

실효 조건 - Virtual Condition

명시된 크기와 기하 공차를 결합하여 특정 기능의 허용 변동 범위를 정의하는 개념

부품이 제대로 맞고 작동할 수 있도록 하기 위해, 해당 기능에 대한 최악의 상황을 나타낸다.

크기를 갖는 형체의 규정된 MMC나 LMC의 재료조건과

그 재료조건을 위한 기하공차의 전체적인 영향에 의해 얻어지는 일정한 경계선

위 홀의 예시에서 합격요건을 지키는 한 무수히 많은 종류의 합격된 제품들이 있을 것이다.

많은 합격 케이스들이 갖는 공통점이 있다.

어떤 특정한 위치를 침범하지 않는다는 것

9~11 사이 원은 모두 합격

홀을 뚫는다 (재료를 삭제한다)는 상황에서 빨간 원 경계 안 쪽은 무조건 재료가 삭제됨을 보장한다.

이 영역을 실효 조건 (Virtual Condition)이라 부른다.

홀의 직경이 가장 작은 상태 MMC에서 위치 공차 허용범위 내로 빼서 계산

VC 예시 (보라색 선)

즉, VC = MMC - 위치공차값

(홀의 경우 MMC (60-2) - 위치공차 1.0 = VC 57)

홀의 경우 순서대로 VC 8 / 44.3 / 7.7

P.S

사실, 위처럼 모디파이어가 없는 기본형에서는 VC라고 부르지 않는다.
~~원래 기본형에서는 Maximum inner boundry Maximum outer boundry 이런 식으로 부름~~

일단은 이해를 하기 위해 VC라 칭했다고 한다.

모디파이어 (Modifier)

동그라미 안에 M, L, S 등이 들어가 있는 기호를 모디파이어라고 부른다.

좌 RFS / 중간 MMC 모디파이어 / 우 LMC 모디파이어

Ⓜ : AT MMC	MMC일때
Ⓛ : AT LMC	LMC일때
Ⓢ : RFS (Regardless Feature of Size)	형체치수무관계 (사이즈랑 위치랑 무관한 관계) 현재는 주로 기본형으로 생략

AT MMC, AT LMC를 붙이게 되면 홀 사이즈에 따라 위치공차 값이 가변적으로 적용됨
사용이유 : 제작자 입장에서 제작을 편하게 해 주기 위해서

AT MMC 예시1

Q) 크기? A) 홀 크기 10에 +-1 이면 될 것 같다.
Q) 위치? A) 위치는 위에서 30, 왼쪽에서 50위치
Q) 위치공차? A) 위치공차는 모르겠고 VC 8만 지켜돌라

VC를 8로 맞춰돌라
Ø9	위치공차 1로
Ø9.1	위치공차 1.1로
Ø9.2	위치공차 1.2로
Ø10	위치공차 2로

AT MMC 예시2

Q) 위치공차? A) 앞으로는 "MMC일 때"의 공차만 적어놓겠다. 나머지 계산 가능합니까?
Q) 예를 들어 MMC니까 9일 때 위치공차 1 적용 맞습니까? VC 8 나오는 것 맞습니까?
A) 맞습니다.

모디파이어 전체 요약

RFS	VC 없음
홀 MMC	MMC - 위치오차값 = VC
홀 LMC	LMC + 위치오차값 = VC
핀 MMC	MMC + 위치오차값 = VC
핀 LMC	LMC - 위치오차값 = VC

Youtube TeleV2 신입사원 도면강좌 13~16

치수공차, MMC & LMC

bumjae — Fri, 20 Dec 2024 07:17:16 +0900

공차

설계상(공정상) 허용하는 오차

현실에서 완전 정확하게 만들 수 없기 때문에 공차 (허용오차)가 꼭 필요하다.
가공되는 모든 치수에는 공차가 붙는다.

공차에는 치수공차와 기하공차 두가지 종류가 있다.

치수공차

최대 한계 치수와 최소 한계 치수의 차

플러스 마이너스 톨러렌싱, 공차값 전체 기입 (리미트 디멘져닝)

공차 하한 상한 무제한 MIN,MAX

MIN과 MAX를 동시에 사용하는 것은 불가능하다.

MMC & LMC

MMC (Maximum material condition)	재료를 최대한으로 투입해 제작된 상태
LMC (Least material condition)	재료를 최소한으로 투입해 제작된 상태

CASE 1 : 상한 = MMC, 하한 = LMC

CASE 2 : 하한 = LMC, 상한 = MMC

MMC & LMC 개념을 알기 위해 형상 종류를 알고가야 한다.

Internal Feature	안으로 들어간 형상 (대표적으로 Hole, Slot)
External Feature	밖으로 튀어나온 형상 (대표적으로 Pin)

CASE 1 : 상한 = MMC , 하한 = LMC

위 Pin 형상에서 상한이 11이고, 하한이 9일 때

최대 재료 투입한 상태 11이 MMC이다.

최소 재료 투입한 상태 9가 LMC이다.

CASE 2 : 하한 = LMC , 상한 = MMC

위 Hole 형상에서 상한이 11이고, 하한이 9일 때

홀은 재료를 많이 투입할 수록 직경이 작아진다.

최대 재료 투입한 상태 9가 MMC이다.

최소 재료 투입한 상태 11이 LMC이다.

정리하면 MMC는 Pin일 때 최대직경 / Hole일 때 최소 직경

치수에서 MMC나 LMC를 논 할 수 있는 경우는 FOS(Feature of Size)

즉, 사이즈 치수인 경우에만 가능하다.

Youtube TeleV2 신입사원 도면강좌 11~12

규격, 치수

bumjae — Fri, 20 Dec 2024 06:21:24 +0900

규격

도면 규격은 나라마다 사용하는 표준이 다름

ASME (구 ANSI)	미국
ISO	유럽
JIS	일본
KS	한국

ASME와 ISO는 출발이 같으며 JIS는 ISO를 기반하고, KS는 JIS와 흡사

투상법

주로 3각법(Third Angle Projection)과 1각법(First Angle Projection) 사용

한국은 대부분 3각법 사용

위 3각법, 아래 1각법

우측면도가 왼쪽이면 1각법

치수 스타일

보통 한국은 ISO 스타일을 사용

ASME	- 치수선을 중간에 끊고 치수를 무조건 가로 방향 기입 - 마침표 사용
ISO	- 치수선을 끊지않고 치수선과 나란하게 치수 기입 - 콤마 사용
공통	- 치수선은 반드시 측정방향과 나란해야 한다 - 치수가 기입되는 선이 치수선 (Dimension Line) - 형상으로 부터 치수선에 연장되는 선이 치수보조선 or 연장선 (Extension Line)

치수 기입 팁

치수는 부족하지 않게 과도하지도 않게 (구속조건 확인)
도면에 제작 방법까지 명시할 필요는 없다.
하나에 대해 두 가지 이상의 해석이 나오지 않도록 명확히 그려야 한다. (혼동 지양)
같은 레벨의 치수끼리 정렬한다.
치수선 or 보조선의 불필요한 겹침을 피한다.
가장 가까운 치수는 10mm, 그다음부터는 6mm 간격으로 치수 그리기
스태거링 (staggering)하면 가독성이 높아진다. (같은 위치일 때 지그재그로 치수 정렬)
치수는 형상 외부에 배치한다.
(표준 외) 폰트의 크기가 너무 크면 보기에 그리 좋지 않다.
(표준 외) 치수가 너무 멀리 있으면 보기에 좋지 않다.
90도 치수는 생략해도 된다. (규정에 의거)

ASME Y14.5 (i) (j)	그려놓기를 90도처럼 그려놓았는데 90도라고 명시하지 않은 형상은 알아서 90도라고 생각한다. (공차 (+-0.5도))
ISO 2768-1	90도처럼 보이는데 명시되지 않은 것은 90도라고 생각하고 생략해도 된다.

Champer - 모따기, Fillet (Round) - 모깎기

형상의 날카로운 모서리에 손을 다치지 않게
다른 부품과의 결합이 쉽게 하기 위해

C / R / CR

R / SR

Ø / SØ

기호

Champer - 모따기 (C)
Fillet - 모깎기 (R)
Spherical Radius - 구형 모따기 (SR)
2차원 원형 지름 (Ø)
구형 원형 지름 (SØ) ex. 조이스틱
Controlled Radius - 표면을 더욱 처리한 라운드 (CR)

우측이 CR이며 안쪽으로 다시 꺾인 형태가 없어야 한다.

이 중에서 챔퍼 "C"는 ASME, ISO 규정에서는 사용하지 않는다고 한다.

그 이유는 두 챔퍼의 크기와 각도를 명시하는 방식으로 규정되어 있기 때문이다.

P.S "CR"은 ASME 도면에서만 사용 가능

챔퍼의 크기가 같아 줄여서 사용을 한다면 위와 같이 명시한다.

C와 CR를 사용하는 규정은 일본 JIS 규정으로 KS 규정은 JIS와 흡사하기 때문에 사용한다고 한다.

치수의 종류

치수 (Dimension)	일반 치수 제작에 참여하는 치수 = 공정에 가공되는 치수
참조치수 (Reference Dimension)	모두 지워도 도면해석에 문제없는 치수 사용 이유 - 이전 공정에서 이미 맞춰와서 이번에는 가공될 필요가 없을 때 - 자동으로 도출되는 치수 (지우기 가능) - 참고용 치수 (남은 치수 계산에 용이하게)
기본치수 (Basic Dimension)	'기하공차'를 해석할 때만 쓰는 치수

위 3개의 치수를 제외하고는 규정상 표준에 정의된 치수는 없다.

이외의 치수 같은 경우는 사용처에 물어보고 따를 것

도면 해석 팁

도면에서 치수 정보의 부족함을 쉽게 찾는 방법

하나의 치수는 형상의 위치정보이거나 사이즈 정보이거나 둘 중 하나이다.

사이즈 정보, 위치 정보

지름 원형 형상을 보고 사이즈 정보라는 것을 알것이고

"원형 형태라든지 홀 혹은 실린더의 외벽 그 다음에 마주 보고 있는 두 평면 따놓은 슬롯이라든지 이런 것들은 확실하게 얘는 사이즈다" 라고 말할 수 있다.

Youtube TeleV2 신입사원 도면강좌 1 ~ 10

object, companion object

bumjae — Tue, 2 Jan 2024 04:56:50 +0900

Object

Kotlin에서 object는 두가지 형태로 나뉜다.

Object Declarations (객체 선언식)
Object Expressions (객체 표현식)

Object Declarations

Kotlin에서는 Java와 다르게 Singleton Class를 사용하기 위에 Object Declarations(객체 선언)을 사용한다.

Java에서는 아래 코드처럼 보통 클래스의 constructor를 private으로 선언하고, statice 변수에 클래스 객체를 저장하는 방식으로 싱글턴 패턴을 구현한다.

public class Manager {
    private static Singleton INSTANCE;

    private Manager() { }

    public static Singleton getInstance() {
        if (INSTANCE == null) {
            INSTANCE = new Manager();
        }
        return INSTANCE;
    }
}

Kotlin에서는 객체 선언 (object) 기능을 통해 싱글턴을 언어 자체에서 기본지원 한다.

object Manager{

}

위 코드를 Java로 Decompile 해보면 아래와 같다.

Singleton 형태로 변환 되어 있다.

public final class Manager {
   @NotNull
   public static final Manager INSTANCE;

   private Manager() {
   }

   static {
      Manager var0 = new Manager();
      INSTANCE = var0;
   }
}

object Manager: TestClass(), ApiInterface {
	
	private val name: String = "Bumjae"
	
	override fun TestClassTodo(){
		...
	}
}

object 내에 class와 같이 멤버 변수 / 메서드를 가질 수 있으며, class 및 interface의 상속이 가능하다.
따라서, object를 선언식으로 사용하게 되면 자바의 Singleton 패턴과 같이 객체를 생성하여 사용할 수 있다.

Object Expressions

표현식 object는 선언식과 달리 Singleton의 형태로 사용하지 않는다.

호출할 때 마라 새로운 인스턴스가 생성되고, 익명 클래스 안에서 자신이 포함된 함수의 로컬 변수에 접근할 수 있다.

주로 다음과 같은 형태로 사용한다.

익명 클래스의 객체를 바로 생성하고자 하는 경우

fun main() {
    val user = object{
        val name = "Bumjae"
        val age = 28
    }
    println(user.name)
    println(user.age)
}

추상클래스, 인터페이스의 구현체를 익명 클래스의 객체로 구현하고자 하는 경우

interface MyInterface{
    val name:String
    val age: Int
    fun greeting()
}

val myListener= object: MyInterface{
    override val name = "Bumjae"
    override val age = 28
   	override fun greeting(){
       	println("my name is ${name}")
       	println("and I'm ${age} years old!")
   	}
}

fun main() {
    myListener.greeting()
}

Java의 static

Java에는 static 키워드를 통해 클래스의 인스턴스를 생성하지 않고도 변수, 메서드를 사용할 수 있다.
이러한 static 키워드를 통해 선언된 변수, 메서드를 각각 클래스 변수, 클래스 메서드라한다.

public final class User {
  static public final String TAG = "user_tag";  // 클래스 변수
  static public plusOne(int num):int {
  		return num + 1
  }
}

// 클래스의 인스턴스를 생성하지 않고 호출 가능
// User.TAG
// User.plusOne(10)

그러나 Kotlin의 경우에는 static 키워드가 존재하지 않는다.
대신 Java의 static 키워드와 매우 유사하게 사용 할 수 있는 companion object (동반 객체)가 존재한다.

Companion Object

companion object (동반 객체)는 이름 그대로 클래스 내부에 존재하며, 클래스가 메모리에 적재될 때 함께 생성된다.

동반 객체라는 이름답게, 클래스당 하나의 companion object만을 둘 수 있다.
object와 같이 클래스, 인터페이스를 상속 받을 수 있다.
Outer class는 companion object에 접근 가능하나, companion object 내에서는 Outer class에 접근할 수 없다.
별도 클래스의 인스턴스를 생성하지 않고 클래스명으로 접근하여 자바의 static 변수, 메소드처럼 사용할 수 있다.
클래스명.Companion으로 접근하며, 변수에 할당 가능

class User {
    companion object {
        val TAG = "user_tag"

        fun printName(name: String) {
            println("$TAG user name : $name")
        }
    }
}

fun main(){
    println(User.TAG)
    User.printName("bumajae")

    val userObject = User.Companion
    println(userObject.TAG)
}

Java의 static과 동일한가?

위에 강조한 부분으로 클래스명.Companion 으로 접근 할 수 있으며, 변수에 할당이 가능하다는 점인데 이 말은 companion object는 static과 달리 객체로써 생성된다는 것이다.

위 코드를 Java로 Decompile 해보면 User class 내부에 Companion이라는 클래스가 있으며, 해당 Companion 객체를 생성한다.
Companion 클래스만 static으로 되어 있으며, Companion 클래스 내부의 변수, 메서드는 static 형태로 존재하지 않는다.

public final class User {
   @NotNull
   private static final String TAG = "user_tag";
   @NotNull
   public static final Companion Companion = new Companion((DefaultConstructorMarker)null);

   public static final class Companion {
      @NotNull
      public final String getTAG() {
         return User.TAG;
      }

      public final void printName(@NotNull String name) {
         Intrinsics.checkNotNullParameter(name, "name");
         String var2 = ((Companion)this).getTAG() + " user name : " + name;
         System.out.println(var2);
      }

      private Companion() {
      }

      // $FF: synthetic method
      public Companion(DefaultConstructorMarker $constructor_marker) {
         this();
      }
   }
}

만약 static이 되게 하고 싶으면 companion object 내 변수, 메서드에 각각 @JvmField, @JvmStatic 어노테이션을 붙이면 static 키워드가 붙으므로 Java의 static 변수, 메서드와 같이 사용 할 수 있다.

Object vs Companion Object

Object declaration	companion object
Class 전체가 하나의 Singleton 으로 선언	Class 내 일부분이 Singleton으로 선언
해당 Class가 사용될 때 초기화	해당 Class가 로드 될 때 초기화

Reference
https://parade621.tistory.com/37
https://medium.com/@lunay0ung/kotlin-object-declaration-그리고-companion-object-feat-static-d5c97c21168
https://www.androidhuman.com/2016-07-10-kotlin_companion_object

Retrofit 과 Coroutine 사용시 enequeue 내부적 구현

bumjae — Tue, 2 Jan 2024 01:25:35 +0900

viewModelScope.launch{
    RetrofitService.naverService.getSearchNews(query = keyword, sort = "sim").run{
    	if (isSuccessful){
        	...
        } else {
        	...
        }
    }
}

Retrofit을 사용할 때 Coroutine과 사용하게 되면 enqueue()의 비동기 코드를 실행하는 코드가 없어도 스스로 값을 가져오게 된다.

그래서 바로 Response<>를 사용해 요청 이후의 응답을 바로 받아 사용을 한다.

이 동작에 대해 이해하려 한다.

enequeue의 내부적 구현

Retrofit 사용 API Interface 구현체 내부적 구현

사용 개발자는 Interface에 추상적인 api 함수들을 Retrofit Annotaion과 함께 정의한다. interface NaverApi { @GET(RetrofitService.NEWS_END_POINT) suspend fun getSearchNews( @Header("X-Naver-Client-Id") clientId : String = BuildConfig.NAVE

bumjae.tistory.com

이전 글에서 Interface의 내부적 구현에서 HttpServiceMethod.parseAnnotations()에서 아래 isKotlinSuspendFunction 변수를 사용해 SuspendForResponse와 SuspendForBody를 생성해 return 해준다고 하였다.

boolean isKotlinSuspendFunction = requestFactory.isKotlinSuspendFunction;

if (!isKotlinSuspendFunction) {
      return new CallAdapted<>(requestFactory, callFactory, responseConverter, callAdapter);
    } else if (continuationWantsResponse) {
      //noinspection unchecked Kotlin compiler guarantees ReturnT to be Object.
      return (HttpServiceMethod<ResponseT, ReturnT>)
          new SuspendForResponse<>(
              requestFactory,
              callFactory,
              responseConverter,
              (CallAdapter<ResponseT, Call<ResponseT>>) callAdapter);
    } else {
      //noinspection unchecked Kotlin compiler guarantees ReturnT to be Object.
      return (HttpServiceMethod<ResponseT, ReturnT>)
          new SuspendForBody<>(
              requestFactory,
              callFactory,
              responseConverter,
              (CallAdapter<ResponseT, Call<ResponseT>>) callAdapter,
              continuationBodyNullable);
    }

loadServiceMethod

그리고 이 모든 정보들을 가지고 loadServiceMethod로 돌아가 result에 SuspendForResponse를 저장하고, method 정보와 함께 serviceMethodCache에 저장한다.

ServiceMethod<?> loadServiceMethod(Method method) {
    ServiceMethod<?> result = serviceMethodCache.get(method);
    if (result != null) return result;

    synchronized (serviceMethodCache) {
      result = serviceMethodCache.get(method);
      if (result == null) {
        result = ServiceMethod.parseAnnotations(this, method);
        serviceMethodCache.put(method, result);
      }
    }
    return result;
  }

serviceMethodCache에는 메서드 정보, 그리고 실행에 대한 함수에 대한 정보(SuspendForResponse, callAdapter, callFactory, requestFactory, responseConverter)를 가지고 있다.

InvocationHandler

이렇게 가진 정보로 create의 return 값의 Proxy 생성으로 돌아가서 invoke를 수행한다.

new InvocationHandler() {
  private final Platform platform = Platform.get();
  private final Object[] emptyArgs = new Object[0];

  @Override
  public @Nullable Object invoke(Object proxy, Method method, @Nullable Object[] args)
      throws Throwable {
    // If the method is a method from Object then defer to normal invocation.
    if (method.getDeclaringClass() == Object.class) {
      return method.invoke(this, args);
    }
    args = args != null ? args : emptyArgs;
    return platform.isDefaultMethod(method)
        ? platform.invokeDefaultMethod(method, service, proxy, args)
        : loadServiceMethod(method).invoke(args);
  }
});

loadServiceMethod() 메서드의 결과로 SuspendForResponse객체를 가지고, invoke를 수행하게 된다.

이 SuspendForResponse 클래스는 HttpServiceMethod안에 있고,
이때의 invoke는 HttpServiceMethod.java 안의 SuspendForResponse클래스 내부의 invoke() 메서드가 수행된다.

HttpServiceMethod.invoke

이때 adapt(call, args)에서 call은 이전에 requestFactory에서 수행했던 Annotaion 파싱, 메서드 정보, callFactory, responseConverter 등의 정보들을 가지고 수행하게 된다.

// HttpServiceMethod

@Override
  final @Nullable ReturnT invoke(Object[] args) {
    Call<ResponseT> call = new OkHttpCall<>(requestFactory, args, callFactory, responseConverter);
    return adapt(call, args);
  }

SuspendForResponse.adapt

위의 adapt(call, args)를 통해 위의 adapt가 실행되는데, callAdapter의 adapt(call)을 실행한다.

여기 생성된 call 객체 안에 requestFactory 안에 "GET"이라는 정보, BASE_URL 등 중요 정보가 있다.

// HttpServiceMethod.java 내부의 class SuspendForBody 안의 adapt

protected Object adapt(Call<ResponseT> call, Object[] args) {
      call = callAdapter.adapt(call);

      //noinspection unchecked Checked by reflection inside RequestFactory.
      Continuation<Response<ResponseT>> continuation =
          (Continuation<Response<ResponseT>>) args[args.length - 1];

      // See SuspendForBody for explanation about this try/catch.
      try {
        return KotlinExtensions.awaitResponse(call, continuation);
      } catch (Exception e) {
        return KotlinExtensions.suspendAndThrow(e, continuation);
      }
    }

그리고 위의 awaitResponse()의 인자인 continuation에 Coroutine을 실행할 코드가 있다.

Retrofit Call.awaitResponse

이 부분에서 enqueue()를 이미 진행해주고 있기 때문에 "실행"코드 없이 결과 값을 받을 수 있다.

// KotlinExtensions.kt

suspend fun <T> Call<T>.awaitResponse(): Response<T> {
  return suspendCancellableCoroutine { continuation ->
    continuation.invokeOnCancellation {
      cancel()
    }
    enqueue(object : Callback<T> {
      override fun onResponse(call: Call<T>, response: Response<T>) {
        continuation.resume(response)
      }

      override fun onFailure(call: Call<T>, t: Throwable) {
        continuation.resumeWithException(t)
      }
    })
  }
}

resumeWithException() 메서드를 통해 내부적으로 resumeWith() 메서드를 실행하고, 결과값을 받고 Result 클래스를 이용해 값을 전달

@SinceKotlin("1.3")
@InlineOnly
public inline fun <T> Continuation<T>.resume(value: T): Unit =
    resumeWith(Result.success(value))

@SinceKotlin("1.3")
@InlineOnly
public inline fun <T> Continuation<T>.resumeWithException(exception: Throwable): Unit =
    resumeWith(Result.failure(exception))

Coroutine Dispatchers를 지정하지 않는 이유

아래 코드처럼 Dispachers를 신경 쓰고 지정해 주는 사람도 있다.

하지만 이는 불필요한 작업이다.

Retrofit Call의 메서드로 자체적 비동기 호출을 하고, 결과에 따라 콜백을 처리해 준다.

즉, Dispatchers를 지정해 주어도 코루틴의 흐름을 타지 않고, 자바 스레드 풀에서 돌게 된다.

CoroutineScope(Dispatchers.IO).launch{
	RetrofitService.naverService.getSearchNews(query = keyword, sort = "sim").run{
    	if (isSuccessful){
        	...
        } else {
        	...
        }
    }
    
    withContext(Dispatchers.Main){
    	//UI SET
    }
}

Retrofit.enqueue

Retrofit의 enqueue는 OkHttp의 enqueue를 실행

OkHttp의 call 객체를 생성하여, 그 call 객체를 이용해 enqueue를 실행한다.

// Retrofit.enqueue()

@Override
  public void enqueue(final Callback<T> callback) {
    Objects.requireNonNull(callback, "callback == null");

    okhttp3.Call call;
    Throwable failure;

    synchronized (this) {
      if (executed) throw new IllegalStateException("Already executed.");
      executed = true;

      call = rawCall;
      failure = creationFailure;
      if (call == null && failure == null) {
        try {
          call = rawCall = createRawCall();
        } catch (Throwable t) {
          throwIfFatal(t);
          failure = creationFailure = t;
        }
      }
    }

    if (failure != null) {
      callback.onFailure(this, failure);
      return;
    }

    if (canceled) {
      call.cancel();
    }

    call.enqueue(
        new okhttp3.Callback() {
          @Override
          public void onResponse(okhttp3.Call call, okhttp3.Response rawResponse) {
            Response<T> response;
            try {
              response = parseResponse(rawResponse);
            } catch (Throwable e) {
              throwIfFatal(e);
              callFailure(e);
              return;
            }

            try {
              callback.onResponse(OkHttpCall.this, response);
            } catch (Throwable t) {
              throwIfFatal(t);
              t.printStackTrace(); // TODO this is not great
            }
          }

          @Override
          public void onFailure(okhttp3.Call call, IOException e) {
            callFailure(e);
          }

          private void callFailure(Throwable e) {
            try {
              callback.onFailure(OkHttpCall.this, e);
            } catch (Throwable t) {
              throwIfFatal(t);
              t.printStackTrace(); // TODO this is not great
            }
          }
        });
  }

OkHttp.enqueue

client.dispatcher().enqueue()를 실행

void enqueue(Callback responseCallback, boolean forWebSocket) {
  synchronized (this) {
    if (executed) throw new IllegalStateException("Already Executed");
    executed = true;
  }
  client.getDispatcher().enqueue(new AsyncCall(responseCallback, forWebSocket));
}

OkHttp.Dispatcher.enqueue

synchronized 블록을 통해 AsyncCall을 처리

void enqueue(AsyncCall call) {
    synchronized (this) {
      readyAsyncCalls.add(call);

      // Mutate the AsyncCall so that it shares the AtomicInteger of an existing running call to
      // the same host.
      if (!call.get().forWebSocket) {
        AsyncCall existingCall = findExistingCallWithHost(call.host());
        if (existingCall != null) call.reuseCallsPerHostFrom(existingCall);
      }
    }
    promoteAndExecute();
  }

AsyncCall

AsyncCall은 Runnable을 상속받아 비동기 실행을 돕는다.

final class AsyncCall extends NamedRunnable {
  private final Callback responseCallback;
  private final boolean forWebSocket;
  private AsyncCall(Callback responseCallback, boolean forWebSocket) {
    super("OkHttp %s", originalRequest.urlString());
    this.responseCallback = responseCallback;
    this.forWebSocket = forWebSocket;
  }

AsyncCall 클래스 내부에 promoteAndExecute 메서드는 readyAsyncCall을 runningAsyncCall로 승격시켜 주고 executeOn메서드를 통해 실행시켜 준다.

executeOn() 메서드에서는 executorService를 통해 인자로 runnable로 받아 스레드를 이용해 실행시켜 준다.
Executor 구현체는 전달받은 작업을 큐에 넣은 후, 사용할 수 있는 스레드가 존재하면, 해당 스레드에 작업을 실행한다.

그래서 Dispatchers를 바꿔주며 Coroutine을 사용해도 사실은 아무런 영향을 미치지 못한다고 한다.

안드로이드에서는 Lifecycle에 따라 코루틴을 자동으로 취소해 주는 lifecycleScope를 이용하거나 viewModelScope를 이용하면 된다.

Interface
https://rlaudals2374.medium.com/retrofit의-구현체는-어디에-있을까-e04b7952c408
https://seokzoo.tistory.com/4?source=post_page-----964f4b5d0a5d--------------------------------

Retrofit Dispatchers
https://dalinaum.github.io/android/2021/01/28/retrofit-does-not-need-dispachers-io.html

Retrofit 사용 API Interface 구현체 내부적 구현

bumjae — Fri, 22 Dec 2023 20:38:08 +0900

사용

개발자는 Interface에 추상적인 api 함수들을 Retrofit Annotaion과 함께 정의한다.

interface NaverApi {
    @GET(RetrofitService.NEWS_END_POINT)
    suspend fun getSearchNews(
        @Header("X-Naver-Client-Id") clientId : String = BuildConfig.NAVER_CLIENT_ID,
        @Header("X-Naver-Client-Secret") clientPw : String = BuildConfig.NAVER_CLIENT_SECRET,
        @Query("query") query : String,
        @Query("sort") sort : String,
    ): Call<NewsResponse>
}

Retrofit Builder에 Url, Client, Convert 등 등을 설정해준다.

private val retrofit = Retrofit.Builder()
    .baseUrl(BASE_URL)
    .client(provideHttpClient())
    .addConverterFactory(createGsonConverterFactory())
    .build()
    
val naverService = retrofit.create(NaverApi::class.java)

그리고 create 함수로 정의한 API Interface를 넘긴다.

개발자는 API Service의 구현체를 직접 만들지 않는다.

Interface를 정의하기만 하고 사용할 때에는 Retrofit.create을 이용해서 Api Service의 구현체를 받아온다.

이 받아오는 구현체의 내부 동작을 이해하려 한다.

Retrofit.create 함수의 매개변수를 보면 Class<T!> 라는 Java Class를 받는다.
여기에 리플렉션을 이용해 Interface::class.java로 java클래스로 바꾸어준다.

리플렉션(::)은 런타임의 클래스를 참조하는 기술

KClass 참조하여 java Class로 변환해주는 확장 프로퍼티를 사용해 자바 클래스로 넘겨준다.

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.jvm/java.html

Retrofit.create

create 함수의 내부, API endpoints를 정의한 service interface의 구현체를 만들어준다

public <T> T create(final Class<T> service) { // 넘겨준 NaverApi Interface의 java Class
  validateServiceInterface(service);
  return (T) // T (NaverApi)로 타입 변환 후 Proxy 반환
      Proxy.newProxyInstance( // Proxy 인스턴스 생성
          service.getClassLoader(), // NaverApi Class가 로드된 클래스로더 넘겨주기
          new Class<?>[] {service}, // NaverApi Class 넘겨주기
          new InvocationHandler() { // InvocationHandler 정의하여 넘겨주기
            ...
          });
}

validateServiceInterface(service)

전달 받은 인자가 Interface인지 확인하고, 아닐 시 IllegalArgumentException을 발생

private void validateServiceInterface(Class<?> service) {
  if (!service.isInterface()) {
    throw new IllegalArgumentException("API declarations must be interfaces.");
  }
  Deque<Class<?>> check = new ArrayDeque<>(1);
  check.add(service);
  
  ...

코드에 Proxy.newProxyInstance를 사용하는데 일단 Proxy에 대해 알아본다.

Proxy

타겟이 되는 클래스의 기능을 확장하거나, 클래스에 대한 접근을 제어하기 위해 사용하는 클래스이다.

아래와 같은 Hello Interface가 있고, 이것을 구현한 HelloTarget 클래스가 있을때

interface Hello {
    fun sayHello(name: String): String
    fun sayHi(name: String): String
}

class HelloTarget : Hello {
    override fun sayHello(name: String): String {
        return "Hello $name"
    }

    override fun sayHi(name: String): String {
        return "Hi $name"
    }
}

Proxy를 이용하면 Hello Interface의 메서드를 변경하지 않고 부가 기능을 추가 할 수 있다.

HellowUppercase라는 Hello의 구현체를 따로 만들고, HelloTarget의 객체를 선언해준다.

타겟의 기능을 가져와 수행하고 결과를 다시 대문자로 변환한다.

Hello의 메서드를 호출하면 HelloTarget이 위임받아 원래의 기능을 수행하고 uppercase() 메소드를 통해 대문자로 변환하는 기능을 추가한 것이다.

class HelloUpperCase: Hello{
    private val helloTarget = HelloTarget()

    override fun sayHello(name: String): String {
        return helloTarget.sayHello(name).uppercase(Locale.getDefault())
    }

    override fun sayHi(name: String): String {
        return helloTarget.sayHi(name).uppercase(Locale.getDefault())
    }
}

정리하면 Proxy를 사용하면 타겟의 코드 수정 없이 기능을 확장하거나 부가 기능을 추가 할 수 있다.

Dynamin Proxy

하지만 위와 같은 Proxy는 Interface를 직접 구현해야하고, 중복이 발생하는 단점이 있다.

두 함수 중 하나만 수정 하고 싶어도, 모든 메서드를 override해야하고, 중복된 코드가 많아진다.

Dynamic Proxy는 일일이 프록시를 생성하지 않고 런타임 시점에 Interface를 구현하는 클래스 또는 Instance를 만들어주는 것을 뜻한다.

그것을 수행하는게 Proxy의 newProxyInstance() 이다.

Proxy.newProxyInstance

Java의 Refelction API에서 제공해주는 Dynamic Proxy 클래스를 만드는 함수

@CallerSensitive
public static Object newProxyInstance(ClassLoader loader,
                                      Class<?>[] interfaces,
                                      InvocationHandler h)
    throws IllegalArgumentException 
{
    Objects.requireNonNull(h);

    final Class<?>[] intfs = interfaces.clone();	// java class Type의 Interface를 클론
    
    Class<?> cl = getProxyClass0(loader, intfs);	// getProxyClass : Proxy 클래스 return 받음
    
    final Constructor<?> cons = cl.getConstructor(constructorParams);	// cl에 대한 생성자 받아오기
    
    final InvocationHandler ih = h; 전달 받은 InvocationHandler 할당
    
    // reflected 된 객체에 접근 가능하게 설정
    if (!Modifier.isPublic(cl.getModifiers())) {
        cons.setAccessible(true);
    }
    
    // 생성자로 위에 정의한 InvocationHandler를 가진 인스턴스 반환
    return cons.newInstance(new Object[]{h});
}

넘겨준 파라미터 loader, interfaces, InvocationHandler를 받아서 동적으로 인스턴스 생성

ClassLoader loader : Proxy를 만들 클래스 로더
Class<?>[] interfaces : 어떤 Interface의 Proxy를 만들 것인지 명시
InvocationHandler h : InvocationHandler Interface의 구현체
return 값 : 동적으로 만든 Profxy 객체

ClassLoader를 참조, 런타임에 해당하는 Interface의 구현체 (Proxy Instance)를 만든다.

인자 InvocationHandler

invoke()라는 메소드 하나만 가지고 있는 인터페이스

동적으로 생성될 Proxy의 메소드가 호출되면 Invoke를 거치게 되고, 여기서 메소드의 기능을 확장할 수 있다.

platform의 method가 defaultMethod라면 invokeDefaultMethod를 반환, 아니라면 loadServiceMethod.invoke를 반환

new InvocationHandler() {
  private final Platform platform = Platform.get();
  private final Object[] emptyArgs = new Object[0];

  @Override
  public @Nullable Object invoke(Object proxy, Method method, @Nullable Object[] args)
      throws Throwable {
    // If the method is a method from Object then defer to normal invocation.
    if (method.getDeclaringClass() == Object.class) {
      return method.invoke(this, args);
    }
    args = args != null ? args : emptyArgs;
    return platform.isDefaultMethod(method)
        ? platform.invokeDefaultMethod(method, service, proxy, args)
        : loadServiceMethod(method).invoke(args);
  }
});

Platform

단어 그대로 플랫폼을 지칭

Android Platform 레벨에 접근하기 위한 클래스

class Platform {
  private static final Platform PLATFORM = findPlatform();

  static Platform get() {
    return PLATFORM;
  }

  private static Platform findPlatform() {
    return "Dalvik".equals(System.getProperty("java.vm.name"))
        ? new Android() //
        : new Platform(true);
  }

Default Method

자바 8부터 지원한 public non-abstract한 instance 메소드

인터페이스에 정의되어있는 body가 있는 non-static 메소드

@IgnoreJRERequirement // Only called on API 24+.
boolean isDefaultMethod(Method method) {
  return hasJava8Types && method.isDefault();
}

/**
 * Returns {@code true} if this method is a default
 * method; returns {@code false} otherwise.
 *
 * A default method is a public non-abstract instance method, that
 * is, a non-static method with a body, declared in an interface
 * type.
 *
 * @return true if and only if this method is a default
 * method as defined by the Java Language Specification.
 * @since 1.8
 */
public boolean isDefault() {
    // Android-changed: isDefault() implemented using Executable.
    return super.isDefaultMethodInternal();
}

이렇게 해서 위의 platform은 Android가 담기고, 개발자가 선언해준 인터페이스의 함수는 default가 아니기에platform.isDefaultMethod가 false가 나와 아래의 loadServiceMethod가 실행

즉, Dynamic Proxy를 통해 Retrofit을 위해 선언해준 interface에 대해서 동적으로 클래스를 생성해주는 역할을 하는 것이 Dynamic Proxy

Retrofit.loadServiceMethod

serviceMethodCache는 Retrofit 클래스 최상단에 선언되어 있는 Map객체 프로퍼티이다.

Retrofit 객체는 map을 이용해 메소드들을 캐싱 처리하여 loadServiceMethod 호출 시 캐시에 해당 메서드가 있다면 이를 사용하고, 없으면 parseAnnotations로 메소드를 만들어 set해주고 있다.

처음 실행시 비어있기 때문에 null을 반환하여 아래 synchronized 블록을 실행합니다.
그 안에서 값이 저장되지 않은 채로 get을 하기때문에 result는 첫 값으로 null이며, 후에 if문을 실행

즉, 사용할 때 API 첫 번째 호출에는 새 메서드를 생성, 다음 호출부터는 캐싱된 메서드를 가져온다.

public final class Retrofit {
    private final Map<Method, ServiceMethod<?>> serviceMethodCache = new ConcurrentHashMap<>();

    ServiceMethod<?> loadServiceMethod(Method method) {
        ServiceMethod<?> result = serviceMethodCache.get(method);
        if (result != null) return result;

        synchronized (serviceMethodCache) {
            result = serviceMethodCache.get(method);
            if (result == null) {
                result = ServiceMethod.parseAnnotations(this, method);
            serviceMethodCache.put(method, result);
       }
    }
    return result;
}

ServiceMethod.parseAnnotations

requestFactory를 이용해 (PUT, POST, GET 등)어노테이션을 수집하고, 이를 HttpServiceMethod.parseAnnotations에 넘겨준다.

HttpServiceMethod.parseAnnotations에선 최종적으로 메서드의 Response, Return 타입들을 정의한다.

abstract class ServiceMethod<T> {
  static <T> ServiceMethod<T> parseAnnotations(Retrofit retrofit, Method method) {
    RequestFactory requestFactory = RequestFactory.parseAnnotations(retrofit, method);

    Type returnType = method.getGenericReturnType();
    if (Utils.hasUnresolvableType(returnType)) {
      throw methodError(
          method,
          "Method return type must not include a type variable or wildcard: %s",
          returnType);
    }
    if (returnType == void.class) {
      throw methodError(method, "Service methods cannot return void.");
    }

    return HttpServiceMethod.parseAnnotations(retrofit, method, requestFactory);
  }

  abstract @Nullable T invoke(Object[] args);
}

RequestFactory.parseAnnotations

여기서 실제로 지정해준 Annotation들을 파싱한다.

private void parseMethodAnnotation(Annotation annotation) {
  if (annotation instanceof DELETE) {
    parseHttpMethodAndPath("DELETE", ((DELETE) annotation).value(), false);
  } else if (annotation instanceof GET) {
    parseHttpMethodAndPath("GET", ((GET) annotation).value(), false);
  } else if (annotation instanceof HEAD) {
    parseHttpMethodAndPath("HEAD", ((HEAD) annotation).value(), false);
  } else if (annotation instanceof PATCH) {
    parseHttpMethodAndPath("PATCH", ((PATCH) annotation).value(), true);
  } else if (annotation instanceof POST) {
    parseHttpMethodAndPath("POST", ((POST) annotation).value(), true);
  } else if (annotation instanceof PUT) {
    parseHttpMethodAndPath("PUT", ((PUT) annotation).value(), true);
  } else if (annotation instanceof OPTIONS) {
    parseHttpMethodAndPath("OPTIONS", ((OPTIONS) annotation).value(), false);
  } else if (annotation instanceof HTTP) {
    HTTP http = (HTTP) annotation;
    parseHttpMethodAndPath(http.method(), http.path(), http.hasBody());
  } else if (annotation instanceof retrofit2.http.Headers) {
    String[] headersToParse = ((retrofit2.http.Headers) annotation).value();
    if (headersToParse.length == 0) {
      throw methodError(method, "@Headers annotation is empty.");
    }
    headers = parseHeaders(headersToParse);
  } else if (annotation instanceof Multipart) {
    if (isFormEncoded) {
      throw methodError(method, "Only one encoding annotation is allowed.");
    }
    isMultipart = true;
  } else if (annotation instanceof FormUrlEncoded) {
    if (isMultipart) {
      throw methodError(method, "Only one encoding annotation is allowed.");
    }
    isFormEncoded = true;
  }
}

HttpServiceMethod.parseAnnotations

중요한 변수 isKotlinSuspendFunction, 해당 함수가 suspend function 인지 확인하는 변수

이 suspendFunction 관련 변수들과 처리는 다른 글에서 다룰 것이다.

static <ResponseT, ReturnT> HttpServiceMethod<ResponseT, ReturnT> parseAnnotations(
      Retrofit retrofit, Method method, RequestFactory requestFactory) {
    boolean isKotlinSuspendFunction = requestFactory.isKotlinSuspendFunction;
    boolean continuationWantsResponse = false;
    boolean continuationBodyNullable = false;
    ...

함수 코드 아래에 보면 suspend function이 아니라면 CallAdapted를 생성하여 리턴하고, Response 객체를 리턴값으로 가진다면 SuspendForResponse를, Body가 필요하다면 SuspendForBody를 생성하여 리턴한다.

if (!isKotlinSuspendFunction) {
      return new CallAdapted<>(requestFactory, callFactory, responseConverter, callAdapter);
    } else if (continuationWantsResponse) {
      //noinspection unchecked Kotlin compiler guarantees ReturnT to be Object.
      return (HttpServiceMethod<ResponseT, ReturnT>)
          new SuspendForResponse<>(
              requestFactory,
              callFactory,
              responseConverter,
              (CallAdapter<ResponseT, Call<ResponseT>>) callAdapter);
    } else {
      //noinspection unchecked Kotlin compiler guarantees ReturnT to be Object.
      return (HttpServiceMethod<ResponseT, ReturnT>)
          new SuspendForBody<>(
              requestFactory,
              callFactory,
              responseConverter,
              (CallAdapter<ResponseT, Call<ResponseT>>) callAdapter,
              continuationBodyNullable);
    }

이 모든 정보들을 가지고 Retrofit.loadServiceMethod로 돌아가 result에 SuspendForResponse를 저장하고, method 정보와 함께 serviceMethodCache에 저장한다.

즉, serviceMethodCache에는 메소드 정보, 그리고 실행에 대한 함수에 대한 정보(SuspendForResponse, callAdapter, callFactory, requestFactory, responseConverter)를 가지고 있다.

내부 동작 정리

Retrofit.create API 지정
- Proxy.newProxyInstance 로 동적 인스턴스 생성
  - 인자의 InvocationHandler 에서 메소드의 기능을 확장
    - 플랫폼 확인
    - default 메소드가 아니면 Retrofit.loadServiceMethod 호출
Retrofit.loadServiceMethod 호출
- map을 이용해 메소드들을 캐싱 처리 (첫 호출에만 새 메서드 생성)
- 메서드 없을시 ServiceMethod.parseAnnotations 호출
  - ServiceMethod.parseAnnotations
    - RequestFactory.parseAnnotations
      - 실제로 Annotion들을 파싱
    - HttpServiceMethod.parseAnnotations
      - 최종적으로 파싱한 RequestFactory와 메서드로 Response, Return 타입들을 정의

코드에서 Dynamic Proxy 클래스를 생성하고 invocationHandler를 정의하는 모습을 볼 수 있었다.

만약 클래식한 Proxy 패턴이라면 명시적으로 프록시 클래스를 정의해야 한다.

Proxy 패턴을 사용한다면 각각의 API Interface마다 Proxy 클래스를 만들어야 하고, 구현체가 필요하기 때문에 Interface의 함수들을 일일이 정의해준 다음 Proxy 클래스에서 사용해야 한다.

이것은 코드가 길어지며 반복되어 구현과 관리도 힘들어진다.

API Interface에 정의하는 함수들은 웬만해선 모두 API Call을 위한 API Endpoints 함수들이고 각각의 Interface 구현체들을 구현할 필요 없다.

Annotation으로 각 함수들이 할 일을 알려주고 이를 런타임에 Reflection을 통해 얻어와서 비슷한(API 함수들) 함수들을 찍어낸다.

일종의 팩토리를 이용해 모든 API 함수에 대응하는 InvocationHandler의 invoke를 정의하면서, Dynamic Proxy를 만들어내게 된다.

이렇게 하여 개발자는 Interface의 구현체를 만들지 않고 지정만 해주어 사용할 수 있다.

이러한 솔루션이 들어간게 Retrofit.create() 함수이다.

Retrofit Interface
https://rlaudals2374.medium.com/retrofit의-구현체는-어디에-있을까-e04b7952c408
https://ongveloper.tistory.com/674?source=post_page-----964f4b5d0a5d--------------------------------

Proxy
https://live-everyday.tistory.com/216
https://live-everyday.tistory.com/217

Service

bumjae — Thu, 14 Dec 2023 07:38:54 +0900

Service

안드로이드 4대 컴포넌트 중 하나이며 사용자에게 인터페이스를 제공하지 않고 백그라운드에서 오래 실행되는 작업을 수행할 수 있는 애플리케이션 구성요소

다른 애플리케이션 구성 요소가 서비스를 시작할 수 있고, 다른 앱을 전환하더라도 백그라운드에서 계속 실행된다.

또한 앱 구성요소와 서비스를 바인딩하여 서비스와 상호작용 할 수 있고, 프로세스 간 통신(IPC)도 실행할 수 있다.

종류

Background Service

사용자에게 보이지 않는 백그라운드 작업을 수행하며, 시스템 리소스가 부족할 경우 강제 종료될 수 있다.

API 25 이상부터는 앱이 Foreground에 있지 않을 때 백그라운드 서비스를 강제로 종료시킨다.

Foreground Service

만약 서비스가 백그라운드에서 계속 돌게 된다면, 안드로이드 시스템에 의해서 무작위로 종료당할 수 있다.

실시간으로 사용 중인 다른 앱에서 더 많은 자원(메모리)을 필요로 한다면, 오래 도는 서비스는 결코 안전하지 못하다.

Foreground Service는 활성화된 액티비티와 동일한 우선순위를 가지므로 시스템에 메모리가 부족하더라도 강제 종료될 확률이 낮다.

하지만 사용자가 서비스의 동작을 인지할 수 있도록 반드시 알림(Notify)을 제공해야 한다.

시스템은 이로 인해 사용자가 서비스를 사용 중임으로 인지하고 종료하지 않는 것이다.

Bound Service

안드로이드의 구성요소가 서비스에 바인딩하여 상호작용 할 수 있다.

IBinder라는 인터페이스로 Client - Server 관계처럼 서비스와 상호작용하며 여러 프로세스에 걸쳐 프로세스 간 통신(IPC)을 수행할 수도 있다.

여러 개의 구성 요소가 서비스에 한꺼번에 바인딩될 수 있지만, 모든 구성요소에서 바인딩이 해제되면 해당 서비스는 소멸된다.

LifeCycle

onCreate

서비스가 처음 생성되었을 경우 onStartCommand 혹은 onBind가 호출되기 전에 호출된다.

서비스가 이미 실행중일 경우는 이 메소드는 호출되지 않는다.

onStartCommand

startService()로 실행되었을 경우 onCreate 이후 실행된다.

이 함수가 호출되면 백그라운드에서 무한히 실행되므로, 반드시 stopSelf() 혹은 stopService()로 서비스를 종료시켜야 한다. (바인딩만 할 경우 이 함수를 사용하지 않아도 된다.)

onStartCommand는 return 값이 존재하는데 아래와 같다.

START_NOT_STICKY	서비스를 명시적으로 다시 시작할 때 까지 만들지 않는다. 서비스가 불필요하게 여러개 생성되는 것을 막을수 있는 방법이다.
START_STICKY	서비스를 다시 만들지만 마지막 Intent를 onStartCommand의 인자로 다시 전달하지 않는다. 이는 일단 계속 살아있어야되지만 별다른 동작이 필요하지 않은 음악앱같은 서비스에 적절
START_REDELIVER_INTENT	서비스를 다시 생성하고 마지막 Intent를 onStartCommand의 인자로 다시 전달한다. 즉각적인 반응이 필요한 파일 다운로드 서비스 같은 곳에 적합

onBind

안드로이드의 구성요소가 서비스에 바인딩하고자 하는 경우에 호출 / bindService()

이 함수의 구현체는 IBinder를 return 하여 클라이언트가 서비스와 통신을 주고받기 위해 사용할 인터페이스를 제공해야 된다.

항상 이 함수를 구현해야 하며 바인딩을 원하지 않을 시 null을 반환

차이 확인

<application
    ...
    <service android:name=".MyBackgroundService"/>
    <service android:name=".MyForegroundService"/>
    <service android:name=".MyBoundService"/>
</application>

Background

class MyBackgroundService : Service() {

    private var job : Job? = null
    private var count = 0

    override fun onBind(p0: Intent?): IBinder? = null

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {

        job = CoroutineScope(Dispatchers.Default).launch {
            while (isActive){
                Log.e("Service Test", "BackgroundService 실행중")
                Log.e("Service Test", "$count")

                try {
                    delay(2000)
                    count++
                } catch (e: Exception){
                    e.printStackTrace()
                }
            }
        }

        return START_NOT_STICKY
    }

    override fun onDestroy() {
        super.onDestroy()
        job?.cancel()
        Log.e("Service Test", "onDestroy : job cancel")
    }
}

val backgroundService = Intent(this@MainActivity, MyBackgroundService::class.java)
startService(backgroundService)

//stop
stopService(backgroundService)

Foreground

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />

class MyForegroundService : Service() {
    private var job : Job? = null
    private var count = 0

    override fun onBind(p0: Intent?): IBinder? = null

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {

        job = CoroutineScope(Dispatchers.Default).launch {
            while (isActive){
                Log.e("Service Test", "ForegroundService 실행중")
                Log.e("Service Test", "$count")

                try {
                    delay(2000)
                    count++
                } catch (e: Exception){
                    e.printStackTrace()
                }
            }
        }
        initNotification()
        return START_NOT_STICKY
    }

    override fun onDestroy() {
        super.onDestroy()
        job?.cancel()
        Log.e("Service Test", "onDestroy : job cancel")
    }

    private fun initNotification(){
        val channel = NotificationChannel(
            "channel-one",
            "Channel-One",
            NotificationManager.IMPORTANCE_LOW)
            .apply {
                setShowBadge(false)
            }

        getSystemService(NotificationManager::class.java).createNotificationChannel(channel)

        val builder = Notification.Builder(this@MyForegroundService, "channel-one")
            .setContentTitle("ForegroundService")
            .setContentText("서비스 실행중")
            .setSmallIcon(R.drawable.ic_launcher_foreground)
            .setOngoing(true)

        startForeground(1, builder.build())
    }
}

val foregroundService = Intent(this@MainActivity, MyForegroundService::class.java)
startService(foregroundService)

//stop
stopService(foregroundService)

Bound

class MyBoundService : Service(){

    private val mBinder = MyBinder()

    private var count = 0
    private var job = CoroutineScope(Dispatchers.Default).launch {
        while (isActive){
            Log.e("Service Test", "BoundService 실행중")
            Log.e("Service Test", "$count")

            try {
                delay(2000)
                count++
            } catch (e: Exception){
                e.printStackTrace()
            }
        }
    }

    inner class MyBinder : Binder() {
        fun getService() : MyBoundService {
            return this@MyBoundService
        }
    }

    override fun onBind(p0: Intent?): IBinder = mBinder

    override fun onCreate() {
        job.start()
    }
    
    //연결한 안드로이드 컴포넌트에서 사용할 함수
    fun getCount() = count

    override fun onDestroy() {
        super.onDestroy()
        job.cancel()
        Log.e("Service Test", "onDestroy : job cancel")
    }
}

private lateinit var mBoundService : MyBoundService
var isService = false

private val connection = object : ServiceConnection {
    override fun onServiceConnected(name: ComponentName?, service: IBinder?) {
        val binder = service as MyBoundService.MyBinder
        mBoundService = binder.getService()
        isService = true
        Log.e("BoundService Test", "Connected")
    }
    
    override fun onServiceDisconnected(name: ComponentName?) {
        isService = false
    }
}

Activity, Fragment 등등 안드로이드 요소와 서비스를 연결할 Connection 지정

bindService() 메서드를 통해 시스템에 전달하면 서비스와 연결할 수 있음

onServiceConnected : 서비스가 연결되면 호출

onServiceDisconnected : 정상적 연결 해제되었을 때는 호출되지 않고, 비정상적으로 서비스가 종료되었을 때만 호출

변수 isService : onServiceDisconnected 구조 때문에 서비스 연결 상태를 확인하는 로직이 필요해 선언

bindService(intent, connection, Context.BIND_AUTO_CREATE)
//BIND_AUTO_CREATE : 서비스가 생성되어 있지 않으면 생성 후 바인딩을 하고 생성되어 있으면 바로 바인딩


//Unbind
if (isService){
    unbindService(connection)
    isService = false
}

MyBoundService에 만든 함수 사용

if (isService){
    Toast.makeText(this@MainActivity, "BoundService Count: ${mBoundService.getCount()}", Toast.LENGTH_SHORT).show()
} else {
    Toast.makeText(this@MainActivity, "BoundService가 연결되지 않았습니다.", Toast.LENGTH_SHORT).show()
}

Service
https://velog.io/@kingdo/Android-Service란
https://parade621.tistory.com/52
https://seosh817.tistory.com/115

알림 없이 Foreground 이용 참고
https://stickode.tistory.com/749

ActivityManager getRunningServices Deprecated
https://copyprogramming.com/howto/java-kotlin-check-if-service-is-running

AlarmManager

bumjae — Tue, 12 Dec 2023 23:33:26 +0900

Backgorund 작업 구분

Background 작업으로 AlarmManager나 WorkManager, Coroutine을 사용할 수 있는데 공식 문서를 보면 사용 구분에 따라 어떠한 기술을 사용해야 할지 가이드라인을 제공하고 있다.

즉시 (Immediate)

사용자와 상호작용 요구

앱의 Scope 내부에서만 유요한: Coroutine, RxJava
앱 외부 Scope에서도 유요한: WorkManager
미디어나 스마트키 위젯에 유요한: Foreground Service

정시 (Exact)

사용자와 상호작용 요구하지 않음

정확한 시간에 작동해야함

AlarmManager

지연 (Deferred)

사용자와 상호작용 요구하지 않음

정확한 시간에 작동하지 않아도 됨

WorkManager

정확한 시간에 동작하며 사용자와 상호작용 않는 작업은 AlarmManager 사용을 고려

AlarmManager

시스템 알람 서비스에 대한 접근과 알람을 통해 미래 특정 시점에 앱이 실행되도록 예약할 수 있게 만들어주는 클래스
알람이 울리면 등록된 Intent가 시스템에 의해 BroadCast 되고 앱이 시작된다.

단, 등록된 알람은 디바이스를 종료하고 재부팅하면 지워진다고 명시되어 있다.
(재부팅 시 지워지는 부분은 Manifest에 Boot receiver를 등록해 주어 해결)

이렇게 실행된 앱은 등록된 알람의 Receiver 메소드에서 CPU Wake Lock을 유지하고 지정해 둔 작업이 처리되기 전까지 Device를 켜둔다.

이렇듯 알람매니저는 해당 앱이 현재 실행되지 않더라도 특정 시간에 특정 작업(Notification, Sound 등등)을 실행하기 위해 사용한다.

특징

지정된 시간 혹은 간격으로 Intent를 실행
Broadcast Receivcer와 조합해서 서비스를 시작하고 다른 작업을 시작 가능
앱이 실행 중이 아니거나 기기가 대기 상태인 경우에도 이벤트나 작업을 트리거
Timer 혹은 지속적으로 실행하는 백그라운드 서비스를 사용하지 않고 작업을 예약
앱의 리소스 요구사항을 최소화하는데 도움
앱이 실행되고 있는 경우에는 AlarmManager보다는 Timer나 Thread & Handler 클래스 사용하는 것이 시스템 리소스를 더 효과적으로 제어할 수 있음
반복된 알람에 좋은 선택일 수 있지만 대상이 네트워크 작업이라면 배터리 소모가 커지고 서버에도 부담을 줄 수 있음

val alarmManager = getSystemService(Context.ALARM_SERVICE) as AlarmManager

알람 유형

ELAPSED_REALTIME	시스템 부팅 시간 이후 (SystemClock.elapsedRealtime) 기준
ELAPSED_REALTIME_WAKEUP	+ 기기 절전 모드 해제
RTC	UTC 시계 시간 (System.currentTimeMillis)를 기준
RTC_WAKEUP	+ 디바이스가 꺼져있을 때 깨움

단일 알람 함수

set

API 19 이후, 정확하지 않게(inexact) 동작
연기되고 시간이 지난 이후에 전달. OS에서 전체 시스템 알람을 "batch"하는 정책을 사용
- 디바이스가 Wake up 하는 것을 최소화하고 배터리 사용량을 최적화
- 실제 알람의 순서도 불일치
- 정확한 순서가 필요할 시, setWindow, setExact

setExact

OS가 전달 시간 최적화하지 않음
요청된 시간에서 가능한 한 가까운 시간 내에 전달

setAndAllowWhileIdle

Doze 모드일 때도 실행되는 set → batch 정책 사용
실제 Doze 모드일 때 실행 되어야 하는 알람의 경우에만 다뤄야 한다.
- ex) 일정이 되었다는 알림이 오는 캘린더
Doze 모드일 때 동작해야 하므로, 과도한 사용을 막았다.
- 특정 앱의 빈도수 제한이 있음 (재사용 시 시간제한?)

setExactAndAllowWhileIdle

setExact + setAndAllowWhileIdle

Version별 사용

when {
    Build.VERSION.SDK_INT >= Build.VERSION_CODES.M -> 
        alarmManager.setExactAndAllowWhileIdle(
            AlarmManager.RTC_WAKEUP, AlarmManager.INTERVAL_FIFTEEN_MINUTES, pendingIntent
        )
    Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT -> 
        alarmManager.setExact(
            AlarmManager.RTC_WAKEUP, AlarmManager.INTERVAL_HOUR, pendingIntent
        )
    else ->
        alarmManager.set(
            AlarmManager.RTC_WAKEUP, AlarmManager.INTERVAL_DAY, pendingIntent
        )
}

Doze 모드에서도 동작하려면 setAndAllowWhileIdle, setExactAndAllowWhileIdle를 사용

정확한 알람을 구현하려 할 때 Doze 모드에서도 발생할 수 있는 setExactAndAllowWhileIdle을 사용하는데 이상한 점이 있다. 문서에서도 정확한 알람과 Doze 모드에서도 발생하게 하려면 이 메서드를 사용하라 나왔는데 확인을 해보면 몇 분씩 늦어 정확한 시간에 수행하지 않을 때가 있다.

setExactAndAllowWhileIdle은 오해의 소지가 있다고 한다.

Android 문서에 따르면 이 메서드는 "정확히 명시된 시간에 전달되도록"이라 하고 나중에는 "요청된 트리거 시간에 최대한 가깝게"라고 설명하고 있다.

제한됨: 잠자기/대기 문서에 따르면 이 유형의 알람은 동일한 앱에서 9분당 두 번 이상 실행할 수 없다.
순서 미보장: OS는 동일한 앱에서도 다른 알람의 순서에 맞지 않게 이러한 종류의 알람이 트리거 되도록 일정을 변경할 수 있다.
유연성: Android는 이 방법을 사용하여 일반 알람보다 알람을 예약할 때 OS가 더 유연하도록 선택했다고 생각한다. 또한 "장치가 유휴 상태일 때 배터리 수명을 최적화하기 위해 일정을 더 자유롭게 지정할 수 있다."라고 명시되어 있다.

결국 OS 멋대로 실행해 주는 것이다.

알람 앱처럼 완벽하게 엄격한 알람이 필요한 경우는 setAlarmClock을 사용할 것

setAlarmClock

AlarmClockInfo로 표현되는 시간에 알람을 예약
알람이 실행될 때, 디바이스를 깨우고, 사용자에게 알림을 주는 용도로 사용
화면 키기, 소리를 재생, 진동 등등

val calendar = Calendar.getInstance().apply {
    timeInMillis = System.currentTimeMillis()
    add(Calendar.HOUR_OF_DAY, hour)
    add(Calendar.MINUTE, minute)
    add(Calendar.SECOND, second)
}
val alarmClock = AlarmManager.AlarmClockInfo(calendar.timeInMillis, pendingIntent)
alarmManager.setAlarmClock(alarmClock, pendingIntent)

AlarmClockInfo에 들어가는 PendingIntent는 setAlarmClock을 이용해 알람을 지정하고

Notification으로 설정된 알람을 보여줄 때 알림 창에서 Notification을 탭 하면 실행되는 PendingIntent라고 한다.

https://stackoverflow.com/questions/34699662/how-does-alarmmanager-alarmclockinfos-pendingintent-work

반복 알람 함수

setIneactRepeating

반복 실행 알람 예약
시스템에서 batch

setRepeating

반복 실행 알람 예약
알람 지연 시 가능한 한 빨리 스킵된 알람이 전달됨
- 전달이 늦어져도 스케쥴은 정상 작동
한 시간마다 repeating, 7:45부터 8:45까지 폰이 자고 있다면 (8시 발생 알람 스킵)
8시 45분에 폰을 킬 때, 8시 발생 알람이 울리고 다음 알람은 9시에 잡힌다. (9시 45분이 아님)
⇒ 실제 발생 시간 기준 몇 시간 후 반복되는 알람을 하고 싶다면 일회성 알람을 사용해 자체 스케줄 할 것
API 19 이후, 정확하지 않게 동작. 연기되고 시간이 지난 이후에 전달됨

알람 취소

cancel

Intent.filterEquals에 해당하는 알람이 취소

Pending Intent 생성 시 등록한 RequestCode가 같아야 한다
Extras를 제외 Action, Categories, Data, Mimetype, Package, Component가 같아야 한다

Doze 모드

Android 6.0(API 레벨 23)부터 추가된 기능으로 기기를 오랫동안 사용하지 않는 경우 앱의 백그라운드 CPU 및 네트워크 활동을 지연시켜 배터리 소모를 줄여주는 모드

사용자가 전원을 충전하지 않고 화면이 꺼진 채로 기기를 일정 기간 정지 상태로 두면 기기는 Doze 모드를 시작

기기를 움직이거나 화면 켜기, 충전기 연결 등을 하여 기기 절전 모드를 해제 시 시스템은 Doze 모드를 종료하고 모든 앱은 정상적인 활동으로 돌아간다.

알람 제약 사항

잠자기 및 앱 대기 모드에 맞게 최적화 | App quality | Android Developers

앱에서 Android 6.0의 절전 기능을 테스트하고 최적화합니다.

developer.android.com

전체코드

https://github.com/wo9374/StudyProject/tree/main/AlarmManager

AlarmManager
https://yellowc-137.tistory.com/23
https://greedy0110.tistory.com/69
https://velog.io/@thevlakk/Android-AlarmManager-파헤치기-1
https://velog.io/@thevlakk/Android-AlarmManager-등록-여부-확인-및-주의점-2-Feat.삽질
https://velog.io/@thevlakk/Android-그간-있었던-AlarmManager-이슈들3

AlarmClockInfo PendingIntent
https://stackoverflow.com/questions/34699662/how-does-alarmmanager-alarmclockinfos-pendingintent-work

Doze 모드
https://kimch3617.tistory.com/entry/Doze-모드란-Doze-모드-최적화

PendingIntent Flag
https://developer88.tistory.com/187

Notification

bumjae — Sat, 9 Dec 2023 00:24:51 +0900

사용자에게 미리 알림을 주고 다른 사람과의 소통을 가능하게 하며
앱에서 보내는 기타 정보를 적시에 제공하기 위해 Android가 앱의 UI 외부에 표시하는 메시지

Notification의 구성

전체적으로는 Notification 객체에 각종 정보를 담고 이 객체를 NotificationManager로 시스템에 등록하는 구조

SDK 33 이상부터는 Notification에 대한 권한 지정과 요청이 필요하다. (33 이상에서만 해당 권한 추가 가능)

<manifest ...>
    <uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>
    
    ...
</manifest>

Manager

NotificationManager : 알림을 시스템에 발생시키는 SystemService

getSystemService() 함수를 이용하여 NotificationManager를 얻어서 사용하거나 NotificationManagerCompat을 이용해 바로 이용해도 좋다

// NotificationManager 객체 생성
val manager = getSystemService(NOTIFICATION_SERVICE) as NotificationManager

// NotificationManagerCompat을 이용해 바로 이용해도 좋다
NotificationManagerCompat.from(context)

Builder

알림을 다양한 정보로 생성

NotificationCompat.Builder를 생성한 후 Builder에 각종 setter 함수를 사용하여 알림의 구성 정보를 명시한 후 Notification을 만들고 NotificationManager로 알림을 발생

if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    // Notification Channel 아이디, 이름, 설명, 중요도 설정
    val channelId = "channel_one"

    // 채널 생성 코드...

    // API 26 이상에서는 Builder 생성자에 NotificationChannel의 아이디값을 설정
    notificationBuilder = NotificationCompat.Builder(this, channelId)
} else {
    // 26 미만은 생성자에 context만 설정
    notificationBuilder = NotificationCompat.Builder(this)
}

notificationBuilder.apply {
    setSmallIcon(android.R.drawable.ic_notification_overlay)  // 작은 아이콘 설정
    setWhen(System.currentTimeMillis()) // 시간 설정
    setContentTitle("Content Title")    // 알림 메시지 설정
    setContentText("Content Message")   // 알림 내용 설정
    setDefaults(Notification.DEFAULT_VIBRATE)  // 알림과 동시에 진동 설정(권한 필요)
    setAutoCancel(true)  // 클릭 시 알림이 삭제되도록 설정
    setOngoing(true)     // 알림 제거 막기 (전체 지우기 등)
    
    // 알림 중요도 26버전 미만을 고려할 때 지정
    //setPriority(NotificationCompat.PRIORITY_DEFAULT) 
}

Channel

NotificationChannel : SDK 26 (Android 8)부터 추가된 알림의 관리 단위

앱의 환경설정에서 Notification의 ON/OFF를 설정할 수 있는데, 이때 사용되는 개념이 바로 '채널'이다.

NotificationChannel(id: String!, name: CharSequence!, importance: Int)

생성자로 Channel의 id, name, importance를 설정

Channel에 대해 설명, 소리, 진동, 불빛 등의 옵션을 설정
Manager의 createNotificationChannel 함수를 사용하여 시스템에 NotificationChannel을 설정

if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    // Notification Channel 아이디, 이름, 설명, 중요도 설정
    val channelId = "channel_one"
    val channelName = "첫 번째 채널"
    val channelDescription = "첫 번째 채널 설명"
    val importance = NotificationManager.IMPORTANCE_DEFAULT

    // NotificationChannel 객체 생성
    val channel = NotificationChannel(channelId, channelName, importance).apply{
        // 설명 설정
        description = channelDescription
        
        // 채널에 대한 각종 설정(불빛, 진동, 소리 등)
        enableLights(true)
        lightColor = Color.RED
        enableVibration(true)
        vibrationPattern = longArrayOf(100L, 200L, 300L)
        
        val uri = RingtoneManager.getDefaultUri(RingtoneManager.TYPE_NOTIFICATION)
        val audio = AudioAttributes.Builder()
                        .setContentType(AudioAttributes.CONTENT_TYPE_SONIFICATION)
                        .setUsage(AudioAttributes.USAGE_ALARM)
                        .build()
        setSound(uri, audio)
    }
    
    // 시스템에 channel 등록
    manager.createNotificationChannel(channel)
    
    or
    
    NotificationManagerCompat.from(this).createNotificationChannel(channel)
}

Importance (중요도)

Notification의 중요도에 따라 알림의 형태가 달라진다.

SDK 26 (Android 8.0) 이상은 Notification Channel에 중요도 importance를 설정하고

SDK 25 (Android 7.1) 이하는 Notification (Builder)에 중요도 priority 설정

버전 지원에 따라 importance 값과 priority 값 모두 가지게 될수 있는데 결과는 importance를 따라간다.

중요도	SDK 26 이상 Channel Importance	SDK 25 이하 Notification Priority
긴급 알림음이 울리며 헤드업으로 표시	IMPORTANCE_HIGH	PRIORITY_HIGH PRIORITY_MAX
높은 알림음이 울림	IMPORTANCE_DEFAULT	PRIORITY_DEFAULT
중간 알림음이 울리지 않음	IMPORTANCE_LOW	PRIORITY_LOW
낮음 알림음이 없고 상태표시줄에 표시되지 않음	IMPORTANCE_MIN	PRIORITY_MIN

사용 및 취소

Notificiation

NotificationBuilder를 통해 알림 내용을 구성했다면 NotificationManager를 통해 알림을 상태바에 등록

build() 함수를 사용하여 Notification 객체를 생성한 후 NotificationManager의 notify 함수를 통해 알림을 등록한다.

이때, 식별자 값(Int)을 두는데 이 값은 알림을 업데이트하거나 지울 때 사용한다.

// Notification 객체 생성
val notification = notificationBuilder.build()
// Notification 식별자 값, Notification 객체
manager.notify(0, notification)

or

NotificationManagerCompat.from(this).notify(0, notificationBuilder.build())

Progress

진행상황을 표시하기 위해서 Progress도 이용할 수 있다.

NotificationBuilder.setProgress(int max, int progress, boolean indeterminate)

아무 생각없이 높은 중요도 채널 ID로 Progress를 했더니 테스트 기기의 사운드 진동 알림이 폭주를 했다.

개발 의도에 따라 다르겠지만 Progress가 완료되었을 때만 소리진동 알림을 해주기 위해 만들어둔 다른 알림 중요도의 채널을 setChannelId()로 Switching을 해주었다.

val notifyId = 0
val notificationBuilder = NotificationCompat
            .Builder(this, CHANNEL_ID_SILENT)	//낮은 importance로 설정해둔 소리 안나는 채널 ID
            .setSmallIcon(R.drawable.ic_launcher_foreground)
            .setWhen(System.currentTimeMillis())
            .setContentTitle("Progress")
            .setContentText("Progress Notification")
            .setProgress(100, 0, false)
            
lifecycleScope.launch {
    for (i in 1..100) {
        notificationBuilder.setProgress(100, i, false)
        
        NotificationManagerCompat.from(this).notify(notifyId, notificationBuilder.build())
            
        delay(100)
    }

    //Progress 완료시 사운드 진동 알림 (채널 switching)
    notificationBuilder.setChannelId(CHANNEL_ID_SOUND_VIBE) //높은 inportance로 설정해둔 소리진동 채널 ID
    NotificationManagerCompat.from(this).notify(notifyId, notificationBuilder.build())
}

Cancel

식별자 값을 이용해 알림을 지운다.

//사용한 Notification 식별자 값
val progressNotify = 0
val pictureNotify = 1

NotificationManagerCompat.from(this).cancel(progressNotify)
NotificationManagerCompat.from(this).cancelAll() //모두 삭제

사용자 Interaction

알림 Touch

대부분은 탭을 하게 되면 알림에 응답하는 앱의 액티비티 화면을 켜는 데 사용하게 된다.

탭 이벤트가 발생하면 앱에서의 화면이 아니라 상태바(시스템 화면)에서 발생하는 것이므로 시스템에 이벤트가 발생하면 어떻게 처리해 달라고 의뢰하는 방식을 사용하여 탭에 응답한다.

이러한 방식을 사용하기 위해서 PendingIntent 객체가 사용되고 이를 setContentIntent()의 인자로 대입한다.

PendingIntent는 알림에서만 사용되지 않으며 인텐트 발생을 누군가에게 의뢰해야 하는 여러 곳에서 사용

//알림 클릭시 띄울 Intent
val intent = Intent(
    this@MainActivity, MainActivity::class.java
).apply { flags = Intent.FLAG_ACTIVITY_CLEAR_TASK or Intent.FLAG_ACTIVITY_NEW_TASK }

//PendingIntent 생성 getActivity, getBroadcast, getService 등등
val pendingIntent = PendingIntent.getActivity(
    this@MainActivity, 0, intent,PendingIntent.FLAG_UPDATE_CURRENT
)

notificationBuilder.apply {
    setSmallIcon(android.R.drawable.ic_notification_overlay)
    setWhen(System.currentTimeMillis())
    ...
    
    setContentIntent(pendingIntent)
}

Action

Notification에 최대 3개까지의 유저 이벤트를 위한 액션을 추가할 수 있다.

ActionBuild를 만들고 NotificationBuilder의 addAction() 함수로 추가 한다.

Action도 마찬가지로 pendingIntent를 사용

val actionBuild= NotificationCompat
    .Action
    .Builder(R.drawable.ic_launcher_foreground, "확인", pendingIntent)
    .build()

notificationBuilder.apply {
    ...
    
    addAction(actionBuild)
}

RemoteInput

SDK 24 (Android 7.0)부터는 사용자가 Activity를 열지 않고 Notification에서 바로 텍스트 입력창을 열어 답장이 가능하다.

큰 별개의 기능은 아니고 Action에 RemoteInput.Builder를 추가하면 된다.

1.RemoteInput.Builder를 통해 노티피케이션에 텍스트 입력창을 추가

2. 답장 작업 PendingIntent 생성 (임시 MainActivity 띄우는 pending 사용)

3. RemoteInput과 PendingIntent를 연결하는 Action을 생성

4. 만든 Action을 NotificationBuilder에 addAction을 통해 전달

val keyTextReply = "key_text_reply"
val remoteInput = RemoteInput.Builder(keyTextReply)
    .setLabel("답장을 입력하세요.")
    .build()

val remoteInputAction= NotificationCompat
    .Action
    .Builder(R.drawable.ic_launcher_foreground, "답장", remotePendingIntent) //답장 전송시 수행할 PendingIntent
    .addRemoteInput(remoteInput)
    .build()
    
notificationBuilder.apply {
    ...
    
    addAction(remoteInputAction)
}

Notification Style

NotificationBuilder의 setStyle()을 통해 여러 가지 모양의 Notification을 만들 수 있고 적용되는 스타일은 크게 확장형과 커스텀으로 나눌 수 있다.

BigPicture

Notification의 확장된 영역에 Image를 추가

공식 문서는 사진 1mb 이하 사용 권장 (고용량 실험 결과 : MainThread 부하, 성능 저하, 에뮬은 SystemUI isn't responding)

BigPictureStyle().bigPicture(image)

val picture = BitmapFactory.decodeResource(this.resources, R.drawable.ex_pic)
val style = NotificationCompat.BigPictureStyle().bigPicture(picture)

notificationBuilder.apply {
    ...
    setStyle(style)
}

BigText

Notification의 확장된 영역에 Text를 추가

BigTextStyle().bigText(text)

val style = NotificationCompat.BigTextStyle().bigText(getString(R.string.lorem_ipsum))

notificationBuilder.apply {
    ...
    setStyle(style)
}

InBox

BigTextStyle()과 다르게 짧은 텍스트 여러 줄이 확장된 영역에 최대 6개 표시

InBoxStyle().addLine(text)

val style = NotificationCompat.InboxStyle()
                .addLine("inBox A")
                .addLine("inBox B")
                .addLine("inBox C")
                .addLine("inBox D")
                .addLine("inBox E")
                .addLine("inBox F")

notificationBuilder.apply {
    ...
    setStyle(style)
}

Messaging

여러 사람 사이의 순차 메시지를 표시

MessagingStyle.addMessage(message)

메시지는 NotificationCompat.MessagingStyle.Message를 통해 텍스트, 시간, 보낸 사람을 표시하는 메시지 객체를 만들 수 있다.

선택적으로 setConversationTitle()을 사용해 대화 위에 표시되는 제목을 추가 가능

이 스타일은 SDK 24 (Android 7.0) 이상을 지원하는 기기에만 적용, 그 이하 버전에서는 NotificationCompat(호환성 라이브러리)를 통해 일반 확장형 Notification이 보인다.

import androidx.core.app.Person

val person1 = Person.Builder().setName("Lee").build()
val person2 = Person.Builder().setName("Kim").build()

val msg1 = NotificationCompat
    .MessagingStyle
    .Message("Hi Kim", System.currentTimeMillis(), person1)

val msg2 = NotificationCompat
    .MessagingStyle
    .Message("Oh Hi", System.currentTimeMillis(), person2)

val style = NotificationCompat
    .MessagingStyle(person1)
    .setConversationTitle("Greeting")
    .addMessage(msg1)
    .addMessage(msg2)

notificationBuilder.apply {
    ...
    setStyle(style)
}

CustomView

CustomView를 설정해 사용할 수 있지만 협소한 공간에 알림을 띄우는 것이기 때문에 복잡한 레이아웃 같은 Notification은 사용하기 힘들 수 있다.

NotificationCompat.DecoratedCustomViewStyle

RemoteViews는 다른 프로세스에 표시할 수 있는 뷰를 나타낸다.

Layout Resource 파일을 통해서 뷰의 계층 구조가 만들어진다.

하지만 RemoteView에 사용되는 View들은 한정적이다.

https://developer.android.com/reference/android/widget/RemoteViews

notificationBuilder.apply {
    ...
    .setStyle(NotificationCompat.DecoratedCustomViewStyle())
    .setCustomContentView(
        RemoteViews(packageName, R.layout.custom_notiview).apply {
            setTextViewText(R.id.txt_1, "커스텀 뷰")
            setTextViewText(R.id.txt_2, "테스트")
        }
    )
}

디자인 자신 없다면 건들면 안 되겠다.

알림 중요도 관련사항

설정한 importance / priority 값이 항상 알림의 동작을 결정한다고 보장할 수 없다.

importance / priority 값이 알림의 동작을 결정하는 것은 맞으나 다양한 상황에서 해당 값이 바뀔 수 있으므로 항상 설정해 준 값대로 알림이 동작할 것이라고 판단하지 말라고 한다.

실제로 importance 값을 High로 세팅한 Channel 이어도 해당 Channel 설정에서 importance 값을 변경할 경우 high 가 아닌 가장 최근에 변경한 값으로 적용됨을 확인할 수 있다.

(유저가 변경한 설정이 유지되는 게 자연스러운 로직이라고 한다.)

버전별 권한 관련

타겟 sdk 32 이하의 앱이 Android 13 디바이스 설치 시 Notification Channel을 등록할 때 자동으로 Notification 권한 요청 팝업이 나옴
32 이상 앱이 Android 13 디바이스 설치시 Notification 권한요청을 개발자가 원하는 타이밍에 노출 가능
32 이상 앱이 Android 12 이하 디바이스에 설치시 기존과 동일하게 Notification 권한 요청 없이 사용 가능
32 앱을 33으로 업데이트 시 기존 알림 권한 동의 상태라면 업데이트 이후 기본으로 허용이지만 예외 있음
- 기기에 따라 자동으로 허용되지 않고 다시 한번 권한을 얻어야 하는 경우가 있음
- 때문에 Notification 권한이 허가되어 있는지 한 번 확인하는 작업을 넣기를 권장

권한 팝업 관련사항

sdk 32 이하 앱의 경우, 시스템이 자동으로 권한 팝업을 띄웠을 때, 사용자가 거부 버튼을 한번 누르면, 앱이 재시작해도 팝업이 발생하지 않는다.
33 이상 앱의 경우, 앱이 권한 팝업을 띄웠을 때, 사용자가 거부 버튼을 두 번 누르기 전까지 퍼미션 팝업을 계속 띄울 수 있다.
사용자가 거부 버튼을 눌러서 더 이상 팝업을 띄울 수 없다면 사용자가 직접 앱 설정에 들어가서 권한을 허가해줘야 한다.

const val DENIED = "denied"
const val EXPLAINED = "explained"

// 권한 요청용 Activity Callback 객체
private val registerForActivityResult =
    registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->
        val deniedPermissionList = permissions.filter { !it.value }.map { it.key }
        when {
            deniedPermissionList.isNotEmpty() -> {
                val map = deniedPermissionList.groupBy { permission ->
                    if (shouldShowRequestPermissionRationale(permission)) DENIED else EXPLAINED
                }
                // 단순히 권한이 거부 되었을 때
                map[DENIED]?.let {
                
                }
                map[EXPLAINED]?.let {
                    // 권한 요청이 완전히 막혔을 때(주로 앱 상세 창 열기)
                }
            }

            else -> { // 모든 권한 허가

            }
        }
   }

구현 코드

https://github.com/wo9374/StudyProject/tree/main/Notification

Permission
https://android-developer.tistory.com/entry/안드로이드13에서-Notification-허가-받기-방법-및-변경점
https://salmonpack.tistory.com/32

중요도
https://rkdxowhd98.tistory.com/188
https://vagabond95.me/posts/notification-with-oreo/

Style
https://hyejineee.github.io/blog/android-notification-implement

Kotlin DSL, buildSrc 의존성 주입

bumjae — Thu, 7 Dec 2023 23:21:54 +0900

2023 4월 13일 구글이 Android의 새로운 빌드 언어로 Kotlin DSL을 채택
구글이 채택한 Kotlin DSL이 무엇인지, 어떤 장점이 있는지 알아본다.

Kotlin DSL

Kotlin으로 작성된 도메인 특화 언어(DSL)로 Gradle, Android 등 여러 영역에서 사용되며 정적 타입 검사, 람다 함수, 확장 함수 등과 같은 Kotlin 언어의 장점을 살려 직관적인 DSL을 구축 가능하게 한다.

Kotlin DSL 채택 이유

꼭 Kotlin DSL을 사용해야 하는 것은 아니나 다른 DSL의 비해서 특정 도메인이나 작업에 대해 보다

표현력이 뛰어나고 유연한 코드를 작성할 수 있도록 도와주는 도구로 채택된 것으로 본다

Kotlin DSL is Now the Default for New Gradle Builds

Today we're excited to announce that we're switching the default language for build scripts to Kotlin! We've been working with the Gradle and JetBrain

android-developers.googleblog.com

Kotlin DSL 장점

간결하고 가독성이 높은 코드
- Kotlin은 간결하고 표현력이 뛰어난 프로그래밍 언어, Kotlin의 장점을 살려 더욱 간결하고 가독성이 높은 코드를 작성할 수 있게 함

타입 안전성

- 정적 타입 언어로 컴파일 시점에서 오류 검출, 컴파일러의 검사를 통해 더욱 안정적인 코드를 작성 가능

IDE 지원

- 안드로이드 스튜디오를 비롯한 다양한 IDE 지원, IDE에서 DSL의 구문 강조 표시, 자동 완성, 코드 내비게이션 등의 기능을 활용할 수 있으며, 개발 생산성을 향상 가능

유연성과 확장성

- Kotlin은 객체 지향 프로그래밍과 함수형 프로그래밍을 모두 지원하므로, Kotlin DSL을 작성할 때 유연하고 확장 가능한 구조를 구성 가능

Kotlin의 기능 활용

- Kotlin은람다식, 확장 함수, Null 안전성 등 다양한 특징과 기능 제공, Kotlin DSL을 사용하면 이러한 기능을 활용하여 DSL를 보다 효율적으로 작성 가능

Kotlin DSL 단점

학습 곡선
- Kotlin DSL은 Kotlin 언어의 특성과 문법을 이해필요, Kotlin 언어에 익숙하지 않은 개발자들에게는 학습 곡선이 존재할 수 있다.

생산성 저하
- 표현력이 높고 강력한 기능을 제공하지만, 초기 구현 및 설정에는 추가적인 작업이 필요할 수 있다. 기존의 설정 방식이나 프레임워크에 익숙한 개발자들에게는 처음에는 생산성 저하가 있을 수 있다.

제한된 확장성
- Kotlin 언어의 기능과 제한적인 범위 내에서 확장이 가능하나 특정한 요구사항이나 도메인에 따라 확장의 어려움이 존재할 수 있다. 이는 Kotlin 언어의 한계이거나 DSL 설계의 한계로 인해 발생할 수 있다.

Kotlin DSL, Groovy DSL 차이

	Kotlin	Groovy
언어	Kotlin 언어	Groovy 언어
문법	정적 타입, 람다식, 확장 함수 등의 Kotlin 문법	동적 타입, 클로저, 메소드 체인 등의 Groovy 문법
타입 안전성	정적 타입으로 타입 안전성 보장	동적 타입으로 타입 안전성 제한적
확장성	Kotlin 언어 기능을 활용한 확장성	Groovy 언어 기능을 활용한 확장성
가독성	Kotlin 표현력을 활용한 가독성	Groovy 표현력을 활용한 가독성
IDE 지원	안드로이드 스튜디오 등 Kotlin IDE에서 지원	IntelliJ IDEA 등 Groovy IDE에서 지원
도구 및 라이브러리	Kotlin과 Gradle 통합 지원	Groovy와 Gradle 통합 지원
사용범위	주로 안드로이드 및 Kotlin 기반 프로젝트	다양한 프로젝트 및 스크립트
학습 곡선	Kotlin 언어	Groovy 언어

이런 장∙단점을 가졌지만, 모든 프로젝트에 Kotlin DSL을 사용할 수는 없다.

어떤 DSL을 사용할지의 대한 여부는 프로젝트의 특정 상황과 요구 사항에 따라 결정해야 한다.

구글에서 Kotlin DSL을 Android 앱용 Gradle 빌드 파일의 기본 스크립트로 사용하겠다고 밝힌 시점에서,
변화가 빠른 Android 생태계를 따라가기 위해 지금부터는 적극적으로 Kotlin DSL을 활용할 것이다.

buildSrc

의존성 관리와 IDE 자동완성 지원을 위해 kotlin 코드를 가지는 buildSrc 모듈을 만들 수 있다.

Gradle이 수행되면 buildSrc 디렉터리가 존재하는지 체크한다.
이 경우 Gradle은 자동적으로 코드를 컴파일하고 테스트한 뒤 당신의 빌드 스크립트의 classpath에 넣는다.
이 방법은 유지 보수, 리팩터링 및 코드 테스트가 더 쉽다.

빌드 로직을 포함할 수 있는 Gradle 프로젝트 루트 디렉터리

buildSrc와 Kotlin DSL을 사용해서 매우 적은 구성으로 커스텀 빌드 코드를 작성하고 전체 프로젝트에서 이 로직을 공유하여 사용

buildSrc를 변경하면 전체 프로젝트의 빌드 캐시가 무효화되기 때문에 잦은 수정을 피해야 한다.

Setting

rootDirectory에 buildSrc Directory 생성

buildSrc/build.gradle.kts 생성

plugins {
    `kotlin-dsl`
}
repositories {
    mavenCentral()
}

buildSrc/src/main/kotlin/Dependency.kt 생성

사용할 의존성 작성 (임시로 라이브러리 dependency만)

import Versions.hilt
import Versions.room

object Versions {
    const val hilt ="2.49"

    const val ksp = "1.9.21-1.0.15"

    const val room = "2.6.1"
}

object Lib {

    object Room{
        const val core = "androidx.room:room-runtime:$room"
        const val compiler = "androidx.room:room-compiler:$room"
        const val ktx = "androidx.room:room-ktx:$room"
    }

    object Activity{
        const val ktx = "androidx.activity:activity-ktx:1.8.1"
    }

    object Dagger{
        object Hilt{
            const val core = "com.google.dagger:hilt-android:$hilt"
            const val compiler = "com.google.dagger:hilt-android-compiler:$hilt"
        }
    }

    object Kotlin{
        const val coroutine = "org.jetbrains.kotlinx:kotlinx-coroutines-android:1.6.4"
    }
}

각 그래들 kts로 변경 / build.gradle -> build.gradle.kts 변경

작성한 dependency 사용 (사용이 안될 때 Sync 진행)

build.gradle.kts (:app)

plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
    
    id("com.google.devtools.ksp")
    id("dagger.hilt.android.plugin")
}

android {
    namespace = "com.ljb.example"
    compileSdk = 34

    defaultConfig {
        applicationId = "com.ljb.cleanarchitecture"
        minSdk = 21
        targetSdk = 34
        versionCode = 1
        versionName = "1.0"

        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            isMinifyEnabled = false
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
    ...
}

dependencies {
    ...
    
    implementation(Lib.Dagger.Hilt.core)
    ksp(Lib.Dagger.Hilt.compiler)
    
    implementation(Lib.Activity.ktx)
}

build.gradle.kts (:project)

plugins {
    ...
    id("com.google.devtools.ksp") version Versions.ksp apply false
    id("com.google.dagger.hilt.android") version Versions.hilt apply false
}

setting.gradle.kts

pluginManagement {
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.name="Example"
include (":app")

Kotlin DSL
https://developer.android.com/studio/build/migrate-to-kts?hl=ko
https://android-developers.googleblog.com/2023/04/kotlin-dsl-is-now-default-for-new-gradle-builds.html
https://blog.imqa.io/kotlin-dsl/

buildSrc
https://seansation-blog.tistory.com/7

DataStore / Preference, Proto

bumjae — Mon, 4 Dec 2023 19:19:08 +0900

안드로이드에서 단순한 데이터셋을 로컬에 저장하기 위해서 흔히 기본적으로 내장되어 있는 SharedPreferences를 사용한다.
하지만 Primitive data만 저장 가능했으며, 커스텀 데이터 타입 저장을 위해 GSON을 통해 Json String으로 변환하여 저장하는 코드들이 생겨났다.

그리고 미숙한 처리에 종종 Runtime Error, ANR이 날 수도 있다.

SharedPreferences 단점

실제 XML 파일 I/O 작업을 하는 것으로 UI Thread에서 작업할 경우 안전하지 않음
Runtime Exception으로부터 안전하지 않음
XML 파일이기에 외부에서 쉽게 파일을 읽을 수 있음 (DataStore도 읽을 수는 있음)
비동기 API를 제공하지만 Listener를 통해서만 값을 Read 할 수 있음
Type-Safety 미제공

아래에서 설명할 DataStore는 SharedPreferences를 대체하기 위해 Jetpack에서 발표한 라이브러리이다.

DataStore

Kotlin coroutine과 Flow를 사용하여 비동기적으로, 일관되게 데이터를 저장이 가능

Preferences DataStore

SharedPreferences 처럼 key-value 형태로 저장
Type-Safety를 제공 X

Proto DataStore

커스텀 데이터 타입을 Protocol buffer를 통하여 저장
미리 정의된 schema를 통하여 Type-Safety를 보장

비교

아래 표는 SharedPreferences와 DataSore의 비교표로 왜 DataStore를 사용해야 하는지 알 수 있다.

SharedPreference vs DataStore

PreferencesDataStore 구현

build.gradle (app)

dependencies {
    implementation("androidx.datastore:datastore-preferences:<latest_version>")
    //Multi Module Ver.
    //implementation("androidx.datastore:datastore-preferences-core:<latest_version>")
}

Data package나 쓰일 곳에 User 파일을 만들고 DataStore를 생성하는 코드를 넣는다

by 키워드를 써서 DataStore의 구현을 preferencesDataStore()에 맡기는 Context 확장 프로퍼티

import android.content.Context
import androidx.datastore.core.DataStore
import androidx.datastore.preferences.core.Preferences
import androidx.datastore.preferences.preferencesDataStore

val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "user_prefs")

만든 dataStore를 관리할 class 생성

import androidx.datastore.core.DataStore
import androidx.datastore.preferences.core.*
import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.map

class UserManager(private val dataStore: DataStore<Preferences>) {
    companion object {
        val USER_AGE_KEY = intPreferencesKey("USER_AGE")
        val USER_NAME_KEY = stringPreferencesKey("USER_LAST_NAME")
        val USER_GENDER_KEY = booleanPreferencesKey("USER_GENDER")
    }

    suspend fun storeUser(age: Int, lastName: String, isMale: Boolean) {
        dataStore.edit {
            it[USER_AGE_KEY] = age
            it[USER_NAME_KEY] = lastName
            it[USER_GENDER_KEY] = isMale
        }
    }

    val userAgeFlow: Flow<Int?> = dataStore.data.map { it[USER_AGE_KEY] }
    val userNameFlow: Flow<String?> = dataStore.data.map { it[USER_NAME_KEY] }
    val userGenderFlow: Flow<Boolean?> = dataStore.data.map { it[USER_GENDER_KEY] }
}

내부적으로 코루틴을 사용하기 때문에 데이터를 저장하는 storeUser()의 앞에 suspend 키워드를 붙임
intPreferencesKey(), stringPreferencesKey() 등의 함수가 보이는데 이것은 저장될 값들의 키를 정의하는 함수

타입에 맞는 함수를 쓰고 그 안에 키로 사용할 문자열을 넣어줌, 같은 이름의 키가 여러 개 있다면 ClassCastException 발생

버튼을 누르면 입력된 값들을 DataStore에 저장하고, 저장된 값이 바뀌면 이를 관찰해서 View에 사용

class PreferencesActivity : AppCompatActivity() {

    private lateinit var userManager: UserManager

    override fun onCreate(savedInstanceState: Bundle?) {
        ...
        
        userManager = UserManager(dataStore)
        
        btnSave.setOnClickListener{
            CoroutineScope(Dispatchers.IO).launch { userManager.storeUser(임시나이, 이름, 성별) }
        }
        btnClear.setOnClickListener{
            CoroutineScope(Dispatchers.IO).launch { userManager.clearUser() }
        }

        observeData()
    }

    private fun observeData() = lifecycleScope.launch {
        launch {
            userManager.userAgeFlow.collectLatest { val age = it }
        }
        launch {
            userManager.userNameFlow.collectLatest { val name = it }
        }
        launch {
            userManager.userGenderFlow.collectLatest { val genderBool = it }
        }
    }
}

ProtoDataStore 구현

ProtoDataStore를 구현할 때 Protocol Buffer도 구현해야 한다.

Protocol Buffer

Google에서 개발한 이진 직렬화 포맷

플랫폼 및 언어에 독립적이며, 다양한 언어와 시스템에서 데이터를 효율적으로 전송하기 위해 사용

주요 장점은 작은 메시지 크기, 빠른 직렬화/역직렬화 속도 및 강력한 타입 안정성을 제공

build.gradle (project) / 작성자는 Kts 환경 (build.gradle.kts)

plugins {
    ...
    
    id("com.google.protobuf") version "<latest_version>" apply false
}

build.gradle (app) / Protobuf 플러그인 및 라이브러리 의존성 추가

plugins {
    ...
    id("com.google.protobuf")
}

protobuf {
    protoc {
        artifact = "com.google.protobuf:protoc:3.25.1"
    }
    generateProtoTasks {
        all().forEach { task ->
            task.builtins{
                id("java"){ option("lite") }
            }
        }
    }
}

dependencies {
    ...
    implementation("androidx.datastore:datastore:<latest_version>")
    //Multi Module Ver.
    //implementation("androidx.datastore:datastore-core:<latest_version>")
    
    implementation("com.google.protobuf:protobuf-javalite:<latest_version>")
}

프로젝트 내에서 .proto 파일을 작성 ( 작성자는 src\main\proto 디렉토리 생성 후 Sample.proto 작성 )

syntax = "proto3";

option java_package = "com.ljb.datastore";
option java_multiple_files = true;

message Sample {
  int32 age = 1;
  string name = 2;
  
  enum Gender {
    MALE = 0;
    FEMALE = 1;
  }
  Gender gender = 3;
  bool initData = 4;
}

syntax : 사용할 Protobuf 버전을 지정하는 부분, protocol buffer 3 버전을 사용한다는 것을 명시
java_package : 클래스가 생성될 package 명 명시 (ex:전체 패키지 이름)
java_multiple_files : 최상위 수준인 클래스, enum에 해당하는 자바 클래스, enum 파일 등을 별도의 파일로 분리할지를 결정하는 항목, 자세한 건 https://protobuf.dev/programming-guides/proto3/
message : 데이터 구조 정의, 자료형을 선언, 그 안에 적절한 멤버 변수를 정의, 각 멤버 변수에 붙은 1, 2, ...에 해당하는 값은 해당 멤버 변수에 부여된 고유 값

작성 후 rebuild를 진행해주면 .proto 파일에서 정의한 자료형이 Java 클래스로 빌드되고, 이를 활용해 Android Studio 내에서 DataStore를 구현할 수 있게 된다.

Serializer 작성

Proto는 JSON처럼 직렬화된 데이터를 사용, 이를 활용하려면 직렬화/역직렬화 과정이 필요

앱 패키지 내 적절한 경로에 Serializer 생성

ViewModel을 싱글톤으로 쓰는 것과 유사한 이유로 DataStore도 단일 객체로 사용, Serializer도 object로 선언

object SampleSerializer: Serializer<Sample> {
    override val defaultValue: Sample
        get() = Sample.getDefaultInstance()

    override suspend fun readFrom(input: InputStream): Sample {
        try {
            return Sample.parseFrom(input)
        } catch (e: InvalidProtocolBufferException){
            throw CorruptionException("Cannot read proto.", e)
        }
    }

    override suspend fun writeTo(t: Sample, output: OutputStream) {
        t.writeTo(output)
    }
}

Repository

직접적인 데이터 조작은 Repository에서 진행, ViewModel이 Repository에 딸린 Flow를 읽거나 메소드를 호출하는 식으로 간접적으로 데이터에 접근

class SampleRepository(private val sampleProtoDataStore: DataStore<Sample>) {
    val flow : Flow<Sample> = sampleProtoDataStore.data

    suspend fun setUserData(name:String, age:Int, gender: Sample.Gender, initData: Boolean){
        sampleProtoDataStore.updateData { sample ->
            sample
                .toBuilder()
                .setName(name)
                .setAge(age)
                .setGender(gender)
                .setInitData(initData)
                .build()
        }
    }

    suspend fun clearUserData(){
        sampleProtoDataStore.updateData { sample ->
            sample
                .toBuilder()
                .clearName()
                .clearAge()
                .clearGender()
                .clearInitData()
                .build()
        }
    }
}

생성자 매개 변수 DataStore<T> : .proto에서 정의한 데이터를 직접 읽고 쓸 수 있는 메소드를 제공해 주는 클래스
쓰기 및 수정 접근 : Proto는 .proto에서 지정한 멤버 변수별로 Getter와 Setter를 제공

ViewModel

susfed fun 함수 이므로 viewModelScope 사용

class ProtoViewModel(private val repository: SampleRepository) : ViewModel() {
    val flow: Flow<Sample> = repository.flow

    fun setUserData(name:String, age:Int, gender: Sample.Gender, initData: Boolean){
        viewModelScope.launch { repository.setUserData(name, age, gender, initData) }
    }

    fun clearUserData(){
        viewModelScope.launch { repository.clearUserData() }
    }
}

ViewModelFactory에도 Repository를 매개 변수로 넣어줌

class ProtoViewModelFactory(private val repository: SampleRepository) : ViewModelProvider.Factory {
    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        if (modelClass.isAssignableFrom(ProtoViewModel::class.java)){
            @Suppress("UNCHECKED_CAST")
            return ProtoViewModel(repository) as T
        }
        throw IllegalArgumentException("Unknown ViewModel class")
    }
}

Activity

최상단에 Repository의 매개 변수 DataStore<T>에 들어갈 변수 생성, 만들어둔 SampleSerializer 지정

fileName : 로컬에 저장될 Protobuf 파일의 이름
serializer : 말그대로 Serializer

private val Context.sampleDataStore: DataStore<Sample> by dataStore(
    fileName = "sample.pb",
    serializer = SampleSerializer
)

class ProtoActivity : AppCompatActivity() {

    private lateinit var viewModel: ProtoViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        ...
        
        viewModel = ViewModelProvider(this,
            ProtoViewModelFactory(SampleRepository(sampleDataStore))
        )[ProtoViewModel::class.java]

        setUi()
        observeData()
    }

    private fun setUi() {
        ...
        btnSave.setOnClickListener {
            CoroutineScope(Dispatchers.IO).launch { viewModel.setUserData(이름, 나이, 성별, 초기Init) }
        }
        btnClear.setOnClickListener {
            CoroutineScope(Dispatchers.IO).launch{ viewModel.clearUserData() }
        }
    }

    private fun observeData() = lifecycleScope.launch {
        //UI 처리
        viewModel.flow.collectLatest { sampleProto ->
            val age = sampleProto.age
            val name = sampleProto.name
            val initData = sampleProto.initData
            if (sampleProto.gender == Sample.Gender.MALE){
                
            }
        }
        
    }
}

전체코드

https://github.com/wo9374/StudyProject/tree/main/DataStore

Preference, Proto 둘 다 동일 실행 화면

PreferencesDataStore
https://developer.android.com/topic/libraries/architecture/datastore?hl=ko
https://developer.android.com/codelabs/android-proto-datastore?hl=ko#0
https://onlyfor-me-blog.tistory.com/519

ProtoDataStore
https://velog.io/@i_meant_to_be/Proto-Datastore-Jetpack-Compose

Protobuffer
https://protobuf.dev/programming-guides/proto3/
https://velog.io/@heetaeheo/Protobuf

Kts build
https://stackoverflow.com/questions/75025962/configuring-protocol-buffers-0-9-x-with-kotlin-dsl

Ktor

bumjae — Sun, 3 Dec 2023 17:33:55 +0900

JetBrains에서 만들어진 Kotlin을 사용하여 연결된 시스템에서
비동기 서버 및 클라이언트를 구축하기 위한 오픈 소스 프레임 워크

설치, 사용이 간편하여 실행 파이프 라인에 단계를 추가하려는 경우 확장 가능하다.

Coroutine의 비동기 속성으로 인해 여러 요청 수신이 가능하고 MultiPlatform이기도 하다.

즉 서버뿐 아니라 Ktor Client를 써서 Android, iOS, JS에서 마이크로서비스를 사용할 수도 있다.

Ktor Client를 쓰면 요청 생성, 응답 처리 및 인증, Json 직렬화 등과 같은 기능으로 기능을 확장할 수 있다.

Creating a client application | Ktor

ktor.io

구현할 Android는 Client이기 때문에 Client만 알아보았다.

안드로이드에 Ktor 적용

build.gradle (project)

plugins {
    id("com.android.application") version "8.1.4" apply false
    id("org.jetbrains.kotlin.android") version "1.9.0" apply false

    kotlin("plugin.serialization") version "1.9.21" apply false
    //kotlin("jvm") version "1.9.21" // 멀티플랫폼이나 다른 플러그인에 serialization 사용할 때 지정
}

build.gradle (app)

dependencies {
    //Ktor
    implementation("io.ktor:ktor-client-android:<latest-version>")
    
    //JVM, Android 및 Native 플랫폼에서 사용할 수 있는 완전 비동기식 코루틴 기반 엔진
    implementation("io.ktor:ktor-client-cio:<latest-version>")
    
    //HTTP Request을 로깅하기 위해 사용
    implementation("io.ktor:ktor-client-logging-jvm:<latest-version>")
    
    //직렬화/역직렬화를 위한 ContentNegotiation
    implementation("io.ktor:ktor-client-content-negotiation:<latest-version>")
    
    //Serialization json
    implementation("io.ktor:ktor-serialization-kotlinx-json:<latest-version>")
    
    //Serialization XML
    //implementation("io.ktor:ktor-serialization-kotlinx-xml:<latest-version>")
    
    //Multi Platform Serialization
    //implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:<latest-version>")  
}

Manifast

<uses-permission android:name="android.permission.INTERNET" />

Basic SetUp Client

기본 Client를 사용하는 방법

Retrofit에서는 함수 형식으로 선언하여 팩토리 패턴으로 클라이언트를 생성하던 것을, Ktor에서는 Scope를 할당하여 DSL 형식으로 작성함으로써 가독성을 높인 것 같음

private const val BASE_URL = "https://"

val ktorClient = HttpClient(CIO){
    defaultRequest {
        url {
            protocol = URLProtocol.HTTPS
            host = BASE_URL
        }
    }
    install(ContentNegotiation) {
        json() // for json
    }
}

object Service {
    suspend fun getTodoData(): List<TodoData> {
        ktorClient
        .get<HttpResponse>(path = "todo")
        .body<List<TodoData>>()
    }
    
    // Or Client에 defaultRequest 없이도 바로 사용 가능
    suspend fun getD() : List<TodoData> {
        client.get("url"){
            url{ 
            	header("HEADER","HEADER.String")
            	header("HEADER","HEADER.String")
            }
        }
    }
    
}

//api 호출
val result = Service.getTodoData()

Json 형식의 Request 값을 데이터 객체로 변환하기 위해, Retrofit은 ConverterFactory를 추가하지만
Ktor은 install 함수(플러그인 설치 기능)에 ContentNegotiation를 전달하여 Converter 추가

아래 코드는 네이버 검색 API를 호출하려고 만든 Client와 사용하는 코드이다.

object ApiInfo {
    //const val BASE_URL = "https://openapi.naver.com/v1/search/news.json"
    const val HOST = "openapi.naver.com"
    const val PATH = "/v1/search/news.json"

    const val HEADER_ID = "X-Naver-Client-Id"
    const val HEADER_SECRET = "X-Naver-Client-Secret"
}

val ktorClient = HttpClient(CIO) {
    expectSuccess = true          //응답 유효성 검사 true/false
    //followRedirects  = false    //리다이렉트 true/false
    
    //Http 요청에 대해 default value를 세팅하는 역할
    defaultRequest {
        url {
            protocol = URLProtocol.HTTPS
            host = HOST 	//URL Host
            path(PATH)		//요청 EndPoint
        }

        //요청 Header 추가 (localProperies 네이버 API id, key)
        headers {
            header(HEADER_ID, BuildConfig.NAVER_CLIENT_ID)
            header(HEADER_SECRET, BuildConfig.NAVER_CLIENT_SECRET)
        }
    }

    // install: client configuration block에 plugin을 가져옴
    install(ContentNegotiation) {
        json(
            Json {
                prettyPrint = true          // Json string을 읽기 편하게 만들어줌
                isLenient = true            // 따옴표 규칙 완화
                encodeDefaults = true       // null 또는 잘못된 값이 들어간 경우 default property value로 대체
                ignoreUnknownKeys = true    // Field 값이 없는 경우 무시할지 (모델에 없고, json에 있는 경우 해당 key 무시)
            }
        )
    }
    
    //Http 요청 로깅들을 만드는 로깅 역할
    install(Logging) {
        //logger = Logger.DEFAULT
        logger = object : Logger {
            override fun log(message: String) {
                Log.v("Ktor Logger", message)
            }
        }
        level = LogLevel.ALL
        //filter {  request -> request.url.host.contains("ktor.io") }
    }
    
    //응답의 상태를 기록하는 Observer
    install(ResponseObserver) {
        onResponse { response -> Log.d("HTTP status: ", "${response.status.value}") }
    }
}

class NewsApi(private val client: HttpClient){
    suspend fun getNews(query: String) : HttpResponse = client.get{
        parameter("query", query)
    }
}

class NewRepository{
    private val newsApi = NewsApi(ktorClient)

    suspend fun getSearchNews(query: String): Flow<List<NewsData>> = flow{
        try {
            newsApi.getNews(query).run {
                if (status.isSuccess()){
                    //Data Reponse 자동 역직렬화
                    val response = body<NewsResponse>() 
                    
                    emit(response.items)
                }else{
                    //Api Error 처리
                }
            }
        }catch (e: Exception){
            //Network Error 처리
        }
    }
}

NewRepository는 ViewModel이나 Presenter, Controller에서 getSearchNews()를 호출해 Data를 받아왔다.

전체코드

https://github.com/wo9374/StudyProject/tree/main/NetworkLibrary/Ktor

Ktor
https://daryeou.tistory.com/345
https://medium.com/@ans188/ktor란-무엇일까-750dcc9f77f5
https://velog.io/@dldmswo1209/Compose-UI-Ktor-api-호출

Architecture Pattern MVC, MVP, MVVM, MVI

bumjae — Sat, 2 Dec 2023 02:06:17 +0900

협업을 할 때 다른 개발자의 해당 메서드가 무슨 역할을 하는지
모르기 때문에 누군가 작성해 놓은 코드를 디버깅하면서 분석을 하게 된다.
이는 곧 리소스의 낭비이다.

그래서 협업 환경에서 코드 네이밍과 자세한 주석, 이해하기 쉬운 구조는
곧 동료 작업자에 대한 배려이자 실력의 척도가 된다.

Architecture Pattern

구조를 만들고 같은 역할을 하는 class를 묶어, 이해하기 쉽게 적응할 수 있도록 하자는 유명 개발자들의 생각으로 소프트웨어 아키텍처는 공식화되었고, 해당 아키텍처를 아는 사람은 조금 더 수월하게 프로젝트를 이해할 수 되었다.

사전적 정의로 아키텍처 패턴은 공통적으로 자주 발생하는 문제를 해결하는 재사용 가능한 해결방법이다.
실제로 아키텍처 패턴은 반복적으로 발견되고 재사용할 수 있는 잘 정의된 속성을 가진 아키텍처 클래스를 의미한다.

모바일 앱 4대 Architecture에 대해 정리해 본다

MVC (Model-View-Controller)

Model

애플리케이션에 사용되는 데이터와 처리 로직이 담김
View 또는 Controller와 묶이지 않기 때문에 재사용이 가능

View(UI)

사용자에게 보여주는 보이는 화면

Controller

사용자로부터 입력을 받고, 모델에 의해 View정의

Android에서는 View와 Controller가 Activity에 포함
이러한 문제점 때문에 Activity에 코드들이 몰리는 현상이 발생

장점

구현이 쉽고, 이해하기 쉬우며, 구현 속도도 가장 빠름

단점

Controller와 View가 결합되어 있기 때문에 UnitTest에 어려움이 있음. UI 로직과 Controller에서 실행하는 로직들을 분리하기 어렵기 때문
UI변경점이 있을 때, Controller의 코드 변경 또한 불가피
Model과 View의 의존성이 높기 때문에 앱이 커질수록 스파게티 코드가 될 위험이 높아짐 (MVP의 등장 배경)

MVP (Model-View-Presenter)

MVP의 특징은 Activity가 View의 역할만 수행
Android에 있어서 MVP는 컴포넌트 분리가 좀 더 명확하게 이루어 짐

Model

MVC의 모델과 동일

View(UI)

Activity를 자연스럽게 View의 일부로 간주하게 됨

Presenter

Controller와 같은 역할을 하나, Interface로 이루어져 UnitTest에 자유로움

이제 Activity단에서 바로 Model을 호출하는 것이 아닌, Presenter에서 View로 전달

장점

Model과 View의 의존성이 없어졌기 때문에 관련된 코드만 수정이 용이
UI와 Data파트가 명확히 구분되어 간편하게 코딩 가능

단점

애플리케이션이 커질수록 View와 Presenter 사이의 의존성이 강해짐
기능이 많아지면 Presenter의 비중이 커지기 때문에 분리하기가 어려움

MVC와 다르게 명확하게 컴포넌트가 구분되기 때문에 역할에 따라 분리가 잘된 코드를 볼 수 있지만,
Presenter와 View가 1:1 관계를 갖고 있기 때문에 프로젝트가 커질수록 Presenter 또한 비례해서 늘어나게 됨

MVVM (Model-View-ViewModel)

MVVM은 presenter에 의존하지 않고, Observer pattern을 이용해 객체의 변경이 일어날 때마다 UI를 갱신

Observer Pattern
상태 변화가 있을 때마다 메서드를 통하여 관찰 대상자가 직접
옵저버들에게 통지하여 상태를 동기화할 수 있도록 하는 디자인 패턴을 의미
즉, 객체에 변화가 일어날 때마다 콜백이 일어나게 됨

Model

MVC의 모델과 동일

View(UI)

ViewModel의 Data들을 구독하고 있다가 객체가 변할 때 UI를 업데이트

ViewModel

Model과 상호 작용하며, View에 종속되지 않고 1:N 구조를 가짐
MVVM의 가장 큰 특징은 View가 어떤 종속성도 가지지 않는다는 것, 그래서 ViewModel을 다른 View에서도 활용이 가능

장점

View와 Model이 독립
바인딩하기 때문에 코드의 양이 감소
ViewModel에서 View 코드가 없기 때문에 UnitTest를 쉽게 가능

단점

데이터 바인딩이 필수적으로 요구
간단한 UI에서 ViewModel을 설계해야 하고, 그만큼 과도한 엔지니어링이 일어날 수 있음
다양한 곳에서 많은 데이터를 받기 때문에 관리를 제대로 못 할 경우 버그가 발생

AAC ViewModel과의 차이

AndroidX에 있는 AAC ViewModel은 MVVM의 ViewModel과 다르다.
Android에서의 ViewModel은 Fragment와 Activity의 데이터 전달, 화면 전환 시 잃어버리는 데이터를 저장하는 저장소인 셈

LiveData와 StateFlow를 추가하여 MVVM Architecture를 구현한 것이기 때문에 결론은 AAC ViewModel을 쓴다고 해서 MVVM을 사용한다고 할 수 없음

마찬가지로 MVVM을 한다고 해서 AAC ViewModel을 사용할 필요는 없기에, 어떤 기업은 AAC ViewModel을 사용하지 않고도 MVVM을 구현한다고 함

AAC ViewModel 설명

Android AAC (Android Architecture Component)

Android Architecture Component 테스트와 유지보수가 쉬운 앱을 디자인할 수 있도록 돕는 라이브러리의 모음 ViewModel 앱의 Lifecycle을 고려하여 UI 관련 데이터를 저장하고 관리하는 컴포넌트 UI Controller로

bumjae.tistory.com

MVI (Model-View-Intent)

MVVM에서 해결하지 못하는 상태 문제와 부수 효과 문제가 제기됨

상태 문제
프로그레스 바의 상태, 버튼 활성화 상태와 같이 화면에 나타나는 모든 정보를 상태라고 하는데,
의도치 않은 방향으로 상태가 제어된다면 이것을 상태 문제라고 함

부수 효과(side effect)
원래의 목적과 다른 효과 또는 부작용이 발생하는 상태를 의미
예를 들어 네트워크 통신 때 데이터를 가져오는 함수는 데이터를 못 가져올 수도 있다.
function add(a, b){a+b+c}는 a와 b를 더한 값의 예상과 다르게 c 때문에 값이 변경될 수도 있다.

데이터가 로딩되었음에도, 프로그레스 바가 돌고 있다.

MVVM으로 구현하면서 ViewModel에서 상태를 관리하게 되는데

여러 데이터를 분산하다 보니 관리 포인트가 불가피하게 늘어나고, 버그가 발생

데이터의 흐름을 제어하지 못하는 것이 문제였기 때문에

MVI는 단일 상태 관리와 단방향 데이터 흐름을 통해 MVVM의 문제점을 해결하고자 함

위 그림과 같이 단방향으로 흐르는 구조

Model

다른 Model과 다르게 상태(State)를 의미
intent로 전달받은 객체에 맞추어 새로운 불변객체를 Model로 생성

View(UI)

Model의 결과물인 상태를 구독하고 있다가 변경 시 UI 업데이트를 진행

Intent

앱의 상태를 바꾸려는 의도를 의미
Model에게 앱의 상태를 전달

MVI에 따르면, Model에서 호출되는 값은 불변하기에 예상이 가능해야 함 하지만 서버나 데이터베이스에서 값을 가져올 경우 이 값을 예측할 수 없음

MVI는 이러한 문제를 SideEffect를 통해 제어

SideEffect
백그라운드 작업, 액티비티 전환과 같은 부수적인 작업을 의미
Android 하단 알림 바 Toast 또한 SideEffect로 보는 경우가 많다

MVI는 MVP, MVVM과 다르게 I가 실제 컴포넌트를 지칭하지 않음

어떤 구조로 만들자는 의미보다는 어떻게 데이터와 상태의 흐름을 어떻게 다룰 것이냐는 패러다임에 가까움

그래서 MVI의 많은 예제를 보면 MVVM, MVP 기반으로 작성된 코드를 많이 볼 수 있음 (MVVM 기반으로 연습함)

장점

하나의 State객체만을 바라보기 때문에 상태 충돌이 일어나기 어려움
쉬운 데이터의 흐름을 파악
불변객체이기 때문에 스레드에 대해 안전

단점

러닝 커브가 높음 (기본적으로 MVP와 MVVM을 깔고 시작)
Model 업데이트를 위해 새로운 인스턴트를 끼워 넣기 때문에 리소스가 낭비될 수 있음
작은 변경에도 intent를 거쳐야 함

구현코드
https://github.com/wo9374/StudyProject/tree/main/DesignPattern

Architecture Pattern
https://daryeou.tistory.com/310
https://meetup.nhncloud.com/posts/342

RoomDB warning: Schema export directory is not provided

bumjae — Wed, 29 Nov 2023 11:07:38 +0900

Room을 사용 중 빌드 창 warning 문구

warning: Schema export directory is not provided to the annotation processor so we cannot export the schema. You can either provide `room.schemaLocation` annotation processor argument OR set exportSchema to false.

Room 라이브러리를 사용해서 Database 스키마를 생성할 때 exportSchema 설정에 의해 위의 경고가 뜬다.

exportSchema는 Boolean 타입으로 Database Schema를 폴더로 내보낼지 정할 수 있다.

default 값이 true로 되어있어 경로를 지정해주지 않을 시 warning 경고를 띄운다. 스키마 경로 지정이 필요 없어 false를 하면 경고는 바로 사라진다.

@Database(entities = [NumberEntity::class], version = 1, exportSchema = false)
abstract class NumbersDatabase : RoomDatabase(){
    abstract fun dao(): NumbersDao
}

경로를 지정 방법은 DB를 사용하는 모듈의 build.gradle에서 defaultConfig 하위 섹션에 스키마 경로를 작성

Groovy version

android {
    // ... (compileSdkVersion, buildToolsVersion, etc)

    defaultConfig {
        // ... (applicationId, miSdkVersion, etc)
        
        javaCompileOptions {
            annotationProcessorOptions {
                arguments += ["room.schemaLocation": "$projectDir/schemas".toString()]
            }
        }
    }
}

Kapt version

defaultConfig {
    kapt {
        arguments {
            arg("room.schemaLocation", "$projectDir/schemas")
        }
    }
}

Ksp version

defaultConfig {
    ksp {
        arg("room.schemaLocation", "$projectDir/schemas")
    }
}

Android Studio New LogCat

bumjae — Mon, 27 Feb 2023 09:13:17 +0900

Android Studio Dolphin 버전에서 새로 나온 LogCat의 필터 쿼리

내 앱에서 발생하는 내용만 보기 (PIDs for the local app project)

package:mine

내 앱에서 발생하는 내용에서 필터링 (ex) ViewModel 또는 UiState라는 문자가 포함된 내용만 필터링

package:mine ViewModel | UiState

패키지, 태그, 레벨 조합

package:my-package-ID, tag:my-tag, level:ERROR

-를 붙여 특정 태그 제외

-tag:exclude-this-tag

정규 표현식 (~을 키값 뒤에 붙여준다)

tag~:regex-tag

Logcat
https://brownsoo.medium.com/새로운-로그캣-필터-쿼리-a77da65f04f7
https://m1nzi.tistory.com/9

Android 13에 따른 compileSdkVersion , targetSdkVersion 타겟 33 구글 정책 변경

bumjae — Fri, 23 Dec 2022 10:10:06 +0900

SDK 버전을 높이기 위해 변경된 사항과
수정해야 할 사항들 중 중요하다 판단되는 것들을 알아보고 정리

Performance and battery

Foreground Services (FGS) 작업 관리자

Android 13(API 33)에서는 타겟 SDK 버전과 관계없이 사용자가 "알림 창"에서 "포그라운드 서비스"를 중지할 수 있다.

FGS 작업 관리자라고 하는 새로운 기능에는 현재 포그라운드 서비스를 실행 중인 앱 목록이 표시된다.

이 목록에는 활성 앱이라는 라벨이 적용되어 있다. 각 앱의 옆에는 중지 버튼이 있다.

아래 그림은 Android 13을 실행하는 기기에서 FGS 작업 관리자 워크플로를 보여준다.

JobScheduler를 사용한 작업 미리 가져오기 처리 개선

JobScheduler는 앱이 JobInfo.Builder.setPrefetch()를 사용하여 특정 작업을 '미리 가져오기' 작업으로 표시할 방법을 제공한다.

미리 가져오기 작업은 사용자 환경을 개선하기 위해 다음번 앱이 실행되기 직전에 실행해야 하는 작업을 의미한다.

JobScheduler는 이제까지 이 신호만 사용하여 미리 가져오기 작업이 기회가 될 경우 사용 가능한 데이터나 여분의 데이터를 사용하도록 했다.

Android 13에서는 시스템이 앱이 다음번에 실행될 시점을 판단하려고 시도하며, 이 추정을 바탕으로 미리 가져오기 작업을 실행한다.

앱은 다음번 앱 실행에 앞서 실행할 모든 작업을 미리 가져오기 작업으로 처리하도록 시도 해야 한다.

배터리 리소스 사용률

"배터리 리소스 사용률" 도입 - 시스템이 기기 배터리 수명을 더 효율족으로 관리 할 수 있는 다양한 방법을 제공한다.

시스템 Restricted: "앱 대기 버킷"에 앱을 배치하는 경우에 적용되는 규칙 업데이트
사용자가 앱의 "백그라운드 배터리 사용"을 Restricted 상태로 설정한 경우 앱이 실행할 수 있는 작업에 관한 새로운 제한사항
장기 실행 "포그라운드 서비스"에 관해 사용자에게 경고하는 새로운 시스템 알림

우선순위가 높은 Firebase 클라우드 메시징(FCM) 할당량

Firebase 클라우드 메시징(FCM) 할당량을 업데이트하여 우선순위가 높은 FCM에 응답하여 알림을 표시하는 앱을 위해 우선순위가 높은 FCM 전송의 안정성을 개선한다.

Android 13(API 수준 33)에서 변경된 사항

앱 대기 버킷이 앱에서 사용할 수 있는 우선순위가 높은 FCM 수를 더 이상 결정하지 않는다.
우선순위가 높은 FCM 할당량은 우선순위가 높은 FCM에 대한 응답으로 사용자에게 표시되는 알림 수에 비례하여 확장된다.
이전 버전 Android에서와 같이 할당량을 초과하는 우선순위가 높은 FCM은 일반 우선순위로 다운그레이드된다.

FCM에 대한 응답으로 포그라운드 서비스(FGS)가 시작될 때 RemoveMessage.getPriority()의 결과를 확인하여 PRIORITY_HIGH인지 확인하고 잠재적인 "ForegroundServiceStartNotAllowedException" 예외를 처리하는 것이 좋다.

애플리케이션에서 우선순위가 높은 FCM에 대한 응답으로 알림을 항상 게시하지는 않는 경우 알림을 유발하는 메시지가 다운그레이드되지 않도록 이러한 FCM의 우선순위를 Normal로 변경하는 것이 좋다.

개인 정보 보호

알림 런타임 권한

- Android 13에서 새로운 런타임 알림 권한인 POST_NOTIFICATIONS 도입

<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>

- 앱은 포그라운드 서비스를 실행하기 위해 POST_NOTIFICATIONS 권한을 요청할 필요가 없다.

- 그러나 이전 버전의 Android에서와 마찬가지로 앱은 포그라운드 서비스를 시작할 때 알림을 포함해야 한다.

클립보드 민감 콘텐츠 숨기기

- 사용자가 민감한 콘텐츠를 클립보드에 복사할 수 있도록 허용하는 앱은 플래그를 추가하여 클립보드 콘텐츠 미리 보기에서 해당 콘텐츠를 숨겨야 한다.

- 앱에서 사용자가 민감한 콘텐츠(예: 비밀번호나 신용카드 정보)를 클립보드에 복사할 수 있도록 허용하는 경우 ClipboardManager#setPrimaryClip()을 호출하기 전에 ClipData의 ClipDescription에 Flag를 추가해야 한다.

- 이 Flag를 추가하면 민감한 콘텐츠가 콘텐츠 미리보기에 표시되지 않는다.

// When your app targets API level 33 or higher
clipData.apply {
    description.extras = PersistableBundle().apply {
        putBoolean(ClipDescription.EXTRA_IS_SENSITIVE, true)
    }
}

// If your app targets a lower API level
clipData.apply {
    description.extras = PersistableBundle().apply {
        putBoolean("android.content.extra.IS_SENSITIVE", true)
    }
}

보안

Intent Filter가 일치하지 않는 Intent 차단

- 앱이 Android 13 이상을 타겟팅하는 다른 앱의 내보낸 구성요소로 인텐트를 전송하면 이 인텐트는 수신 앱의 <intent-filter> 요소와 일치하는 경우에만 전달, 일치하지 않는 인텐트는 차단된다.

- 앱이 Android 13 이상으로 업그레이드되면 다른 앱에서 전송된 모든 인텐트가 앱에서 선언된 <intent-filter> 요소와 일치하는 경우에만 앱의 내보낸 구성요소로 전달된다.

공유 사용자 ID Migration

- 앱이 지원 중단된 android:sharedUserId 속성을 사용하고 이 속성의 기능에 더 이상 종속되지 않는 경우

- 다음 코드 스니펫과 android:sharedUserMaxSdkVersion 속성을 32로 설정할 수 있다.

android:sharedUserId="SHARED_PACKAGE_NAME"
android:sharedUserMaxSdkVersion="32"

이 속성은 앱이 공유 사용자 ID를 더 이상 사용하지 않는다고 시스템에 알림 앱이android:sharedUserMaxSdkVersion을 선언하고 Android 13 이상을 실행하는 기기에 새로 설치된 경우 앱은 android:sharedUserId가 정의된 적이 없는 것처럼 작동. 업데이트된 앱은 여전히 기존 공유 사용자 ID를 사용합니다.

Targeting Android 13, Sdk 33 App

근처 Wi-Fi 기기의 새 런타임 권한

- Android 13 이상을 타겟팅하고 Wi-Fi Api를 사용하는 경우, ACCESS_FINE_LOCATION 대신 NEARBY_WIFI_DEVICES를 요청 (앱이 Wi-Fi API에서 물리적 위치 정보를 얻는 것이 아니어야 함)

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" 
				android:maxSdkVersion="32" />

<uses-permission android:name="android.permission.NEARBY_WIFI_DEVICES" 
				android:usesPermissionFlags="neverForLocation" />

새로운 Media 권한

- READ_EXTERAL_STORAGE deprecated / 다른 앱에서 만든 미디어 파일에 액세스 해야 하는 경우 다음과 같은 세분화된 미디어 권한을 하나 이상 요청해야 한다.

미디어 유형	요청 권한
이미지 및 사진	READ_MEDIA_IMAGES
동영상	READ_MEDIA_VIDEO
오디오 파일	READ_MEDIA_AUDIO

백그라운드에서 생체 신호 센서를 사용하려면 새로운 권한이 필요

- Android 13에서는 심박수, 체온, 혈중 산소 농도 등과 같은 생체 신호 센서에 '사용 중인 동안' 액세스라는 개념이 도입

- 앱이 Android 13을 타겟팅하며 백그라운드에서 실행되는 동안 생체 신호 센서 정보에 액세스해야 하는 경우 기존 BODY_SENSORS 권한에 더해 새로운 BODY_SENSORS_BACKGROUND 권한을 선언해야 한다.

<uses-permission android:name="android.permission.BODY_SENSORS" />
<uses-permission android:name="android.permission.BODY_SENSORS_BACKGROUND" />

Android 13
https://developer.android.com/about/versions/13/behavior-changes-all?hl=ko
https://developer.android.com/about/versions/13/behavior-changes-13?hl=ko

Technote

동력전달장치 - 2D,3D

조립품 단면

3D 도면

조립품

분해도

별도 사용 부품

2D 도면

BCD / 홀 종류,표기법,깊이

BCD (Bolt Cricle Diameter)

BCD에 공차가 없는 이유

홀의 종류

홀의 표기법

홀의 깊이값

카운터보어, 카운터 싱킹 기호

카운터 보어 예시

카운터 싱킹 예시

모양공차(선/면 윤곽도), ○,◎, U 모디파이어

윤곽도

면 윤곽도

선 윤곽도

선 윤곽도, 면 윤곽도 차이

데이텀이 있는 경우 윤곽도

윤곽도 기호

○ (All Around)

◎ (All Over)

All Around와 All Over 차이점

U 모디파이어

윤곽도와 다른 모양공차의 차이점

흔들림 공차(원 흔들림, 온 흔들림)

흔들림 공차

자세공차(평행도,직각도,경사도), 기본치수

자세공차의 특징

예시

직각도(수직도)

평행도

경사도

경사도를 그냥 각도+공차로 관리하면 안될까?

기본치수

기본치수 필요유무

MMB

기존 RFS 개념

AT MMC 개념

AT MMB

MMC vs MMB 비교

AT MMC, AT MMB 동시 사용

데이텀 시프팅이란?

모양공차 (진원도,원통도,진직도,평면도), 모양공차 오답 케이스

진원도, 원통도

진원도, 원통도 예시

진원도에서 축이 틀어진 예시

진직도

진직도 Type1 - 표면 위 각 직선 성분의 편차를 관리

진직도 Type1에서 가능한 최악의 케이스

진직도 Type2 : FOS(Feature Of Size)의 치수에 붙인 경우

진직도는 "단위길이당" 컨트롤이 가능

평면도

평면도 주의사항

단위면적당 요건 부여 가능

모양공차 오답 케이스

CASE 1 : 모양공차에 데이텀 사용 X

CASE 2 : 모양공차 Ø 사용 불가 (진직도 Type 2 예외)

CASE 3 : 기본치수 사용 불가

CASE 4 : 치수공차역 > 기하공차역 관계(진직도, 평면도 Type2 예외)

전부 수정한 도면

모양공차 간단 정리

사용 이유

위치공차 (위치도,동심도,대칭도)

기본치수 없이 쓰이는 위치도

CASE 1 : 형상에 수직 한 데이텀인 경우

CASE 2 : A 형상의 축에 B 형상의 축을 맞추는 경우

CASE 3 : A 형상의 중심평면에 B 형상의 중심평면을 맞추는 경우

위치공차가 이상하게 명시되어 있어 도면 해석이 안 되는 경우

CASE 1 : FOS가 아닌 경우

CASE 2 : 기하공차의 위치가 잘못된 경우

CASE 3 : FOS가 아닌 경우

CASE 4 : 데이텀의 위치가 잘못된 경우

CASE 5 : 기본치수 오사용

동심도, 대칭도

축, 중심평면

CASE 2 : 모양공차 Ø 사용 불가
(진직도 Type 2 예외)

CASE 4 : 치수공차역 > 기하공차역 관계
(진직도, 평면도 Type2 예외)