Jun 1 | 7:25 PM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
chike m. | has entered the room |
Mark M. |
hello, chike!
|
Mark M. |
how can I help you today?
|
chike m. |
Hi Mark
|
chike m. |
ok, let me paste it
|
Jun 1 | 7:30 PM |
chike m. |
View paste
(25 more lines)
|
Mark M. |
first, get rid of the close() calls
|
Mark M. |
and I mean *all* the close() calls
|
chike m. |
ok
|
Mark M. |
as you would appear to be closing the database in many places, including the one triggering "The connection pool for /data/user/0/com.chikeandroid.debtmanager20.mock/databases/Debts.db has been closed but there are still 1 connections in use"
|
chike m. |
but it can lead to leaking of the db
|
Mark M. |
not if it is a singleton
|
Mark M. |
by definition, it was leaked when you wrote your app
|
chike m. |
ok
|
Mark M. |
a database is one of those things that typically we can never close, as we never know when it is safe to do so
|
Mark M. |
so, you just leave it open
|
Mark M. |
it will remain open as long as the process does
|
Mark M. |
(or, rather, as long as the process is alive)
|
chike m. |
So since it's a singleton, I should not close it
|
Mark M. |
and there is no particular harm in the process being terminated with an open database
|
Mark M. |
correct
|
Mark M. |
now, in some of my book samples, I close the database
|
Mark M. |
but that is because it is only being referenced in one class, typically a fragment
|
Mark M. |
and I know when I am done with it (i.e., when the fragment is destroyed)
|
chike m. |
alright, I get it now
|
Mark M. |
but, that's only typically practical for tiny projects
|
chike m. |
Alright, Mark! thanks
|
Mark M. |
I am not sure if you are familiar with "the seven stages of grief", but I too wanted to always close the database, and I went through those seven stages and am now at "acceptance" that we just don't need to do it
|
Mark M. |
"-)
|
Mark M. |
er, :-)
|
Mark M. |
(gosh, I cannot even type an emoticon today...)
|
Jun 1 | 7:35 PM |
chike m. |
haha
|
chike m. |
:-)
|
chike m. |
one more thing
|
chike m. |
If I am using Loaders in a fragment and also using setRetainInstance(true), just for retaining the data.
|
chike m. |
are they not performing the same thing somehow?
|
Mark M. |
yes
|
Mark M. |
a Loader will retain whatever it loaded (e.g., a Cursor)
|
Mark M. |
if the fragment gets recreated due to a configuration change, you will be given the loaded data again in the new fragment via the appropriate callback
|
Mark M. |
I do not think that I have tried using a Loader from a retained fragment, so I do not know if those will conflict
|
chike m. |
ok
|
chike m. |
I think I'm done for now!
|
Mark M. |
OK
|
chike m. |
Thanks Mark!
|
Mark M. |
you're welcome!
|
chike m. | has left the room |
Jun 1 | 8:25 PM |
Mark M. | turned off guest access |