ارائه دهنده داده آپلود

public void close()

زمانی فراخوانی می‌شود که این UploadDataProvider دیگر توسط یک درخواست مورد نیاز نباشد، به طوری که منابع (مانند یک فایل) بتوانند به طور صریح آزاد شوند.

public abstract long getLength()

اگر این یک آپلود غیر قطعه‌بندی شده باشد، طول آپلود را برمی‌گرداند. اگر این یک آپلود قطعه‌بندی شده باشد، همیشه باید -۱ را برگرداند.

public abstract void read(UploadDataSink uploadDataSink, ByteBuffer byteBuffer)

خواندن، داده‌ها را در byteBuffer آپلود می‌کند. پس از اتمام، موقعیت بافر تا انتهای بایت‌های خوانده شده به‌روزرسانی می‌شود. محدودیت بافر تغییر نمی‌کند. هر فراخوانی این متد باید پس از یک فراخوانی واحد، چه همزمان و چه غیرهمزمان، برای uploadDataSink انجام شود: onReadSucceeded در صورت موفقیت یا onReadError در صورت شکست. تا زمانی که یکی از این متدها یا دیگری فراخوانی نشود، هیچ یک از متدهای read یا rewind فراخوانی نخواهند شد. حتی اگر UrlRequest مرتبط لغو شود، یکی از آنها باید قبل از اینکه منابع بتوانند با خیال راحت آزاد شوند، فراخوانی شود. ایجاد یک استثنا همچنین منجر به آزاد شدن منابع و خطا در درخواست می‌شود.

نکته: برای آپلودهای غیر قطعه‌بندی‌شده، onReadSucceeded باید تنها زمانی فراخوانی شود که خواندن با موفقیت انجام شده باشد و حداقل یک بایت در byteBuffer خوانده شده باشد. برای آپلودهای قطعه‌بندی‌شده (اندازه داده‌ها ناشناخته است)، فراخوانی onReadSucceeded برای آخرین قطعه با یک بایت بافر خالی مجاز است.

public abstract void rewind(UploadDataSink uploadDataSink)

داده‌های آپلود را به ابتدا برمی‌گرداند. زمانی فراخوانی می‌شود که Cronet از ارائه‌دهنده‌ی داده‌های آپلود بخواهد در وضعیتی معادل با حالتی باشد که انگار read هنوز فراخوانی نشده است.

برای اعلام پایان عملیات، پیاده‌سازی‌های این تابع باید برای نشان دادن موفقیت، تابع onRewindSucceeded و در صورت شکست، onRewindError را فراخوانی کنند. حتی اگر UrlRequest مربوطه لغو شود، یکی از این دو باید قبل از آزادسازی ایمن منابع فراخوانی شوند. ایجاد یک استثنا از این متد معادل فراخوانی onRewindError است. اگر از قابلیت rewind پشتیبانی نشود (برای مثال، اگر از یک جریان یک‌باره خوانده شود)، این تابع باید بلافاصله onRewindError فراخوانی کند.

پیاده‌سازی‌کننده می‌تواند با اطمینان فرض کند که نه read و نه فراخوانی همزمان rewind ، تا زمانی که به گره چاه اطلاع دهد که برگرداندن تمام شده است، همانطور که در پاراگراف قبلی توضیح داده شد، صادر نخواهد شد.

این روش به صورت داخلی توسط Cronet استفاده می‌شود اگر نیاز باشد بدنه چندین بار آپلود شود. این می‌تواند در موقعیت‌های مختلفی رخ دهد، به عنوان مثال هنگام دنبال کردن تغییر مسیرها، یا هنگام تلاش مجدد برای درخواست‌ها پس از یک وقفه زمانی یا قطع شبکه. توجه داشته باشید که اگرچه پیاده‌سازی rewinding عموماً اختیاری است، درخواست‌هایی که در نهایت به آن نیاز دارند، مگر اینکه rewinding پیاده‌سازی شود، با شکست مواجه خواهند شد.