1. 메인 화면 구성
(1) EditTextView로 검색창을 구현
(2) 검색 버튼을 구현
(1) 리싸이클러뷰로 구현
(2) 임의의 값으로 리싸이클러 뷰의 아이템이 잘 출력되는지 확인
(fork, star, title, subtitle)
2. API 연결
(1) ApplicationClass 생성
(2) RetrofitUtil 생성
(3) RepositoryAPI 생성
(1) RepositoryService 생성
(2) BaseCallback 생성
(1) Repository 생성
(2) Repositories 생성
(1) 결과가 없을 때
(1-1) 어댑터에는 이미 불러온 리스트가 있고, 더 불러올게 없을 경우
(1-2) 원래 없었던 경우 (처음 검색했을 때, 한 번 검색한 상태에서 또 검색했을 때) 모두의 경우
> (1)의 경우 한번이라도 이 곳에 오게되면, addOnScrollListener는 컨트롤 할 수 없더라도,
불필요한 레트로핏 통신으로 가는 것은 막아줘야합니다. (stopThisIsEnd를 true로 바꿔줍니다.)
(2) 결과가 있다.
(2-1) 첫번째로 검색할 때 > 검색
(2-2) 한번 검색을 하고, 다른 것을 검색할 때 > 기존의 것을 지우고, 새로 검색
(2-3) 첫번째 검색 후 추가로 볼 때
(1) UI가 디스플레이 영역을 넘어서거나 어색한 부분들을 교정합니다.
3. Coroutine, DI, mvvm 패턴
(1) retrofit의 Callback 방식 > 코루틴의 runCatching 방식
(1) repository 모듈 생성
(2) viewModel 모듈 생성
(3) network 모듈 생성
(1) MainViewModel을 생성
(2) DiffUtil을 사용하여 분기별로 다른 notify가 아닌 일괄적인 submit
(3) 리사이클러뷰 데이터 바인딩
(4) 메인 액티비티 검색 결과 없을 시 텍스트, 검색 결과 수 데이터 바인딩
4. 프로젝트 구조 변경
(1) di는 따로 구성
(2) ui(presentation) - data(data) - entity(domain)의 패키지로 나눔
(1) 모델 및 엔티티 생성
(2) 엔티티 entity 패키지로 이동
(1) data패키지에 Mapper 생성
5. 주석 및 코멘트
6. 에러 및 이슈
6-1. 엔티티, 모델의 null 처리 관련 에러 이슈 : 이슈 해결 링크
위의 이슈 단계에서 [2. API 연결] 와 [7. 마무리] 가 실질적인 두 가지 완료 시점입니다.
(클릭 후 해당 branch에서 클론하시면, 다른 시점의 코드들을 받아 보실 수 있습니다.)
-두 가지 시점은 구현된 코드는 다소 다르지만, 결과는 같습니다. 한 가지 차이점이 있다면, [2. API 연결] 시점에서는 디스플레이의 회전이 작동하면, 데이터가 휘발되는 반면, [7. 마무리] 시점에서는 liveData가 사용되어 회전이 작동해도 데이터가 휘발되어 보여지지는 않는 것입니다.-
[2. API 연결] 의 완료 시점에서는
리사이클러뷰에 notifyDataSetChanged()와 notifyItemRangeInserted()를 이용하여 검색이 이루어지는 경우의 분기에 따라 결과를 notify 하는 방법이 다릅니다. 이슈와 코드 주석에서 보시면 알 수 있듯이 갈라지는 다양한 상황과 로딩이 사라질 때 예상할 수 없는 예외를 고려하여 구현했습니다.
하지만 기능 구현에만 집중하여 비동기 작업이나, 패턴들의 적용은 최소한으로 구현했습니다.
[7. 마무리] 의 완료 시점에서는
비동기 작업을 위한 코루틴 적용, mvvm 패턴 적용 그리고 네트워크 통신을 위한 레트로핏이나, viewModel 등을 모듈화 하여 koin으로 DI 했습니다. mvvm 패턴에서는 mvvm 패턴의 시초인 마이크로소프트의 .NET에서 말하는 "View와 ViewModel의 어떠한 명시적인 커플링 없는 구현"에는 실패했지만, mvvm화와 데이터 바인딩을 통한 메인 액티비티의 역할을 줄이고 세분화 하여 유지 보수의 효율이라는 장점은 챙길 수 있는 코드 구조로 구현했습니다.
또한 이런 과정에서 notifyXXX()를 사용하는 대신 diffUtil을 사용하여 일괄적인 submit으로 어댑터의 MutableList의 변화에 대한 효율을 증가시켰습니다. 그리고 프로젝트 구조를 바꾸면서 모델과 엔티티를 분리해서 맵핑 시켜주는 레파지토리 패턴을 적용하여, 최대한 백엔드의 변화를 프론트엔드에서 알 수 없게 하여 , 프로젝트를 변화에 이전 완료 시점보다 잘 적응할 수 있는 구조로 구현했습니다.
