hello, Francesco!

Hello

how can I help you today?

:-)

Well i am pretty new, so i have many doubts :-) But right now i'm trying to understand more about database management

I posted a question on stackoverflow, but it's submerged by thumbleweeds

do you have a link?

sure

just a sec

OK, give me a moment to review it

Of course, thank you so much!

hmmm... I thought I covered this in the book, but perhaps I haven't...

anyway, the answer pretty much is: you never close your database

nothing will actually ever close it

it will remain open until the process is terminated, for whatever reason

Oh i didn't read all the book yet :-)

however, SQLite is transactional, and so an open database doesn't have any sort of un-flushed buffers or anything

similarly, with a ContentProvider, you wind up in the same state: the ContentProvider opens the database and never closes it

this bugged me for quite some time, until enough other experts told me that I was a paranoid lunatic, and not closing the database is fine

Sorry, i don't really know what transactional exactly means

ummm...

most SQL-style databases, and plenty of NoSQL databases, have the concept of transactions

a transaction is a unit of work

Sounds something like "atomic"?

more or less

at least, they're similar concepts

Well, ok i'll surely read more about it, i lack some experience with dbs in general

for the purposes of this discussion, a transactional database means that everything will be written to disk as transactions are committed

and *everything* is in a transaction -- an individual SQL operation is in a transaction by itself if you don't bundle it into a larger transaction

hence, by the time your insert(), update(), delete(), execSQL(), etc. calls complete, the disk has everything

so there's no danger that different queries might make a mess by "interleaving"?

that's a separate issue

that's handled by using a singleton SQLiteOpenHelper, which will then give you thread safety

the transactional nature means that a "close" of a database really doesn't do much

and it definitely doesn't do anything that affects your data

so, the fact that we're not closing the database is not a big deal

if it wasn't transactional, closing it would be like a flush?

well, it could be

there are some systems in which if you do not cleanly close a connection, data corruption can occur as a result

the lower-level you get, the more likely it is you will run into such things

ok

so, for example, if you do your own disk I/O, you need to think about ensuring that the bytes are written to disk before you try having somebody else use a file

as, by default, they will be cached at the app and OS levels, being written out eventually

hello, EGHDK!

hello EGHDK :)

EGHDK: Francesco's had a shot, so it's your turn -- do you have a question?

OK, if either of you have a question, go ahead

Hey mark, question regarding proguard. I had it working but added a new jar to my project. I added it to my proguard-project.txt just like my other jars. `-libraryjars libs/metadata-extractor-2.6.4.jar` But now I can't export. It gives me a whole bunch of warnings.

Warning: com.drew.metadata.xmp.XmpDirectory: can't find referenced class com.adobe.xmp.

why are you using -libraryjars?

I know this is rather specific, but thought I'd give it a shot since you were in office hours.

I have no idea. I took a sample proguard-project from SO, because I couldn't get it to work. I saw that someone had a bunch of jars there, so I added all of mine as well, and it worked/export didn't fail.

AFAIK, that's not necessary

what may be necessary is to add more -keep directives to tell ProGuard not to obfuscate certain things

okay, I'm gonna remove the line and try to export again.

Francesco: if you have another question, go ahead

It's still related to my stackoverflow question. I did implement my own Application object, but online found different opinions about why it isn't ok and i should prefer a singleton object

Quick question. Does pulling down the notification tray/bar put the foreground activity in pause or stop or anything?

EGHDK: no, no lifecycle methods for that, IIRC

Francesco: I tend to steer people towards singletons over custom Application classes

in particular, you can have only one custom Application class, but N singletons

Ok, like to manage N different objects that each need to be unique?

no, more like "not glomming together a thousand lines of code into a single Application class, versus having cleaner code organization" :)

Ok :)

IOW, using Application because "I need something with global scope" isn't a great reason

however, places where you need a Context (like setting up a SQLiteOpenHelper), and where you may need to initialize it from arbitrary code paths, using Application is reasonable

so, in the case of your database logic, that's not a bad use of Application

Lol yes i did proceed with the "i need global scope" approach :)

getApplicationContext() though right? For DBs? You wouldn't have to create your own singleton context? (Jumping in on Freancescos question)

well, the Context you want for a singleton SQLiteOpenHelper is an Application (via getApplication()), so you don't leak a Context

what Francesco did was create a custom subclass of Application, and initialize a SQLiteOpenHelper there, in its onCreate()

using the Application instance itself as the Context

Gotcha.

So the better route for a singleton SQLiteOpenHelper (for an application that is constantly reading and writing to the DB) is to use getApplication() as the Context in the Constructor for SQLiteOpenHelper? Because in you're book Im certain that you say to use getApplicationContext()

getApplication() and getApplicationContext() do the same thing

never understood why they have both of them

they both return the singleton Application instance set up by the system

getApplication() is seven fewer characters :)

hahahah

Interesting.

You better re-write the DB section in your book to use the shorter method name. hahah

And also, I removed the -libraryjars and I'm getting the same error. I guess I'll post a SO question. Not a big deal.

I feel like I had other questions for you, but I can't remember them.

as I mentioned, you probably need to add some -keep directives to indicate stuff that ProGuard should not obfuscate

so anything with -keep proguard won't obfuscate?

correct

Okay. Very helpful. Thanks.

eventually, I'll add a ProGuard chapter to the book

though at my current pace, it might not be until 2015

(too much tech, too little time)

Yes yes yes.

:)

Now with Android Wear as well.

hahah.

yeah, I'll get to that once hardware is available to ordinary people

same thing with Glass

You must do this 24/7 though correct? I'm guessing you don't have time to work for any other company?

CommonsWare is a beyond-full-time gig

not 24/7, though

trust me: you want me to have slept decently before writing

hahaha. I believe you. Okay, so I was reading in my java book that basically the first time a java class is loaded, is will hold statics. So, is there any way to "unload" a class? Like lets say I have a static called MyObjectCount=0; and in the constructor I do an increment, then I will always have access to that static from other classes, but is there any way to unload it? Flush everything out?

Mark, using an AsyncTask to do the query in background is the same as using a CursorLoader (at least conceptually)?

"So, is there any way to "unload" a class?" -- not in Android

Francesco: CursorLoader extends AsyncTaskLoader, which uses an AsyncTask for its loading

you can certainly do your own AsyncTask or other form of background thread and do your queries there

not in Android... but in Java there is? What if the class I want to unload isn't part of the android framework... not extending Activity or Fragment or anything.

EGHDK: let me rephrase: not in the Dalvik VM, for classes that are part of the framework or the APK

there are some arcane tricks that can give you unloadable classes, but using them to "flush" statics is like swatting a fly with a Buick

just null out the static data members or otherwise reset them

Hah! I'll keep that in mind "swatting a fly with a Buick"

haha!

Last question for now. File I/O in android (and java) really frightens me. Gets me anxious knowing I have to work with the file system. Is there anything I should do thatll calm my nerves? aka. I always put off features that involve file io in my projects and I dont know what to do. I guess maybe start out with a few small projects? In my case it's mostly reading .txt/log files line by line, and also dealing with downloading .zips and then opening them in android and reading them.

"Is there anything I should do thatll calm my nerves?" -- IANAP (I am not a pharmacist)

the only thing with Java file I/O that's remotely tricky is ensuring that what you write is written fully to disk before you need somebody else to use it

otherwise, it's generally considered less scary, though more low-level, than database I/O

moreover, it's also stuff that's been done for a decade-plus, so there should be countless code snippets available, or JARs for common patterns (e.g., reading in a CSV)

IANAP thats a new one. Do you know off the top of your head if your book goes over i/o or if you have github projects with it? I'm slowly reading through from the very begining. and trying not to jump around.

Android adds its quirks in terms of where you can read and write and what permissions you might need for that, but it doesn't change the bulk of your code

I have a chapter on file storage, though it is focused on what makes Android different

your Java book should have material on standard Java file I/O

and that's a wrap for today's chat

the transcript will be posted to http://commonsware.com/office-hours/ later

EGHDK: excellent post as usual from Mr. Smith

Mark thank you so much

android storage confuses the hell outta me.

Alright mark. I'll be back. thanks again.

note that Version 5.7 of the book will be released in the next half-hour or so

you'll be able to grab your update from your Warescription page

I'll be publishing the chat transcript at the same time, so it'll come out a bit later than my normal couple-of-minutes delay

are changes usually posted on the homepage?

changes from 5.6 to 5.7

the most detailed changes are on the Warescription page and the CommonsBlog (http://commonsware.com/blog)

the Android page on the main site will have a few short bullet points on what's new (http://commonsware.com/Android)

plus the changebars and such in the book itself

the next office hours chat is not until April

due to some scheduling conflicts

have a pleasant day!