В общем, я не рекомендую, чтобы объекты Room, отклики на модернизацию и подобные вещи рассматривались как модель данных в памяти. Они являются объектами передачи данных, поскольку на них распространяются ограничения, с которыми не нужно сталкиваться пользовательскому интерфейсу и логике в приложении. В случае чего-то вроде Retrofit способ организации данных и их доставки сервером может иметь мало общего с тем, как вы хотите работать с данными в приложении. В вашем случае вам нужны три отдельных столбца, что означает три различных свойства Kotlin, будь то в сущности или в @Embedded
объекте, как он у вас есть.
Типичный подход состоит в том, чтобы использовать PersonDTO
или PersonEntity
или что-то, что использует Комната, которую вы конвертируете в / из Person
объектов, имеющих желаемую структуру:
data class Person (val firstName: String,
val lastName: String,
val boolsheet: BooleanArray)
@Entity(tableName = "people_table")
data class PersonEntity (@ColumnInfo(name = "first_name") val firstName: String,
@ColumnInfo(name = "last_name") val lastName: String,
val a: Boolean = true,
val b: Boolean = true,
val c: Boolean = false
){
constructor(somebody: Person): this(
somebody.firstName,
somebody.lastName,
somebody.boolsheet[0],
somebody.boolsheet[1],
somebody.boolsheet[2]
)
@PrimaryKey(autoGenerate = true)
var id: Int = 0
fun toPerson(): Person = Person(firstName, lastName, booleanArrayOf(a, b, c))
}
Теперь, Person
и все, что с этим связано, ничего не знает о Room, и у вас есть API, который вы хотите. PersonEntity
будет использоваться вашим хранилищем, скрывая детали. И если когда-нибудь вам понадобится, чтобы хранилище также общалось с сервером, хранилище может нормализоваться между Person
и представлением, которое вам необходимо для вашего API веб-службы.
Если вам это не нравится, придерживайтесь Person
и @Embedded
и добавьте к нему val boolsheet = booleanArrayOf(bools.a, bools.b, bools.c)
, чтобы получить значения Boolean
в итерируемой структуре.