আপলোডডেটাপ্রোভাইডার

fun close(): Unit

যখন কোনো অনুরোধের জন্য এই UploadDataProvider-টির আর প্রয়োজন হয় না, তখন এটিকে কল করা হয়, যাতে রিসোর্স (যেমন একটি ফাইল) স্পষ্টভাবে মুক্ত করা যায়।

abstract fun getLength(): Long

যদি এটি একটি নন-চাঙ্কড আপলোড হয়, তাহলে আপলোডটির দৈর্ঘ্য ফেরত দেবে। যদি এটি একটি চাঙ্কড আপলোড হয়, তবে অবশ্যই -১ ফেরত দিতে হবে।

abstract fun read(uploadDataSink: UploadDataSink!, byteBuffer: ByteBuffer!): Unit

byteBuffer এ আপলোড ডেটা পড়ে। কাজটি সম্পন্ন হলে, বাফারের অবস্থান পঠিত বাইটগুলোর শেষ পর্যন্ত আপডেট করা হয়। বাফারের সীমা পরিবর্তন করা হয় না। এই মেথডের প্রতিটি কলের পরে অবশ্যই uploadDataSink কে একবার কল করতে হবে, যা সিনক্রোনাস বা অ্যাসিনক্রোনাস হতে পারে: সফল হলে onReadSucceeded এবং ব্যর্থ হলে onReadError । এই মেথডগুলোর কোনো একটি কল না করা পর্যন্ত read বা rewind কোনোটিই কল করা হবে না। এমনকি যদি সংশ্লিষ্ট UrlRequest বাতিলও করা হয়, রিসোর্স নিরাপদে মুক্ত করার আগে এই দুটির কোনো একটি অবশ্যই কল করতে হবে। একটি এক্সেপশন থ্রো করলেও রিসোর্স মুক্ত হয়ে যাবে এবং রিকোয়েস্টটি এররড হয়ে যাবে।

দ্রষ্টব্য: নন-চাঙ্কড আপলোডের ক্ষেত্রে, onReadSucceeded শুধুমাত্র তখনই কল করা উচিত যখন রিড সফল হয় এবং byteBuffer এ অন্তত এক বাইট রিড করা হয়। চাঙ্কড আপলোডের ক্ষেত্রে (যেখানে ডেটার আকার অজানা), একটি খালি বাইট বাফার থাকা সত্ত্বেও শেষ চাঙ্কটির জন্য onReadSucceeded কল করার অনুমতি আছে।

abstract fun rewind(uploadDataSink: UploadDataSink!): Unit

আপলোড ডেটাকে একেবারে শুরুতে ফিরিয়ে নিয়ে যায়। এটি তখন কার্যকর হয় যখন ক্রোনেট চায় যে আপলোড ডেটা প্রোভাইডারটি এমন একটি সমতুল্য অবস্থায় থাকুক, যেন read এখনও কল করা হয়নি।

অপারেশনটি যে শেষ হয়েছে তা বোঝানোর জন্য, এই ফাংশনের ইমপ্লিমেন্টেশনগুলোকে সফলতার জন্য onRewindSucceeded , অথবা ব্যর্থতার ক্ষেত্রে onRewindError কল করতে হবে। এমনকি সংশ্লিষ্ট UrlRequest বাতিল করা হলেও, রিসোর্সগুলো নিরাপদে মুক্ত করার আগে দুটির মধ্যে একটি অবশ্যই কল করতে হবে। মেথড থেকে একটি এক্সেপশন থ্রো করা onRewindError কল করার সমতুল্য। যদি রিওয়াইন্ডিং সমর্থিত না হয় (উদাহরণস্বরূপ, যদি কোনো ওয়ান-অফ স্ট্রিম থেকে রিড করা হয়), তবে এটি অবিলম্বে onRewindError কল করবে।

বাস্তবায়নকারী নিরাপদে ধরে নিতে পারেন যে, পূর্ববর্তী অনুচ্ছেদে বর্ণিত পদ্ধতি অনুযায়ী, রিওয়াইন্ডিং শেষ হওয়ার বিষয়ে সিঙ্ককে অবহিত না করা পর্যন্ত কোনো read বা যুগপৎ rewind কল জারি করা হবে না।

বডি একাধিকবার আপলোড করার প্রয়োজন হলে ক্রোনেট অভ্যন্তরীণভাবে এই পদ্ধতিটি ব্যবহার করে। এটি বিভিন্ন পরিস্থিতিতে ঘটতে পারে, যেমন রিডাইরেক্ট অনুসরণ করার সময়, অথবা টাইমআউট বা নেটওয়ার্ক সংযোগ বিচ্ছিন্ন হওয়ার পর অনুরোধ পুনরায় চেষ্টা করার সময়। উল্লেখ্য যে, যদিও রিওয়াইন্ডিং প্রয়োগ করা সাধারণত ঐচ্ছিক, কিন্তু যে অনুরোধগুলির জন্য এটির প্রয়োজন হয়, সেগুলি রিওয়াইন্ডিং প্রয়োগ করা না হলে ব্যর্থ হবে।