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.
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.
I'm trying to access since different activities to an unique database, however when I work with databases I have to create a different database instance since every activity and this produce an unwanted result, how can i manage an unique database since different activities?
however when I work with databases I have to create a diferent
database instance since every activity and this produce an unwanted
result, how can i manage an unique database since diferents
activities?
So did you think about Singleton? I think your problem is directly designated for an usage of Singleton design pattern. An usage has only benefits(always only one instance, not wasting of memory, clean and human-readable code etc.).
Let's write some code:
private static SQLiteOpenHelper instance;
public static SQLiteOpenHelper getInstance(Context c) {
if (instance == null) {
instance = new SQLiteOpenHelperImplementation(c);
}
return instance;
}
I have only good experiences with Singleton.
Notes:
To improve your work with database i have a few suggestions for you:
If you have more than one table, i suggest you to create "operation"
classes which will wrap CRUD operations and specific methods for each
table.
To improve performance, security and integrity of db always use
TRANSACTIONS. It's very useful and efficient practise
In concurrent programming, always use synchronized blocks and methods to avoid problems related to access to database and making changes
Always when work is done, release your cursors and close database
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.
There have been a few questions on this topic but none giving firm reasons for why there should or shouldn't be a single or multiple instances of the databaseHelper.
When is it a good idea to have multiple instances of DatabaseHelper and when is it not. Is less complexity (if that is actually the case ) a good enough reason to have just a single instance ?
Your DatabaseHelper should be a singleton for sure. Each helper maintains the single connection to the database. If you have multiple helpers with connections to the same database, then concurrency issues will result. Sqlite does it's own locking underneath the single connection to ensure proper concurrent access to the database so using that single connection (and therefore that single helper) for all of your database operations is recommended and required.
Use one DatabaseHelper for each database in the application. SQLite takes care of file locking for you (many reads, only one write) and Android using Java locking in SQLiteDatabase. However, you can still get have a concurrency failure (simulataneous connections writing at once). It's the multiple connnections part that you want to avoid and that is what is managed by one instance of the DatabaseHelper.
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.