I'm trying to create a Searchable Activity to be used with the Action Bar.
I have a CursorAdapter supplying the data from a ContentProvider.
What I have trouble understanding is why does the API examples, ie, searchableDictonary, performs a managedQuery instead of doing something async with the CursorLoaders.
Perhaps I'm missing something?
Because this example is fairly old and CursorLoaders didn't exist at the time. If loaders work for you, do use them. Are you having any specific problem?
Related
My app implementation is an activity which uses Viewpager and different fragments to show on screen depending on tab selection or user swiping the screen. I have attached the screenshot example.
Now I want to load data on these fragments from my database in a listview. I was reading about loaders but not sure how to implement - whether to use Cursorloader which uses content provider or to use Asynctaskloader. I want to avoid Cursorloader since it mandates uses of content provider, however let me know if it will still make sense to go for it rather than Asynctaskloader.
Also, can I use a single loader maybe in activity and use this loader to display data in different fragments? Or should I be implementing a loader for each of the fragments?
Before thinking to use loaders I previously had used Simplecursoradapter to display the results but I have heard its better to use loaders for asynchronous operations. But let me know if Simplecursoradapter will suffice for lightweight operation.
I know I have asked too many questions but I am a beginner and a little confused at this point. Please help.
I'm reading the official documentation from android's content providers and I've seen this:
Decide if you need a content provider.
You need to build a content
provider if you want to provide one or more of the following features:
You want to offer complex data or files to other applications.
You want to allow users to copy complex data from your app into other
apps.
You want to provide custom search suggestions using the search
framework.
You don't need a provider to use an SQLite database if the
use is entirely within your own application.
I'm developing an app that syncs data on background when the position changes through an IntentService.
What I've seen is that with ContentProvider you could observe when data changes which I really want without user noticing it. It changes in IntentService and MainActivity observes this changes and when it's notificated, layout content change
Is it a great idea to use a ContentProvider although they don't even mention this?
Thanks
Personally, I have been using ContentProviders in all my projects for the last year and a half. They provide good, database independent, data abstraction to access your data. They are very flexible, I even had a play project where one URI pointed to a SharedPreference while all others where for accessing database tables. ContentProviders also allow you to use already built framework infrastructure such as CursorLoaders, for example. Implementing your own from interfaces and abstract classes is not that hard, but it may be time consuming and error prone, being able to just leverage work that's already been tried and tested is a great advantage.
By the way, I remember the same exact question on a post in google+ about 2 weeks ago where Cyril Mottier gave a very good answer. You can read it here.
I write an Android app and asking myself how to manage cursors. I know how to get data through a cursor back from the database. I don’t want to handle the lifecycle of these cursors by myself.
For Android 2.x and below I used, according to the Android API, methods like managedQuery and startManagingCursor. These methods are now deprecated. Instead of these methods I should use the Loader class for example (CursorLoader). As far as I know CursorLoader must be backed by a ContentProvider. The Android SDK recommends ContentProvider only if I want to share my data. But I just want to write a simple app, where no data should be shared.
In all my research I just find tutorials about Loaders in combination with ContentProvider. The SDK says that I can also write my own Loader over the class AsyncTaskLoader. Does someone already have some experience how to implement such a Loader? Are there any best practices? Are there any good tuturials how to implement such a Loader?
Or is it just better to implement a ContentProvider, so I can use the CursorLoader (this means a lot of work for just having a managed cursor)?
To make the ContentProvider private use android:exported="false" in your manifest.
ContentProviders are easier than you think and are the suggested way by the Android team. See http://responsiveandroid.com/2012/03/19/using-an-android-cursor-loader-with-a-content-provider.html for a good example of creating a ContentProvider.
So I have an Android app that is running in a TabActivity that separates 3 different activities through this tabs. I've set a DatabaseHandler class with SQLite and all, fine.
The thing is, so far I don't really know how to deal with the database since it will be receiving data from one of the activities and I need to be showing that data in a different one. I don't know if I should declare the db in the main TabActivity or where, I've never worked with SQL in Android before and I'm pretty lost at the moment.
I tried to picture it so it is more understandable: Explanatory Graph (Sorry, I don't have enough reputation yet to post the image into the post directly)
Thanks in advance.
Although using your DatabaseHandler is posssible within each activity in the long term I think most non-trivial apps would benefit from using a ContentProvider
ContentProvider provides an abstraction over your data. It becomes really powerful when you combine it with a CursorLoader and LoaderManager available back to Android 1.6 by using the support library.
These concepts require a bit of study but will make sharing data across multiple Fragment or Activities simpler and less error prone.
Mobile Tuts has a couple of good tutorials that are worth reading on top of the official Android documentation and examples:
http://mobile.tutsplus.com/tutorials/android/android-sdk_content-providers/
http://mobile.tutsplus.com/tutorials/android/android-sdk_loading-data_cursorloader/
You should be okay, as long as you close your connection with the database as soon as you're done reading/writing to the database.
Each activity should be able to have their own DatabaseHandler.
Are there any advantages of Loaders over Async task? Also, how to make loaders compatible for phones with Android froyo.
Edit:
The primary problem here is that I'm not using the native DB(SqlLite). Using the DB on development server. Obviously, I can't use CursorLoader any more. AsyncTaskLoader has no examples at all. If any, please do link.
Is it a better idea to load the data required onto the local DB and then query it using CursorLoader?
Yes, Loaders are more advantageous than AsyncTask as they take care of a lot of things that AsyncTask falls short of, miserably.
Screen Orientation changes are difficult in AsyncTask. I used to have such a problem, till I used an Activity Control class, which I used to retain while configuration changed. I can give you some code if you want to know how. The app used to crash, though, when you changed the orientation multiples times even before the entire data loaded. The secret here is not load a lot of data with your first thread and and finish your threading tasks as soon as possible. Even if it happens in the background, Android has a shabby way of dealing with threads. You never know when one of your tasks would be killed.
Even if you use a AsyncTaskLoader, makes sure that you use an Activity manager. This will help you in getting more control over the activites and AsyncTask.
Yes, it is compatible in all the old version of Android. You need to include the support library(Most of the times, this is included by default but its always nice to double check.)
For one, loaders are easier to code (they're almost built-in in Fragments).
Loaders (specifically CursorLoader) also handles your cursor for you (like the deprecated manageQuery).
Check out this link to read on how to use Loaders pre-Honeycomb.
There simpler to implement and take care of a lot of the life cycle management which previously had to be done "by hand" with AsyncTasks. See the answer to this question for further detail.
With regards to using them with Froyo, they're available via the compatibility library.
It seems no one is talking about the disadvantages of loaders! I'm currently working on a system that runs other services in the background.
What I have noticed is that as soon as a screen with a loader is resumed. The cursor used by the loader locks up the DB.
It may not be open to most people but getDatabaseWriter from sqlite is actually a synchronized method and hence the cursor used by the loader is never closed until the loader is reset or terminated thus locking up access to the DB.
I cannot recommend using a loader under these circumstances nor can I advice using a loader when your result set consists of less than 100 items which are static and never seem to change.
Another advantage with loaders is that they handle screen turn event gracefully whereas asynctask can give you trouble.
Biggest diff:
CursorLoader will update your UI's content as soon as its related ContentProvider changes its content(say through a Service), while AsyncTask will only update your UI when you tell it.