Hello Mark, nice to talk to you again.

hello, Andre!

how can I help you today?

Ok. If you remember I am struggling to get Room going on my previous SQLiteHelper Database app.

I got rid of Dagger and am making my database injection like this link

I think this way I could have more control opening and closing the database to perform my backup copy and restoration

OK, but I don't know what you are asking, so I don't know what to tell you

I can manage to make the copy of my database to the sdcard with the database closed or opened. The problem is trying to open the database again if I close it.

I have this error E/ROOM: Invalidation tracker is initialized twice :/.

when I use (Room database instance) db.openHelper.writableDatabase to open it again

it's possible that you are encountering a bug/limitation in Room

and then my app crashes with the message Cannot perform this operation because the connection pool has been closed

That is why I dont

hmmm... I filed a somewhat related issue here: https://issuetracker.google.com/issues/65820362

don't close it to copy the backup. Is there a problem to keep it opened while copying the file to the scared?

sdcard sorry

the risk is if other code -- such as the invalidation tracker -- tries doing database I/O while you are in the middle of copying

the primary objective is to ensure that nothing can be manipulating the database in the middle of a copy

Ok, so if I am sure that I am not making any kind of request to the database I am ok ?

um, well, Room has its own stuff that accesses the database, such as the aforementioned invalidation tracker

so, if the RoomDatabase is open, I am not certain how you can be sure that nothing else is working with the database while the copy is occurring

So for now we are risking the data trying to do a backup with Room ?

at least via the file-copy approach, yes, if we can't close and reopen the database, IMHO

Well than an option is to close it, make the copy and kill the app.

At least we have the backup.

that doesn't sound user-friendly

this is one of the reasons why I need to dig into this subject more

and it's one of the reasons why I'm kicking myself for not having addressed this previously

too many things to do, too little time...

we need a clear solution for the backup problem

and it sounds like the direction that I would be going is a direction that isn't working

which means we need Googly advice, I suspect

Andre: let me take a question from Ettie, and I'll return to you in a little bit

Ettie: hi! welcome to the chat!

if you have an Android app development question, fire away, and I can try to answer it

Ettie: if you come up with a question, chime in, and I can turn to you

but, in the meantime...

Andre: back to you! do you have another question?

Ok. I have managed to restore a backup by deleting the data in the active database, attaching the database file in scard and copying its content to the active database. It is taking more time than when I was able to close the database and just copy the file.

I am using RxJava and tryied

I am not surprised that attach-and-copy is slower than a straight copy

straight file copy, that is

tried this solution: http://tomstechnicalblog.blogspot.com.br/2016/0...

that's unlikely to help here

as you are single-threaded on the database access, at the SQLiteDatabase level

Yes I have noticed, you already answered my question.

Hi. Sorry for the interruption. Can I ask about Services in Android 8?

Ettie: sure, go right ahead!

Thanks! I've been reading up on how to handle a Service in Android 8, which up till now, worked just fine. I've tried to use startForeground() but for some reason, I can't get the notification to show while the Service is running. I even converted my Service class into an IntentService just to see if it would work, but the same thing happened. Any ideas?

Ok, so in your opinion, according to the actual moment of the Room database, I am in the right path of doing and restoring my backups ?

Andre: yes, though, again, I'm nervous about keeping the database open

Ettie: I am having a bit of difficulty following that code

are you sure that shouldServiceRun() is returning true?

beyond that, this code will only have your service be foreground during the "//all functions and calculations here" part

so, depending on how quick that is, you might not see the actual foreground effect

True, but I see the notification from Android that an app is running in the background.

I'm not sure why that happens instead of the foreground notification.

shouldServiceRun() will return true.

if you have not done so already, try fully uninstalling the app, then running it again

particularly if you were trying other importance levels previously

BTW, Andre, at this point, I'll try to take questions from both of you simultaneously, so chime in if you have a question

It is funny this issue because we have this post

and there she opens and closes the database in all method

with the SupportSQLiteOpenHelper

like I said, I need to spend more time on the database-closing issue

but, particularly with a blog post with a handful of snippets, take the code with a grain of salt

I mean because to get a SupportSQLiteOpenHelper you have to instantiate Room database

agreed

After uninstalling and reinstalling, I see that the foreground notification shows and disappears quickly and then app is running in background notification appears.

Looks like something is working, but maybe not long enough?

that implies that you are calling stopForeground(), but the service is still considered to be running

is this the IntentService edition of your code?

Yes.

OK, that's strange, as the service should be destroyed once onHandleIntent() returns

Thank you for the support, despite of all I am a little bit happy that I was not totally wrong. See you.

Andre: sorry I didn't have anything better for you!

I will keep in touch to get any news. Thanks.

Ettie: I'm not sure why the running-in-the-background notification is showing up if the service is destroyed

should I move the stopForeground() to the onDestroy()?

that would be a worthwhile experiment

for example, if your notification then sticks around, and you're sure that the background work is done, that implies that something is keeping your service around

I see.

Reviewing my onDestroy(), I already put stopForeground() and then stopSelf() in an if statement checking if it's Android O or not.

you don't need stopSelf() in onDestroy(), as the service is already being destroyed

you might consider adding some Log statements to see what of your code is getting executed when

or, if you prefer, set breakpoints and run the app in the debugger

Ok. Thanks.

Thanks for your time and your insights.

sorry that I didn't have a clear solution for you

I still appreciate it. Thanks.