Develop Reference

What to do when activity is destroyed but I must continue executing code in fragment?

I have a pretty odd problem here. In a fragment, I do a process and when the process finishes I show an advert that callsback to the fragment when user clicks/dismisses the ad. The problem is that in some devices when the ad calls back to the handler (that is in the running fragment) the activity containing the fragment has been destroyed, but I need to do some more work through a runnable. So, in this case the runnable throws a NullPointerException int is run method when executed.
I could just check if the activity is still alive and run just the runnable when it is, but in the cases it is not alive I still need to continue to do the part of the job that needs to be done after the ad.
How do you handle this kind of situations? I have been thinking about the problem during some hours without finding a solution to this.
Thanks in advance.

You can use AsyncTask in this case .
AsyncTask processes are not automatically killed by the OS. AsyncTask processes run in the background and is responsible for finishing it's own job in any case. You can cancel your AsycnTask by calling cancel(true) method. This will cause subsequent calls to isCancelled() to return true. After invoking this method, onCancelled(Object) method is called instead of onPostExecute() after doInBackground() returns.
Hope it helps..

mmm the way this is asked I am not sure what you are asking, perhaps some text connectors might work, I am not sure if this is a quite basic question about state changes or a very complex one.
from what I understood:
wouldn't this be the same problem as when you flip screen? make a Bundle of the data that is restored through activity changes. This way if your activity has been Destroyed you restore it
fragments have a feature that you can use to keep instance alive across a configuration change: retainInstance
setRetainInstance(true) // false by default
Parcelable like Serializable, is an API for saving an object out to a stream of bytes. Objects may elect to implement the Parcelable interface if they are what we will call "stashable" here. Objects are stashed in Java by putting them in a Bundle, or by marking them Serializable so they can be serialized, or by implementing the Parcelable interface. Whichever way you do it, the same idea applies: you should not be using any of these tools unless your object is stashable
---or---
turn that "advert" of yours into an Alert, which wont mess with the Activity.
---or---
run the response on a different thread?

Making Asynchronous Service Calls in Android

I am trying to make asynchronous service-call in my android app using AsyncTask Class, but for each and every service call in my activity i need to have a subclass in my Application which Extends AsyncTask. Can anyone Suggest me a better way of doing this???
In My Scenario Service Calls have different return-type,then i need to return an object for all service calls and typecast it according, Is there any better way of doing this ???

Is it a service you wrote? If so, you could make the service itself asynchronous so that you can make calls on it that return instantaneously and later get notified via a callback. That would remove the need for the AsyncTasks on your Activity.
If you can't change the Service, one thing you can do is have a background worker thread that's responsible for interacting with the Service, and you post messages to it from the main thread using a Handler. The worker thread uses another Handler to deliver the results back to the UI thread once each work item is finished.
See: http://developer.android.com/reference/android/os/Handler.html

"AsyncTask must be subclassed to be used." sez the droid.

Don't declare the AsyncTask as an inner class of your activity. Declare this class once in it's own scope, and you can use it from anywhere. As far as the data to pass in and out, you can make the first parameter a String or Uri and pass in the request data, and you can use an internal listener object in the AsyncTask that can be set by the activity to receive a call back when onPostExecute fires.
EDIT
I made a gist to demonstrate the simplest version of this. Using the example AsyncTask-derived class, you can reuse this one class throughout your entire app and pass it all of your endpoints and receive the result inside your activities (or anywhere else you need to make your service calls). If you need to make this more extensive, you can just change the input object from a String to some more complex data structure containing anything you need to pass to your service call (post params, http method, etc) and you can change the signature of the OnPostExecuteListener interface if you want to return structured data and not just the raw result
https://gist.github.com/80c59fb70e195ca142bb

How to have one AsyncTask for all my db calls

I am looking for the right way of designing my app here.
I have 5 activities and each one calls a separate DB method (update, insert, delete ..etc).
I was wondering, instead of creating 5 asynctask classes, each is a private class belonging to the activity to be called from, is there way I can create one asynctask class so I instantiate its object in all the activities?
In C++, you can pass "an entire method" to be executed so Ican create an assign task and pass a method to it to be executed, but I am not sure I can do that in Java. Or what would be the best practice in your mind?
Thank you

Check the Runnable class.
A Runnable represents a task that can be executed. You need to implement it's run() You can pass an instance of Runnable to your AsyncTask and execute it in it's doInBackground(...) method.
There might be a better way to do this, but this is the only thing that is comming to my mind right now.

I'm not sure if this would fit your bill but I would recommend creating an IntentService, that would automatically and asynchronously queue up your Database/Content-Provider read and writes.
You can write separate read, write and update methods that will be handled in the onHandleIntent method of the IntentService. The Intent service insures that
the database/CP access is done asynchronously
successive database/CP access requests are automatically queued and handled
the Service is stopped/started automatically, no need to manage the lifecycle
the database/CP read/write is done even if the app goes into the background
For ListView/Adapter access, consider using loaders

Pattern for reusing Android AsnycTask over several Activities?

I have several Activity subclasses in my project, each calling a SOAP based web service, processing and displaying the results. The SOAP serialization, the call handling and the parsing of result into various POJO objects is encapsulated in the MyWebService class. This class executes the actual web service call(s) via an AsyncTask.
For being able to pass back the results to the calling Activity subclass, I figured I enforce that all these activities should implement a WebServiceResultProcessor interface, defining a single function (processWebServiceResults) acting as a callback for the AsyncTask, called from onPostExecute.
I also want to display a ProgressDialog during the web service call. And here comes my question. For being able to display the ProgressDialog (either from MyWebService or it's AsyncTask), I need to pass a reference to the caller Activity's Context. And for being able to execute the callback function from the AsyncTask, I also need to pass the same object reference, but this time as a WebServiceResultProcessor. This seems to me a code smell, passing the same object twice, but can't see any way around that. Instead of interfacing, I could create a new base class, extending the Activity class and enforce inheritance from the extension class, but that would mean I'd exclude ListActivity and the likes from using this MyWebService class.
Is there a better way to do this?

+1, a nice question!
This is not a direct answer on your question. However let me say I think AsyncTask is not a right choice for such stuff. I think so because in this case AsyncTask holds a reference to an Activity (via ProgressDialog instance or the callbacks to be called from onPostExecute()).
Just imagine: in Android the OS may kill the Activity before AsyncTask executes its doInBackground(). This is, of course, some sort of a corner case, but it isn't impossible. Consider a scenario: user gets an incoming call, your activity becomes invisible, the OS needs some more RAM and thus it decides to kill your activity. A memory leak case, at least.
I don't know why Google literally hides the info on how UI should be properly separated from background tasks. Yes, they say "use a Service". But it is not a trivial undertaking. It's a pity Google provides nice guides to almost every development topic, but not on this one. Nevertheless I can suggest to check the "Google I/O 2010 - Android REST client applications" presentation for inspiration. Looks like they gave a key on how such things should be done in Android.

You may have a look into this blog article (part 1 and part 2), which implements a web service with AsyncTaskLoader and the same web service with a Service component. Furthermore it shows the differences between both approaches and there are also interesting comments to the article.

Despite Arhimed's warning, I ended up using AsyncTask, as it still fits my purposes. I just make sure that all Activities calling web services, upon their onDestroy(), send a cancel() to the invoked AsyncTask. The AsyncTask implementation itself gracefully handles the cancel request by checking isCancelled() everywhere where necessary.
As for the original question, I must have had a lapse - the solution is really simple. I pass the Activity subclass instance as an Object to the AsyncTask, and cast it to either Context or to WebServiceResultProcessor, as necessary. Fragments showing how it works:
if (callerActivity instanceof Context) {
ProgressDialog dialog = new ProgressDialog((Context)callerActivity);
}
...
if (callerActivity instanceof WebServiceResultProcessor) {
((WebServiceResultProcessor)callerActivity).processWebServiceResults(soapObject);
}

Activity with backgroundthread, not innerclass, communication

Hey all, this will contain a few questions since I don't seem to really get it.
I have 1 class, the activity. which should display informations.
Then I have a background thread, extends runnable, which keeps getting new data (there for I didn't use AsyncTask, I could use it as a service, but since I hold a some critical resources in it, I would like not have it released when exiting the activity thread)
But I am in great doubt how to communicate between these 2.
First I thought of Intent, but these seem to be used mostly for launching other activities, or alike, and I need something permanent, since data will be in a steady flow.
Then I found out handler, but this doesn't seem to work when my thread is not an innerclass, so I'm thinking about either going back to the old Java observer pattern, if it's not possible to somehow pass the handler to the outerclass.
Any thoughts would be greatly appreciated
Sincerely
Anders Metnik

There is a mechanism for your case - it is called handlers. Read more here.
As for having thread as inner class:
Create your thread as a separate class, add a constructor with a handler parameter and pass it from your activity.

Thread is not suppose to live outside Creator Activity Context, especially you want to preserve it out of Activity, better use Service (and manage the thread) to hold those data.
Intent is the best in terms of communicating between contexts. I think one of the scenario you can adopt is like this:
Application-class: holds those 'permanent' data you mentioned
Service-class: Work (background) and send out "intents" to signal the update state of the operations
Activity-class: Intent Receiver. Whenever intent signal received, grab the necessary data from the Application-class.