Databases
StackOverflow2013
Postsdbo
POAndroid: Extending user's contact book. Performance ContentProvider vs Sqlite vs List in memory
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POAndroid: Extending user's contact book. Performance ContentProvider vs Sqlite vs List in memory
    primarykey
    data
    text
    <p>Me and my Android team have a problem. We have an app that present the user's contact book, with extended information.</p> <p><strong>Current setup</strong></p> <p>Our app reads the Contacts Provider of the Android OS. Sends this information to our Server that calculates a couple of necessary fields for us. This information is later fetched by our app and we save this information in an SQLite database. What we end up with in our database is two tables. One with all Numbers and all the extra information that the server calculated for us. The other table is one with all Contacts (one contact can have multiple numbers). This Contacts table was created only for performance; we can have a Cursor selecting all rows in this Contacts table in our CursorAdapter when presenting the contact book for the user. Hence, when presenting the contact book to the user, we only need to read from our own SQLite database and only one table (e.g. no JOINs). </p> <p><strong>The main problem</strong></p> <p>There is a lot of syncing going on. Since, data is duplicated, we need to check for adds/changes/removes and need to sync all the f-ing time. Moreover, when we now are about to change a particular thing in our presentation layer, we need to change our Contacts table to include this particular information.</p> <p><strong>Priority for us</strong></p> <p>1st: Performance when presenting the contact book to the user. </p> <p>2nd: Code maintainability.</p> <p>Hence, do not comment "Do not duplicate data--it's the root of all problems". It is more important to us that the user does not have performance issues than if we as developers have to spend some extra time writing good synchronization algorithms.</p> <p><strong>Solutions?</strong></p> <p>I don't know why, but I've always thought that a CursorAdapter (reading all rows from one table) is performing much better than an ArrayAdapter with a List of objects (held in memory). Anyone know if this is true? Because one solution which will help us at least half the way is to, on start up, join the Contacts Provider (native contact book) and our extended information, save this in a List in memory and present this with an ArrayAdapter. </p> <p>Creating your own Content Providers? I know little about creating your own content provider. Anyone tried to create a content provider that extend the information of the native contact book and join these. Maybe with the implementation of this interface: ContactsContract.DataColumnsWithJoins? Anyone tried anything similar? How's the performance when presenting this information in a CursorAdapter?</p> <p>Please ask for any more information I might have forgot and I will update the question!</p> <p>Thanks a lot in advance for all helpful tips and solutions!</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USjelgh
    1. USjelgh
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POAndroid: Extending user's contact book. Performance ContentProvider vs Sqlite vs List in memory
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POAndroid: Extending user's contact book. Performance ContentProvider vs Sqlite vs List in memory
      1. USjelgh
      1. VTBountyStart
    3. VO
      singulars
      1. POAndroid: Extending user's contact book. Performance ContentProvider vs Sqlite vs List in memory
      1. This table or related slice is empty.
      1. VTUpMod
    1. COA well designed databse in normal form (e.g., http://www.bkent.net/Doc/simple5.htm) does not only help maintaining your code, it will also speed up processing dramatically. That is, if indexes are used wisely. Moreover, you don't have to spend computation time to synchronize your data (since you have to lock the database for such operations to avaid inconsistent data). It also blows your database up, which you should avoid at any cost in a mobile environment. In my practical work, I cannot find any reason not to use a normalized database design (that does not have doublicated data).
      singulars
      1. POAndroid: Extending user's contact book. Performance ContentProvider vs Sqlite vs List in memory
      1. USDan
    2. CONow you are talking generally about databases, and yes I agree. However, as Android uses something they call Cursors. These cursors are the object you get back when you issue a query. But they are not filled with data. You step forward and get one row at a time while the cursor is a direct link into the database--this helps memory consumption. However, they perform very bad when using joins.
      singulars
      1. POAndroid: Extending user's contact book. Performance ContentProvider vs Sqlite vs List in memory
      1. USjelgh
    3. COAs far as I know, the cursor buffers the data retrieved from a query. It wouldn't make much sense otherwise. Thus, the join performance should be the join performance of the SQLite DB.
      singulars
      1. POAndroid: Extending user's contact book. Performance ContentProvider vs Sqlite vs List in memory
      1. USDan
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload