Firebase Storage: یہ کیا ہے، فائل اپ لوڈ اور کلاؤڈ اسٹوریج

Firebase Storage کیا ہے اور یہ کیسے کام کرتا ہے

Firebase Storage ایک کلاؤڈ آبجیکٹ اسٹوریج ہے جو Google Cloud Storage پر بنایا گیا ہے اور Android، iOS اور ویب پلیٹ فارمز کے لیے SDK فراہم کرتا ہے۔ ہر فائل Google Cloud bucket میں ایک آبجیکٹ کے طور پر محفوظ کی جاتی ہے اور فائل سسٹم جیسے راستے سے پتہ کیا جاتا ہے: gs://bucket-name/path/to/file.jpg. ایک فائل 5 TB تک ہو سکتی ہے، جو بغیر پہلے کمپریشن کے کسی بھی میڈیا ڈیٹا کو ذخیرہ کرنے کی اجازت دیتی ہے۔

Firebase Storage کا فن تعمیر کلاسک فولڈر کے درجہ بندی کے بجائے لنکس کا حوالہ ماڈل (gsutil references) استعمال کرتا ہے، حالانکہ SDK ڈویلپر کی سہولت کے لیے ڈائریکٹری انٹرفیس فراہم کرتا ہے۔ طبعی طور پر، تمام آبجیکٹ bucket کے فلیٹ نام کی جگہ میں محفوظ کیے جاتے ہیں، اور ورچوئل فولڈرز راستے کے سابقے استعمال کرکے بنائے جاتے ہیں۔ یہ فائلوں کی تعداد سے قطع نظر لکیری تلاش کی کارکردگی کو یقینی بناتا ہے۔

Google Cloud Storage کے براہ راست استعمال کے مقابلے Firebase Storage کا اہم فائدہ Firebase Authentication اور Security Rules کے ساتھ بلٹ ان انضمام ہے۔ ڈویلپر کو علیحدہ IAM کردار اور سروس اکاؤنٹس ترتیب دینے کی ضرورت نہیں ہے: رسائی کے قواعد Firebase Realtime Database Rules جیسی اعلانیہ زبان میں لکھے جاتے ہیں اور ہر درخواست پر خودکار طور پر لاگو ہوتے ہیں۔

bucket کی ساخت اور فائل کے راستے

Firebase کنسول میں سروس کو فعال کرنے پر ایک Firebase Storage bucket خودکار طور پر بنایا جاتا ہے۔ فائل کا راستہ /فولڈر_کا_نام/فائل_کا_نام پیٹرن کی پیروی کرتا ہے اور اس میں نیسٹڈ سطحیں ہو سکتی ہیں۔ صارفین کے درمیان ڈیٹا کو الگ کرنے کے لیے /users/{userId}/images/{imageId}.jpg اسکیما کے مطابق راستوں کو منظم کرنے کی سفارش کی جاتی ہے۔ یہ ساخت سیکیورٹی قواعد لکھنے کو آسان بناتی ہے کیونکہ راستے میں مالک کا شناخت کنندہ ہوتا ہے۔

یہ سمجھنا ضروری ہے کہ Firebase Storage کلاسیکی معنوں میں کوئی رلیشنل ڈیٹا بیس یا فائل سرور نہیں ہے۔ یہ مکمل فائلوں کو پڑھنے اور لکھنے کے آپریشنز کے لیے بہتر کردہ آبجیکٹ اسٹوریج ہے۔ جزوی فائل اپ ڈیٹ ممکن نہیں ہے: اگر آپ اسی راستے پر دوبارہ اپ لوڈ کرتے ہیں تو پرانی آبجیکٹ نئی سے بدل دی جاتی ہے۔ چھوٹا سٹرکچرڈ ڈیٹا ذخیرہ کرنے کے لیے، Firebase Realtime Database یا Cloud Firestore استعمال کریں۔

Firebase Storage کی قیمتوں اور حدود

Firebase Storage کی قیمت ذخیرہ کردہ ڈیٹا کی مقدار اور آپریشنز کی تعداد پر منحصر ہے۔ مفت منصوبہ (Spark) میں روزانہ 5 GB اسٹوریج، 20,000 رائٹ آپریشنز اور 50,000 ریڈ آپریشنز شامل ہیں۔ ادا شدہ منصوبہ (Blaze) اصل استعمال کی بنیاد پر چارج کرتا ہے: $0.026 فی GB ذخیرہ کردہ ڈیٹا، $0.05 فی 10,000 رائٹ آپریشنز، اور $0.004 فی 10,000 ریڈ آپریشنز۔ باہر جانے والے ٹریفک کے لیے اضافی چارجز لاگو ہوتے ہیں۔

چند ہزار صارفین والی زیادہ تر موبائل ایپلیکیشنز کے لیے، پروٹو ٹائپنگ اور جانچ کے مرحلے میں مفت حد کافی ہے۔ لاکھوں صارفین تک پیمانہ کرتے وقت، بہتر بنائے گئے اپ لوڈ نقطہ نظر اور کلائنٹ سائیڈ کیشنگ کے ساتھ Storage کے اخراجات شاذ و نادر ہی $50–$100 ماہانہ سے تجاوز کرتے ہیں۔

Firebase Storage میں فائلیں کیسے اپ لوڈ کریں

Firebase Storage میں فائل اپ لوڈ کرنا مناسب SDK طریقہ کے ذریعے کیا جاتا ہے، جو اسٹوریج کا راستہ اور فائل ڈیٹا (بائٹ اری، URI، سٹریم یا Bitmap) قبول کرتا ہے۔ SDK خود بخود کنکشن کا انتظام کرتا ہے، بڑے سائز کے لیے فائل کو حصوں میں تقسیم کرتا ہے، اور پیش رفت سے باخبر رہنے کے لیے کال بیک فراہم کرتا ہے۔ اپ لوڈ براہ راست کلائنٹ ڈیوائس سے Google Cloud پر کیا جاتا ہے، آپ کے سرور کو نظرانداز کرتے ہوئے، جو آپ کے اپنے بنیادی ڈھانچے پر بوجھ کم کرتا ہے۔

Android کے لیے، Firebase Storage SDK StorageReference اور UploadTask کلاسز استعمال کرتا ہے۔ StorageReference روٹ پاتھ سے Firebase.storage.reference کے ذریعے بنائی جاتی ہے اور bucket میں ایک مخصوص فائل کی طرف اشارہ کرتی ہے۔ UploadTask پیش رفت، توقف اور مکمل ہونے کے لیے سننے والے واپس کرتا ہے۔ جب کنکشن منقطع ہوتا ہے، UploadTask خود بخود آخری کامیابی سے منتقل کردہ بائٹ سے اپ لوڈ دوبارہ شروع کرتا ہے — اس رویے کو دوبارہ شروع ہونے والا اپ لوڈ کہا جاتا ہے۔

فائل میٹا ڈیٹا (Content-Type، حسب ضرورت فیلڈز) اپ لوڈ شروع کرتے وقت ایک علیحدہ SettableMetadata آبجیکٹ کے طور پر منتقل کیا جاتا ہے۔ براؤزر میں فائلوں کی صحیح نمائش اور CDN کیشنگ کے لیے Content-Type کو صحیح طریقے سے سیٹ کرنا اہم ہے۔ Firebase Storage تمام معیاری MIME اقسام کو سپورٹ کرتا ہے: image/jpeg، image/png، video/mp4، application/pdf اور دیگر۔

اپ لوڈ کے دوران میٹا ڈیٹا کا انتظام

فائل میٹا ڈیٹا میں سسٹم فیلڈز (Content-Type، Cache-Control، Content-Disposition) اور حسب ضرورت کلید-ویلیو جوڑے (customMetadata) شامل ہوتے ہیں۔ سسٹم فیلڈز ڈاؤن لوڈ کے دوران HTTP ہیڈر کو کنٹرول کرتے ہیں۔ مثال کے طور پر، Cache-Control: public, max-age=31536000 ایک سال کے لیے رسپانس کیشنگ کو فعال کرتا ہے، جو ایک ہی فائل کے بار بار ڈاؤن لوڈ کو نمایاں طور پر کم کرتا ہے اور ٹریفک بچاتا ہے۔

حسب ضرورت میٹا ڈیٹا Firestore میں علیحدہ مجموعہ بنائے بغیر فائل کے بارے میں اضافی معلومات منتقل کرنے کے لیے آسان ہے۔ مثال کے طور پر، uploadedBy فیلڈ اپ لوڈ کرنے والے صارف کا userId محفوظ کر سکتا ہے، جو صارف کے تیار کردہ مواد والی گیلریوں کے نفاذ کو آسان بناتا ہے۔ حسب ضرورت میٹا ڈیٹا Security Rules کے ذریعے علیحدہ طور پر محفوظ نہیں ہے — ان تک رسائی فائل کی طرح کے قواعد کے ذریعے منظم کی جاتی ہے۔

متعدد اپ لوڈ اور بیچ پروسیسنگ

جب آپ کو بیک وقت متعدد فائلیں اپ لوڈ کرنے کی ضرورت ہو (مثال کے طور پر، گیلری سے تصاویر)، تو بغیر حدود کے متوازی میں آزاد UploadTasks چلانے کی سفارش نہیں کی جاتی ہے۔ موبائل آلات پر، 3–5 سے زیادہ فائلوں کا متوازی اپ لوڈ نیٹ ورک سٹیک کو اوورلوڈ کرتا ہے اور ٹائم آؤٹ کا سبب بنتا ہے۔ بہترین حکمت عملی 3 کی ہم وقتی حد یا مشترکہ پیش رفت بار ڈسپلے کے ساتھ ترتیب وار اپ لوڈ استعمال کرنا ہے۔

اپ لوڈ کے بعد سرور سائیڈ پروسیسنگ (تھمب نیل جنریشن، کمپریشن، مواد کی نگرانی) کے لیے، Firebase Cloud Functions ٹریگر استعمال کریں: functions.storage.object().onFinalize(). یہ فنکشن ہر فائل اپ لوڈ مکمل ہونے کے بعد خود بخود کال ہوتا ہے اور پروسیس شدہ کاپی کو مختلف راستے پر محفوظ کر سکتا ہے۔ مزید تفصیلات عام استعمال کے معاملات کے سیکشن میں ہیں۔

فائل ڈاؤن لوڈ اور لنک کا انتظام

Firebase Storage دو ڈاؤن لوڈ طریقوں کو سپورٹ کرتا ہے: SDK کے ذریعے براہ راست ڈاؤن لوڈ (بائٹ اری یا مقامی فائل حاصل کرنا) اور HTTP رسائی کے لیے براہ راست ڈاؤن لوڈ URL حاصل کرنا۔ براہ راست URL ImageView میں، WebView میں تصاویر ظاہر کرنے یا صارف کو لنک فراہم کرنے کے لیے استعمال کیا جا سکتا ہے۔ ڈاؤن لوڈ URL ایک سیکیورٹی ٹوکن کے ساتھ بنایا جاتا ہے جسے Firebase کنسول میں منسوخ کیا جا سکتا ہے۔

storageReference.downloadUrl طریقہ https://firebasestorage.googleapis.com/v0/b/{bucket}/o/{path}?alt=media&token={token} فارمیٹ میں URL واپس کرتا ہے۔ سیکیورٹی ٹوکن جنریشن کے دوران خود بخود URL میں شامل ہو جاتا ہے، لہٰذا لنک کو غیر مجاز رسائی کے خطرے کے بغیر تیسرے فریق (مثال کے طور پر، میسنجر میں) کے ساتھ شیئر کیا جا سکتا ہے۔ تاہم، اگر ٹوکن سے سمجھوتہ کیا جاتا ہے، تو اسے Firebase کنسول کے Storage سیکشن کے ذریعے منسوخ کیا جا سکتا ہے — اس کے بعد، اس ٹوکن والے تمام لنکس کام کرنا بند کر دیں گے۔

کلائنٹ پر ڈاؤن لوڈ کردہ فائلوں کو کیش کرنے کے لیے، ETag میکانزم یا MD5 ہیش کے ساتھ مقامی اسٹوریج استعمال کریں۔ Firebase Storage فائل کی درخواست کرتے وقت HTTP ہیڈر ETag واپس کرتا ہے، جس کا مقامی طور پر محفوظ کردہ قدر سے موازنہ کرکے غیر تبدیل شدہ فائلوں کو دوبارہ ڈاؤن لوڈ کرنے سے بچا جا سکتا ہے۔ یہ خاص طور پر میڈیا مواد کے لیے مفید ہے: اوتار، کور امیجز، پیش نظارہ — وہ فائلیں جو شاذ و نادر ہی اپ ڈیٹ ہوتی ہیں لیکن اکثر درخواست کی جاتی ہیں۔

براہ راست ڈاؤن لوڈ URL اور ان کی حفاظت

ٹوکن کے ساتھ ڈاؤن لوڈ URL غیر تصدیق شدہ صارفین کو فائل تک رسائی فراہم کرنے کا بنیادی طریقہ ہے (مثال کے طور پر، نیوز فیڈ میں تصویر ظاہر کرنا)۔ ٹوکن ایک بار بنایا جاتا ہے اور منسوخ ہونے تک تبدیل نہیں ہوتا، لہٰذا URL کو ڈیٹا بیس میں محفوظ کیا جا سکتا ہے (مثال کے طور پر، Firestore میں avatarUrl فیلڈ کے ساتھ)۔ جب اوتار تبدیل کیا جاتا ہے، پرانی فائل حذف کر دی جاتی ہے اور نیا URL بنا کر محفوظ کر لیا جاتا ہے۔

یاد رکھنا ضروری ہے: ڈاؤن لوڈ URL کا ہونا Security Rules کو منسوخ نہیں کرتا۔ اگر کوئی قاعدہ فائل پڑھنے سے انکار کرتا ہے، تو downloadUrl طریقہ اجازت سے انکار کی خرابی واپس کرے گا۔ اس کا مطلب ہے کہ فائل کا صحیح راستہ جاننے کے باوجود، ایک غیر تصدیق شدہ کلائنٹ لنک حاصل نہیں کر سکتا۔ ایک بار حاصل کرنے کے بعد، URL Security Rules کو نظرانداز کرتے ہوئے HTTP رسائی فراہم کرتا ہے — لہٰذا ٹوکن ڈاؤن لوڈ لنک کا واحد تحفظ ہے۔

کیشنگ اور ETag کے ساتھ کام کرنا

HTTP ETag ایک فائل ورژن شناخت کنندہ ہے جو مواد میں تبدیلی کے ساتھ بدلتا ہے۔ Firebase Storage GET رسپانس میں خود بخود ETag واپس کرتا ہے۔ کلائنٹ ایپلیکیشن ETag کو مقامی کیش میں محفوظ کر سکتی ہے اور بعد کی درخواستوں پر If-None-Match: {etag} ہیڈر بھیج سکتی ہے۔ اگر فائل تبدیل نہیں ہوئی ہے، تو سرور ڈیٹا منتقل کیے بغیر 304 Not Modified سٹیٹس واپس کرتا ہے۔

موبائل ایپلیکیشن میں ذہین کیشنگ لاگو کرنے کے لیے، مقامی فائل سسٹم اور ڈیٹا بیس (مثال کے طور پر، راستہ-ETag جوڑے محفوظ کرنے کے لیے Room) کا مجموعہ استعمال کریں۔ فائل لوڈ کرتے وقت، ڈیٹا بیس سے ETag چیک کریں: اگر یہ سرور سے مماثل ہے تو مقامی کاپی استعمال کریں۔ یہ نقطہ نظر سٹیٹک میڈیا فائلوں کے لیے ٹریفک کو 60–80% تک کم کرتا ہے اور گیلریوں والی اسکرین لوڈنگ کو تیز کرتا ہے۔

Firebase Storage کے لیے سیکیورٹی قواعد

Security Rules Firebase Storage میں فائلوں تک رسائی کے کنٹرول کے لیے ایک اعلانیہ زبان ہے، جو Firebase سرور کی طرف سے عمل میں لائی جاتی ہے۔ ہر قاعدہ bucket کے راستے سے منسلک ہوتا ہے اور ان شرائط کی وضاحت کرتا ہے جن کے تحت پڑھنے یا لکھنے کی کارروائی کی اجازت ہے۔ قواعد ہر درخواست سے پہلے چیک کیے جاتے ہیں اور کلائنٹ کوڈ کے ذریعے نظرانداز نہیں کیے جا سکتے۔ یہ غیر مجاز رسائی کے خلاف ڈیٹا کے دفاع کی واحد لائن ہے۔

بنیادی قاعدہ ہے صرف تصدیق شدہ صارفین کے لیے رسائی: allow read, write: if request.auth != null. یہ قاعدہ اس بات کی ضمانت دیتا ہے کہ صرف لاگ ان صارفین ہی فائلیں پڑھ اور لکھ سکتے ہیں۔ مزید باریک ترتیب کے لیے، request.auth.uid متغیر استعمال کیا جاتا ہے، جس میں موجودہ صارف کا شناخت کنندہ ہوتا ہے۔ uid کا فائل راستے کے حصے سے موازنہ کرکے، آپ ہر صارف کے لیے ایک الگ تھلگ اسٹوریج بنا سکتے ہیں۔

اہم: Security Rules مواد کی توثیق کا طریقہ کار نہیں ہے۔ اگر آپ کو فائل کی قسم، سائز یا نقصان دہ کوڈ کی موجودگی چیک کرنے کی ضرورت ہے، تو request.resource قاعدہ استعمال کریں، جس میں اپ لوڈ کردہ فائل کا میٹا ڈیٹا ہوتا ہے۔ دستیاب خصوصیات ہیں request.resource.size (فائل کا سائز)، request.resource.contentType (MIME قسم) اور request.resource.md5Hash (چیکسم)۔ تاہم، مکمل مواد کی توثیق Cloud Functions کے ذریعے سرور کی طرف سے کی جاتی ہے۔

صارف کے تیار کردہ مواد کے لیے قواعد کی مثال

صارف کے اوتار اور گیلری والی ایپلیکیشن کے لیے عام ترتیب مندرجہ ذیل ہے۔ صارف صرف اپنی ڈائریکٹری /users/{userId}/ میں لکھ سکتا ہے، لیکن اس ڈائریکٹری میں کسی بھی فائل کو پڑھ سکتا ہے (عوامی گیلری)۔ فائل کا سائز 5 MB تک محدود ہے اور قسم صرف تصاویر تک محدود ہے۔ قواعد کا یہ مجموعہ سوشل اور UGC ایپلیکیشنز میں Firebase Storage کے 80% استعمال کے معاملات کا احاطہ کرتا ہے۔

سیکیورٹی ٹپ: پورے bucket کے لیے allow read, write: if true قاعدہ کبھی استعمال نہ کریں۔ یہ آپ کے projectId کو جاننے والے کسی بھی شخص کے لیے تحریری رسائی کھول دیتا ہے۔ 2025 میں، غیر محفوظ Firebase buckets پر حملے بڑھ گئے ہیں، جہاں حملہ آور غیر قانونی مواد ذخیرہ کرنے کے لیے کھلی رسائی استعمال کرتے ہیں۔ ہمیشہ کم سے کم ضروری اجازتوں سے شروع کریں اور انہیں صرف واضح ضرورت پر بڑھائیں۔

Cloud Functions کے ذریعے مواد کی توثیق

Cloud Functions ٹریگر functions.storage.object().onFinalize() اپ لوڈ کے بعد مواد کی توثیق کرنے کی اجازت دیتا ہے۔ اگر فائل توثیق میں ناکام ہوتی ہے (مثال کے طور پر، وائرس پر مشتمل ہو یا پلیٹ فارم کے قواعد کی خلاف ورزی کرتی ہو)، تو فنکشن اسے حذف کر سکتا ہے اور صارف کو مطلع کر سکتا ہے۔ یہ اصل مواد کو چیک کرنے کا واحد طریقہ ہے، کیونکہ Security Rules صرف میٹا ڈیٹا (سائز اور MIME قسم) دیکھتی ہے، بائنری ڈیٹا نہیں۔

توثیق کی مثال: ایک Node.js فنکشن اپ لوڈ کردہ فائل کو عارضی ڈائریکٹری میں ڈاؤن لوڈ کرتا ہے، اسے اینٹی وائرس ڈیٹیکٹر (مثال کے طور پر، ClamAV) کے ذریعے چلاتا ہے، اور اگر خطرہ پایا جاتا ہے — فائل کو حذف کرتا ہے اور Firebase Crashlytics میں ایونٹ لاگ کرتا ہے۔ فنکشن کے عمل درآمد کا وقت 540 سیکنڈ تک محدود ہے، جو 50 MB تک کی فائلوں کی جانچ کے لیے کافی ہے۔

Kotlin میں Firebase Storage کے لیے کوڈ مثالیں

آئیے Kotlin کا استعمال کرتے ہوئے Android ایپلیکیشن میں Firebase Storage انضمام کی عملی مثالوں کو دیکھتے ہیں۔ کوڈ معیاری Firebase SDK کلاسز استعمال کرتا ہے اور ڈیوائس گیلری سے تصویر اپ لوڈ کرنا، پیش رفت سے باخبر رہنے کے ساتھ فائل ڈاؤن لوڈ کرنا اور ڈاؤن لوڈ URL حاصل کرنا ظاہر کرتا ہے۔ تمام مثالوں میں خرابی کا انتظام اور کنکشن ضائع ہونے پر کام معطل کرنا شامل ہے۔

کوڈ استعمال کرنے سے پہلے، یقینی بنائیں کہ build.gradle فائل میں انحصار implementation(platform("com.google.firebase:firebase-bom:33.0.0")) اور implementation("com.google.firebase:firebase-storage") شامل ہے۔ Firebase BOM خود بخود تمام SDKs کے ہم آہنگ ورژن منتخب کرتا ہے، ورژن تنازعات کو ختم کرتا ہے۔

گیلری سے تصویر اپ لوڈ کرنا

پہلی مثال Intent ACTION_GET_CONTENT کے ذریعے صارف کے ذریعے منتخب کردہ فائل اپ لوڈ کو ظاہر کرتی ہے۔ حاصل کردہ فائل کا URI Firebase Storage SDK کو بھیجا جاتا ہے، جو اس URI سے ڈیٹا پڑھتا ہے۔ putFile طریقہ URI قبول کرتا ہے اور UploadTask واپس کرتا ہے — ایک آبجیکٹ جس کے ذریعے آپ پیش رفت کو ٹریک کر سکتے ہیں، اپ لوڈ کو روک سکتے ہیں اور دوبارہ شروع کر سکتے ہیں۔

val storageRef = Firebase.storage.reference
val imageRef = storageRef.child(
    "users/${auth.uid}/profile.jpg"
)

val metadata = SettableMetadata().apply {
    contentType = "image/jpeg"
    customMetadata = mapOf(
        "uploadedBy" to auth.uid!!
    )
}

imageRef.putFile(imageUri, metadata)
    .addOnSuccessListener {
        Log.d("Storage", "فائل اپ لوڈ ہوگئی")
    }
    .addOnFailureListener { e ->
        Log.e("Storage", "خرابی: ${e.message}")
    }

اوپر دی گئی مثال میں، storageRef متغیر پروجیکٹ bucket کا جڑ حوالہ ہے۔ child طریقہ ایک راستہ سٹرنگ قبول کرتا ہے اور ایک مخصوص فائل کی طرف اشارہ کرنے والی StorageReference واپس کرتا ہے۔ اگر مخصوص راستے پر پہلے سے کوئی فائل موجود ہے، تو اسے اوور رائٹ کر دیا جائے گا۔ contentType اور customMetadata SettableMetadata آبجیکٹ کے ذریعے منتقل کیے جاتے ہیں، جو putFile درخواست سے منسلک ہوتا ہے۔

پیش رفت کے ساتھ فائل ڈاؤن لوڈ کرنا

دوسری مثال ImageView میں ڈسپلے کے لیے بائٹ اری حاصل کرکے فائل ڈاؤن لوڈ کو ظاہر کرتی ہے۔ getBytes(maxSize) طریقہ پوری فائل کو میموری میں لوڈ کرتا ہے۔ 10 MB سے بڑی فائلوں کے لیے، getFile(localUri) استعمال کریں — یہ مواد کو RAM میں محفوظ کیے بغیر براہ راست مقامی فائل میں محفوظ کرتا ہے، OutOfMemoryError کو روکتا ہے۔

val islandRef = storageRef.child("images/island.jpg")

val ONE_MEGABYTE: Long = 1024 * 1024
islandRef.getBytes(ONE_MEGABYTE)
    .addOnSuccessListener { bytes ->
        imageView.setImageBitmap(
            BitmapFactory.decodeByteArray(
                bytes, 0, bytes.size
            )
        )
    }
    .addOnFailureListener { e ->
        Log.e("Storage", "اپ لوڈ ناکام: ${e.message}")
    }

ڈاؤن لوڈ URL حاصل کرنے کے لیے (مثال کے طور پر، Firestore میں لنک محفوظ کرنے کے لیے)، downloadUrl طریقہ استعمال کریں:

islandRef.downloadUrl.addOnSuccessListener { uri ->
    Log.d("Storage", "ڈاؤن لوڈ URL: $uri")
    // Firestore میں uri.toString() محفوظ کریں
}

ٹپ: ڈاؤن لوڈ URL ایک بار بنایا جاتا ہے اور منسوخ ہونے تک مستحکم رہتا ہے۔ فائل کو ہر بار ظاہر کرتے وقت درخواست کرنے کے بجائے، پہلے اپ لوڈ پر اسے ڈیٹا بیس میں محفوظ کریں۔ اس سے Firebase Storage کو درخواستوں کی تعداد کم ہوتی ہے اور UI کی کارکردگی بہتر ہوتی ہے۔

Firebase Storage کے عام استعمال کے معاملات

Firebase Storage موبائل ایپلیکیشنز میں کسی بھی صارف اور سسٹم فائلوں کو ذخیرہ کرنے کے لیے استعمال ہوتا ہے۔ سب سے عام منظرناموں میں اوتار اور پروفائل تصاویر، مواد کی فیڈ میں تصاویر، ویڈیو اور آڈیو فائلیں، صارفین کے درمیان اشتراک کے لیے دستاویزات (PDF, DOCX) اور چھوٹے پیمانے پر ڈیٹا بیک اپ شامل ہیں۔ ان تمام صورتوں میں، Storage میٹا ڈیٹا اور لنکس ذخیرہ کرنے کے لیے Firestore کے ساتھ مل کر ایک خصوصی فائل اسٹوریج کے طور پر کام کرتا ہے۔

سوشل ایپلیکیشنز سب سے عام استعمال کا معاملہ ہیں۔ ہر صارف ایک اوتار، پوسٹ تصاویر اور میڈیا فائلیں اپ لوڈ کرتا ہے۔ راستے کی ساخت /users/{uid}/posts/{postId}/image.jpg ڈیٹا کو الگ کرتی ہے اور Security Rules کو آسان بناتی ہے۔ جب کسی صارف کو حذف کیا جاتا ہے، تو Cloud Function تمام صارف ڈائریکٹریوں میں جا کر اسٹوریج صاف کر سکتی ہے۔ Firebase بلاگ (2025) کے مطابق، یہ پیٹرن 70% پروڈکشن Firebase پروجیکٹس میں استعمال ہوتا ہے۔

ای کامرس ایپلیکیشنز پروڈکٹ تصاویر، کیٹلاگ اور ہدایات کے ساتھ PDF فائلیں ذخیرہ کرنے کے لیے Firebase Storage استعمال کرتی ہیں۔ اس صورت میں، فائل تک رسائی عام طور پر عوامی ہوتی ہے (تصدیق کے بغیر پڑھنا)، جبکہ تحریری رسائی اجازت کی جانچ کے ساتھ Cloud Functions کے ذریعے منتظمین تک محدود ہوتی ہے۔ پروڈکٹ ڈاؤن لوڈ URLs دیگر پروڈکٹ ڈیٹا کے ساتھ Firestore میں محفوظ کیے جاتے ہیں، جس سے Storage کو اضافی درخواستوں کے بغیر تصاویر ظاہر کی جا سکتی ہیں۔

میسنجر اور چیٹس گفتگو میں بھیجی گئی تصاویر اور صوتی پیغامات Firebase Storage میں محفوظ کرتے ہیں۔ راستہ /chats/{chatId}/messages/{messageId}.jpg کے طور پر تشکیل دیا جاتا ہے۔ پڑھنے کی رسائی صرف چیٹ شرکاء تک محدود ہے، جس کی تصدیق Firestore ڈیٹا کا استعمال کرتے ہوئے Security Rules کے ذریعے کی جاتی ہے۔ یہ ان چند منظرناموں میں سے ایک ہے جہاں ایک قاعدہ کسی دوسری Firebase سروس سے ڈیٹا پڑھتا ہے: allow read: if firestore.exists(/databases/(default)/documents/chats/{chatId}/members/{request.auth.uid}).