0

Having written couple of little apps I realized now - reading through the activity lifecycle docs several times again http://developer.android.com/reference/android/app/Activity.html - that there are good guidelines on how to structure activities which I haven't followed.

I would just like to get clarity around this in cases of user screen activities that work with DB values.

Is this the best recommended way to structure activities that require user interaction in combination with DB usage?

1. onCreate()
  • setContentView
  • get and set the fixed UI elements such as x = findViewById
  • set the setOnClickListeners and other Listeners
  • any other stable/unchanged elements of the activity
2. onResume()
  • since its also called AFTER EACH onCreate...
  • open DB here
  • get values from DB
  • fill the user fields with DB dependant values
  • configure the screen elements which depend on DB values as opposed to those that are stable

3 . onPause()

  • finish all DB updates ensuring consistent DBs
  • save all user created data that is required when activity resumes again
  • close DB

Certainly this is not black and white, but do I understand it correctly that this is a general design principle in such cases so the activity is stable and reliable to interruptions such as phone calls, low memory situations, etc...

Many thanks four your input!

user387184
  • 10,953
  • 12
  • 77
  • 147

1 Answers1

0

I would argue closing the DB is not that critical: http://www.touchlab.co/blog/single-sqlite-connection/

There have been a number of posts on this. Recent one:

SQLiteDatabase close() function causing NullPointerException when multiple threads

Also, I'm not sure why you would do all of your db calls in onResume. If you're just loading the data once, it would also do well in onCreate (I would put that in an AsyncTask, though).

Community
  • 1
  • 1
Kevin Galligan
  • 16,159
  • 5
  • 42
  • 62
  • first, I think the DB might get corrupted if not closed in one activity when switching to another which also opens the DB. second, onCreate is NOT called when app resumes from interruptions and during the activity the DB data might have been changed by the user - these changes will not be reflected when loading only in onCreate after activity resumes.. That's why I thought it's recommended to do it in onResume – user387184 Nov 06 '11 at 22:36
  • "first, I think the DB might get corrupted if not closed in one activity when switching to another which also opens the DB" No. It will not get corrupted. You could have problems writing from 2 threads, but deadlock problems. Not corruption. Without hardware issues, you will never corrupt your sqlite db, unless you literally write over the file. Please read the blog post. The idea is you keep a singleton connection that all activities/services share. http://www.touchlab.co/blog/single-sqlite-connection/ – Kevin Galligan Nov 06 '11 at 22:44
  • "onCreate is NOT called when app resumes from interruptions and during the activity the DB data might have been changed by the user" That's a reason not to do it in onCreate. I agree. It seemed like you were looking for general guidelines. If the data would not be changed by the user, doing it in onResume wouldn't be a great idea, right? It all depends (short version, there aren't too many hard and fast "general rules"). – Kevin Galligan Nov 06 '11 at 22:46
  • all right, I got it - good approach, and certainly a good alternative to opening/closing the DB all the time! Thanks! – user387184 Nov 06 '11 at 22:48