Small architecture question

I have a ListActivity which lists a bunch of "things." If you click on one of these "开发者_C百科things," you're taken to another ListActivity which lists a bunch of "stuff" for that "thing."

Say I want to give the user the ability to edit the name of some of the "stuff"; or even delete some of the "stuff." At what point should I actually perform that action on my database?

Ex: If a row of "stuff" gets deleted, should the database be updated before I return my user to the list of "things?" Or should the user return to the list of "things" and then the database is updated? Or does it not matter?

Mind you the database updating will likely happen in a service (I'll also be calling a web service to update the cloud).

I would do the database transaction after the user is finished messing with it, only because I would want to give them some way to undo an accidental deletion before committing it to the database.

Edit: See jball's answer. He understood you better than I did.

It depends on what is important in your application. If it's important that a user never thinks a child is deleted when it fails to delete, you should wait to get a response from the server before displaying the new list of children to the user.

However, if deletion confirmation is not so important and application responsiveness is critical, update the user's display and then do the deletion asynchronously behind the scenes.

You should definitly update the child activity as soon as the action is commited. That way you will not have inconsistencies. Updating many changes to child activity when returning to parent, while exiting is risky, because if the network loses connection, you may not have all the changes fully committed. This could lead to database inconsistencies.