Hi, Cursor.deleteRow() will be deprecated in or removed from the next SDK.
On Tue, Jul 8, 2008 at 4:10 PM, Disco Stu 010 <[EMAIL PROTECTED]> wrote: > > Hey Mark, > > Thanks again. I had reached the same conclusion as you that > Cursor.deleteRow() should result in a DataProvider.delete with some > URI. However, I dont see that happening. I added a Log.w statement to > query(), insert(), delete() and update() methods of the data provider > and only query() and insert() are being called. > > Maybe some Android team members can shed light on this? > > Thanks, > DS. > > PS: BTW, I am able to single-step through the debugger on insert so > atleast in this case, the debugger seems to work - NS. > > > On Jul 8, 2008, at 3:39 PM, Mark Murphy wrote: > >> >>> Mark Murphy, any thoughts? :) >> >> <blink, blink> >> >> Thanks for the vote of confidence! Though, bear in mind, I'm not an >> Android team member, nor do I play one on TV. >> >>> Now, according to the documentation, deleteRow is supposed to >>> delete a >>> row "from the underlying datastore". How does the Cursor know what >>> table/row the cursor correspond to? >> >> It's been a while since I looked at NotePad, so forgive me if I mis- >> speak >> here... >> >> NotePad uses a ContentProvider (NotePadProvider), so the Cursor you're >> presumably referring to is the one in the activity showing the notes >> (e.g., NotesList). In that case, the Cursor isn't directly accessing >> the >> database (a la SQLiteCursor), but rather wraps the Intent-laden IPC >> mechanism that Android has...somewhere...that bridges between the >> Cursor >> and the ContentProvider interface supported by the NotePadProvider. >> Content providers may not be in-process, particularly if they're >> supplied >> by some other application than your own. >> >> When you call deleteRow() on the Cursor, the Cursor does not know the >> table/row, as the Cursor has no idea how the ContentProvider is >> providing >> the content: SQLite? in-memory data? random-data generator? >> >> What the Cursor *does* know, though, is the Uri of the piece of >> content >> the Cursor presently points to. On a deleteRow(), that Uri eventually >> winds up as a parameter to the delete() method on the NotePadProvider >> (again, via Androidy IPC goodness). It is up to NotePadProvider to >> parse >> that Uri and determine the appropriate table/row. >> >>> I tried to single-step through the >>> NotesList application and the delete method belonging to the >>> DataProvider class, NotePadProvider is not used at all. >> >> I find that somewhat difficult to believe. Maybe the debugger >> doesn't step >> through the Android innards as Cursor#deleteRow() goes through the >> IPC to >> get to ContentProvider#delete(). >> >>> Further more, the cursor can be the result of a complex "join" query >>> in which case, how would anyone know which row to delete? >> >> If you do a complex join while query()-ing >> "content://com.google.provider.NotePad/notes", and you get back rows >> with >> IDs of 4, 8, 15, 16, 23, and 42, the Cursor turns those into Uri >> instances >> like "content://com.google.provider.NotePad/notes/4" and so on. >> >> When it comes to Cursors and ContentProviders, the Uri is your friend. >> >> -- >> Mark Murphy (a Commons Guy) >> http://commonsware.com >> _The Busy Coder's Guide to Android Development_ -- Available Now! >> >> >> > > > > > > -- Romain Guy www.curious-creature.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
