0

Hy,

I have been reading about content providers, Loaders and loaderManagers for whole week now and sadly I must admit, I'm no closer to working solution. And also, I think integrating full blown loadermanager-cursorLoader system would be perhaps an overkill for my needs. So if any of you could assess if this is true (or just excuse from my side :)), maybe direct me in right direction or even provide working example/implementation steps for my specific case, that would be great!

Background:

  • I need to assure minimum compatibility up to API 10. App uses complex pre-populated SQLite backend with more than 30 tables in different relations to each other. And I load it by extending SQLiteAssetHelper class (not default SQLiteOpenHelper).
  • BUT, interaction between user and database is almost exclusively on level of reading and displaying data, with very few (and far between) examples of some creates/updates/deletes (for, let's say some notes), so no need for synchronous and locking RDB. Most of the time user just selects button/listview position which should re-query RDB and update views accordingly.
  • I also do not need to provide data (and don't wish to) to other apps. So, I guess, no explicit need for content provider (although I am aware I could forbid sharing of content provider in AndroidManifest).

So my questions are:

  1. Taking in to account background I provided, what would be right approach for minimum working solution that would enable querying RDB based on variable provided by button/list position that was pressed by user, and then displaying results of that query in new view/updating current view.
  2. Silly one, but it seems like I can't find definitive answer to this: Per developer guidelines, each table should provide primary key column named "_ID" for cursors to work. Here is the sillines -> What does that mean, exactly? I found guides that suggested naming them lowercase, like "_id", some tutorials used columns named "id", or "ID" and some even named them "columNameId"... Is it possible to name primary key column like: "columnname_id"? Or for my specific case, my primary key columns are named "ID_column_name", should I rename them all and make appropriate changes to my database? If there is no possible way that names stay the same, which is the most supported naming I can/must choose (ID, id, _id, _ID, ...)?

Thank you all!

Nejc Draganjec
  • 57
  • 7
  • 1
    **1**. A parametric rawQuery where the parameters are placed as **?** and passed as string array values, **2** `_id` fits all your needs. – Phantômaxx Oct 30 '14 at 08:33
  • I thought about parametric rawQuery. But was bit skeptical since they are depreciated (at least my android studio says so) + I wonder what will happen when activity will be recreated. Will my variable, that was passed to activity by intent, still be set and used as parameter? I guess it depends on how and where in activity I set it? – Nejc Draganjec Oct 30 '14 at 10:26
  • `they are depreciated` sounds like **science fiction**. – Phantômaxx Oct 30 '14 at 10:55
  • 1
    You are right. I'm implementing this now, and no such error. But I'm sure I got it during one of my many trials&errors during last week. It must have been something else... My apologies. – Nejc Draganjec Oct 30 '14 at 11:14
  • OK, just to be precise (since rawQuery and execSQL is my favourite db handling method). Don't be sorry - just go on. – Phantômaxx Oct 30 '14 at 11:27

1 Answers1

3

  1. Loaders are used to move potentially long-running database queries into another thread (and to keep the data when the activity is recreated, e.g. on screen rotations).

    When your query is fast, you can just run it directly from the UI thread.

    Android's built-in CursorLoader requires a content provider, but you can write your own loader that accesses the database directly: Usage CursorLoader without ContentProvider.

  2. Cursor adapters require that query has a column named _id containing unique values. You could rename some other unique column to _id while querying (SELECT SomethingElse AS _id ...), but when you have a primary key, you could just as well store it as _id in the database.

    (SQLite ignores case in column names.)

Community
  • 1
  • 1
CL.
  • 173,858
  • 17
  • 217
  • 259