If some one asks you: What are those terms standing for?
How do you explain it to people with no develeopment experience?
As per my knowledge what i understand this terms, i pasting here..
Cursor: Retrieving data from SQLite databases in Android is done using Cursors. The Android SQLite query method returns a Cursor object
containing the results of the query.Cursors store query result records
in rows and grant many methods to access and iterate through the
records.To use Cursors android.database.Cursor must be imported.
Context: Context is an interface to global information about an application environment. It's an abstract class whose implementation
is provided by the Android system.
Context allows access to application-specific resources and classes,
as well as calls for application-level operations such as launching
activities, broadcasting and receiving intents, etc.
All the widgets receive a Context parameter in their constructor. In a
regular Android application, you usually have two kinds of Context,
Activity and Application. It's usually an Activity Context that the
developer passes to classes and methods that need a Context.
DatabaseHelper Class: A good practice for dealing with databases is to create a helper class to encapsulate all the complexities of
accessing the database so that it's transparent to the calling code.
So, create a helper class called DBAdapter that creates, opens,
closes, and uses a SQLite database.
Related
In my app (a SyncAdapter) I include many ContentProviders for use by other apps and was wondering whether it is appropriate to attempt to share a single SQLiteOpenHelper instance between them all to use? If so, how?
If that's not appropriate, is it considered correct to (as examples seem to indicate) repeat instantiation of the SQLiteOpenHelper within each ContentProvider's onCreate method; seems like there should be a better way!
Is there sufficient information in the Manifest for the Operating System to instantiate ContentProviders without creating their containing Application first? If so, then I can not hold a static SQLiteOpenHelper in a class that extends Application for retrieval by ContentProviders.
Help!
The answer was to merge my ContentProviders into a single ContentProvider that is wired-up to handle my various URIs/tables; here's an example from Google themselves. This way you can instantiate your SQLiteOpenHelper and set it to a field for your overridden methods to use, again, see the example. By the way, another good (in the interests of best practice) pattern I picked up from that code is to: override applyBatch to wrap everything it does in a transaction. Thereafter use it and only it (via. ContentProviderOperations) whenever you want to do any persistence; if you do this you can omit transactions from your actual overridden update, delete and insert methods - because you'll not be using them directly! The latter appeals to me as it simplifies my insert, update and delete methods and ensures that a whole sequence of related changes can be rolled back easily if an Exception is thrown.
Is there any way to access the ORMLite DatabaseHelper without application context?
I have a polyhierarchy in my data structure, but I always only save the parents in the database, and would like to retrieve the children with SQL statements.
I would prefer doing this without having to use Context, especially for unit testing. Is this possible, or do I always need to have context to interact with the database?
When you follow the examples, you initiate a database helper or manager once, with a base context from your starting Activity or its parent.
From that point on you don't need to re-create this again with any context.
You will need to provide a context at one point however to initiate it the first time.
Maybe I'm missing something but my question is: can I access the database from different points of my code each one using its own DatabaseHelper instance? Or is it better to have a unique global static DatabaseHelper accessible from everywhere (threads, activities, ...)? What is the best practice in this case?
It is better to have a single instance if you are using multiple threads, as thread synchronization will be applied automatically. Whether that single instance is a singleton or wrapped in a ContentProvider is up to you.
I'm writing an app that allows people to set alarms for various tasks that they need to do. My current plan is to store all the relevant data into an SQLite database. To that end, I have created a class that extends SQLiteOpenHelper and filled it with methods to handle all the CRUD that I'd expect to have to take in. Knowing that it's generally a bad idea to do all the processing on one thread, I looked up ways to separate the work between threads and found CursorLoader and LoaderManager, which seemed ideal as they were available in the Android Compatibility Library. However, LoaderManager seems to require a ContentProvider going by the tutorial in the documentation, and I haven't really seen a need to do anything with ContentProviders since I wasn't planning on allowing other apps to access the data. Without a ContentProvider, I don't know how I'm supposed to get a Uri for my databases to feed into the CursorLoader. Is there a way for me to keep using my class that extends SQLiteOpenHelper and still implement LoaderManager to allow me to keep all the populating ListFragments with my cursor off of the UI thread?
Is there a way for me to keep using my class that extends SQLiteOpenHelper and still implement LoaderManager to allow me to keep all the populating ListFragments with my cursor off of the UI thread?
You just need a different Loader implementation, one that does not involve a ContentProvider. It just so happens that I wrote one of those.
The Android Dev Guide says
Content providers are also useful for
reading and writing data that is
private to your application and not
shared.
Generally, Content Providers are used for providing data to different applications or sharing data among them. I was wondering if there is any use to having private providers and not wanting to share it. Are there any benefits provided that a direct access to DB or file system don't provide?
Thanks,
Rajath
It automatically schedules all your server-side and synchronization DB access in a background thread. However, in your application frontend, the Content Resolver/Provider will normally execute queries/transactions from the UI thread by default. You must perform all transactions asynchronously (i.e. using a CursorLoader) to ensure that your application runs smoothly on the UI side
It localizes re-entrant DB access from the any threads that access through ContentProvider, so that all locking can happen entirely in your ContentProvider override calls, rather than keeping track of it in a DB layer, a service, and a UI layer.
As part of the above, it also provides a nice singleton interface to your data -- If you have ten Activity classes in your app, you just go through ContentResolver static calls from each one, versus needing to deal with opening/closing a SQLiteDatabase in each activity as you jump from one activity to another in your app.
ContentProvider is tied very tightly to the SyncAdapter model -- Meaning it's pretty much the only way to go if you want to keep your database in sync with a server-hosted database out on the net. (your app mirrors a REST api type of situation)
It ties into ContentResolver's ContentObserver interface -- This is an interface where (among many other useful things) a view can register as observing a specific set of data (through the Cursor to that data). Then, if you drive a change into the ContentProvider, the CP can notify the CR, which can in turn notify any relevant cursors, which in turn will requery and cause the view to update. This is much cleaner than having to manually keep track of your views so you can invalidate and redraw them.
As for re-entrant locking of the DB, it doesn't do it completely, but it helps -- your ContentProvider class implements four simple functions (CRUD interface) and, if you choose to override it, a fifth, batchAdd() -- This localizes your locking. The bone simple answer is to simply tag all four/five of those function declarations "synchronized" at the function level and you're done. Much cleaner than trying to figure out locking out from 20 places that access your DB in 5 different Activites.
For example,a multiprocess application use scenario(like: music play service usually run in a remote process), between the two process that in one application share database should use private ContentProvider.