3주차 개발일지

7/15

고객사와의 회의를 통해 요구사항을 분석하였습니다.

특히 개발 관련으로 중요한 안건인 데이터 & 기기 등에 대한 요구 사항을 전달하였습니다.

7/16

alarm manager + broadcast 방식으로 변경

• 근거
  • 근로자가 사용할 워치의 경우 배터리 소모율이 어느정도인가가 중요한 성능지표이다.
  • 그러나 기존 방식인 foreground service는 배터리 소모율이 큰 방식이다.
  • alarm manager 또는 workmanager을 이용하여 배터리 소모율을 줄일 수 있다.
    • 그러나 현재 최소 주기가 15분 미만인 프로젝트의 상황을 고려하여 alarm manager을 통해 데이터를 주기마다 가져오는 것으로 결정하였다.

alarm manager + broadcast 방식으로 변경 후 위치 데이터 가져오는 작업 완료

• 변경 근거
  • 근로자가 사용할 워치의 경우 배터리 소모율이 어느정도인가가 중요한 성능지표!
  • 그러나 기존 방식인 foreground service는 배터리 소모율이 큰 방식이다.
  • alarm manager 또는 workmanager을 이용하여 배터리 소모율을 줄일 수 있다.
    • 그러나 현재 최소 주기가 15분 미만인 프로젝트의 상황을 고려하여 alarm manager을 통해 데이터를 주기마다 가져오는 것으로 결정

개발 에러 해결

• 동료가 질문한 에러를 같이 해결했습니다

코드 구조 개편

개발이 진행되면서 기존 구조로는 가독성측면에서 좋지 못하였고, 개발 시 코드를 구분해서 작성하기에 불편함이 있었습니다.

따라서 구조를 아래와 같이 수정하여 ui, data, service처리를 각각 구분하기 쉽게 하였습니다!

7/17

alarm manager + broadcase receiver

• 기존 foreground service를 통해 백그라운드에서 데이터를 측정하는 방식은 배터리 소모율이 많은 편이다.
• 따라서 alarm manager 를 통해 주기적으로 (최소 1분) 위치를 받아올 수 있도록 구현하였음
• 그러나 요구 사항이 변경됨
  • 최소 주기 1초 ~ 최대 60초까지
• 따라서 alarm manager방식으로 구현할 수 없음
• 기존의 foreground service 방식으로 시도
  • 배터리 효율성을 위한 방식 구현 필요

위치 정보가 받아와지지 않는 문제

• 애뮬레이터 테스트와 기기로 테스트할 때 결과가 다르다
• 애뮬레이터의 경우 위치값의 로그 & 화면 상에 주기적으로 업데이트된다.
• 그러나 실제 기기에서 실행할 경우 위치값이 null로 찍힌다.

추정 원인

• 실 기기상에서는 위치값을 받아오는 과정에 문제가 있다.
• 애뮬레이터의 주소값은 사전에 등록하므로, 문제가 없을 것

추후 변경 사항

현재 LocationManager 방식으로 위치를 가져오는 것 → FusedLocation을 이용하도록 변경

• 이유 : 배터리 효율성

정리

• 고객사 측의 요구사항이 변경되면서 alarm manager 방식으로 구현불가함을 확인함에 따라 기존의 foreground service 방식으로 재수정
• 🚨문제 : 애뮬레이터에서는 정상 작동하지만 워치에서 실행 시 주소 값이 받아와지지 않는 문제 발생
  • 예상 원인
    • 권한 오류
    • 주소를 가져오는 코드 상의 오류
    • 코드 구조에 따라 적용안됨
  • 위와 같이 원인을 정리해서 테스트 진행하였습니다.
  • 확인 결과 현재 서비스와 연결되어있는 Home activity가 아닌 다른 액티비티에서는 위치 값이 제대로 받아지고 있었습니다.
  • 따라서 현재 구조에 문제가 있다고 판단하였고, 구조 수정을 진행 중입니다.