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.
Related
I'm using IntentServices to call a restful service and then turn over the result to a receiver. The back-end requires a user id and authentication token, which I stored in a singleton class. I've run into issues with this singleton being cleaned up when the process is terminated, and its data isn't around when Android tries to restart my activities. User preferences seem like a great place to start this kind of data, but those require a reference to your context.
Where can I put this data so it can be accessed outside of the view? I realize I could just pass it with every single Intent that triggers my IntentService, but am hoping there's a better way.
Thanks!
Service is a ContextWrapper which is a Context so you can use the keyword this when getting an instance of your shared prefs.
For lightweight data such as a few strings etc, SharedPreferences is fine. Just pass any context, every component has one or is one itself. Or pass the application context. Lack of context shouldn't be an issue. Pass it along into your singleton as a parameter.
Using a database, or inventing a proprietary storage mechanism using a file, or creating a content provider, all seem overkill to me.
If you don't want to pass it all the time (which is not that bad), and you still want to stay in the Android framework philosophy, create a ContentProvider for this task.
Or you can go full classical and save them in some file. Or in a sqlite database (Android offers easy support for this).
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.
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.
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.
I've got a quick question on the best way to handle Android contexts. A lot of things (e.g. Service) require that you pass a context as a parameter. At the present time, I have a public static variable that is set to point to getApplication() and I just refer to this throughout my application where a context is required.
Is this ok to do? Or is there a better method to handle this? A lot of my classes don't extend Activity or service and as such, don't have access to this.getApplication().
Everything seems to work ok when I just pass in my static variable.
Is this ok to do?
The Application object, in some cases, will fail to work. For example, it sucks for UI-related stuff.
Dianne Hackborn, a leading Android engineer, has stated her regret at Application existing in the first place.
My general advice is to use Application only when you know specifically why it is superior to using your Activity, Service, etc. There are cases when it is the better answer (e.g., binding to services).
A lot of my classes don't extend Activity or service and as such, dont have access to this.getApplication().
Pass a suitable Context as a parameter, as the Android SDK does.
At the present time, I have a public static variable that is set to
point to getApplication() and I just refer to this throughout my
application where a context is required.
Is this ok to do?
No.
A context applies to the context in which it was obtained. That is, an activity has context for that activity, a service has context for the service, and so on. Now, a lot of folks do what you are doing, and as you observe, it seems to work. That doesn't mean it will continue to work or that it's good design. If that was the proper pattern, Android would have been designed with Context.INSTANCE that is available statically.
An activity, service, and application are contexts (isA). Receivers are passed a context to their onHandlerIntent() method. For all other classes you write, just get used to constructing them with a context. Out of habit, whenever I create a new class, I automatically add a constructor that accepts a context and add a private field to hold it.
When you need a context in a static method, you should pass it in directly as a parameter.