I´m working with RoomDatabase and after setting up my DAO, Database, and Entity classes I need to find a way to get the RoomDatabase instance, but on the documentation, I see this:
If your app runs in a single process, you should follow the singleton
design pattern when instantiating an AppDatabase object. Each
RoomDatabase instance is fairly expensive, and you rarely need access
to multiple instances within a single process.
So from the Udacity courses I see there are various ways to do this the first one:
private lateinit var INSTANCE: MainDBForObjects
fun getDatabase(context: Context): MainDBForObjects{
if (!::INSTANCE.isInitialized){
INSTANCE = Room.databaseBuilder(
context,
MainDBForObjects::class.java, "database"
).fallbackToDestructiveMigration()
.build()
}
return INSTANCE
}
and the other one is with a companion object from the database abstract class:
companion object {
#Volatile
private var INSTANCE: SleepDatabase? = null
fun getInstance(context: Context): SleepDatabase {
synchronized(this) {
var instance = INSTANCE
if (instance == null) {
instance = Room.databaseBuilder(
context.applicationContext,
SleepDatabase::class.java,
"sleep_history_database"
)
.fallbackToDestructiveMigration()
.build()
INSTANCE = instance
}
return instance
}
}
}
So is there any important difference between these 2? is it one better than the other?
Added an implementation to create a Singleton object through double check locking.
This would ensure that a lock is only acquired when required (if the database object is uninitialized) as synchronization is generally expensive
The double check here refers to the null check again within synchronized block, this helps us in scenarios where a thread A had acquired the lock to initialize the object for the first time and other threads were also waiting for it (thread B, C) now as soon as thread A initializes the object and releases the lock all waiting threads immediately get the updated value.
The need for using a local variable is to ensure that partially initialized objects are not visible to threads leading to inconsistent state (related to language semantics, more info here --> https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java)
companion object {
#Volatile
private var sInstance: SleepDatabase? = null
#JvmStatic
fun getInstance(context: Context): SleepDatabase {
val localInstance = sInstance
if (localInstance != null) {
return localInstance
}
return synchronized(this) {
var instance = sInstance
if (instance == null) {
instance = Room.databaseBuilder(
context.applicationContext,
SleepDatabase::class.java,
"sleep_history_database"
)
.fallbackToDestructiveMigration()
.build()
sInstance = instance
}
instance
}
}
}
Related
I'm a beginner to Android development.
When making a singleton in the Application Context, here is my code.
I pass the application context to the instantiation
class Blah{
companion object {
#Volatile
private var INSTANCE: Blah? = null
//Singleton
fun getInstance(applicationContext: Context): Blah =
INSTANCE ?: synchronized(this) {
INSTANCE ?: Blah(applicationContext).also { INSTANCE = it }
}
}
}
Can I pass the application directly to the instantiation? Like so:
class Blah{
companion object {
#Volatile
private var INSTANCE: Blah? = null
//Singleton
fun getInstance(application: Application): Blah =
INSTANCE ?: synchronized(this) {
INSTANCE ?: Blah(application).also { INSTANCE = it }
}
}
}
Will this present memory leaks?
Application is also a singleton. This doesn't cause a memory leak because there is only one instance of Application and when your app is running you have one and when your app isn't running there is nothing there, so go for it.
According to documentation room instance from Room.databaseBuilder() should save data is persist. But still get lost. My Project have to database
First Database
#Database(entities = [FoodModel::class], version = 4, exportSchema = false)
abstract class FoodDatabase : RoomDatabase() {
abstract val foodDatabaseDao: FoodDatabaseDao
companion object {
#Volatile
private var INSTANCE: FoodDatabase? = null
fun getInstance(context: Context): FoodDatabase {
synchronized(this) {
var instance = INSTANCE
if (instance == null) {
instance = Room.databaseBuilder(
context.applicationContext,
FoodDatabase::class.java,
Constants.OVERVIEW_FOOD_DATABASE
)
.fallbackToDestructiveMigration()
.build()
INSTANCE = instance
}
return instance
}
}
}
}
Second Databse
#Database(entities = [MyFoodModel::class], version = 3, exportSchema = false)
abstract class MyFoodDatabase : RoomDatabase() {
abstract val myFoodDatabaseDao: MyFoodDatabaseDao
companion object {
#Volatile
private var INSTANCE: MyFoodDatabase? = null
fun getInstance(context: Context): MyFoodDatabase {
synchronized(this) {
var instance = INSTANCE
if (instance == null) {
instance = Room.databaseBuilder(
context.applicationContext,
MyFoodDatabase::class.java,
Constants.OVERVIEW_FOOD_DATABASE
)
.fallbackToDestructiveMigration()
.build()
INSTANCE = instance
}
return instance
}
}
}
}
Dao of first Database
#Dao
interface MyFoodDatabaseDao {
#Insert
fun insert(food: MyFoodModel)
#Query("SELECT * FROM MyFoodItems ORDER BY name DESC")
fun getAllFood(): LiveData<List<MyFoodModel>>
#Delete
fun deleteFood(foodModel: MyFoodModel)
}
Dao of Second database
#Dao
interface MyFoodDatabaseDao {
#Insert
fun insert(food: MyFoodModel)
#Query("SELECT * FROM MyFoodItems ORDER BY name DESC")
fun getAllFood(): LiveData<List<MyFoodModel>>
#Delete
fun deleteFood(foodModel: MyFoodModel)
}
An android application can have more than one database.
Here as I can see, You are providing same name [Constants.OVERVIEW_FOOD_DATABASE] to your both the databases [MyFoodDatabase, FoodDatabase]. So all values will be written in one database named as Constants.OVERVIEW_FOOD_DATABASE.
Please provide both the database different name and try again.
Edited
As you said, you are using two different instance of same databases and for every database instance, you are changing the database version but you are not migrating your database into that version. Instead you are using fallbackToDestructiveMigration() that does not crash database but clear the data when any existing version is found.
Please try below steps:
remove fallbackToDestructiveMigration() from both database instances.
in second instance add .addMigrations(MIGRATION_1_2) while creating
instance
val MIGRATION_1_2 = object : Migration(1, 2) {
override fun migrate(database: SupportSQLiteDatabase) {
// do nothing because you are not altering any table
}
}
in First instance add .addMigrations(MIGRATION_2_1) while creating instance
val MIGRATION_2_1 = object : Migration(2, 1) {
override fun migrate(database: SupportSQLiteDatabase) {
// do nothing because you are not altering any table
}
}
It will migrate you same database. In my case it is working. I hope it will work in your case too. :)
But it is better to use single database instance and include the list of entities associated with the database within the annotation.
Because room database instances are expensive.
https://developer.android.com/training/data-storage/room
Note: If your app runs in a single process, you should follow the singleton design pattern when instantiating an AppDatabase object. Each RoomDatabase instance is fairly expensive, and you rarely need access to multiple instances within a single process.
If your app runs in multiple processes, include enableMultiInstanceInvalidation() in your database builder invocation. That way, when you have an instance of AppDatabase in each process, you can invalidate the shared database file in one process, and this invalidation automatically propagates to the instances of AppDatabase within other processes.
companion object {
#Volatile
private lateinit var instance: ExampleDatabase
fun getInstance(context: Context): ExampleDatabase {
synchronized(this) {
if(!::instance.isInitialized) {
instance = Room.databaseBuilder(
context.applicationContext, // Why does this require context?
LottoDatabase::class.java,
"lotto_database"
)
.fallbackToDestructiveMigration()
.build()
}
return instance
}
}
}
The above code is the general way of creating singleton of the room database.
I wonder why Room.databaseBuilder function requires a context as the parameter. I know this question might be stupid cuz I'm lack understanding of the Context in Android.
What argument should I pass in that parameter?
What can be different if I pass in the Activity context or application?
I'm following the Android Room with a View - Kotlin code lab and I came across the following code:
companion object {
// Singleton prevents multiple instances of database opening at the
// same time.
#Volatile
private var INSTANCE: WordRoomDatabase? = null
fun getDatabase(context: Context): WordRoomDatabase {
val tempInstance = INSTANCE
if (tempInstance != null) {
return tempInstance
}
synchronized(this) {
val instance = Room.databaseBuilder(
context.applicationContext,
WordRoomDatabase::class.java,
"word_database"
).build()
INSTANCE = instance
return instance
}
}
}
For the most part, this makes sense. However, I'm a little confused by the synchronization part. Technically, couldn't two threads call getDatabase at the same time, and both of them get past the if statement and then each create their own database handles? I would think all of the code in getDatabase needs to be protected by the mutex. Why does only the creation part need to be protected by a mutex?
I am new to Kotlin. Still learning basic syntax.
I've heard about companion objects similar to static in Java. But don't know how to create synchronized singleton in Kotlin.
Just use
object Singleton {
// any members you need
}
It's already synchronized properly:
Object declaration's initialization is thread-safe.
Note that this doesn't guarantee calls on it thread-safe, but that's just as in Java.
There are also other ways, but those two are the most simple ones to generate a singleton class
Method 1- Kotlin Way
object SingletonObj {
init {
// do your initialization stuff
}
}
Method 2- Double Null Check Way in Kotlin
class SingletonObj {
private constructor(context: Context)
companion object {
#Volatile private var mInstance: SingletonObj? = null
public fun get(context: Context): SingletonObj =
mInstance ?: synchronized(this) {
val newInstance = mInstance ?: SingletonObj(context).also { mInstance = it }
newInstance
}
}
}
I think, little bit more research, and i found it . Here is how to do it . Please correct me if it can be done in better way.
companion object {
#Volatile private var INSTANCE: Singleton ? = null
fun getInstance(): Singleton {
if(INSTANCE == null){
synchronized(this) {
INSTANCE = Singleton()
}
}
return INSTANCE!!
}
}
Thread-safe and lazy:
class Singleton private constructor() {
companion object {
val instance: Singleton by lazy { Singleton() }
}
}
Double null check already implemented inside by lazy.