views:

68

answers:

3

I have a ListActivity which lists a bunch of "things." If you click on one of these "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).

+1  A: 

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.

iandisme
Yes, of course, but that's not really what I'm suggesting. Maybe I should be more clear: Should I update the database right before calling "finish()" or should I hit the database after the parent list gets the result.
Andrew
I think this is the right approach. Database inconsistencies are inevitable. What's appropriate is to minimize unnecessary bandwidth traffic.
Andrew
+1  A: 

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.

jball
+1 - I think your answer was more relevant to what Andrew was asking than mine... I still stand by what I said, though :)
iandisme
A: 

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.

Shouvik
But database inconsistencies are inevitable for applications that sync data to a server. From the instant the user performs an action, the databases are out of sync. If the user's phone is off and they're using the web, the databases our out of sync. What is important is to provide a proper mechanism for correctly syncing. If a call fails, there should be some mechanism in place to retry the call at a later time.
Andrew
A simple timestamp will help in that case. Let all the records have their own time stamp. The latest one shall override the older version. That way I guess the device going out of sync for a period of time will be taken care of by simply comparing the file timestamps.
Shouvik