[android-developers] Re: Advice for remote service returning value from http transaction
A few quick questions I tend to ask people using services: 1) Do you really need a service? If all you want to do is some background processing that is transient in nature, a regular thread is OK. It will be killed eventually when your app is no longer on-screen but maybe you can deal with that. 2) Do you really need IPC? AIDL and intents are easy to use for what they are. If your service is intended to only be used by your own application, you can simplify a lot by simply passing pointers around: http://osdir.com/ml/AndroidDevelopers/2009-02/msg02636.html Remember that a service is really just a lifecycle abstraction. It's a shame that the documentation strongly implies that you MUST use rpc to communicate with them, when that isn't true. 3) Are you using intents to give work to the service? If so, what is the lifetime policy of the service? Binding provides this for you, submitting intents does not. In particular, realize that it's scarily easy to leak services by having them enter a state in which they wait for work forever. Make sure there's always a timer running that will shut the service down if it has nothing to do - and make sure that it's set up in onCreate() *not* onStart(). Your service is not guaranteed to ever receive onStart ... if it's killed by the kernel OOM killer and then restarted, it'll receive onCreate but not onStart. Hope that helps! On May 6, 9:38 pm, jseghers jsegh...@cequint.com wrote: I've been researching how to best implement a service which performs a network transaction and returns data to the caller. Clearly, this needs to happen on its own thread which means some form of async response. I can see at least three ways of doing this--some more complex than others. In the descriptions below, C is the caller, S is the service. 1) C wraps a Handler in a Messenger object, adds this to an Intent. C then calls startService with this intent. S extends IntentService which runs the Intents received in a worker thread. S then sends a message to C via the Messenger. This has the benefit of not requiring any of the async binding process or making an IDL interface that needs to be compiled into C. This seems to be the closes to a Handler-based response mechanism of Local Services. 2) C binds to S and then uses AsyncTask to make a blocking call to S. S performs the network transaction and returns the data in the return value or an out parameter. This requires the async binding process, but does not require a callback function since the inter- thread communications is handled by AsyncTask and the worker thread is in C's context. 3) Make the function called in S be completely asynchronous. S defines two interfaces: IMyService and IMyServiceCallback. S implements IMyService.Stub. C implements IMyServiceCallback.Stub. C binds to S then calls S via IMyService, passing its IMyServiceCallback binder. S spins up a worker thread and returns immediately. S then calls the callback when it has completed the network transaction. I am asking for advice on which methods are most appropriate. I do not need the the service running constantly, only when the web transaction is required. C does not use S all the time--definitely don't want to bind during C's onCreate. However, I would like the time from when C determines it needs to use S to getting the results back to be as quick as possible (i.e. adding minimal latency to the already latent network access). Is there any preference to having the worker thread in C or in S? Are there any significant problems with option 1? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Advice for remote service returning value from http transaction
On May 6, 5:33 pm, jseghers jsegh...@cequint.com wrote: On May 6, 2:49 pm, Dianne Hackborn hack...@android.com wrote: [B]e aware that if you do this by sending to a registered broadcast receiver, you can cause security holes because other people can also register for the broadcast and send a broadcast to your client. I think I found more what Dianne was suggesting with PendingIntent. I'm now using Activity.createPendingResult() which overloads the onActivityResult() mechanism and thus there's no need to set up a broadcast receiver. This makes the remote service very close in concept to a LocalService using Handlers. - John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Advice for remote service returning value from http transaction
Yep that's good. On Fri, May 8, 2009 at 10:06 AM, jseghers jsegh...@cequint.com wrote: On May 6, 5:33 pm, jseghers jsegh...@cequint.com wrote: On May 6, 2:49 pm, Dianne Hackborn hack...@android.com wrote: [B]e aware that if you do this by sending to a registered broadcast receiver, you can cause security holes because other people can also register for the broadcast and send a broadcast to your client. I think I found more what Dianne was suggesting with PendingIntent. I'm now using Activity.createPendingResult() which overloads the onActivityResult() mechanism and thus there's no need to set up a broadcast receiver. This makes the remote service very close in concept to a LocalService using Handlers. - John -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Advice for remote service returning value from http transaction
How about doing option 1, but having the caller include a PendingIntent for where the result should be sent. This way the caller doesn't even need to stick around while your service is running -- it can give you a PendingIntent that launches a receiver when you send it back. If you want to go the IDL route, I would suggest an async call, with a callback interface that is suppled and you call when done. On Wed, May 6, 2009 at 12:38 PM, jseghers jsegh...@cequint.com wrote: I've been researching how to best implement a service which performs a network transaction and returns data to the caller. Clearly, this needs to happen on its own thread which means some form of async response. I can see at least three ways of doing this--some more complex than others. In the descriptions below, C is the caller, S is the service. 1) C wraps a Handler in a Messenger object, adds this to an Intent. C then calls startService with this intent. S extends IntentService which runs the Intents received in a worker thread. S then sends a message to C via the Messenger. This has the benefit of not requiring any of the async binding process or making an IDL interface that needs to be compiled into C. This seems to be the closes to a Handler-based response mechanism of Local Services. 2) C binds to S and then uses AsyncTask to make a blocking call to S. S performs the network transaction and returns the data in the return value or an out parameter. This requires the async binding process, but does not require a callback function since the inter- thread communications is handled by AsyncTask and the worker thread is in C's context. 3) Make the function called in S be completely asynchronous. S defines two interfaces: IMyService and IMyServiceCallback. S implements IMyService.Stub. C implements IMyServiceCallback.Stub. C binds to S then calls S via IMyService, passing its IMyServiceCallback binder. S spins up a worker thread and returns immediately. S then calls the callback when it has completed the network transaction. I am asking for advice on which methods are most appropriate. I do not need the the service running constantly, only when the web transaction is required. C does not use S all the time--definitely don't want to bind during C's onCreate. However, I would like the time from when C determines it needs to use S to getting the results back to be as quick as possible (i.e. adding minimal latency to the already latent network access). Is there any preference to having the worker thread in C or in S? Are there any significant problems with option 1? -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Advice for remote service returning value from http transaction
Thank you for your quick reply. I thought about the PendingIntent, but in this application the information is only useful to the Caller if it is received while the Caller is active that time. So if the information arrives later, we'll still process it in the Service and store it for later use, but we don't want to invoke an activity in the Caller. - John On May 6, 12:54 pm, Dianne Hackborn hack...@android.com wrote: How about doing option 1, but having the caller include a PendingIntent for where the result should be sent. This way the caller doesn't even need to stick around while your service is running -- it can give you a PendingIntent that launches a receiver when you send it back. If you want to go the IDL route, I would suggest an async call, with a callback interface that is suppled and you call when done. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Advice for remote service returning value from http transaction
On further investigation, I see that the PendingIntent can be cancelled, and such can work in the way I need by using a BroadcastReceiver (probably dynamically registered). - John On May 6, 12:59 pm, jseghers jsegh...@cequint.com wrote: Thank you for your quick reply. I thought about the PendingIntent, but in this application the information is only useful to the Caller if it is received while the Caller is active that time. So if the information arrives later, we'll still process it in the Service and store it for later use, but we don't want to invoke an activity in the Caller. - John On May 6, 12:54 pm, Dianne Hackborn hack...@android.com wrote: How about doing option 1, but having the caller include a PendingIntent for where the result should be sent. This way the caller doesn't even need to stick around while your service is running -- it can give you a PendingIntent that launches a receiver when you send it back. If you want to go the IDL route, I would suggest an async call, with a callback interface that is suppled and you call when done.- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Advice for remote service returning value from http transaction
We aware that if you do this by sending to a registered broadcast receiver, you can cause security holes because other people can also register for the broadcast and send a broadcast to your client. On Wed, May 6, 2009 at 1:24 PM, jseghers jsegh...@cequint.com wrote: On further investigation, I see that the PendingIntent can be cancelled, and such can work in the way I need by using a BroadcastReceiver (probably dynamically registered). - John On May 6, 12:59 pm, jseghers jsegh...@cequint.com wrote: Thank you for your quick reply. I thought about the PendingIntent, but in this application the information is only useful to the Caller if it is received while the Caller is active that time. So if the information arrives later, we'll still process it in the Service and store it for later use, but we don't want to invoke an activity in the Caller. - John On May 6, 12:54 pm, Dianne Hackborn hack...@android.com wrote: How about doing option 1, but having the caller include a PendingIntent for where the result should be sent. This way the caller doesn't even need to stick around while your service is running -- it can give you a PendingIntent that launches a receiver when you send it back. If you want to go the IDL route, I would suggest an async call, with a callback interface that is suppled and you call when done.- Hide quoted text - - Show quoted text - -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Advice for remote service returning value from http transaction
On May 6, 2:49 pm, Dianne Hackborn hack...@android.com wrote: [B]e aware that if you do this by sending to a registered broadcast receiver, you can cause security holes because other people can also register for the broadcast and send a broadcast to your client. Am I safe by doing the following: Caller has a class instance BR that extends BroadcastReceiver, but does not have an entry in the ApplicationManifest. Caller constructs a PendingIntent using the ComponentName object refering to the BR class. At the time of calling startService, the Caller uses Context.registerReceiver(BR, new IntentFilter()) (thus, if I understand correctly, with an empty IntentFilter it cannot be selected by Intent Resolution). After the service has replied via the PendingIntent, the Caller unregisters the receiver. Can I make the BR class non-public to prevent anyone else from forming an Intent for it? - John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
