[FIX] setOnlyAlertOnce 추가를 통한 소리/진동 제한

[unam98]

📌 개요

closed #273

✨ 작업 내용

• setOnlyAlertOnce(true) 추가를 통해 소리/진동 최초 1회로 제한
• 가독성을 위해 Service 파일 내 함수 배치 조정

✨ PR 포인트

• 당시 service 활용이 처음이라 정확히 알고 개발한 feature가 아니어서 코드적으로 불필요하거나 허술한 부분이 있을 수 있습니다. 혹시 그런 부분이 보인다면 피드백 부탁드립니다! 이 branch로 checkout해서 안드로이드 스튜디오에서 봐주시면 감사하겠습니다! (즉, service를 잘 활용한 것이 맞는지)
• 실 기기로 빌드 돌려서 어떤 문제(1초마다 시스템 알림소리/진동이 계속 울림)였는지 확인 후 지금 pr 올린 branch로 checkout해서 문제가 잘 해결되었는지 테스트 부탁드립니다!
• 공식 문서를 참고하여 당장 눈에 보이는 문제는 해결하긴 했는데 아래 스크린샷 보시면 매초마다 NotificationManager 로그가 계속 찍혀나옵니다. 원래 이게 당연한 건지, 아니면 제가 뭘 잘못해놔서 불필요하게 리소스가 낭비(ex. 함수나 객체 계속 호출)되고 있는지 잘 모르겠습니다. 혹시 이 부분 관련하여 피드백 받아볼 수 있으면 부탁드립니다!
  

https://developer.android.com/training/notify-user/build-notification?hl=ko#Updating

📸 스크린샷/동영상

[leeeha]

노드 서버에서 실행시켜봤는데 저는 NotificationManager 로그는 안 찍히고, TimerService 파일에 있는 아래 코드에 의해 Timber 로그만 찍힙니다! 그리고 알림 소리나 진동은 의도한 대로 1번만 실행돼요!

val timerValue = String.format("%02d:%02d:%02d", hour, minute, second)
Timber.tag("Timer").d(timerValue)

[dongx0915]

고생하셨습니다~!
혹시 NotificationManager 로그는 어느 부분에서 찍은 걸까요?
로그 찍는 코드가 보이지 않는데, 어느 위치인지 알려주시면 감사하겠습니다!

[dongx0915]

해당 PR 내용과는 무관하지만 ForegroundService를 사용하지 않아도 괜찮은가요?
액티비티가 종료 되면 서비스도 같이 종료 되고 있는데, 기획 상으로도 이런 건지 궁금합니다~!

만약 ForegroundService를 써야한다면 서비스 종료 시점, 노티 클릭 했을 때의 동작 등이 수정 되어야할 것 같습니다.

[unam98]

고생하셨습니다~! 혹시 NotificationManager 로그는 어느 부분에서 찍은 걸까요? 로그 찍는 코드가 보이지 않는데, 어느 위치인지 알려주시면 감사하겠습니다!

그 부분 저도 로그 안 찍었는데 같이 나오더라구요. 그래서 시스템에서 자체적으로 나오는 건가 싶었습니다. 안스 버전 차이일 수도 있을 것 같아요. 그동안 플라밍고 쓰다가 최근에 로그인 에러 뜬 게 혹시 버전 문제인가 싶어서 안스 기린으로 업데이트 해봤거든요.

[unam98]

해당 PR 내용과는 무관하지만 ForegroundService를 사용하지 않아도 괜찮은가요? 액티비티가 종료 되면 서비스도 같이 종료 되고 있는데, 기획 상으로도 이런 건지 궁금합니다~!

만약 ForegroundService를 써야한다면 서비스 종료 시점, 노티 클릭 했을 때의 동작 등이 수정 되어야할 것 같습니다.

기존에 팀원들과 같이 논의가 된 부분은 timer를 백그라운드에서 돌리는 것까지만이었습니다. 그런데 이 부분을 구현하다가 service를 활용해 백그라운드에서 돌리면 사용자에게 notification 등으로 명시적인 알림을 반드시 주어야 한다는 내용을 보았고, 이에 제가 추가로 구현해준 부분입니다. (음성 기능은 그냥 심심해서 넣어봄.)

지금 공식문서를 다시 봐보니 포어그라운드 서비스는 알림을 표시해야 합니다.라고 되어있는데 제가 작업하다가 바인드 서비스를 사용하는 방향으로 틀었습니다.

1. 제 시선에서는 바인드 서비스를 쓰면 onServiceConnected를 반드시 구현(override)해야 해서 만약 서비스가 바인드되는 시점에 같이 처리해줘야 할 작업이 있다면 onServiceConnected { } 안에 같이 넣어주면 되니까 관리가 편할 것이라고 생각했습니다.

2. 또 Running 종료 이후에는 Timer를 stop하므로 서비스가 살아있을 이유가 없는데 바인드를 해제해주면 서비스도 같이 소멸시켜줘서 불필요한 리소스 낭비를 막아줄 것이라고 생각했습니다.

3. 마지막으로 '연결'과 '해제'라는 개념이 존재하므로 당시 서비스에 대한 이해가 별로 없었던 입장에서 어떤 것들을 확실히 챙겨줘야 하는지 (서비스를 돌리고 싶을 때 - 연결, 필요 없어졌을 때 - 해제) 직관적으로 파악할 수 있어서 바인드 서비스를 선택했습니다.

"왜 바인드 서비스를 썼는지?"라고 하면 위 3가지가 이유였는데 왜 다른 서비스를 안 썼냐고 하면 당시 바인드 서비스만으로도 구현은 충분하다 생각했어서 타 서비스와 비교해서 어떤 장단점이 있는지까지는 생각 못했습니다.

혹시 바인드 서비스와 비교해서 foreground service를 써야 하는 이유가 있나요? 지금 bind service를 썼을 때 문제되는 부분이 있나요? 궁금합니다! 혹시 제 답변 중에 오개념이 있을 수도 있는데 피드백 주시면 더 공부해보겠습니다 :)

[dongx0915]

혹시 바인드 서비스와 비교해서 foreground service를 써야 하는 이유가 있나요? 지금 bind service를 썼을 때 문제되는 부분이 있나요? 궁금? 합니다! 혹시 제 답변 중에 오개념이 있을 수도 있는데 피드백 주시면 더 공부해보겠습니다 :)

저도 Service에 대해서 자세히 아는 것은 아니지만 bind service가 foreground service보다 우선 순위가 낮다고 알고 있습니다.

일반적으로 러닝을 시작하고 홈을 통해 앱을 내리는 유저가 많을 것 같다고 생각하는데, 이 경우에 Service가 종료되는 이슈가 있을 것 같습니다.

현재 bind service를 사용하면서 RunActivity의 onDestory에서 unbindService를 해주고 있는데, 유저가 홈 버튼을 통해 화면 밖으로 나갔을 때 메모리 부족이나 다른 원인으로 인해 Activity가 소멸 된다면 service도 같이 죽지 않을까요?

꽤 장시간 러닝을 하는 유저도 있을텐데, 앱을 내린채로 장시간 러닝을 하다보면 service가 죽을 것 같습니다.

이걸 바로 테스트 해볼 수 있는 방법은 개발자 모드에서 '활동 유지 안함' 옵션을 켜두면 됩니다!
말 그대로 앱에서 나가는 순간 액티비티가 소멸 되도록 하는 옵션인데, GC 등에 의해서 액티비티가 소멸되는 상황을 재현 할 수 있습니다.

해당 옵션을 켜고 테스트 해보니까, 홈 버튼 눌렀을 떄 바로 Service가 죽어버리네요
기획 상으로 의도된 것이 아니라면 추후 Foreground Service로 바꾸는 것도 논의가 필요해 보입니다!

[unam98]

현재 bind service를 사용하면서 RunActivity의 onDestory에서 unbindService를 해주고 있는데, 유저가 홈 버튼을 통해 화면 밖으로 나갔을 때 메모리 부족이나 다른 원인으로 인해 Activity가 소멸 된다면 service도 같이 죽지 않을까요?

그렇겠네요. 사용자가 직접 activity를 소멸시키는 경우만 생각했었는데 좋은 인사이트네요. foregroundService는 임의로 종료될 일이 없으니 이 부분에선 확실히 더 나은 선택이겠네요. 완전 굿굿 꼼꼼한 피드백 감사합니당