zoo_dev zoo_dev

문제 retrofit과 room은 지금의 안드로이드에 있어서 정말 없어서 안 될 존재이다. 다른 라이브러리들도 많지만 이정도로 간결하게 쓸 수있으면서도 대중적으로 쓰는 안드로이드 라이브러리는 없을 것 같다. 보통 두 라이브러리를 같이 쓰는 경우에 room으로 retrofit의 통신 결과를 캐싱하는 경우가 많은데, 이 때 조금 불편한 문제가 발생한다. 바로 정확히 같은 데이터를 저장함에도 entity와 dto클래스를 따로 생성해줘야 한다는 점이다. 심지어 나는 기상청 api대응 문제로 2개의 entity와 1개의 dto를 만들어서 정확히 같은 데이터를 갖는 클래스가 3개나 있다. 같은 데이터를 받지만 라이브러리에 대응하기 위해 위와 같이 이름만 다른 클래스를 만들어 줘야 했다. 그래서 domain단으로 넘..

*본 글을 과거에 작성한 글을 저장하기 위해 작성됐습니다(23.05.23) 문제 새벽 1시 쯤 테스트겸 앱을 실행시켜보고 있는데 아예 단기 예보가 조회되지 않는 상황이 발생했다. 아직 네트워킹 타임아웃에 대한 처리를 해주지않아서 앱이 종료되면 타임아웃이고 앱이 종료되지 않으면 그 외 문제이다.(이유는 모르겠지만 기상청 api를 안드로이드에서 호출하면 타임아웃이 생각보다 꽤 자주 발생한다. 웹에서 주소로 직접 접속하면 안그런데ㅠ) 그래서 unitTest에서 확인해봤는데 바로 문제를 찾아냈다. 현재 날짜와 시간이 20230523 0131 이라면 20230522 2300 이 되어야 하는데 20230523 2300이 됐다. baseTime이 하루전이 되지 않은게 문제 였는데 그 이유는 다음과 같았다. 이유 빨간..

*본 글을 과거에 작성한 글을 저장하기 위해 작성됐습니다(23.05.10) 단기예보의 baseTime은 위 사진과 같다. 그래서 어떤 시간을 넣든 그 시간보다 이전이면서 가장 큰 기준시를 반환해야 하는데, 그 메소드를 일반적인 when이나 if로 구간을 구분하지 않고 수식으로 구현하고 싶었다. 여러 자잘한 과정들이 있었지만 결론적으로는 다음과 같은 식을 적용하면 어떤 시간을 넣든 알맞은 기준시가 반환된다. 현재시간 = now (((now-10분)+1시간)/3시간)의 몫 * 3시간 - 1시간 한글을 사용해서 간략하게 적은 이유는 시간 데이터를 currentMillis(Long)를 활용할수도 있고 HHmm을 정수로 변환해서 Int형으로 계산할 수 도 있고, 여러 방법들이 있기 때문이다. 문제: current..

*본 글을 과거에 작성한 글을 저장하기 위해 작성됐습니다(23.05.09) 위 메서드는 기상청api 호출을 위해 현재시간을 기준으로 baseDate를 반환하는 메서드이다. n시 40분이후부터 n시의 데이터를 호출할 수 있는데 그러면 23시와 0시사이가 문제이기에 2340~0039 사이의 시간일때는 날자를 하루 당겨줘야한다. 이를 위해서 해당 사이 시간일때는 한시간을 빼는 방식으로 날짜를 하루전으로 당겼는데, 그 조건을 확인하는 메서드가 잘못된것을 깨달았다. 사진에서 커서가 있는 부분의 minuteDateFormat 메서드는 항상 “00mm” 형식의 문자열을 반환하기 때문에 해당 조건문은 항상 맞게되서 getBaseTime이 23시일때는 항상 한시간을 빼는 연산을 거쳤다. 다행이 하루를 빼는것이 아니라 한..

*본 글을 과거에 작성한 글을 저장하기 위해 작성됐습니다(23.05.04) 기상청api는 데이터주는 방식이 정말 참신하다^^ 초단기예보(6시간)은 정보의 타입별로 정렬되어 있고 단기예보(약4일뒤까지)는 시간별로 정렬되어 있다. 왜 그런지는 이해가 대강 가지만 그러면 데이터를 정리하는데 하나의 로직으로 쉽게 해결이 안된다.. 간단히 표현하자면 초단기 1700 A, 1800 A, 1900 A, 1700 B, 1800 B, 1900 B, 1700 C, 1800 C, 1900 C 단기 1700 A, 1700 B, 1700 C, 1800 A, 1800 B, 1800 C, 1900 A, 1900 B, 1900 C 물론 타입별 측정값과 다른 정보도 있지만 대략적으로는 이렇다. 그래서 하나의 로직으로 두 데이터를 쉽게..