Content Provider: جزو کا فن تعمیر اور کام کرنے کا اصول

Content Provider کیا ہے؟

Content Provider ایک Android جزو ہے جو مرکزی ڈیٹا اسٹور تک رسائی کو منظم کرتا ہے اور اسے ایک متحد معاہدہ انٹرفیس کے ذریعے دوسری ایپلیکیشنز کو فراہم کرتا ہے۔ یہ اسٹوریج کے نفاذ کی تفصیلات چھپاتا ہے: ڈیٹا SQLite، فائل سسٹم، کلاؤڈ میں محفوظ کیا جا سکتا ہے یا نیٹ ورک کی درخواست کا نتیجہ ہو سکتا ہے۔

Android سسٹم ڈیٹا کے لیے بلٹ ان Content Providers شامل کرتا ہے — ContactsContract، MediaStore، CalendarContract، CallLog۔ فریق ثالث کی ایپلیکیشنز بھی محفوظ ڈیٹا کے تبادلے کے لیے اپنے فراہم کنندہ بنا سکتی ہیں۔ ہر فراہم کنندہ authority کے ساتھ AndroidManifest.xml میں رجسٹر ہوتا ہے — ایک منفرد سٹرنگ جو URI کا پہلا حصہ بناتی ہے۔

Content Provider کیسے کام کرتا ہے

Content Provider کلائنٹ-سرور ماڈل پر کام کرتا ہے۔ فراہم کنندہ ایک سرور کے طور پر کام کرتا ہے جو چھ لازمی طریقوں کو نافذ کرتا ہے: query، insert، update، delete، getType اور onCreate۔ کلائنٹ (دوسری ایپلیکیشن) ContentResolver کے ذریعے فراہم کنندہ تک رسائی حاصل کرتا ہے، جو Android کے IPC میکانزم کے ذریعے کالز کو فراہم کنندہ کے متعلقہ طریقوں میں ترجمہ کرتا ہے۔

URI اور authority

ہر Content Provider content:// اسکیم کے URI سے شناخت کیا جاتا ہے۔ مثال کے طور پر، content://com.example.app.provider/items۔ پہلا حصہ authority (com.example.app.provider) مینی فیسٹ میں فراہم کنندہ کلاس سے منسلک ہوتا ہے۔ راستہ /items ایک ٹیبل کی طرف اشارہ کرتا ہے، جبکہ /items/5 ID=5 والے مخصوص ریکارڈ کی طرف اشارہ کرتا ہے۔

کال کا عمل

جب کوئی ایپلیکیشن ContentResolver.query(URI) کال کرتی ہے، Android کال کرنے والے پیکیج کی اجازتوں کی جانچ کرتا ہے، authority کے ذریعے فراہم کنندہ کو ڈھونڈتا ہے اور اگر وہ پہلے سے نہیں چل رہا تو اس کا عمل شروع کرتا ہے۔ فراہم کنندہ استفسار پر عمل کرتا ہے اور ایک Cursor لوٹاتا ہے — ایک آبجیکٹ جس میں نتیجہ ہوتا ہے اور کلائنٹ کو ریکارڈز پر گشت کرنے دیتا ہے۔

Content Provider کے اہم طریقے

ContentProvider کلاس کو چھ تجریدی طریقوں کے نفاذ کی ضرورت ہوتی ہے۔ ہر طریقہ ایک URI قبول کرتا ہے اور آپریشن کی قسم کے مطابق نتیجہ لوٹاتا ہے۔ سسٹم ان طریقوں کو کسی بھی عمل سے کال کرتا ہے، لہذا انہیں تھریڈ محفوظ ہونا چاہیے اور عمل کو زیادہ دیر تک مسدود نہیں کرنا چاہیے۔

query طریقہ

query طریقہ ایک URI، کالموں کی projection صف، دلائل کے ساتھ selection سٹرنگ اور ترتیب کی ترتیب قبول کرتا ہے۔ یہ ڈیٹا کے ساتھ Cursor لوٹاتا ہے۔ نفاذ میں، آپ کو UriMatcher کا استعمال کرتے ہوئے URI کو پارس کرنا ہوگا اور ڈیٹا بیس میں متعلقہ SQL استفسار پر عمل کرنا ہوگا۔

insert، update، delete طریقے

یہ طریقے اسٹور میں ڈیٹا تبدیل کرتے ہیں۔ insert ContentValues — کلید-قدر کے جوڑے — وصول کرتا ہے اور نئے ریکارڈ کا URI لوٹاتا ہے۔ update اور delete ریکارڈ فلٹر کرنے کے لیے selection قبول کرتے ہیں اور متاثرہ قطاروں کی تعداد لوٹاتے ہیں۔ ڈیٹا تبدیل کرنے کے بعد، فراہم کنندہ کو ContentResolver.notifyChange کے ذریعے اس کی اطلاع دینی ہوگی۔

Android میں ContentResolver اور URI

ContentResolver سسٹم میں تمام Content Providers کے ساتھ کام کرنے کے لیے ایک واحد رسائی نقطہ ہے۔ کلائنٹ ایپلیکیشن کبھی بھی براہ راست فراہم کنندہ کے طریقوں کو کال نہیں کرتی — صرف ContentResolver کے ذریعے، جسے Android سیاق و سباق سے حاصل کرتا ہے۔ ContentResolver میں CRUD کارروائیوں کے نام وہی ہیں جو فراہم کنندہ میں ہیں لیکن براہ راست حوالہ جات کے بجائے URI قبول کرتے ہیں۔

UriMatcher

فراہم کنندہ کے اندر آنے والی URIs کو پارس کرنے کے لیے UriMatcher استعمال کیا جاتا ہے۔ یہ URI کو عددی کوڈ سے نقشہ بنانے کی اجازت دیتا ہے — مثال کے طور پر، URI content://authority/items کوڈ 1 دیتا ہے، اور content://authority/items/# کوڈ 2 دیتا ہے۔ یہ ہر طریقہ میں دستی URI سٹرنگ پارسنگ کی ضرورت کو ختم کرتا ہے۔

// رابطوں تک رسائی کے لیے ContentResolver کا استعمال
val uri = ContactsContract.Contacts.CONTENT_URI
val cursor = contentResolver.query(
    uri,
    arrayOf(ContactsContract.Contacts.DISPLAY_NAME),
    null, null, null
)
cursor?.use {
    while (it.moveToNext()) {
        val name = it.getString(it.getColumnIndexOrThrow(
            ContactsContract.Contacts.DISPLAY_NAME
        ))
        Log.d("رابطے", "نام: $name")
    }
}

Cursor کو استعمال کے بعد ہمیشہ بند کیا جانا چاہیے — اوپر کی مثال میں، use فنکشن (Kotlin توسیع) یہ کرتا ہے۔ اگر Cursor بند نہیں کیا جاتا، تو میموری لیک ہوتی ہے کیونکہ یہ Binder پول میں ڈیٹا کا حوالہ رکھتا ہے۔ UI منظرناموں کے لیے، LiveData/Flow کے ساتھ CursorLoader یا Room استعمال کریں۔

Kotlin میں Content Provider کی مثال

اپنا خود کا Content Provider بنانا ContentProvider کلاس کو بڑھانے سے شروع ہوتا ہے۔ فراہم کنندہ SQLiteOpenHelper کے ذریعے SQLite ڈیٹا بیس کے ساتھ کام کرتا ہے اور استفسار کی قسم کا تعین کرنے کے لیے UriMatcher استعمال کرتا ہے۔ نوٹوں کی فہرست کو منظم کرنے کے لیے ایک کم سے کم نفاذ پر غور کریں۔

مینی فیسٹ میں رجسٹریشن

فراہم کنندہ AndroidManifest.xml میں application ٹیگ کے اندر رجسٹر ہوتا ہے۔ authorities وصف ایک منفرد شناخت کنندہ متعین کرتا ہے، اور exported متعین کرتا ہے کہ آیا دوسری ایپلیکیشنز فراہم کنندہ تک رسائی حاصل کر سکتی ہیں۔ exported=true کے بغیر، فراہم کنندہ صرف آپ کی ایپلیکیشن کے اندر ہی قابل رسائی ہے۔

// نوٹوں کے لیے Content Provider کی مثال
class NotesProvider : ContentProvider() {

    companion object {
        const val AUTHORITY = "com.example.app.notes"
        const val NOTES_PATH = "notes"
        const val NOTES_URI = "content://$AUTHORITY/$NOTES_PATH"
        const val NOTES_ID = "content://$AUTHORITY/$NOTES_PATH/#"

        private val uriMatcher = UriMatcher(UriMatcher.NO_MATCH).apply {
            addURI(AUTHORITY, NOTES_PATH, 1)
            addURI(AUTHORITY, "$NOTES_PATH/#", 2)
        }
    }

    override fun query(uri: Uri, projection: Array<String>?,
        selection: String?, args: Array<String>?, sort: String?): Cursor? {
        return when (uriMatcher.match(uri)) {
            1 -> dbHelper.readableDatabase.query(TABLE_NOTES,
                projection, selection, args, null, null, sort)
            2 -> dbHelper.readableDatabase.query(TABLE_NOTES,
                projection, "_id=?", arrayOf(uri.lastPathSegment), null, null, null)
            else -> throw IllegalArgumentException("Unknown URI: $uri")
        }
    }

    override fun insert(uri: Uri, values: ContentValues?): Uri? {
        val id = dbHelper.writableDatabase.insert(TABLE_NOTES, null, values)
        context?.contentResolver?.notifyChange(uri, null)
        return ContentUris.withAppendedId(uri, id)
    }

    override fun delete(uri: Uri, selection: String?, args: Array<String>?): Int {
        val count = dbHelper.writableDatabase.delete(TABLE_NOTES, selection, args)
        context?.contentResolver?.notifyChange(uri, null)
        return count
    }

    // getType, update, onCreate مختصر کرنے کے لیے چھوڑ دیے گئے
}

فراہم کنندہ کلاس بنانے کے بعد، اسے android:authorities اور android:exported صفات (true اگر فراہم کنندہ عوامی ہے) کے ساتھ مینی فیسٹ میں رجسٹر کیا جانا چاہیے۔ سسٹم پہلی رسائی پر فراہم کنندہ کی مثال بناتا ہے — یہ UI تھریڈ میں ہوتا ہے، لہذا onCreate کو تیزی سے عمل کرنا چاہیے۔

اجازتوں کے ذریعے ڈیٹا کا تحفظ

Content Provider دو سطحوں پر ڈیٹا تک رسائی کو منظم کرنے کی اجازت دیتا ہے: پڑھنے کی اجازتیں اور لکھنے کی اجازتیں۔ یہ مینی فیسٹ میں android:readPermission اور android:writePermission صفات کے ساتھ متعین کی جاتی ہیں۔ اگر کلائنٹ ایپلیکیشن کے پاس متعلقہ اجازت نہیں ہے، تو سسٹم SecurityException کے ساتھ کال مسترد کر دیتا ہے۔

URI سطح کی اجازتیں

Android FLAG_GRANT_READ_URI_PERMISSION اور FLAG_GRANT_WRITE_URI_PERMISSION جھنڈوں کے ذریعے عارضی اجازتوں کو سپورٹ کرتا ہے۔ یہ اس وقت مفید ہے جب کوئی ایپلیکیشن Intent کے ذریعے کسی دوسری ایپلیکیشن کو فائل URI بھیجتی ہے — وصول کنندہ کو صرف اس مخصوص URI تک محدود وقت کے لیے رسائی ملتی ہے۔ سسٹم وصول کنندہ ایپلیکیشن کے ختم ہونے کے بعد عارضی اجازت منسوخ کر دیتا ہے۔

سسٹم فراہم کنندگان کے لیے، Android کو ایپلیکیشن مینی فیسٹ میں مخصوص اجازتوں کی وضاحت کرنے کی ضرورت ہوتی ہے۔ مثال کے طور پر، رابطوں تک رسائی کے لیے READ_CONTACTS درکار ہے، اور کیلنڈر تک رسائی کے لیے READ_CALENDAR درکار ہے۔ Android 6 سے شروع کرتے ہوئے، یہ اجازتیں انسٹالیشن کے دوران نہیں بلکہ رن ٹائم پر درخواست کی جاتی ہیں۔