ایپ کا داخلی اسٹوریج ڈیوائس پر ایک مخصوص جگہ ہے جو الگ تھلگ اسٹوریج کے ذریعے صرف ایک مخصوص ایپلیکیشن کے لیے قابل رسائی ہے۔ Android Developers, 2026 کے مطابق، ہر ایپلیکیشن اپنی خود کی سینڈبکس ڈائریکٹری حاصل کرتی ہے جس تک دوسری ایپلیکیشنز براہ راست رسائی نہیں رکھتیں۔ یہ نقطہ نظر ڈیٹا کو غیر مجاز پڑھنے سے بچاتا ہے اور موبائل ڈیوائسز کے ملٹی ٹاسکنگ ماحول میں مستحکم کام کو یقینی بناتا ہے۔
اہم نکات
Context.getFilesDir()، getCacheDir() اور getDataDir() فراہم کرتا ہےNSDocumentDirectory اور NSCachesDirectory استعمال کرتا ہےایپ کا داخلی اسٹوریج ایک الگ تھلگ ڈائریکٹری ہے جسے آپریٹنگ سسٹم انسٹالیشن کے دوران ہر ایپلیکیشن کو مختص کرتا ہے۔ دوسری ایپلیکیشنز اور صارف معیاری فائل مینیجرز کے ذریعے اس ڈائریکٹری تک رسائی حاصل نہیں کر سکتے۔ سسٹم ضمانت دیتا ہے کہ اس ڈائریکٹری کے اندر موجود تمام ڈیٹا ایپلیکیشن ان انسٹال ہونے پر مکمل طور پر حذف کر دیا جائے گا۔ یہ نقطہ نظر موبائل آپریٹنگ سسٹمز کے سیکیورٹی ماڈل کی بنیاد بناتا ہے، پروگراموں کے درمیان خفیہ معلومات کے رساو کو روکتا ہے۔
خارجی اسٹوریج (SD کارڈ) کے برعکس، داخلی اسٹوریج ہمیشہ دستیاب ہوتا ہے اور میڈیا کی موجودگی کی جانچ کی ضرورت نہیں ہوتی۔ جدید ڈیوائسز میں NAND فلیش میموری میں پڑھنے اور لکھنے کی رفتار 800–900 MB/s سیکوینشل ریڈ اور 200–300 MB/s سیکوینشل رائٹ تک پہنچتی ہے، جو SATA SSD کے برابر ہے۔ مختص کردہ علاقے کا سائز ڈیوائس کی کل صلاحیت اور کارخانہ دار کی پالیسی پر منحصر ہے: 64 GB فلیش میموری والے ڈیوائسز پر، ایپ کو ضرورت کے مطابق توسیع کی صلاحیت کے ساتھ 16 سے 64 MB ابتدائی جگہ ملتی ہے۔
داخلی اسٹوریج کا فن تعمیر Android اور iOS کے درمیان مختلف ہوتا ہے۔ Android پر، ہر ایپلیکیشن ایک /data/data/<package_name>/ ڈائریکٹری حاصل کرتی ہے، جس کے اندر سسٹم files/، cache/ اور databases/ ذیلی ڈائریکٹریاں بناتا ہے۔ iOS پر، ایپلیکیشن Documents/، Library/ اور tmp/ ڈائریکٹریوں والے سینڈبکس کنٹینر میں کام کرتی ہے، جن میں سے ہر ایک کا اپنا مقصد اور بیک اپ پالیسی ہے۔
ڈویلپرز کے پاس ایپ کے داخلی اسٹوریج میں ڈیٹا محفوظ کرنے کے کئی طریقے دستیاب ہیں۔ ہر طریقہ ایک مخصوص کام حل کرتا ہے اور ایک خاص قسم کے ڈیٹا کے لیے موزوں ہے۔ صحیح طریقہ کا انتخاب براہ راست ایپلیکیشن کی کارکردگی، ڈیولپمنٹ کی سہولت اور صارف کے ڈیٹا کی حفاظت کو متاثر کرتا ہے۔
سب سے نچلی سطح کا طریقہ فائل ڈائریکٹری میں براہ راست فائل لکھنا ہے۔ ایک ایپ اپنے سینڈبکس کے اندر کوئی بھی فائل اور ڈائریکٹری بنا سکتی ہے۔ یہ طریقہ میڈیا فائلز، صارف کی دستاویزات اور کسی بھی بائنری ڈیٹا کو ذخیرہ کرنے کے لیے موزوں ہے جسے منظم تنظیم کی ضرورت نہیں ہے۔ Android پر، ڈائریکٹری تک رسائی Context.getFilesDir() کال کے ذریعے کی جاتی ہے، جو ایپ کی فائل ڈائریکٹری کا مکمل پاتھ لوٹاتا ہے۔ iOS پر، NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) فنکشن اسی مقصد کو پورا کرتا ہے۔
کلید-قدر جوڑے ذخیرہ کرنے کے لیے، Android SharedPreferences اور Kotlin کوروٹینز اور پروٹوبف پروٹوکول پر مبنی زیادہ جدید DataStore فراہم کرتا ہے۔ SharedPreferences /data/data/<package>/shared_prefs/ ڈائریکٹری کے اندر XML فائل میں ڈیٹا ذخیرہ کرتا ہے۔ سادگی کے باوجود، SharedPreferences میں خامیاں ہیں: ہم وقت تحریر UI تھریڈ میں تاخیر کا سبب بن سکتی ہے، اور قسم کی حفاظت کی کمی غلطیوں کے خطرے کو بڑھاتی ہے۔ DataStore Flow پر مبنی غیر ہم وقت API اور پروٹوبف اسکیما کے ذریعے مکمل قسم کی معاونت فراہم کرکے ان مسائل کو حل کرتا ہے۔
متعلقہ رابطوں والے منظم ڈیٹا کے لیے، SQLite یا Room ریپر بہترین انتخاب ہے۔ ڈیٹابیس databases/ ڈائریکٹری کے اندر ایک فائل میں محفوظ ہوتا ہے اور مکمل SQL سنٹیکس کی حمایت کرتا ہے۔ Room ایک سرکاری Jetpack لائبریری ہے جو قسم سے محفوظ API، خودکار اسکیما مائیگریشن اور کوروٹین سپورٹ فراہم کرتی ہے۔ مناسب انڈیکسنگ کے ساتھ ڈیٹابیس کا سائز نمایاں کارکردگی کے نقصان کے بغیر کئی گیگا بائٹس تک پہنچ سکتا ہے۔ موبائل ڈیوائسز پر SQLite ایک جدید فلیگ شپ پروسیسر پر فی سیکنڈ 50,000 تحریری آپریشنز تک ہینڈل کرتا ہے۔
توثیقی ٹوکنز اور انکرپشن کیز جیسے خفیہ ڈیٹا کو ذخیرہ کرنے کے لیے، Android EncryptedSharedPreferences فراہم کرتا ہے۔ معیاری SharedPreferences پر یہ ریپر AES256-GCM-None استعمال کرکے کیز اور ویلیوز کو خود بخود انکرپٹ کرتا ہے۔ انکرپشن ڈسک پر لکھنے سے پہلے فائل کی سطح پر کی جاتی ہے، اس لیے ڈیوائس تک جسمانی رسائی کے باوجود، حملہ آور مواد نہیں پڑھ سکتا۔ EncryptedSharedPreferences AndroidX Security لائبریری کا حصہ ہے، جس میں پوری فائلوں کو انکرپٹ کرنے کے لیے EncryptedFile بھی شامل ہے۔
Android SDK Context کلاس کے ذریعے داخلی اسٹوریج کے ساتھ کام کرنے کے لیے طریقوں کا ایک سیٹ فراہم کرتا ہے۔ ہر طریقہ ایپ سینڈبکس کے اندر ایک مخصوص سسٹم ڈائریکٹری کا پاتھ لوٹاتا ہے۔ آئیے Kotlin مثال استعمال کرکے بنیادی فائل تحریر اور پڑھنے کے آپریشنز دیکھتے ہیں۔
داخلی فائل ڈائریکٹری کا پاتھ حاصل کرنے کا بنیادی طریقہ context.filesDir ہے۔ یہ ایک File آبجیکٹ لوٹاتا ہے جو /data/data/<package>/files/ ڈائریکٹری کی طرف اشارہ کرتا ہے۔ پہلی رسائی پر، سسٹم خود بخود تمام ضروری پیرنٹ ڈائریکٹریاں بنا دیتا ہے۔ داخلی اسٹوریج میں فائل کے سائز واضح طور پر محدود نہیں ہیں، لیکن ڈیٹا کی کل مقدار /data پارٹیشن پر دستیاب جگہ سے تجاوز نہیں کرنی چاہیے، جو عام طور پر کل فلیش میموری کی گنجائش کا 60–80% ہوتی ہے۔
val context = getApplicationContext()
val file = File(context.filesDir, "notes.txt")
file.writeText("نوٹ کا مواد")
val content = file.readText()
println("پڑھا گیا: $content")
writeText اور readText طریقے Kotlin معیاری لائبریری کے ایکسٹینشن فنکشنز ہیں۔ یہ خود بخود اسٹریمز کے کھلنے اور بند ہونے کا انتظام کرتے ہیں، میموری لیک کو روکتے ہیں۔ بائنری ڈیٹا کے لیے، writeBytes اور readBytes استعمال کریں، جنہیں انکوڈنگ کی ضرورت نہیں اور ByteArray ارے کے ساتھ کام کرتے ہیں۔ بڑی فائلوں کے ساتھ کام کرتے وقت، بفرڈ اسٹریمز استعمال کرنے کی سفارش کی جاتی ہے: ٹیکسٹ کے لیے BufferedReader اور BufferedWriter، بائنری ڈیٹا کے لیے BufferedInputStream اور BufferedOutputStream۔
فائلوں کو درجہ بندی میں ترتیب دینے کے لیے، filesDir کے اندر ذیلی ڈائریکٹریاں بنائیں۔ یہ ڈیٹا کو قسم کے مطابق ڈھانچہ دینے میں مدد کرتا ہے: تصاویر، دستاویزات، ایکسپورٹ فائلیں۔ mkdirs() طریقہ پاتھ میں تمام گمشدہ ڈائریکٹریاں بناتا ہے، بشمول نیسٹڈ ڈائریکٹریاں۔ یقینی بنائیں کہ تخلیق کا آپریشن کامیاب ہوا — طریقہ صرف نئی ڈائریکٹریاں بننے پر true لوٹاتا ہے۔ تخلیق کی ناکامیاں اکثر /data پارٹیشن پر ناکافی جگہ یا فائل سسٹم انوڈز ختم ہونے سے متعلق ہوتی ہیں۔
val imagesDir = File(context.filesDir, "images")
if (imagesDir.mkdirs()) {
println("ڈائریکٹری بنائی گئی")
}
val imageFile = File(imagesDir, "photo.jpg")
imageFile.writeBytes(byteArray)
بڑی فائلیں لکھنے سے پہلے دستیاب جگہ چیک کرنے کے لیے، File.getFreeSpace() یا File.getUsableSpace() استعمال کریں۔ دوسرا طریقہ سیکیورٹی کوٹہ کو مدنظر رکھتے ہوئے موجودہ ایپلیکیشن کے لیے دستیاب بائٹس کی تعداد لوٹاتا ہے — یہ کثیر صارف ڈیوائسز کے سیاق و سباق میں زیادہ درست ہے۔ اگر دستیاب جگہ متوقع فائل سائز سے کم ہے تو صارف کو پیغام دکھائیں اور ڈیوائس سیٹنگز میں جگہ خالی کرنے کا مشورہ دیں۔
iOS پر، ہر ایپلیکیشن ایک الگ تھلگ سینڈبکس کنٹینر میں کام کرتی ہے۔ سسٹم خصوصی entitlements کے بغیر اس کی حدود سے باہر جانے کے لیے API فراہم نہیں کرتا۔ فائل سسٹم کے ساتھ کام کرنے کا بنیادی ٹول Foundation فریم ورک کا FileManager کلاس ہے۔ سینڈبکس کنٹینر میں کئی معیاری ڈائریکٹریاں شامل ہیں، جن میں سے ہر ایک کی اپنی بیک اپ پالیسی ہے۔
Documents ڈائریکٹری صارف کے ڈیٹا کے لیے ہے جو ایپلیکیشن لانچز کے درمیان برقرار رہنا چاہیے اور بیک اپ سے بحال ہونا چاہیے۔ iOS خود بخود اس ڈائریکٹری کو iCloud اور iTunes بیک اپ میں شامل کرتا ہے۔ urls(for:in:) طریقہ درخواست کردہ ڈائریکٹری کے URLs کی ایک ارے لوٹاتا ہے — ارے میں پہلا عنصر بنیادی ہے۔
let fm = FileManager.default
let docs = fm.urls(
for: .documentDirectory,
in: .userDomainMask
).first!
let fileURL = docs.appendingPathComponent("data.plist")
try data.write(to: fileURL)
FileManager فائل آپریشنز کے مکمل سیٹ کی حمایت کرتا ہے: فائلیں بنانا، کاپی کرنا، منتقل کرنا، حذف کرنا اور نام تبدیل کرنا۔ ہر آپریشن خرابی پھینک سکتا ہے، اس لیے تمام کالز کو do-catch کنسٹرکٹ میں لپیٹنا ضروری ہے۔ فائل حذف کرنے پر خاص توجہ دیں — آپریشن ناقابل واپس ہے، اور removeItem(at:) کے بعد ڈیٹا بحال کرنا پہلے سے بیک اپ کے بغیر ناممکن ہے۔
سینڈبکس کنٹینر میں موجود تمام ڈیٹا iCloud بیک اپ میں شامل نہیں ہونا چاہیے۔ مثال کے طور پر، ڈاؤن لوڈ کردہ کیش شدہ تصاویر یا عارضی پروسیسنگ فائلوں کو بحال کرنے کی ضرورت نہیں ہے — وہ اگلے استعمال پر دوبارہ بن جائیں گی۔ کسی ڈائریکٹری یا فائل کو بیک اپ سے خارج کرنے کے لیے، isExcludedFromBackup وصف کو true پر سیٹ کریں۔ Apple ان ڈیٹا کو ہمیشہ بیک اپ سے خارج کرنے کی سفارش کرتا ہے جو دور سے بحال کیے جا سکتے ہیں، iCloud اسٹوریج کے استعمال کو کم سے کم کرنے اور بحالی کے وقت کو کم کرنے کے لیے۔
var cacheURL = fm.urls(
for: .cachesDirectory,
in: .userDomainMask
).first!
cacheURL.hasExcludedFromBackupKey = true
var values = URLResourceValues()
values.isExcludedFromBackup = true
try cacheURL.setResourceValues(values)
موبائل ڈیوائس پر ہر اسٹوریج کی قسم کا اپنا مقصد اور استعمال کے قوانین ہیں۔ ان فرقوں کو سمجھنا ڈویلپر کو ہر قسم کے ڈیٹا کے لیے صحیح جگہ منتخب کرنے میں مدد کرتا ہے۔ ذیل میں ایپلیکیشن کے لیے دستیاب تین اہم اسٹوریج اقسام کا موازنہ دیا گیا ہے۔
| خصوصیت | Internal Storage | کیشے ڈائریکٹری | External Storage |
|---|---|---|---|
| دوسری ایپس کو مرئیت | پوشیدہ | پوشیدہ | قابل رسائی |
| ایپ ان انسٹال کرنے پر حذف | مکمل | مکمل | مقام پر منحصر |
| بیک اپ | Android — نہیں، iOS — ہاں (Documents) | نہیں | صرف مطابقت پذیری پر |
| میڈیا کے بغیر دستیابی | ہمیشہ | ہمیشہ | SD کارڈ درکار |
| ڈیٹا ضائع ہونے کا خطرہ | کم سے کم | زیادہ | درمیانہ |
| تجویز کردہ فائل سائز | 100 MB تک | 50 MB تک | کوئی بھی |
داخلی اسٹوریج ایپ کنفیگریشنز، ڈیٹابیس فائلوں اور صارف کی دستاویزات کو ذخیرہ کرنے کے لیے بہترین ہے جو دوسرے پروگراموں کے لیے قابل رسائی نہیں ہونی چاہئیں۔ کیشے ڈائریکٹری عارضی فائلوں کے لیے ہے جو اگلے استعمال پر دوبارہ بنائی جا سکتی ہیں: ڈاؤن لوڈ کردہ تصاویر، API جوابات، درمیانی پروسیسنگ ڈیٹا۔ خارجی اسٹوریج بڑی میڈیا فائلوں (فوٹو، ویڈیو، موسیقی) اور اس ڈیٹا کے لیے سب سے موزوں ہے جسے صارف مشترکہ رسائی کے ذریعے دوسری ایپلیکیشنز کے ساتھ شیئر کرنا چاہتا ہے۔
اسٹوریج کی قسم کا انتخاب Google Play اور App Store پر ایپ کی درجہ بندی کو بھی متاثر کرتا ہے۔ جو ایپلیکیشنز صفائی کے بغیر داخلی اسٹوریج میں بڑی مقدار میں ڈیٹا ذخیرہ کرتی ہیں، انہیں منفی جائزے ملتے ہیں: صارفین جگہ کی کمی کی شکایت کرتے ہیں۔ App Annie کے ایک مطالعہ کے مطابق، 62% صارفین کسی ایپ کو حذف کر دیتے ہیں اگر وہ صفائی کے آپشن کے بغیر ڈیوائس کے داخلی اسٹوریج کا 500 MB سے زیادہ لے۔
ایپ کے داخلی اسٹوریج کا مناسب انتظام کارکردگی، حفاظت اور صارف کے تجربے کو بہتر بناتا ہے۔ مندرجہ ذیل سفارشات سرکاری Android اور iOS دستاویزات کے ساتھ ساتھ لاکھوں انسٹال والی ایپلیکیشنز تیار کرنے کے عملی تجربے پر مبنی ہیں۔
حدی صورتوں کی جانچ پر خصوصی توجہ دینی چاہیے۔ داخلی اسٹوریج بھر جانے پر، تحریری آپریشن میں غیر متوقع طور پر خلل پڑنے پر (ایپ کریش، آنے والی کال)، اور iOS بیک اپ سے بحال کرتے وقت ایپلیکیشن کے رویے کی جانچ کریں۔ ان میں سے ہر منظر نامے میں، ڈیٹا مستقل رہنا چاہیے یا آخری مستحکم حالت میں بحال ہونا چاہیے۔ لین دین والی فائلیں استعمال کریں: ڈیٹا کو عارضی فائل میں لکھیں، پھر اسے جوہری طور پر ہدف میں تبدیل کریں۔ یہ تحریری ناکامی پر خراب ڈیٹا پڑھنے سے روکتا ہے۔
صارف کا کنٹرول نہ بھولیں۔ ایپ سیٹنگز میں عارضی ڈیٹا صاف کرنے اور قبضہ شدہ داخلی اسٹوریج والیوم ظاہر کرنے کا آپشن فراہم کریں۔ Google Play Console کے مطابق، اس خصوصیت والی ایپس کو “کارکردگی” زمرے میں 18% زیادہ مثبت جائزے ملتے ہیں۔
اکثر پوچھے گئے سوالات
ایپ کے داخلی اسٹوریج سے تمام ڈیٹا مکمل طور پر حذف ہو جاتا ہے۔ آپریٹنگ سسٹم ڈیٹابیسز، سیٹنگز اور عارضی فائلوں سمیت بقایا فائلوں کی عدم موجودگی کی ضمانت دیتا ہے۔ خارجی اسٹوریج پر ڈیٹا باقی رہ سکتا ہے۔
ڈیوائس تک روٹ رسائی کے بغیر، دوسری ایپس کسی دوسری ایپ کے Internal Storage سے فائلیں نہیں پڑھ سکتیں۔ Android پر، اس کے لیے سپر یوزر مراعات درکار ہیں، جبکہ iOS پر، سینڈبکس کے ذریعے کرنل سطح پر علیحدگی لاگو کی جاتی ہے۔
کوئی واضح حد نہیں ہے، لیکن کل مقدار /data پارٹیشن پر دستیاب جگہ سے محدود ہے۔ فی ایپلیکیشن 100 MB سے تجاوز نہ کرنے کی سفارش کی جاتی ہے — بڑی مقدار کو خارجی اسٹوریج یا کلاؤڈ پر رکھنا بہتر ہے۔
filesDir مستقل ایپ ڈیٹا کے لیے ہے اور سسٹم اسے ضرورت پڑنے پر ہی حذف کرتا ہے۔ cacheDir عارضی فائلوں کے لیے ہے جنہیں سسٹم میموری کم ہونے پر حذف کر سکتا ہے۔ سسٹم cacheDir کے استحکام کی ضمانت نہیں دیتا۔
Internal Storage سے SD کارڈ میں براہ راست کاپی سیکیورٹی پالیسی کے ذریعے ممنوع ہے۔ صارف کی رضامندی سے مشترکہ اسٹوریج میں ڈیٹا کی کاپیاں بنانے کے لیے Android 10+ پر MediaStore API یا SAF (Storage Access Framework) استعمال کریں۔
خلاصہ
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں