აპლიკაციის მიერ მოთხოვნის რიგში დაყენების შემდეგ გადაცემას DownloadManager ფლობს. მისი საჯარო Request API გვაწვდის სათაურებს, დანიშნულების პარამეტრებსა და ქსელურ შეზღუდვებს, მაგრამ არ აქვს პროქსის საბოლოო წერტილის დამაყენებელი თითო მოთხოვნისთვის.

Proxy-Authorization-ის დამატება addRequestHeader-ის მეშვეობით არ ცვლის პროქსის ჰოსტისა და პორტის არჩევანს. ცალკე HTTP კლიენტის ობიექტის კონფიგურაცია ასევე არ ცვლის უკვე DownloadManager-ისთვის გადაცემულ მოთხოვნას.

თუ ჩამოტვირთვა უნდა მიჰყვეს მოწყობილობის ან ქსელის მხარდაჭერილ პროქსის პოლიტიკას, გამოიყენეთ ეს პოლიტიკა და გაითვალისწინეთ სერვისის რეალური მარშრუტი. თუ აპლიკაციამ ამ ერთი გადაცემისთვის სხვა პროქსი უნდა აირჩიოს, შეინარჩუნეთ გადაცემა აპლიკაციის საკუთარ კლიენტში დოკუმენტირებული პროქსის ინტერფეისით, მაგალითად Proxy ობიექტით გახსნილი URL კავშირი.

ეს არჩევანი ასევე გადასცემს პასუხისმგებლობას ჩამოტვირთვის სასიცოცხლო ციკლზე. შეინარჩუნეთ საჭირო ფონური დაგეგმვა, პროგრესი, საცავთან მუშაობა და აღდგენის ქცევა, ნაცვლად იმისა, რომ სისტემის მიერ მართული ჩამოტვირთვა შეცვალოთ უკვალოდ მოთხოვნით ეკრანის დროებით სასიცოცხლო ციკლში.

დაკავშირებული სტატიები