Raumpersistenzbibliothek und Inhaltsanbieter

In den letzten paar Tagen habe ich Zeit damit verbracht, Neues zu lernen Komponenten der Android-Architektur . Nachdem ich einige Blog-Posts, Dokumentationen und Tutorials verfolgt hatte, wurden mir alle Komponenten klar. Aber plötzlich wurde mir klar, was mit unserem alten Freund war Inhalt Anbieter . Ich mag albern klingen, denn bevor ich diese Frage geschrieben habe, habe ich ziemlich viel Zeit mit der Suche verbracht: Bin ich der einzige, der auf diese Frage gekommen ist? Ich hatte keine hilfreiche Lösung. Wie auch immer, hier ist es, wenn ich eine App mit lokaler DB aufbauen möchte, werde ich jetzt natürlich neue Architekturkomponenten (Live-Daten, Ansichtsmodell, Raum) auswählen, ohne weiter darüber nachzudenken, dass dies sehr hilfreich sein wird, um die App 10x robust zu machen. Aber wenn ich möchte, dass meine DB-Daten für andere Apps zugänglich sind, zum Beispiel To Widget Wie integriere ich Content Provider mit Room?

Ich hatte übrigens die gleiche Frage. Und ich habe eine Probe gefunden hier was meine Frage beantwortet. Hoffe es geht bei dir genauso.

Kurz gesagt, dies befindet sich im DAO-Objekt, das vom Inhaltsanbieter aufgerufen wird query() Methode.

/**
 * Select all cheeses.
 *
 * @return A {@link Cursor} of all the cheeses in the table.
 */
@Query("SELECT * FROM " + Cheese.TABLE_NAME)
Cursor selectAll();

Beachten Sie, wie es zurückkehrt Cursor Objekt. Andere Operationen können Sie sich im Beispiel genauer ansehen.

Dies hier ist, glaube ich, Auswahl Nummer 3 in der Antwort von @CommonsWare.

Wenn ich eine App mit lokaler DB aufbauen möchte, wähle ich jetzt natürlich neue Architekturkomponenten (Live-Daten, Ansichtsmodell, Raum)

Den Begriff “offensichtlich” würde ich da nicht verwenden. Die Architekturkomponenten sind eine Option, aber keine Voraussetzung.

Aber wenn ich möchte, dass meine DB-Daten für andere Apps zugänglich sind, zum Beispiel To Widget Wie integriere ich Content Provider mit Room?

Ein App-Widget hat nichts mit einem zu tun ContentProvider. meiner bescheidenen Meinung nach Sehr wenig Apps sollten Datenbanken für Dritte offen legen über ContentProviderund nein Apps sollten eine verwenden ContentProvider rein für interne Zwecke.

Davon abgesehen haben Sie einige Möglichkeiten:

1. Verwenden Sie keinen Raum, zumindest für die Tabellen, die über die belichtet werden sollen ContentProvider

2. Verwenden Sie Room für interne Zwecke, verwenden Sie dann aber klassische SQLite-Programmiertechniken für die ContentProviderper Anruf getOpenHelper() auf Ihrem RoomDatabase

3. Verwenden Sie Zimmer in der ContentProviderSchreiben Sie Ihren eigenen Code, um a aufzubauen MatrixCursor aus den Room-Entitäten, die Sie abrufen (z query()) oder Erstellen der Entitäten zur Verwendung mit anderen Vorgängen (z insert(), update(), delete()etc.)

Die Raumbibliothek bietet keine besondere Unterstützung für Inhaltsanbieter. Sie können Content Provider nur selbst schreiben und dann Room verwenden, um eine Datenbank abzufragen.

Wenn Sie Android-Architekturkomponenten verwenden und mit SQLite-basierten Inhaltsanbietern arbeiten möchten, ziehen Sie die Verwendung von in Betracht Kripton Persistenzbibliothek: es erlaubt Live-Daten generieren aus DB-Abfragen, Content Provider für Sie generieren, und vieles mehr. Last but not least: Warum müssen Sie das gesamte SQL schreiben, wenn Sie nur die Where-Bedingungen schreiben müssen?

Nur um das klarzustellen, ich bin der Autor der Kripton Persistence Library. Ich habe es geschrieben, weil ich keine einzigartige Bibliothek gefunden habe, die alle meine Anforderungen in Bezug auf die Persistenzverwaltung erfüllt (und ja, weil ich gerne programmiere).

Ich habe eine konvertierte Version von Google Content Provider Sample mit Kripton geschrieben. Sie können es finden hier.

Nur um das Lesen zu vereinfachen. Bei Kripton müssen Sie nur eine DAO-Schnittstelle definieren. Inhaltsanbieter werden durch die Anmerkungen generiert. Dasselbe DAO, das in Kripton konvertiert wird, lautet:

@BindContentProviderPath(path = "cheese")
@BindDao(Cheese.class)
public interface CheeseDao {

    @BindSqlSelect(fields="count(*)")
    int count();

    @BindContentProviderEntry
    @BindSqlInsert
    long insert(String name);

    @BindContentProviderEntry()
    @BindSqlSelect
    List<Cheese> selectAll();

    @BindContentProviderEntry(path = "${id}")
    @BindSqlSelect(where ="id=${id}")
    Cheese selectById(long id);

    @BindContentProviderEntry(path = "${id}")
    @BindSqlDelete(where ="id=${id}")
    int deleteById(long id);

    @BindContentProviderEntry(path = "${cheese.id}")
    @BindSqlUpdate(where="id=${cheese.id}")
    int update(Cheese cheese);

}

Der generierte Inhaltsanbieter macht die DAO-Methode mit URIs verfügbar. Zur Verdeutlichung stelle ich hier nur das generierte JavaDoc (immer von Kripton) ein.

Weitere Informationen zu Kripton auf sein Wiki, meine Seite und weiter meine Artikel .

Verspäteter Beitrag, aber ich bin kürzlich auf dieselbe Ausgabe gestoßen. Letztendlich wurde dieselbe Raumdatenbankinstanz sowohl für lokale als auch für Inhaltsanbieterzwecke verwendet.

Die App selbst verwendet also die Raumdatenbank wie gewohnt und der Inhaltsanbieter “wrapst” die Raumdatenbank mit “open helper” wie folgt:

class DatabaseProvider : ContentProvider() {

    override fun onCreate(): Boolean {
        return true
    }

    override fun query(uri: Uri?, projection: Array<out String?>?, selection: String?, selectionArgs: Array<out String?>?, sortOrder: String?): Cursor? {
        val db = roomDatabase.openHelper.readableDatabase
        db.query(...)
    }

    override fun insert(uri: Uri?, values: ContentValues?): Uri? {
        val db = roomDatabase.openHelper.writableDatabase
        db.insert(...)
    }

    override fun update(uri: Uri?, values: ContentValues?, selection: String?, selectionArgs: Array<out String?>?): Int {
        val db = roomDatabase.openHelper.writableDatabase
        db.update(...)
    }

    override fun delete(uri: Uri?, selection: String?, selectionArgs: Array<out String?>?): Int {
        val db = roomDatabase.openHelper.writableDatabase
        db.delete(...)
    }

    override fun getType(uri: Uri?): String? {
    }
}

Verwenden Sie besser den SupportOpenHelper

public class MyContentProvider extends ContentProvider {
    public MyContentProvider() {
    }

    @Override
    public String getType(Uri uri) {
        // TODO: Implement this to handle requests for the MIME type of the data
        // at the given URI.
        throw new UnsupportedOperationException("Not yet implemented");
    }

    UserDatabase database;

    @Override
    public boolean onCreate() {
        database = Room.databaseBuilder(getContext(), UserDatabase.class, "user.db").allowMainThreadQueries().build();
        return false;
    }

    @Override
    public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
         return database.query(SupportSQLiteQueryBuilder.builder("user").selection(selection, selectionArgs).columns(projection).orderBy(sortOrder).create());
    }

    @Override
    public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs) {
        return database.getOpenHelper().getWritableDatabase().update("user", 0, values, selection, selectionArgs);
    }

    @Override
    public int delete(Uri uri, String selection, String[] selectionArgs) {
        return database.getOpenHelper().getWritableDatabase().delete("user", selection, selectionArgs);
    }

    @Override
    public Uri insert(Uri uri, ContentValues values) {
        long retId = database.getOpenHelper().getWritableDatabase().insert("user", 0, values);
        return ContentUris.withAppendedId(uri, retId);
    }
}