android-loadermanager

Edit: For a detailed how-to, check out my answer . I'm struggling with it for two days now, hope someone can help. I'm trying to use the newest ActionBarSherlock (4.0) with a MapView. I knew it's problematic with fragments, but I don't need them in this activity. But I need Loaders and it appears, that to use Loaders I have to extend the FragmentActivity too. No problem, I thought, we have the android-support-v4-googlemaps from Pete Doyle. As suggested on many SO threads and Google Groups I build the ABS with android-support-v4-googlemaps JAR (android-support-v13-r7-googlemaps.jar actually)

To implement database access in my application I followed Lars Vogel tutorial , but I'm very confused about a couple of things... 1) Every time a call is made to fetchTodo a new cursor will be created and returned. Leaving the previous cursor for the garbage collector. So, if I don't use startManagingCursor or even the CursorLoader for that matter, should I call a .close() on the cursor when I'm done with it ? Outside of fetchTodo scope of course, example: Cursor cursor = mNotesAdapter.fetchTodo(); // do something... cursor.close(); I'm done with this cursor and new one will be created on the

environment (Linux/Eclipse Dev for Xoom Tablet running HoneyComb 3.0.1) In my app I'm using the camera (startIntentForResult()) to take a picture. After the picture is taken I get the onActivityResult() callback and am able to load a Bitmap using a Uri passed via the "take picture" intent. At that point my activity is resumed and I get an error trying to reload the images into a gallery: FATAL EXCEPTION: main ERROR/AndroidRuntime(4148): java.lang.RuntimeException: Unable to resume activity {...}: java.lang.IllegalStateException: trying to requery an already closed cursor at android.app

Ok, the documentation states that it lets the Activity manage the cursor's lifecycle. But I don't really see the point of it since when the activity is destroyed, any references to the newly created cursor should be also erased and then the cursor itself is left to perish in the next garbage collecting cycle. So why bother? You should not rely on cursors being destroyed by the garbage collector... a cursor represents a significant amount of resources: all of the data held by the cursor, plus the connection to the content provider that owns the cursor which also means requiring that its process

To me it's not clear how to get the right cursor if you have multiple Loaders. Lets say you define two different Loader with: getLoaderManager().initLoader(0,null,this); getLoaderManager().initLoader(1,null,this); then in onCreateLoader() you do different things depending on the id: @Override public Loader<Cursor> onCreateLoader(int id, Bundle arg1) { if (id==0){ CursorLoader loader = new CursorLoader(getActivity(), MaterialContentProvider.CONTENT_URI,null,null,null,null); }else{ CursorLoader loader = new CursorLoader(getActivity(), CustomerContentProvider.CONTENT_URI,null,null,null,null); };

At the moment I’m using getContentResolver().query()/managedQuery() to get a cursor to retrieve images from the gallery app. Because the APIs I’m using are partly deprecated I wanted to use CursorLoader with LoaderManager. /** * Creates a cursor to access the content defined by the image uri for API * version 11 and newer. * * @return The created cursor. */ @TargetApi(Build.VERSION_CODES.HONEYCOMB) private Cursor createCursorHoneycomb() { String[] projection = { MediaStore.Images.Media.DATA }; Cursor cursor = getContentResolver().query(imageUri, projection, null, null, null); return cursor; }