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)
It links to https://wares.commonsware.com/app/internal/book/Room/page/chap-paging-005.html, which just redirects to the catalog.
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!