You should not be using GET to update your database. This is abuse of GET. From RFC 2616, Section 9:
9.1.1 Safe Methods Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. 9.1.2 Idempotent Methods Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent. ... ------ So what you want to do is: 1) not use GET to make the change -- typically a POST is what you want -- and 2) if your application is destroyed before it gets the response, at a later point, do a GET to determine the result of the prior POST, to bring your application back in sync with the server. This GET can be something that verifies a single POST, or it can be one that obtains a list of updates since a certain point (perhaps synchronizing with changes made with your app from another device owned by the same user, for example). On Dec 15, 1:34 pm, flipside <[email protected]> wrote: > It isn't so much that I'm expecting the requests to be long-running, I'm > not, but I do need to know that they succeed. I probably confused things by > talking about *gets*. The application issues a get with parameters, and the > server updates a database with the parameters, so although it's a get, it's > not a read-only transaction, I need to be sure that my application can deal > with the situation in which it issues a get and is then destroyed before it > receives the response. > > The reason for reusing the AndroidHttpClient is just to avoid the overhead > of continually recreating it. The idea is to create it and then let it act > as a conduit between the Android app and the server. -- 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] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
