[feat] 필터 검색 / 캐시 적용

[otter66]

화면 이름

• 필터 검색

기능 설명

• 앱 실행 중 중복되는 주소 목록 요청을 하지 않도록 한다.
• 주소 목록을 불러올 때 서버의 응답이 늦어져 ui 업데이트가 늦어지는 것에 영향을 적게 받도록 한다.

필요 태스크

• localDatabase를 사용한 캐시 적용
• 앱 실행 중 주소 조회 요청은 캐싱되기 전에만 일어나도록 한다.
• repository에서 localDatabase의 값을 우선적으로 사용하도록 한다.

---

검색 결과를 필터링하기 위해 주소 목록을 불러올 때 네트워크에 따라 서버로부터 받아오는 작업이 느린 경우가 종종 발생합니다.
변경이 적은 값을 매번 서버로부터 받아오는 것, 사용자가 느끼기에 작업이 오래 걸리는 것은 문제라고 생각해 캐시를 적용하기로 하였습니다.

캐싱 정책

• 사용자가 검색 필터링 중 주소 필터링을 사용하고자 할 때 전체 주소 목록을 서버에 요청해 local database에 저장합니다.
  • 항상 요청하는 것이 아닌, 데이터가 없거나 서버로부터 받아온 값이 31일 이상 경과되었을 경우 요청합니다.
  • 이 과정에서 사용자에게 데이터 제공이 늦어지는 문제를 완화하기 위해 단일 조회를 통해 사용자에게 전달합니다.
    (전체 조회는 따로 일어납니다.)

고민한 구현 방법

• 조회할 때마다 조회한 데이터를 추가시킨다.
  • 이 경우, 값이 변경되었을 때 저장된 데이터 중 변경이 필요한 값을 알 수 없다. 알기 위해서는 결국 서버의 데이터를 전체 조회 해야한다.
• 1회 조회가 일어날 때 모두 업데이트 시킨다.
  • 이 경우, 불필요하게 많은 요청이 발생할 수 있지만, 값의 업데이트와 관리가 용이하다. (=> api 추가 요청으로 해당 문제 해결)
  • 불필요하게 많은 요청이 있으므로 이에 대비하기 위해 업데이트 날짜를 기록한다. 30일 이상 지났을 경우 서버에 재요청 한다.
• 앱이 실행될 때 전체 요청해 저장해둔다.
  • 주소를 조회하는 것은 주소를 조회할 때에만 필요하다고 생각하여 좋지 않은 방법이라고 생각합니다.
  • 또한, 캐싱해야 할 데이터가 늘어날 때 무작정 앱 실행 시점에 캐시 저장 기능을 수행한다면, 앱 성능에 좋지 않은 영향을 미칠 것 같습니다.

Room

Database

• exportSchema는 권장사항에 따라 true로 설정하였습니다. (공식문서)
  어디에 쓰는 것인고.. 생각해보니 필드 정의(엔티티, 스키마)가 바뀌었을 때 쓰이는 것일까요? 찾아보도록 하겠습니다!

참고자료

https://developer.android.com/training/data-storage/room
https://developer.android.com/reference/androidx/room/Room
https://developer.android.com/reference/androidx/room/Database
https://developer.android.com/training/data-storage/room/testing-db#test
https://developer.android.com/reference/androidx/room/Insert#getOnConflict()