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! > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
