1

Is performance in android degrading when interacting with a database storage often?
Is it better to load objects from DB and pass them around or access database frequently to get the objects?
I was thinking if the accessing the DB had more overhead due to instantiating objects from the result set each time.

OneCricketeer
  • 179,855
  • 19
  • 132
  • 245
Jim
  • 18,826
  • 34
  • 135
  • 254
  • I assume you are only referring to SQLite, not a network request? An in-memory database would be more performant than disk. – OneCricketeer Jul 19 '16 at 17:50
  • @cricket_007:Yes only database. You mean comparing with HD db? I was concerned about all the object creations each time we query and get the result set vs keeping the objects in memory and passing them with intents or via static classes – Jim Jul 19 '16 at 17:52
  • SQLite database... yes? Not MySQL/SQL Server/PostgreSQL or NoSQL? – OneCricketeer Jul 19 '16 at 17:53

2 Answers2

2

I was thinking if the accessing the DB had more overhead due to instantiating objects from the result set each time.

Yes, it does, which is why if you are worried about performance, you should not use ORM tools to instantiate objects.

Is performance in android degrading when interacting with a database storage often?

Probably... you are reading from disk, which is slower than in-memory storage (which, hint, SQLite can do)

Is it better to load objects from DB and pass them around or access database frequently to get the objects?

Depends in what context you need actual class objects. If you store data in a database, then you should only query for that data when you need it, load it into an object, then do whatever calculation logic and save it. At least, that is my opinion on the matter. You shouldn't need to be serializing any objects between Activities primarily because you could lose state if you update an object in one Activity, pass it to another, then don't / forget to save it back to the database.

Community
  • 1
  • 1
OneCricketeer
  • 179,855
  • 19
  • 132
  • 245
  • Well even without ORM I would need to create some object after I do a query in the sqlite db. Unless I just return a cursor – Jim Jul 19 '16 at 18:05
  • So the result set is not cached in memory like in MySQL? – Jim Jul 19 '16 at 18:05
  • The cursor is a reference pointer to one row of the database, which I'm not sure about specifics, but I imagine only one row is stored. I'm saying you should query for your result (talking about searching here, not scanning) then only pull out and update the data that you need. – OneCricketeer Jul 19 '16 at 19:50
  • Yes so if the query returns 200 rows with 10 columns, I would have to loop over the result set and for each row instantiate an object that is the business logic object and populate the member fields from the columns. Isn't this extra overhead or you recommend something else? – Jim Jul 19 '16 at 21:43
  • For scanning a Table, there is no way around it, I am still not seeing why you need to make objects. If you are populating a ListView, you bind a Cursor to a row view with a CursorAdapter. – OneCricketeer Jul 19 '16 at 21:52
  • That is a good point I see what you mean, I had in mind a "unified" approach in the db access from UI and services or other non-UI actions. So basically the db access should be done only via cursors (e.g. as you said cursor adapters) for UI and object loading for the rest? – Jim Jul 19 '16 at 22:02
  • In my experience, that seems to be a fine balance in functionality and performance, yes. Objects are limited to controllers and load UI elements from background workers wherever possible for Presenter logic – OneCricketeer Jul 19 '16 at 22:05
  • So I should split my db layer in 2 api interfaces then? Is there a nice design pattern for this in android? – Jim Jul 19 '16 at 22:06
  • One more question. If I use a cursor adapter for a UI and the result set is empty how is this normally handled? Because I would only figure that there is nothing to display *after* the view has been displayed and the cursor loader set, right? – Jim Jul 19 '16 at 22:21
  • MVP seems to be trending pattern at the moment, but I typically find myself following MVC or MVVM. And right, a new query and Cursor need ran to get the a ResultSet outside of the CursorAdapter. And you should only need one method on the SqliteOpenHelper to turn a Cursor into an Object. I just can't think of a use case where you need to scan a table or query result and store all rows as Objects other than a ListView, but CursorAdapter mostly handles that fine. It's my opinion that the only time you should need an object is to perform complex operations on the data that require Java methods – OneCricketeer Jul 20 '16 at 00:15
  • But for using data from a service I can't use a cursor adapter right? – Jim Jul 20 '16 at 05:13
  • A Web-Service? Correct. – OneCricketeer Jul 20 '16 at 16:20
  • Not web service. I meant android services https://developer.android.com/reference/android/app/Service.html – Jim Jul 20 '16 at 16:58
  • I believe that has been answered at [Can you use a LoaderManager from a Service](http://stackoverflow.com/questions/8696146/can-you-use-a-loadermanager-from-a-service) – OneCricketeer Jul 20 '16 at 17:04
0

As google writes:

Note: Because they can be long-running, be sure that you call getWritableDatabase() or getReadableDatabase() in a background thread, such as with AsyncTask or IntentService.

which makes interacting with database out of main thread. So it can be not immadiate, so user will see some delay in app or fast appearing progress bar, or something. Especially when there will be big queries with 'union' and 'join'. But in most cases it is fast enough.

About your thinkig to access object due memory cache. It makes sense. Exact the same working with images provided by google here. So in your case db is disc cache other is same. You will need to provide some memory cache for your objects, but beware. If you working with huge number of them or each will be so heavy, you will need to provide not just simple wrapper to Map, that stores your objects, but something like LruCache.

So gathering all, you will recieve data from db, then store it in memory until app will need more memory.

Michael Spitsin
  • 2,539
  • 2
  • 19
  • 29