Are those two interchangable in context of Room database entity, or, if not, what are the differences between them?
#Ignore is a Room-specific annotation, saying that Room should ignore that field or method.
transient is a Java construct, indicating that this field should not be serialized in standard Java serialization. Room happens to treat this similarly to #Ignore by default. Mostly, that is there for cases where you are inheriting from some class that happens to use transient and you do not control that class (e.g., it is from a library).
For your own code, if you are not using Java serialization, I recommend sticking with #Ignore for the fields. transient is not an available keyword for a method, so to tell Room to ignore certain constructors, you have no choice but to use #Ignore.
Adding to CommonsWare's answer
transient is not good option for ignoring fields for Room as CommonsWare answered. It will create blocker when same modal is being used to parse data from server and store into database.
Let's assume you have a modal class MyModal.java as below
public static class MyModal {
#SerializedName(“intField”)
public int intField;
#SerializedName(“strField”)
public String strField;
#SerializedName(“booleanField”)
public boolean booleanField;
}
If you want to NOT SAVE booleanField into database, and if you modified that field as
transient : It will ignore this field while saving into database, BUT it will also ignore this field while parsing data which comes from server.
#Ignore : It will only ignore this field while inserting data into database, but this field will participate into json parsing.
Related
While writing code for RecyclerView to get data I figured out there's a data class in Kotlin.
Following codes are taken from two different projects which are linked above.
#Serializable
data class MarsPhoto(
val id: String,
#SerialName(value = "img_src")
val imgSrc: String
)
class Contacts {
#SerializedName("country")
private val country:String? = null
fun getCountry():String?{
return country
}
}
I know that both classes are doing same job. So what does differentiate them? I also wonder in the MarsPhoto data class how they can get the id without declaring SerialName just the way they did for imgSrc. (I am just on the way to learning kotlin now, so I'm absolute beginner).
Basically for "data" class the compiler automatically derives the following members from all properties declared in the primary constructor:
equals()/hashCode() pair
toString() of the form "MarsPhoto(id=1, imgSrc=asdf)"
componentN() functions corresponding to the properties in their order of declaration.
copy()
You can read a lot more at enter link description here
On the SerializedName part of your question. if you are dealing with Gson lib by default it is using fields name as "SerializedName". And only if you want to use something different then field name, you can use SerializedName annotation and pass your custom value there. But usually, everybody just writes #SerializedName() with duplication of field names as value for every field.
It's a good idea if you are receiving and Serializing data from server from Json. Because Backend developers can use a bad keys in response, which you don't want to use in your code, so #SerializedName will be the only place where you will have to see this key, and you can name your fields however you like.
#Serializable used to mark class as serializable to disk or like into a file( alternative is Parcel able in android) special useful in case of process death or configuration changes and #SerializedName("country") used for json parsing when u receive the response from server
You get the id without #SerializedName because the JSON property field is the same as your variable name, but imgSrc and img_src is not. Still, even if they are the same, you should always use #SerializedName, because your variable names could be converted to random letters during code optimization, and obfuscation.
I'm trying to use a room entity with a value class:
#JvmInline
value class UserToken(val token: String)
and the entity:
#Entity(tableName = TABLE_AUTH_TOKEN)
data class TokenEntity(
#PrimaryKey val id: Int = 0,
val token: UserToken
)
I get the following error:
error: Entities and POJOs must have a usable public constructor. You can have an empty constructor or a constructor whose parameters match the fields (by name and type).
public final class TokenEntity {
^
is it even possible to use room with value class? I couldn't find anything about this. thanks
See the comment from #CommonsWare. Android does not yet support value classes for Room.
The same holds true for the value classes introduced in kotlin 1.5. The type is not supported.
— Support Inline class in Room entity
Here is a possible explanation according to Kotlin Inline Classes in an Android World.
Looking to solve this you could try and add a TypeConverter for your Inline class, but since your Inline class is just the value it wraps when it’s compiled, this doesn’t make much sense and it doesn’t work as you’d expect even if you tried...
I’m just guessing it’s because this is a TypeConverter converting UserId to Int which is basically the same as Int to Int 😭. Someone will probably solve this problem, but if you have to create a TypeConverter for your Inline class then you are still plus one class for the count (multidex). 👎
I think yes if you can provide a type converter for it to change it to some sort of primitive data type (int , string, long ...etc) when it needs to be stored, and to change it back to its class type when it's fetched from database.
You can read about Type Converters from here
Referencing complex data using Room
other than that, your other class should be an entity and bind both your entities together using a Relation.
at least that's what I know about how to use Room.
UserToken always will have only one attribute? In this case, you don't need two classes, just use token: String directly on your entity class;
If you really need keep this class, you have two options:
TypeConverter, where you basically will convert the object into a json, and save as string in the database;
Relation, where you will transform the UserToken in a entity, and on TokenEntity save the tokenId.
Have an error with Room:
someField has protected access in LibraryClass
I have no access to this field, because it's in library. How can I force Room to not save this field(because I don't need it)?
How can I force Room to not save this field
Don't inherit from that class. Having an #Entity inherit from some class that you do not control is fairly risky, and this is the sort of problem that you will encounter. Have your #Entity be a simple POJO.
I have a class structure with
Class x {
int a;
int b;
Y[] yList;
}
Class Y {
int m;
int n;
}
I am using data binding, Room and Dagger. I am getting compilation error as 'cannot find class DatabindingComponent', possibly because Room doesn't allow persistent of Nested objects. To enable I used #Embedded annotation but still getting same error. But if I use #Ignore annotation indicating Room that do not process this field; compilation is happening successfully.
How to reference nested array of objects for Room Database without foreign key?
Please refer to
https://developer.android.com/topic/libraries/architecture/room.html#no-object-references
https://developer.android.com/reference/android/arch/persistence/room/Ignore.html
https://developer.android.com/reference/android/arch/persistence/room/Embedded.html.
How to reference nested array of objects for Room Database without foreign key?
If you do not want Y to be an #Entity with its own table, the only option that I know of is to use #TypeConverters:
Define two static methods with #TypeConverter that convert Y[] to and from some basic type (e.g., String, by using JSON)
Register the class holding those methods using #TypeConverters somewhere (e.g., on your RoomDatabase subclass)
This works using collection classes (e.g., List, Set). I would guess that it works with Java arrays (Y[]), though I have not tried it.
I cannot find it clearly documented anywhere if getters and setters are actually required for fields in a Realm Model. For example, the documentation at https://realm.io/docs/java/latest/api/io/realm/RealmObject.html says
The only restriction a RealmObject has is that fields are not allowed
to be final, transient' or volatile. Any method as well as public
fields are allowed. When providing custom constructors, a public
constructor with no arguments must be declared and be empty.
Fields annotated with Ignore don't have these restrictions and don't
require either a getter or setter.
Which seems to hint that it is required with getters and setters for non-ignored fields. Yet, the documentation at https://realm.io/docs/java/latest/#customizing-objects says
It is possible to use RealmObjects almost like POJOs. Extending from
RealmObject, you can let the fields be public, and use simple
assignments instead of setters and getter.
and then show the code for a Realm Model that does not have any getters and setters and instead have public fields we should use. Really? I thought Realm didn't even store any values in the actual fields, so reading and writing from them is probably a bad idea? I mean their debugging docs https://realm.io/docs/java/latest/#debugging state:
Unfortunately these values are wrong because the field values are not
used. Realm creates a proxy object behind the scenes and overrides the
getters and setters in order to access the persisted data in the Realm
So could someone please enlighten me? Can I skip getters and setters and just stick with public fields? Is there any thorough docs on this?
public fields work in most cases, and since Realm 2.0.0 they work even in constructors of RealmObjects (allowing "default values"), and work if you directly access the property.
For example,
SomeObject obj = results.get(i);
obj.blah = "Blahblah";
That works, because managed RealmObjects' field access are transformed by the Realm-Transformer into proxy getter/setter calls (in this case, into the realmSet$blah method).
This has been the case since 0.88.0, when Realm started being provided as a Gradle plugin.
However, a major limitation is that the proxy field access doesn't run in instrumentation tests, because the androidTestCompile scope does not run the transformer.