How to create Entity and data classes by ROOM in android?
I have JSON structure:
data class ListResponse(val item: ListItem)
data class ListItem(
@SerializedName("id")
val id: List<CheckUnCheckItem>
)
data class CheckUnCheckItem(
@SerializedName("check")
val check: CheckItem,
@SerializedName("unCheck")
val UnCheck: UnCheckItem
)
data class CheckItem(
@SerializedName("url")
val url: String,
@SerializedName("text")
val text: String,
@SerializedName("color")
val color: String
)
data class UnCheckItem(
@SerializedName("url")
val urlUnCheck: String,
@SerializedName("text")
val textUnCheck: String,
@SerializedName("color")
val colorUnCheck: String
)
But How can I create such ROOM Entity?
Do I need to use @TypeConverter?
@Entity(tableName = TABLE_NAME)
data class ListEntity(
@PrimaryKey @SerializedName("id")
val id: CheckUnCheckItem,
@SerializedName("check")
val check: CheckItem,
@SerializedName("unCheck")
val unCheck: UnCheckItem,
@SerializedName("url")
val url: String,
@SerializedName("text")
val text: String,
@SerializedName("size")
val size: String
){
companion object{
const val TABLE_NAME = "db_table"
}
class RoomTypeConverters{
@TypeConverter
fun convertCheckItemListToJSONString(checkList: CheckItem): String = Gson().toJson(checkList)
@TypeConverter
fun convertJSONStringToCheckItemList(jsonString: String): CheckItem = Gson().fromJson(jsonString,CheckItem::class.java)
}
}
is my data and entity classes are correct? Do I need class witch extends RoomDatabase? Or better I need to separate db and create for check and uncheck another db?

As database implies it is able to store data not just one but many. As such a single database is all that would be required. SQLite is a relational database and is designed to store related data. Related data is typically stored in multiple tables. So again a single database will very likely be sufficient.
For example, based upon your
@Entityannotated ListEntity class then:-Room has to know about the Type Converters. So you need an
@TypeConvertersannotation. It's placement defines the scope. Using the annotation to preced the@Databaseannotation has the most far reaching scope.This class should be annotated with the
@Databaseannotation, theentitiesparameter of the annotation should include the list of classes for each each table (@Entityannotated class). e.g.However, using the above along with your classes results in a build error as per:-
ListEntity.java:11: error: Cannot figure out how to save this field into database. You can consider adding a type converter for it. private final a.a.so74708202kotlinroomentitydesign.CheckUnCheckItem id = null;Amending the RoomTypeConverters class to be:-
Resolves the build issue and in theory you have a potentially usable database.
However, you obviously need code to access the database. As such you would very likely want to have. as previously mentioned, an
@Daoannotated interface e.gThis will suffice to allow rows to be inserted into the database and for all the rows to be extracted from the database into a
List<ListEntity).From the
builtdatabase you need to get an instance of the TheDAOs and thus the@Databaseannotated class could then be:-
To demonstrate actual use of the above then consider the following code in an activity:-
The output to the log being:-
The Database via App Inspection being"-
So finally
From a database aspect yes, they work after a few amendments. However, I suspect that your classes are probably not what you intended.
An Alternative Approach
If this were to be approached from a database perspective and normalised and without bloat and without the need for type converters then consider the following:-
The embedded Item's (uncheck and check) are basically repetition, so could probably be a table (related to the db_table). Hence 2 tables. One for the ListEntity (Alternative) and another for the Items (AlternativeItem) so the 2
@Entityannotated classes could be:-As you would typically want the Alternative along with it's related AlternativeItems then a POJO that caters for the togetherness :-
There would be a need for some extra functions in the
@Daoannotated interface, so :-insertAlternativeAndUncheckAndCheckdoes what it says (note that it is overly simple and could need some enhancements to expand upon the principle)To demonstrate this, all that is then required is to add the new entities to the
entities parameterand to then add some code to the activity.The amended
@Databaseannotation:-The activity code (that caters for both approaches in a similar/equivalanet way of storing and retrieving the data) :-
When run then the result is now:-
The database, via App Inspection (in regards to the alternative approach) is:-
and :-
i.e. only the actual data is store the BLOAT (field/type descriptions, separators, enclosing data) is not stored thus
However, the negative, is that more code and thought is required.
Note this answer is intended to deal with the basic principles and is most certainly not fully comprehensive.