Content Provider: mi ez, a komponens architektúrája és működési elve

Mi az a Content Provider?

Content Provider — egy Android komponens, amely kezeli a hozzáférést egy központosított adattárolóhoz, és más alkalmazások számára elérhetővé teszi azokat egy egységes szerződéses interfészen keresztül. Elrejti a tárolás implementációs részleteit: az adatok tárolhatók SQLite-ban, fájlrendszeren, felhőben, vagy lehetnek hálózati kérés eredményei.

Az Android beépített Content Provider-eket tartalmaz a rendszeradatokhoz — ContactsContract, MediaStore, CalendarContract, CallLog. Harmadik féltől származó alkalmazások is létrehozhatják saját szolgáltatóikat a biztonságos adatcseréhez. Minden szolgáltató regisztrálva van az AndroidManifest.xml-ben az authority — az URI első részét képező egyedi karakterlánc — megadásával.

Hogyan működik a Content Provider

A Content Provider a kliens-szerver modell szerint működik. A szolgáltató szerverként működik, amely hat kötelező metódust implementál: query, insert, update, delete, getType és onCreate. A kliens (másik alkalmazás) a ContentResolver-en keresztül fér hozzá a szolgáltatóhoz, amely az Android IPC mechanizmusán keresztül továbbítja a hívásokat a szolgáltató megfelelő metódusaihoz.

URI és authority

Minden Content Provider-t egy URI azonosít a content:// séma szerint. Például content://com.example.app.provider/items. Az első rész authority (com.example.app.provider) a szolgáltató osztályához van kötve a manifestben. A /items útvonal egy táblára, a /items/5 pedig egy adott ID=5 rekordra mutat.

A hívás folyamata

Amikor egy alkalmazás meghívja a ContentResolver.query(URI)-t, az Android ellenőrzi a hívó csomag engedélyeit, megtalálja a szolgáltatót az authority alapján, és elindítja a folyamatát, ha még nem fut. A szolgáltató végrehajtja a lekérdezést, és visszaad egy Cursor-t — egy objektumot, amely tartalmazza az eredményt, és lehetővé teszi a kliens számára a rekordokon keresztüli iterálást.

A Content Provider fő metódusai

A ContentProvider osztály hat absztrakt metódus implementálását igényli. Minden metódus fogad egy URI-t, és a művelet típusának megfelelő eredményt ad vissza. A rendszer ezeket a metódusokat bármely folyamatból meghívhatja, ezért azoknak szálbiztosaknak kell lenniük, és nem blokkolhatják a végrehajtást hosszú ideig.

query metódus

A query metódus fogad egy URI-t, egy oszloptömböt (projection), egy selection karakterláncot argumentumokkal és a rendezési sorrendet. Visszaad egy Cursor-t adatokkal. Az implementációban az URI-t az UriMatcher segítségével kell elemezni, és a megfelelő SQL lekérdezést végrehajtani az adatbázison.

insert, update, delete metódusok

Ezek a metódusok módosítják az adatokat a tárolóban. Az insert fogadja a ContentValues-t — kulcs-érték párokat — és visszaadja az új rekord URI-ját. Az update és delete a selection-t fogadja a rekordok szűréséhez, és visszaadja az érintett sorok számát. Az adatok módosítása után a szolgáltatónak értesítenie kell erről a ContentResolver.notifyChange-en keresztül.

ContentResolver és URI Androidban

ContentResolver — egy egységes hozzáférési pont az összes Content Provider-rel való munkához a rendszerben. A kliens alkalmazás soha nem hívja meg közvetlenül a szolgáltató metódusait — csak a ContentResolver-en keresztül, amelyet az Android a kontextusból szerez. A CRUD műveletek a ContentResolver-ben ugyanazokkal a nevekkel rendelkeznek, mint a szolgáltatónál, de közvetlen referenciák helyett URI-t fogadnak.

UriMatcher

A bejövő URI-k elemzéséhez a szolgáltatón belül a UriMatcher használatos. Lehetővé teszi az URI numerikus kóddal való összerendelését — például a content://authority/items URI 1-es kódot ad, a content://authority/items/# pedig 2-es kódot. Ez kiküszöböli az URI karakterlánc manuális elemzésének szükségességét minden metódusban.

// ContentResolver használata névjegyek eléréséhez
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("Névjegyek", "Név: $name")
    }
}

A Cursor-t használat után be kell zárni — a fenti példában ezt a use (Kotlin kiterjesztő függvény) teszi. Ha a Cursor nincs bezárva, memóriaszivárgás lép fel, mert referenciát tart a Binder poolban lévő adatokra. UI forgatókönyvekhez használja a CursorLoader-t vagy a Room-ot LiveData/Flow-val.

Content Provider példa Kotlinban

A saját Content Provider létrehozása a ContentProvider osztályból való származtatással kezdődik. A szolgáltató SQLite adatbázissal dolgozik az SQLiteOpenHelper segítségével, és az UriMatcher-t használja a lekérdezés típusának meghatározásához. Tekintsünk egy minimális implementációt a jegyzetek listájának kezelésére.

Regisztráció a manifestben

A szolgáltató regisztrálása az AndroidManifest.xml-ben az application tagon belül történik. Az authorities attribútum egy egyedi azonosítót állít be, az exported pedig meghatározza, hogy más alkalmazások hozzáférhetnek-e a szolgáltatóhoz. exported=true nélkül a szolgáltató csak az Ön alkalmazásán belül érhető el.

// Példa Content Provider jegyzetekhez
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 kihagyva a rövidség kedvéért
}

Az osztály létrehozása után a szolgáltatót regisztrálni kell a manifestben az android:authorities és android:exported (true, ha a szolgáltató nyilvános) attribútumokkal. A rendszer a szolgáltató egy példányát az első hozzáféréskor hozza létre — ez a UI szálon történik, ezért az onCreate-nek gyorsan kell végrehajtódnia.

Adatvédelem engedélyeken keresztül

A Content Provider lehetővé teszi az adatokhoz való hozzáférés kezelését két szinten: olvasási engedélyek és írási engedélyek. Ezek a manifestben az android:readPermission és android:writePermission attribútumokkal kerülnek beállításra. Ha a kliens alkalmazás nem rendelkezik a megfelelő engedéllyel, a rendszer SecurityException kivétellel elutasítja a hívást.

URI szintű engedély

Az Android támogatja az ideiglenes engedélyeket a FLAG_GRANT_READ_URI_PERMISSION és FLAG_GRANT_WRITE_URI_PERMISSION jelzőkön keresztül. Ez akkor hasznos, amikor egy alkalmazás egy fájl URI-ját Intent-en keresztül továbbítja egy másik alkalmazásnak — a fogadó csak az adott URI-hoz fér hozzá korlátozott ideig. A rendszer visszavonja az ideiglenes engedélyt a fogadó alkalmazás befejezése után.

A rendszerszolgáltatók esetében az Android megköveteli a konkrét engedélyek megadását az alkalmazás manifestjében. Például a névjegyek eléréséhez READ_CONTACTS, a naptárhoz READ_CALENDAR szükséges. Az Android 6-tól kezdve ezek az engedélyek futásidőben kérvényezendők, nem telepítéskor.