Here's scenario:
- Client makes remote call to the service (returns void) and provides a callback object
- Service executes some long running logic on the background thread and then uses callback object to trigger ether success or failure which (since these manipulate visual elements) execute in Activity#runOnUiThread block
The scenario runs fine. The question is - can I use AsyncTask to make code less verbose (how?) and would be there any advantages in doing it that way?
Or should I just get away from client callbacks alltogether and execute remote service calls retrofitted to return some value within AsyncTask#doInBackground?
It is difficult to say whether
AsyncTask
will make things less verbose, since we don't know the verbosity of your current implementation.For me,
AsyncTask
means I don't have to worry about cleaning up threads myself (e.g., post some sort of kill job to aLinkedBlockingQueue
my background thread is waiting on). It also eliminates the customJob
classes I used to create for using withLinkedBlockingQueues
. And, it simplifies a bit doing final work back on the UI thread.In your case, with a remote service, the UI thread issue is less critical, since the activity needs to handle that itself.
I don't see what the difference is between your #2 and your last paragraph. In both cases, your service will call the callback object, which will use something like
runOnUiThread()
to arrange for the work to be done on the UI thread.AFAIK, the only two ways to have a service doing any sort of asynchronous work let the client know that work is done is by a broadcast
Intent
or a callback object. BroadcastIntents
are convenient but public (i.e., other code can watch for them).I suspect I probably have not helped much here, but I just don't know enough of your scenario to provide greater detail.
I'm having quite the same question : i'm developping a map activity, with a 'lazy-loading' functionnality (xml from Network, parsing it, then updating my map with the 'items' created from that parsing...)
i wondered what would be 'the best' way to implement it...
I guess a more precise answer might be found from Android contributors on the Android-developper-group...