Ultimately calls through a binder object are a direct function call. Most of my comments along these lines have been about defining aidl interfaces for communicating with local services, which is a waste (there is lots of generated code that will never be used), and a lot more work (you need to define your interface solely in terms of what aidl supports).
The local service api demo shows a good way to go about this: http://android.git.kernel.org/?p=platform/development.git;a=blob;f=samples/ApiDemos/src/com/example/android/apis/app/LocalServiceBinding.java;h=ddcfad5fc3fcf2b4f2c3630e75cff2cba7f95ad7;hb=HEAD As far as the service being killed... if there is not enough memory to run it and everything else, yes it will be killed. At some point there isn't much we can do about it. (Fwiw, the browser by itself on certain pages can use enough memory to start to cause background services to be killed.) However, for your particular use case... if you have an ongoing notification associated with it running, allowing the user to explicitly stop it, then you can use Service.setForeground() for ONLY the time you have the notification shown. Please don't abuse this. Well actually people are already abusing it so I will probably need to do something like turn that into a no-op and add a now API that explicitly associates foreground state with a notification... but anyway, this is how the music player tells the system that it is doing something that the user is aware of as running in the foreground. On Sun, Jul 19, 2009 at 9:33 AM, Guillaume Perrot <guillaume.p...@gmail.com>wrote: > I was not aware of the overhead issue with a "local" Binder, I thought this > case was optimized. > I hope the Android team will work on this so that we won't have to reinvent > the wheel. > I will look at your code once it'll be available, this sounds interesting. > > 2009/7/19 Mark Murphy <mmur...@commonsware.com> > > >> Guillaume Perrot wrote: >> > Using both startService and bindService is handy to wait for the >> > onServiceConnected callback before requesting a singleton reference >> > that is set in the service's onCreate. >> > If you do this just after the startService, the reference will be >> > null. >> >> Correct, because startService() (and bindService() FWIW) are asynchronous. >> >> > The startService is needed for the service to continue running when >> > the activities have been destroyed (and call unbind). >> >> Correct. >> >> > A use case is a service managing a background XMPP connection in a >> > chat/social application (only the "sign out" user action would call >> > stopService). >> > So, Mark I don't understand your point when you say not to use both >> > startService and bindService. >> >> Going through Binder, and all of the work to set up an out-of-process >> connection to something in your same process, just to find out when a >> service is ready for use, seems like a waste. I do not get the >> impression that Binder is optimized for the in-process case, given all >> of the comments to that effect from the core Android team. >> >> To that end, I've put together a local IntentBus, that uses Intents and >> IntentFilters to enable decoupled communication between activities and >> services inside of a single process. It works like broadcast Intents, >> just, er, "localcast" instead. If all goes well, an early cut of this >> will go out as open source tomorrow. I haven't focused on this >> particular scenario (activity starting a service and finding out when it >> is ready for use), but it's probably a logical extension of the bus. >> >> -- >> Mark Murphy (a Commons Guy) >> http://commonsware.com | http://twitter.com/commonsguy >> >> Android 1.5 Programming Books: http://commonsware.com/books.html >> >> >> > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
