이런 종류의 논리 처리에 객체 파괴 및 재구성이 포함되는 경우 객체 참조는 매핑하면 안 되지만 데이터 값은 매핑되어야 합니다. 네트워크 처리를 Activity 또는 RecylerView에 직접 배치하지 마세요. 다운로드의 경우 다운로드 스레드를 관리하기 위해 백그라운드 서비스를 시작한 다음 서비스가 활동과 통신하도록 하는 것이 가장 좋습니다. 이렇게 하면 개체가 대응할 수 있는지 여부만 신경 쓸 필요가 없습니다. 서비스에서 귀하에게 보고한 다운로드 진행 상황에 대한 정보입니다. 서비스와 활동 간의 상호 작용에 관해서는 인터넷에 튜토리얼과 휠이 너무 많아서 자세히 설명하지 않겠습니다.
시스템 자체 DownloadManager이든 사용자 정의 다운로드 구성 요소이든 파일 다운로드에는 다운로드 ID가 있거나 Uri에 해당합니다. 시스템이 자동으로 DownloadManager 데이터베이스를 전달한다는 점은 언급할 가치가 있습니다. 다운로드 정보를 보관합니다.
이 전제로는 아직 충분하지 않습니다. 이는 DownloadManager의 구체적인 구현과 관련이 있습니다. Query 인터페이스만 제공하는 것 같습니다. 따라서 다운로드 진행 상황을 실시간으로 쿼리하려면 백그라운드 스레드를 생성해야 합니다.
마지막으로 RecyclerView의 ItemView과 ID 또는 Uri의 대응을 어떻게 관리할지 고민해야 합니다.
위 1과 2는 일부 주류 이미지 비동기 로딩 프레임워크(예: github: nostra13/Android-Universal-Image-Loader)를 참조하여 구현할 수 있습니다.
p.s. 너무 복잡하다고 생각하시면 github erehmi/CountDownTask를 참고해주세요. (저는 뻔뻔하게도 제 프로젝트 [페이스 커버]를 추천합니다.)
p.p.s. 전체 목록을 새로 고치기 위해 직접 informDataChanged()를 수행하는 것은 성능이 너무 낮기 때문에 권장되지 않습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
이런 종류의 논리 처리에 객체 파괴 및 재구성이 포함되는 경우 객체 참조는 매핑하면 안 되지만 데이터 값은 매핑되어야 합니다. 네트워크 처리를 Activity 또는 RecylerView에 직접 배치하지 마세요. 다운로드의 경우 다운로드 스레드를 관리하기 위해 백그라운드 서비스를 시작한 다음 서비스가 활동과 통신하도록 하는 것이 가장 좋습니다. 이렇게 하면 개체가 대응할 수 있는지 여부만 신경 쓸 필요가 없습니다. 서비스에서 귀하에게 보고한 다운로드 진행 상황에 대한 정보입니다. 서비스와 활동 간의 상호 작용에 관해서는 인터넷에 튜토리얼과 휠이 너무 많아서 자세히 설명하지 않겠습니다.
이 전제로는 아직 충분하지 않습니다. 이는
DownloadManager의 구체적인 구현과 관련이 있습니다. Query 인터페이스만 제공하는 것 같습니다. 따라서 다운로드 진행 상황을 실시간으로 쿼리하려면 백그라운드 스레드를 생성해야 합니다.마지막으로
RecyclerView의ItemView과 ID 또는 Uri의 대응을 어떻게 관리할지 고민해야 합니다.위 1과 2는 일부 주류 이미지 비동기 로딩 프레임워크(예: github: nostra13/Android-Universal-Image-Loader)를 참조하여 구현할 수 있습니다.
p.s. 너무 복잡하다고 생각하시면 github erehmi/CountDownTask를 참고해주세요. (저는 뻔뻔하게도 제 프로젝트 [페이스 커버]를 추천합니다.)
p.p.s. 전체 목록을 새로 고치기 위해 직접 informDataChanged()를 수행하는 것은 성능이 너무 낮기 때문에 권장되지 않습니다.
이러한 유형의 다운로드 작업에는 서비스를 이용하는 것이 가장 좋습니다