"For example, to correctly implement asynchronous HTTP requests is an entirely different challenge in iOS and Android. On iOS you use the built in libraries, and if your user happens to change applications during the request, you can be sure you have up to 30 seconds, usually more, to complete whatever actions need done before termination. On android, you must implement the `android.app.Service` API for all your important web calls. The app can be killed at any time, and you must retain your arguments, and retry the call in case it happens to die."

Except... no, you don't. :/

The first sentence of the documentation on Service: "A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use."

Do you need to do either of those things? If you say no, then don't use Service.

http://developer.android.com/reference/android/app/Service.h...

In the Processes and Threads documentation: http://developer.android.com/guide/topics/fundamentals/proce...

It describes how when the user leaves the activity in a process, it goes in the background. It doesn't kill the process. You can continue doing networking. You don't need a Service to have background threads in your process. (In fact again from the Service documentation, a Service is not a thread at all.)

Just continue doing your work, and if the system needs your RAM for other processes, it will kill your process, but otherwise you can continue downloading in the background.

This is exactly how for example the web browser, and any app using a WebView, works.

This is similar in many ways to iOS. Not surprising, iOS seems um inspired in its multitasking design by Android.

user:	hackbod
created:	July 31, 2011
karma:	5