UploadDataProvider

fun close(): Unit

इस तरीके को तब कॉल किया जाता है, जब किसी अनुरोध के लिए इस UploadDataProvider की ज़रूरत नहीं होती है. इससे संसाधनों (जैसे कि कोई फ़ाइल) को साफ़ तौर पर रिलीज़ किया जा सकता है.

abstract fun getLength(): Long

अगर यह नॉन-चंक्ड अपलोड है, तो अपलोड की लंबाई दिखाता है. अगर यह एक बार में कई हिस्सों में अपलोड किया गया डेटा है, तो हमेशा -1 वैल्यू दिखाता है.

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

byteBuffer में अपलोड किए गए डेटा को पढ़ता है. यह प्रोसेस पूरी होने के बाद, बफ़र की पोज़िशन को पढ़े गए बाइट के आखिर में अपडेट कर दिया जाता है. बफ़र की सीमा में कोई बदलाव नहीं किया गया है. इस तरीके के हर कॉल के बाद, uploadDataSink को एक कॉल करना ज़रूरी है. यह कॉल सिंक्रोनस या एसिंक्रोनस हो सकता है: onReadSucceeded कॉल तब किया जाता है, जब कॉल सफल हो जाता है. वहीं, onReadError कॉल तब किया जाता है, जब कॉल पूरा नहीं होता. इनमें से किसी एक तरीके या दूसरे तरीके को कॉल किए जाने तक, न तो read को कॉल किया जाएगा और न ही rewind को. अगर इससे जुड़ा UrlRequest रद्द कर दिया जाता है, तो भी संसाधनों को सुरक्षित तरीके से रिलीज़ करने से पहले, इनमें से किसी एक को कॉल करना ज़रूरी है. अपवाद होने पर, संसाधन भी खाली हो जाएंगे और अनुरोध में गड़बड़ी होगी.

ध्यान दें: बिना चंक किए गए अपलोड के लिए, onReadSucceeded को सिर्फ़ तब कॉल किया जाना चाहिए, जब पढ़ने की प्रोसेस पूरी हो गई हो और कम से कम एक बाइट को byteBuffer में पढ़ा गया हो. अगर डेटा को कई हिस्सों में अपलोड किया जा रहा है (डेटा का साइज़ पता नहीं है), तो आखिरी हिस्से के लिए onReadSucceeded को कॉल किया जा सकता है. इसके लिए, बाइट बफ़र को खाली छोड़ना होगा.

abstract fun rewind(uploadDataSink: UploadDataSink!): Unit

यह कुकी, अपलोड किए गए डेटा को शुरुआत में वापस ले जाती है. इस फ़ंक्शन को तब शुरू किया जाता है, जब Cronet को अपलोड डेटा प्रोवाइडर को ऐसी स्थिति में रखना होता है जैसे कि read को कभी कॉल नहीं किया गया था.

कार्रवाई पूरी होने का सिग्नल देने के लिए, इस फ़ंक्शन को लागू करने वाले लोगों को onRewindSucceeded को कॉल करके यह बताना होगा कि कार्रवाई पूरी हो गई है. अगर कार्रवाई पूरी नहीं होती है, तो उन्हें onRewindError को कॉल करना होगा. अगर इससे जुड़ा UrlRequest रद्द कर दिया जाता है, तो भी संसाधनों को सुरक्षित तरीके से रिलीज़ करने से पहले, इनमें से किसी एक को कॉल करना ज़रूरी है. किसी तरीके से अपवाद थ्रो करना, onRewindError को कॉल करने के बराबर है. अगर रिवाइंड करने की सुविधा काम नहीं करती है (उदाहरण के लिए, अगर एक बार की स्ट्रीम से डेटा पढ़ा जा रहा है), तो इसे तुरंत onRewindError को कॉल करना चाहिए.

लागू करने वाला व्यक्ति यह मान सकता है कि जब तक वह सिंक को यह सूचना नहीं देता कि रिवाइंडिंग पूरी हो गई है, तब तक न तो read और न ही एक साथ rewind कॉल जारी किया जाएगा. इसके बारे में पिछले पैराग्राफ़ में बताया गया है.

अगर बॉडी को कई बार अपलोड करना होता है, तो Cronet इस तरीके का इस्तेमाल अंदरूनी तौर पर करता है. ऐसा कई स्थितियों में हो सकता है. उदाहरण के लिए, रीडायरेक्ट फ़ॉलो करते समय या टाइमआउट या नेटवर्क डिसकनेक्ट होने के बाद अनुरोधों को फिर से आज़माते समय. ध्यान दें कि वीडियो को पीछे ले जाने की सुविधा को लागू करना आम तौर पर ज़रूरी नहीं होता. हालांकि, जिन अनुरोधों के लिए यह सुविधा ज़रूरी होती है उन्हें लागू न करने पर, वे अनुरोध पूरे नहीं हो पाएंगे.