[Feat] #655 - RequestContainer 구현 및 Extension

[L-j-h-c]

🔥Pull requests

⛳️ 작업한 브랜치

• feature/#655

👷 작업한 내용

• RequestContainer 구현
• NoticeAPI에 시험적으로 적용

참고사항

1. Request가 발생할 때마다 싱글톤 객체에 저장하고 새로운 리퀘스트가 오면 cancel()해주는 방식입니다.

2. Plugin의 onfail에서 네트워크 에러 팝업이 떠서, errorCode가 6인 경우(cancel())에 네트워크 팝업을 띄우지 않도록 했습니다.

3. NoticeAPI에는 시험적으로 적용했고, throttle 주석처리 해놓았습니다.

4. Container 적용과는 관련 없이, 스파커 활동과 안내 탭을 번갈아 이동하는 경우 무한스크롤로 인한 인덱스 에러가 존재하는 것 같습니다.

10/13 추가 수정사항

1. RequestContainer의 Container를 Dictionary 형태로 전환했고, 특정 API가 어떤 분류에 속하는지 구분할 수 있도록 열거형을 생성했습니다. APIType에 관련된 request들만 cancel하는 식으로 효율성을 높였습니다.

2. 보관함에서는 3가지 API가 동시 호출되기 때문에 단순히 API에서 doCleanRequest()를 하는 경우 마지막에 호출된 API로 인해 앞에 호출된 2가지(진행중, 실패) API의 request가 cancel되어버리는 문제가 생겨서 이를 분기처리했습니다.

3. 위 2번의 과정에서 알게된 사실은 dispatchGroup을 사용하는 경우 group.enter의 시점에 여러 비동기 처리가 다른 스레드를 통해서 동시에 진행된다는 것입니다. 따라서 첫 번째 API에만 doCleanRequest를 하면 2의 문제가 해결되겠다는 예상과 달리 첫 번째 API에서 doCleanRequest가 수행되기 전에 다른 비동기 블록이 먼저 request로 만들어져서 group이 leave를 하지 못하는 상황이 생겼습니다. 따라서 Ongoing API의 Completion에 나머지 API 블록을 집어 넣었고, 그랬더니 무한 로딩(leave를 하지 못하는 상황)이 해결되었습니다.

4. 기존 알림 뷰에서 스파커 활동의 컬렉션뷰를 스크롤 시켜 놓고 안내 탭으로 갔다가 다시 스파커 활동 탭을 누르면 인덱스 에러가 생겼습니다. 살펴보니 셀이 생성되는 와중에 list가 removeAll()되어 생기는 문제였고, API Completion 시점에 removeAll하는 것으로 문제를 해결했습니다.

📟 관련 이슈

• Resolved: #655