⚙ [기술 검토] Paging3

이미지 데이터를 모두 로드하기에는 다운로드, 로딩 속도가 느림. 리스트 형태를 효율적으로 관리할 필요를 느낌.

❌ 문제점

• 대량 데이터를 한 번에 가져오면 데이터 비용이 증가하고, 네트워크와 메모리 부하로 인하여 앱 성능 저하
• 리스트의 이미지 로딩 속도가 느려 사용자 경험이 저하됨.

🔍 해결방안 리서칭

Pagination 직접 구현

LazyList를 활용하여 스크롤이 끝에 도달했을 때마다 Loading Indicator를 띄우고 추가적인 데이터 로드 수행

장점

• 단순하고 유연한 데이터 바인딩이 가능
• Compose UI와 자연스럽게 결합

단점

• 복잡한 페이징 로직이나 상태 관리를 수동으로 구현해야 됨.
• 스크롤 포지션에 대한 관리가 필요함.

Paging3

대량의 데이터를 효율적으로 관리하고 페이징 작업을 간단히 처리할 수 있도록 설계된 라이브러리. RecyclerView, Compose와 최적화 되어있다.

장점

• 필요한 데이터만 로드하고, 기존 데이터를 메로리에서 제거하여 메모리 사용량이 적음.
• LoadState를 통한 자동화된 상태 관리를 통하여 로딩 인디케이터, 에러 메시지 등을 쉽게 처리
• 같은 페이지를 중복해서 요청하는 경우 자동으로 앞선 요청의 결과값만을 사용

단점

• PagingSource, Pager, LoadState, RemoteMediator 등의 구조를 이해하여야 해서 러닝 커브가 있다.
• 간단한 데이터 소스에서는 오히려 복잡해질 수 있다.

✅ Paging3 사용 결정

직접 구현하는 방식보다 Paging3를 사용하는 것으로 결정. 그 이유는 다음과 같다.

• LoadState, RemoteMediator를 통하여 State 관리를 쉽게 할 수 있음.
• ViewModel에서 PagingSource, RemoteMediator와 한 번 연결하여 자동으로 Pagination을 하도록 한다.
• 초기 설정만 잘 해놓으면 이후의 구현이 쉬워진다.

따라서 저희는 Paging3를 사용하여 대량의 데이터를 리스트에 보여주는 것을 구현하기로 결정.

2️⃣ Paging3 State 관리

(추가 되었습니다)

Paging3를 사용하면서 기본적인 데이터 연결만 하여 1차 MVP를 배포하였었고, 이후에 서비스 완성도를 높이기 위하여 Success, Failure, Loading에 관련된 UI 처리를 진행할 필요가 존재.

아직 Paging3를 제대로 이해하지 못하고 사용하고 있었을 때 따로 UiState를 만들어 관리하려고 했으나 앞서 Paging3를 찾아보면서 LoadResult, LoadState가 존재했다는 것을 기억하고 해당 기술에 대한 검토를 다시 시작하였다.

팀원들과 함께 Paging을 사용하면서 State에 따른 처리를 하는 방법을 더 서칭하였다.

• PagingSource에서 서버, database에서 값을 가져오면서 에러가 뜨면 LoadResult.Error()를 반환한다.
• 초기화가 필요하다면 LoadResult.Invalid를 사용한다.
• 성공이 이루어지면 LoadResult.Page()를 반환한다.

UI에서...

• LoadState.reresh, append, prepend, hasError를 통해서 각 상태에 대한 처리를 진행한다.
• Footer에서 append를 사용하여 추가 요청에 대한 처리를 진행
• 전체적인 UI는 refresh를 사용하여 Loading, NotLoading, Error로 로딩, 성공, 실패 처리에 대하여 분기처리를 통하여 UI를 처리한다.

Paging3는 자체적으로 위와 같이 다양한 상태 관리에 대하여 값들을 반환하기 때문에 이를 Flow로 받고, collectAsLazyPagingItems를 사용하여 loadState를 받아서 관리한다면 쉽게 state에 대한 처리를 진행할 수 있었다.