3 points difficiles à gérer Java Realm

Realm est généralement utile, bien qu'il soit difficile à gérer.

En principe, j'ai trouvé cela difficile à gérer principalement lorsque vous utilisez Realm comme une simple base de données. Surtout, il est difficile à gérer par rapport à la version Swift.

Le test unitaire ne peut pas être effectué avec la JVM seule

Le royaume dépend d'Android, je dois donc l'exécuter avec Android Test. Dans ce cas, vous pouvez utiliser Robolectric, mais il semble que Realm ne soit pas encore pris en charge (https://github.com/realm/realm-java/issues/904).

Autrement dit, son exécution prend beaucoup de temps, ce qui rend les tests inconfortables.

Bien sûr, cela peut fonctionner avec PowerMock, mais je veux vérifier que l'insertion, la mise à jour et la sélection fonctionnent correctement dans le domaine avec un test ciblant Dao. (Pour les couches autres que Dao, Dao est moqué, il n'y a donc pas de problème.)

Dans l 'exemple officiel, PowerMock J'utilise.

Actuellement, il n'y a pas de solution fondamentale, et il semble que vous ne puissiez tester que si la méthode est appelée correctement par mock.

Crash lors de l'accès après la fermeture

Il est naturel d'ouvrir et de fermer la ressource, mais lorsque j'accède à la propriété avec l'intention de la mettre dans l'entité, elle plante (Cette instance de Realm a déjà été fermée`). Java Realm est une spécification inaccessible après la fermeture d'une ressource.

Pour éviter cela, vous devez tout gérer dans la transaction. Si vous souhaitez le compléter avec Dao seul, vous devez le copier dans une instance non gérée par le royaume comme suit.

    fun find(): AuthEntity? {
        var result: AuthEntity? = null
        Realm.getDefaultInstance().use { realm ->
            val entity = realm.where(AuthEntity::class.java).findFirst()
            if (entity != null) {
                result = realm.copyFromRealm(entity)
            }
        }
        return result
    }

Le royaume est généralement configuré pour être instancié avec onCreate () et fermé avec ```onDestroy () (Official Document. docs / java / latest /) semble également être "fermé avec" ʻonDestory () `` ).

Mais vous ne voulez pas que l'activité dépende de l'élément Dao, et vous ne voulez pas que le ViewModel dépende de Realm, par exemple, dans MVVM. Donc, je pense que je vais créer une classe qui enveloppe Realm et l'implémenter pour éliminer la dépendance. Cependant, il est exagéré d'être au courant des transactions sans dépendre du royaume, même pour un simple traitement d'acquisition.

Par conséquent, je pense qu'il existe une décision / solution pour écrire le code ci-dessus. Cependant, ce procédé semble être coûteux en termes de mémoire et de temps de traitement.

L'entité a besoin d'un constructeur par défaut public

Lors de l'utilisation avec Kotlin, vous devez mettre une valeur par défaut dans l'argument en raison de cette restriction. Si vous utilisez le plugin kotlin-noarg, le constructeur par défaut est automatiquement généré, mais dans le cas de Realm, il n'a pas pu être construit car il a été joué lors de la pré-vérification. Correspondant partie sourceest.

Donc, même si vous n'avez pas besoin des valeurs par défaut, vous écrirez une classe comme celle-ci.

@RealmClass
data class SampleEntity(
        @PrimaryKey
        @SerializedName("id")
        var id: Int = 0,

        @SerializedName("sample")
        var sample: String = ""
) : RealmModel