Can anytime AppDatabase in Android Room be null?
While adding Room Database, it is suggested to use Singleton Design Pattern
Note: You should follow the singleton design pattern when instantiating an AppDatabase object, as each RoomDatabase instance is fairly expensive, and you rarely need access to multiple instances.
So, adding Room Database, following Google example which is written in Java, in will be as below
private var INSTANCE: AppDatabase? = null
fun getInstance(context: Context): AppDatabase? {
if (INSTANCE == null){
synchronized(AppDatabase::class){
INSTANCE = Room.databaseBuilder(context.applicationContext,
AppDatabase::class.java, "app_database")
.build()
}
}
return INSTANCE
}
When I call getInstance, compiler suggests that getInstance can be null. So my question is there any case that getInstance be null and do I have to check if it's null. If not, then how should I instantiate AppDatabase so that getInstance return AppDatabase not AppDatabase? and it fits documentation recommendation?
kotlin singleton
edited Nov 19 '18 at 15:51
Jayson Minard
39.2k17108172
asked Nov 5 '18 at 6:26
musooffmusooff
496212
add a comment |
While adding Room Database, it is suggested to use Singleton Design Pattern
Note: You should follow the singleton design pattern when instantiating an AppDatabase object, as each RoomDatabase instance is fairly expensive, and you rarely need access to multiple instances.
So, adding Room Database, following Google example which is written in Java, in will be as below
private var INSTANCE: AppDatabase? = null
fun getInstance(context: Context): AppDatabase? {
if (INSTANCE == null){
synchronized(AppDatabase::class){
INSTANCE = Room.databaseBuilder(context.applicationContext,
AppDatabase::class.java, "app_database")
.build()
}
}
return INSTANCE
}
When I call getInstance, compiler suggests that getInstance can be null. So my question is there any case that getInstance be null and do I have to check if it's null. If not, then how should I instantiate AppDatabase so that getInstance return AppDatabase not AppDatabase? and it fits documentation recommendation?
kotlin singleton
edited Nov 19 '18 at 15:51
Jayson Minard
39.2k17108172
asked Nov 5 '18 at 6:26
musooffmusooff
496212
add a comment |
While adding Room Database, it is suggested to use Singleton Design Pattern
Note: You should follow the singleton design pattern when instantiating an AppDatabase object, as each RoomDatabase instance is fairly expensive, and you rarely need access to multiple instances.
So, adding Room Database, following Google example which is written in Java, in will be as below
private var INSTANCE: AppDatabase? = null
fun getInstance(context: Context): AppDatabase? {
if (INSTANCE == null){
synchronized(AppDatabase::class){
INSTANCE = Room.databaseBuilder(context.applicationContext,
AppDatabase::class.java, "app_database")
.build()
}
}
return INSTANCE
}
When I call getInstance, compiler suggests that getInstance can be null. So my question is there any case that getInstance be null and do I have to check if it's null. If not, then how should I instantiate AppDatabase so that getInstance return AppDatabase not AppDatabase? and it fits documentation recommendation?
kotlin singleton
edited Nov 19 '18 at 15:51
Jayson Minard
39.2k17108172
asked Nov 5 '18 at 6:26
musooffmusooff
496212
While adding Room Database, it is suggested to use Singleton Design Pattern
Note: You should follow the singleton design pattern when instantiating an AppDatabase object, as each RoomDatabase instance is fairly expensive, and you rarely need access to multiple instances.
So, adding Room Database, following Google example which is written in Java, in will be as below
private var INSTANCE: AppDatabase? = null
fun getInstance(context: Context): AppDatabase? {
if (INSTANCE == null){
synchronized(AppDatabase::class){
INSTANCE = Room.databaseBuilder(context.applicationContext,
AppDatabase::class.java, "app_database")
.build()
}
}
return INSTANCE
}
When I call getInstance, compiler suggests that getInstance can be null. So my question is there any case that getInstance be null and do I have to check if it's null. If not, then how should I instantiate AppDatabase so that getInstance return AppDatabase not AppDatabase? and it fits documentation recommendation?
kotlin singleton
kotlin singleton
edited Nov 19 '18 at 15:51
Jayson Minard
39.2k17108172
asked Nov 5 '18 at 6:26
musooffmusooff
496212
edited Nov 19 '18 at 15:51
Jayson Minard
39.2k17108172
asked Nov 5 '18 at 6:26
musooffmusooff
496212
edited Nov 19 '18 at 15:51
Jayson Minard
39.2k17108172
edited Nov 19 '18 at 15:51
Jayson Minard
39.2k17108172
edited Nov 19 '18 at 15:51
Jayson Minard
39.2k17108172
39.2k17108172
asked Nov 5 '18 at 6:26
musooffmusooff
496212
asked Nov 5 '18 at 6:26
musooffmusooff
496212
asked Nov 5 '18 at 6:26
musooffmusooff
496212
496212
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Use something like this to make sure it is not null
object DatabaseSource {
private lateinit var INSTANCE: AppDatabase
fun getInstance(context: Context): AppDatabase {
if (!::INSTANCE.isInitialized) {
synchronized(AppDatabase::class) {
if (!::INSTANCE.isInitialized) {
INSTANCE = Room.databaseBuilder(context.applicationContext,
AppDatabase::class.java,
"app_database").build()
}
}
}
return INSTANCE
}
}
Call it with:
val db = DatabaseSource.getInstance(context)
And this will never be null so you no longer have that issue.
I added double locking to be safer for thread safety on the getInstance() call.
But really you should be using dependency injection with singletons to avoid this passed in dependency of context and this manual creation/locking. You'll have to have the context available everywhere which is a bad pattern.
This also acts as an answer to your other post which is apparently a duplicate of this one.
answered Nov 19 '18 at 17:40
Jayson MinardJayson Minard
39.2k17108172
That indeed was what I am looking for. But how would I pass thecontexthere? Since I am creating INSTANCE in mycompanion object, it's not a good practice to havecontextinside static fields. Looking google sample, I see that they usealsowhich works perfectly. What do you say?
– musooff
Nov 20 '18 at 2:16
Are you using dependency injection? because this seems like it should be injected as a singleton, and the context should be made available for injection as well.
– Jayson Minard
Nov 20 '18 at 2:38
1
The comment about not usinglateinitthere is not universally a valid comment. It is fine in any context where you KNOW the lifecycle gaurantees it will be instantiated before use. Here the only way to access it is by a method that guarantees it is valid. So you are fine. The other comment is not relevant without this context.
– Jayson Minard
Nov 20 '18 at 3:07
1
I saw your proposed edit of volatile, but since this is only modified under lock, and we are checking if assigned which is I believe a bit field that would not be partially set. You can add it if you want, but not sure it is really what you want and will just add more contention on accessing it.
– Jayson Minard
Nov 20 '18 at 3:11
1
Let's not add things we see in other posts without reason.
– Jayson Minard
Nov 20 '18 at 3:12
|
show 4 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53149350%2fcan-anytime-appdatabase-in-android-room-be-null%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Use something like this to make sure it is not null
object DatabaseSource {
private lateinit var INSTANCE: AppDatabase
fun getInstance(context: Context): AppDatabase {
if (!::INSTANCE.isInitialized) {
synchronized(AppDatabase::class) {
if (!::INSTANCE.isInitialized) {
INSTANCE = Room.databaseBuilder(context.applicationContext,
AppDatabase::class.java,
"app_database").build()
}
}
}
return INSTANCE
}
}
Call it with:
val db = DatabaseSource.getInstance(context)
And this will never be null so you no longer have that issue.
I added double locking to be safer for thread safety on the getInstance() call.
But really you should be using dependency injection with singletons to avoid this passed in dependency of context and this manual creation/locking. You'll have to have the context available everywhere which is a bad pattern.
This also acts as an answer to your other post which is apparently a duplicate of this one.
answered Nov 19 '18 at 17:40
Jayson MinardJayson Minard
39.2k17108172
That indeed was what I am looking for. But how would I pass thecontexthere? Since I am creating INSTANCE in mycompanion object, it's not a good practice to havecontextinside static fields. Looking google sample, I see that they usealsowhich works perfectly. What do you say?
– musooff
Nov 20 '18 at 2:16
Are you using dependency injection? because this seems like it should be injected as a singleton, and the context should be made available for injection as well.
– Jayson Minard
Nov 20 '18 at 2:38
1
The comment about not usinglateinitthere is not universally a valid comment. It is fine in any context where you KNOW the lifecycle gaurantees it will be instantiated before use. Here the only way to access it is by a method that guarantees it is valid. So you are fine. The other comment is not relevant without this context.
– Jayson Minard
Nov 20 '18 at 3:07
1
I saw your proposed edit of volatile, but since this is only modified under lock, and we are checking if assigned which is I believe a bit field that would not be partially set. You can add it if you want, but not sure it is really what you want and will just add more contention on accessing it.
– Jayson Minard
Nov 20 '18 at 3:11
1
Let's not add things we see in other posts without reason.
– Jayson Minard
Nov 20 '18 at 3:12
|
show 4 more comments
Use something like this to make sure it is not null
object DatabaseSource {
private lateinit var INSTANCE: AppDatabase
fun getInstance(context: Context): AppDatabase {
if (!::INSTANCE.isInitialized) {
synchronized(AppDatabase::class) {
if (!::INSTANCE.isInitialized) {
INSTANCE = Room.databaseBuilder(context.applicationContext,
AppDatabase::class.java,
"app_database").build()
}
}
}
return INSTANCE
}
}
Call it with:
val db = DatabaseSource.getInstance(context)
And this will never be null so you no longer have that issue.
I added double locking to be safer for thread safety on the getInstance() call.
But really you should be using dependency injection with singletons to avoid this passed in dependency of context and this manual creation/locking. You'll have to have the context available everywhere which is a bad pattern.
This also acts as an answer to your other post which is apparently a duplicate of this one.
answered Nov 19 '18 at 17:40
Jayson MinardJayson Minard
39.2k17108172
That indeed was what I am looking for. But how would I pass thecontexthere? Since I am creating INSTANCE in mycompanion object, it's not a good practice to havecontextinside static fields. Looking google sample, I see that they usealsowhich works perfectly. What do you say?
– musooff
Nov 20 '18 at 2:16
Are you using dependency injection? because this seems like it should be injected as a singleton, and the context should be made available for injection as well.
– Jayson Minard
Nov 20 '18 at 2:38
1
The comment about not usinglateinitthere is not universally a valid comment. It is fine in any context where you KNOW the lifecycle gaurantees it will be instantiated before use. Here the only way to access it is by a method that guarantees it is valid. So you are fine. The other comment is not relevant without this context.
– Jayson Minard
Nov 20 '18 at 3:07
1
I saw your proposed edit of volatile, but since this is only modified under lock, and we are checking if assigned which is I believe a bit field that would not be partially set. You can add it if you want, but not sure it is really what you want and will just add more contention on accessing it.
– Jayson Minard
Nov 20 '18 at 3:11
1
Let's not add things we see in other posts without reason.
– Jayson Minard
Nov 20 '18 at 3:12
|
show 4 more comments
Use something like this to make sure it is not null
object DatabaseSource {
private lateinit var INSTANCE: AppDatabase
fun getInstance(context: Context): AppDatabase {
if (!::INSTANCE.isInitialized) {
synchronized(AppDatabase::class) {
if (!::INSTANCE.isInitialized) {
INSTANCE = Room.databaseBuilder(context.applicationContext,
AppDatabase::class.java,
"app_database").build()
}
}
}
return INSTANCE
}
}
Call it with:
val db = DatabaseSource.getInstance(context)
And this will never be null so you no longer have that issue.
I added double locking to be safer for thread safety on the getInstance() call.
But really you should be using dependency injection with singletons to avoid this passed in dependency of context and this manual creation/locking. You'll have to have the context available everywhere which is a bad pattern.
This also acts as an answer to your other post which is apparently a duplicate of this one.
answered Nov 19 '18 at 17:40
Jayson MinardJayson Minard
39.2k17108172
Use something like this to make sure it is not null
object DatabaseSource {
private lateinit var INSTANCE: AppDatabase
fun getInstance(context: Context): AppDatabase {
if (!::INSTANCE.isInitialized) {
synchronized(AppDatabase::class) {
if (!::INSTANCE.isInitialized) {
INSTANCE = Room.databaseBuilder(context.applicationContext,
AppDatabase::class.java,
"app_database").build()
}
}
}
return INSTANCE
}
}
Call it with:
val db = DatabaseSource.getInstance(context)
And this will never be null so you no longer have that issue.
I added double locking to be safer for thread safety on the getInstance() call.
But really you should be using dependency injection with singletons to avoid this passed in dependency of context and this manual creation/locking. You'll have to have the context available everywhere which is a bad pattern.
This also acts as an answer to your other post which is apparently a duplicate of this one.
answered Nov 19 '18 at 17:40
Jayson MinardJayson Minard
39.2k17108172
edited Nov 20 '18 at 3:13
answered Nov 19 '18 at 17:40
Jayson MinardJayson Minard
39.2k17108172
answered Nov 19 '18 at 17:40
Jayson MinardJayson Minard
39.2k17108172
answered Nov 19 '18 at 17:40
Jayson MinardJayson Minard
39.2k17108172
39.2k17108172
That indeed was what I am looking for. But how would I pass thecontexthere? Since I am creating INSTANCE in mycompanion object, it's not a good practice to havecontextinside static fields. Looking google sample, I see that they usealsowhich works perfectly. What do you say?
– musooff
Nov 20 '18 at 2:16
Are you using dependency injection? because this seems like it should be injected as a singleton, and the context should be made available for injection as well.
– Jayson Minard
Nov 20 '18 at 2:38
1
The comment about not usinglateinitthere is not universally a valid comment. It is fine in any context where you KNOW the lifecycle gaurantees it will be instantiated before use. Here the only way to access it is by a method that guarantees it is valid. So you are fine. The other comment is not relevant without this context.
– Jayson Minard
Nov 20 '18 at 3:07
1
I saw your proposed edit of volatile, but since this is only modified under lock, and we are checking if assigned which is I believe a bit field that would not be partially set. You can add it if you want, but not sure it is really what you want and will just add more contention on accessing it.
– Jayson Minard
Nov 20 '18 at 3:11
1
Let's not add things we see in other posts without reason.
– Jayson Minard
Nov 20 '18 at 3:12
|
show 4 more comments
That indeed was what I am looking for. But how would I pass thecontexthere? Since I am creating INSTANCE in mycompanion object, it's not a good practice to havecontextinside static fields. Looking google sample, I see that they usealsowhich works perfectly. What do you say?
– musooff
Nov 20 '18 at 2:16
Are you using dependency injection? because this seems like it should be injected as a singleton, and the context should be made available for injection as well.
– Jayson Minard
Nov 20 '18 at 2:38
1
The comment about not usinglateinitthere is not universally a valid comment. It is fine in any context where you KNOW the lifecycle gaurantees it will be instantiated before use. Here the only way to access it is by a method that guarantees it is valid. So you are fine. The other comment is not relevant without this context.
– Jayson Minard
Nov 20 '18 at 3:07
1
I saw your proposed edit of volatile, but since this is only modified under lock, and we are checking if assigned which is I believe a bit field that would not be partially set. You can add it if you want, but not sure it is really what you want and will just add more contention on accessing it.
– Jayson Minard
Nov 20 '18 at 3:11
1
Let's not add things we see in other posts without reason.
– Jayson Minard
Nov 20 '18 at 3:12
That indeed was what I am looking for. But how would I pass the
context here? Since I am creating INSTANCE in my companion object, it's not a good practice to have context inside static fields. Looking google sample, I see that they use also which works perfectly. What do you say?– musooff
Nov 20 '18 at 2:16
That indeed was what I am looking for. But how would I pass the
context here? Since I am creating INSTANCE in my companion object, it's not a good practice to have context inside static fields. Looking google sample, I see that they use also which works perfectly. What do you say?– musooff
Nov 20 '18 at 2:16
Are you using dependency injection? because this seems like it should be injected as a singleton, and the context should be made available for injection as well.
– Jayson Minard
Nov 20 '18 at 2:38
Are you using dependency injection? because this seems like it should be injected as a singleton, and the context should be made available for injection as well.
– Jayson Minard
Nov 20 '18 at 2:38
1
1
The comment about not using
lateinit there is not universally a valid comment. It is fine in any context where you KNOW the lifecycle gaurantees it will be instantiated before use. Here the only way to access it is by a method that guarantees it is valid. So you are fine. The other comment is not relevant without this context.– Jayson Minard
Nov 20 '18 at 3:07
The comment about not using
lateinit there is not universally a valid comment. It is fine in any context where you KNOW the lifecycle gaurantees it will be instantiated before use. Here the only way to access it is by a method that guarantees it is valid. So you are fine. The other comment is not relevant without this context.– Jayson Minard
Nov 20 '18 at 3:07
1
1
I saw your proposed edit of volatile, but since this is only modified under lock, and we are checking if assigned which is I believe a bit field that would not be partially set. You can add it if you want, but not sure it is really what you want and will just add more contention on accessing it.
– Jayson Minard
Nov 20 '18 at 3:11
I saw your proposed edit of volatile, but since this is only modified under lock, and we are checking if assigned which is I believe a bit field that would not be partially set. You can add it if you want, but not sure it is really what you want and will just add more contention on accessing it.
– Jayson Minard
Nov 20 '18 at 3:11
1
1
Let's not add things we see in other posts without reason.
– Jayson Minard
Nov 20 '18 at 3:12
Let's not add things we see in other posts without reason.
– Jayson Minard
Nov 20 '18 at 3:12
|
show 4 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53149350%2fcan-anytime-appdatabase-in-android-room-be-null%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
