Office Hours Transcript: 2021-10-16

Kai_H joined

hello, Kai!

 

how can I help you today?

Hello Mark

 

I don’t have any questions, I think.

fynn joined

Kai: OK, if you come up with a question, chime in!

I just wanted to say thank you and that I think it sucks that you’re stopping the warescription and the bugs.

 

While I can understand it.

fynn: hi! I’ll be with you shortly!

 

Kai: well, I’m glad to stop the bugs 😁

books :D

 

It’s 10 pm at my place, I guess time for bed soon ;-)

 

So thanks for sticking with it for as long as you have.

 

And I’ll miss the office hours.

You live in the same time zone as I do, Kai_h :)

yeah, as I wrote in the blog post, it’s past time for me to try something new

And having an expert to talk to. Especially when I was very new to Android.

I am glad that all of this stuff was useful to you!

 

fynn: how can I help you today?

Hi Mark_Murphy! I’m experiencing some weird crashes due to an IllegalStateException during a room query. The cause appears to be that it can’t end a transaction without having started one first.

that is strange, given that Room usually manages transactions itself

 

are you doing anything unusual with transactions in your own code?

I have not written a manual transaction call

 

I open databases when the fragment is started (in onViewCreated) and close them when the Fragment is being destroyed (in onDestroy).

 

The crashes occur when switching fragments or when opening and closing the app switcher.

I open databases when the fragment is started (in onViewCreated) and close them when the Fragment is being destroyed (in onDestroy).

That’s an unusual pattern. Room is set up more to be managed via singletons (typically created via a dependency injection system: Dagger/Hilt, Koin, etc.)

 

I can see how you can get into trouble with transactions and the like that way

I was thinking about changing that, but I wasn’t sure if anything bad might happen if I don’t close my database after opening it.

 

For instance when instantiating it in the Application class.

generally, no – apps rarely explicitly close their databases

 

SQLite handles that fairly well

 

the big times that you want to explicitly close the database is if you are going to do things with the underlying SQLite files, such as copy them

 

I cover this in Elements of Android Room in the context of import/export and backup/restore sorts of things

I scanned that section earlier today

 

I’m glad to know what these two extra files are doing

ah, you mean the shm and wal files?

Yes, seeing those made me think that I probably shouldn’t leave my database as is

 

that is, not closing it

the problem with Android is that we do not get a reliable "hey, it’s time to close up shop now" event

 

the good news is that SQLite copes fairly well with that

Yes, feels a bit weird to have no place to put such code

if your concern is those files just continuing to grow and never get folded into the main db file, you could open-close-open when you initialize your singleton RoomDatabase

 

so, you open the database, close it right away to get SQLite to merge the WAL content, then re-open the database afterwards

 

I have not tried that in rapid succession, but AFAIK they should all be blocking calls and so there should not be a problem

 

but, in the end, the import/export scenario does the same stuff, just spread out a bit more in time

 

overall, though, your risks of problems are a lot greater by opening/closing the database based on user input

 

(such as in your current setup)

Can the database inspector in IDEA handle it when tables have shm and wal files that are not merged?

I have not played with IDEA’s inspector, but if it works like Studio’s, then yes

I think I had it that using sqlite3 on adb shell did not handle that

ah, that’s because it’s a separate process

(It should be the same very inspector we are using, both from the Android plugin for IDEA)

Studio’s invalidation tracker seems to be talking to our app process

 

anyway, I have neither seen nor heard of problems with the database inspector and WAL-enabled databases

 

and since Room enables WAL by default, I would assume that the Studio team took WAL into account

 

so, my general recommendation is: close when you are sure that it is safe to close

Alright, then I’ll simply put my Database in a place where every class can access it

and just not close it.

if it makes you feel better, it took me years to get comfortable with that

I’m not exactly comfortable, it sounds like quite the bad style :D

ideally, we would get an opportunity to do cleanup before our processes get terminated

 

as I like to point out: ideally, I would have hair

 

alas, this is not an ideal world

I wish it were, but that’s what we have to work with X)

 

Btw, do you know anyone else who is an Android expert and offers office hours, by any chance? ;-)

like these? I am not aware of anyone

Surely not for this kind of super-flat rate ;)

there are group chat options – Kotlinlang Slack, for example

 

and I think there’s a Discord or two floating around

Damn. You’ll leave a hole.

on the flip side, these office hours have steadily declined in attendance

I suppose that’s less fun then

I haven’t attended for quite some time X)

I found a broken link in search. The entry’s title is "Hey, What About Errors?" – I suppose this is not intended?

while it would be funny if it were, no, that’s not intended

 

what did you search on?

I was trying to find anything having to do with a "search bar in nav bar" kind of thing

 

The last one or two times I tried that it went horrible

 

(So I found the entry with "search" as a keyword)

 

yeah, I see that… I will need to figure out what went wrong

 

hmmmm… I removed that section when I updated to Paging 3

 

it must be the search index has an old entry, ugh

 

I will try to get that fixed tomorrow

 

thanks for pointing it out!

:+1:

 

The section about Views in Room in your book was helpful. I did not get the point and how to use it before reading it. Now I might employ it in one of my apps to reduce redundancy in all of its queries

the more complex the database, the more popular views get, and Android app databases often are not that complex

The scenarios is that some entries can be hidden by the user, and those should be ignored for most queries. So now I could do SELECT * FROM visibleItem to avoid forgetting about it.

 

(With visibleItem as a View that queries all visible Items, obviously.)

sounds reasonable!

I was looking into searching in an Android app and stumbled upon "search interfaces" and such. Do you have any idea how they came into existence?

I am sorry, but I am uncertain what you mean

OK, but what do you mean by "how they came into existence"?

I was surprised that it existed and wondered why they were implemented like this.

if you mean the whole "searchable configuration"/"searchable activity" stuff… there are reasons why you never heard of it

 

it was one of those ideas that Google threw against a wall, and it did not stick

It’s still in the documentation and we apparently use it X)

 

Are there alternatives or reasons not to use it?

for in-app search, just do whatever – you can see the simple-as-dirt searching that I have in the full-text search chapter of Elements of Room, for example

 

the overall idea was that Android would offer search that not only searches Google but also searches apps as well, and apps would advertise to participate in that

 

so, if you are looking to try to have your app results show up when users use the Google search bar widget, then this stuff may still be relevant

I noticed that it feels like it should be possible to search in an app from the general Android search, but it doesn’t seem to work

 

In our app, I mean.

I worked with this tech when it came out and it was seriously weird

You think that would still be possible? Doesn’t sound like a bad idea, to be able to search apps from the general search.

 

Yes, it feels weird. That something creates an intent over a search patch and then you have to catch it and do stuff.

I do not know if Android’s search actually uses this anymore – I would hope it does since the documentation suggests that it does

 

but, the documentation sometimes is out of sync with reality

Yes. I found some stuff that I thought was deprecated, if I remember correctly.

I think this kind of search is one of the things that I tried about which I said above that it went horrible

I have not thought about this option in years, and I do not know what the current trend is with respect to integration with Google/Android search

Ok, thanks.

OK, that’s a wrap for today’s chat!

 

The next one is tomorrow at the same time (4pm US Eastern).

Have a good weekend :)

Many thanks for your time!

you’re welcome, and have a pleasant evening!