[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
It's a bit hard to say what design is right without details on what the service actually does. First and most important question - do you really need a service at all? Many apps use services but don't actually need to run all the time. Using a service is like a tax on your user. It's currently invisible but it won't always be that way: expect your users to start asking questions at some point if/when Android makes resource consumption of apps more visible. Most of the time when people are using a permanently running service, what they really want is a service that handles inexactly repeating alarms. Now how to sync state between the activities and the services. Remember that a service is just an object representing a lifecycle construct. It exists in the same process that your activities do, so they can communicate in the same way any two Java objects would communicate - via direct method calls, for instance. It's perfectly OK to use the local service idiom that is shown in the API samples to bind to a service and then cast the result to the object itself. Or if started using an intent, you can just stuff a reference to this into a static field. As to using intents, you don't have to do this. You can just keep track of what the service is meant to do in a file, a database, or whatever else is convenient. But again, really consider whether you need an always-running service. Very few apps actually need this (things like music players being the obvious exception). --~--~-~--~~~---~--~~ 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: Design guidelines question; Services vs. Intent broadcasts.
Beyond agreeing with what Mr. Hearn wrote, a few other points: Erik H wrote: Also, is really an AIDL the right way to allow third-party integration? AIDL has a few huge advantages that may or may not be relevant to you: 1. You actually get return values. 2. You don't need your service running to use AIDL -- the bind operation can auto-start the service if it is not already running. 3. If you use binding to implicitly start your service, Android will shut down the service when there is nothing else bound to it. The combination of #2 and #3 means that I hope you can avoid the always-running service pattern. Use AIDL. If your service needs to do some work on occasion independent of any activity, use AlarmManager and WakeLocks to schedule the startup and execution of that work. After all, you're going to need them anyway, since phones go to sleep, so you may as well minimize your footprint as part of the bargain. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android 1.5 Programming Books: http://commonsware.com/books.html --~--~-~--~~~---~--~~ 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: Design guidelines question; Services vs. Intent broadcasts.
On Jul 6, 1:28 pm, Mike Hearn mh.in.engl...@gmail.com wrote: First and most important question - do you really need a service at all? Many apps use services but don't actually need to run all the time. Using a service is like a tax on your user. It's currently invisible but it won't always be that way: expect your users to start asking questions at some point if/when Android makes resource consumption of apps more visible. Yes. I absolutely need a background service since I'm doing something similar to a music player. :) Now how to sync state between the activities and the services. Remember that a service is just an object representing a lifecycle construct. It exists in the same process that your activities do, so they can communicate in the same way any two Java objects would communicate - via direct method calls, for instance. It's perfectly OK to use the local service idiom that is shown in the API samples to bind to a service and then cast the result to the object itself. Or if started using an intent, you can just stuff a reference to this into a static field. As to using intents, you don't have to do this. You can just keep track of what the service is meant to do in a file, a database, or whatever else is convenient. I agree totally, but my problem is that my service will most likely be used by other applications. There could be three (or more) completely different applications using the service at the same time (a standard UI doing one type of visualization and another app doing a different visualization and a homescreen widget, all in different .apk). So the question remains. If I need to support third-party integration, is a service (published as an AIDL file) better than Intents? And if using Intents, is it better to use sticky intent or should I send very frequent normal broadcast intents from the service to signal its state? Thanks, Erik --~--~-~--~~~---~--~~ 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: Design guidelines question; Services vs. Intent broadcasts.
On Jul 6, 1:35 pm, Mark Murphy mmur...@commonsware.com wrote: AIDL has a few huge advantages that may or may not be relevant to you: 1. You actually get return values. The flow of the application is asynchronous, so i would have to poll the service for updates in that case. 2. You don't need your service running to use AIDL -- the bind operation can auto-start the service if it is not already running. I already do this. The first UI/Widget that starts will also start the service if it is not already running. 3. If you use binding to implicitly start your service, Android will shut down the service when there is nothing else bound to it. ...and I don't want it to shut down because it will keep working even after the user closes the UI. // Erik --~--~-~--~~~---~--~~ 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: Design guidelines question; Services vs. Intent broadcasts.
Erik Hellman wrote: 1. You actually get return values. The flow of the application is asynchronous, so i would have to poll the service for updates in that case. Or register a callback AIDL object with the service. Or use broadcast intents for the callback-style messaging, though these are subject to interception. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android 1.5 Programming Books: http://commonsware.com/books.html --~--~-~--~~~---~--~~ 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: Design guidelines question; Services vs. Intent broadcasts.
On Jul 6, 2:01 pm, Mark Murphy mmur...@commonsware.com wrote: Or register a callback AIDL object with the service. Or use broadcast intents for the callback-style messaging, though these are subject to interception. Yes. But that is my question. What is most effective, considering performance, power-consumption and third-party integration (in that order); Using a service through AIDL or using Intents (with sticky broadcasts for service state)? Security is not an issue at the moment, so we can disregard from that aspect. // Erik --~--~-~--~~~---~--~~ 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: Design guidelines question; Services vs. Intent broadcasts.
Erik Hellman wrote: Yes. But that is my question. What is most effective, considering performance, power-consumption and third-party integration (in that order); Using a service through AIDL or using Intents (with sticky broadcasts for service state)? As Mr. Hearn indicated, this question cannot readily be answered in the abstract. Write them both ways and see how you like them. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 0.9 Available! --~--~-~--~~~---~--~~ 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: Design guidelines question; Services vs. Intent broadcasts.
mjc147 wrote: This is probably relevant for nearly all type of music player-like apps because they need some kind of UI to get started but still need to continue playing once that UI has been exited. And that's a fine reason for having a service. However, it's a rare music player that is designed for multiple front-ends, so a local service would be much simpler. Is there a way around this? When you say implicitly are you implying that the opposite is true when explicitly starting a service? If your service is started via bindService(), it will be stopped sometime after the last client unbinds. If your service is started via startService(), it will run into somebody tells it to stop (stopService(), stopSelf(), Android terminating the process, gravity and a concrete floor negatively impacting the device). If you wish to use AIDL, but still want the service to run even after unbinding, use both startService() and bindService(). -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 0.9 Available! --~--~-~--~~~---~--~~ 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: Design guidelines question; Services vs. Intent broadcasts.
On Jul 6, 7:58 pm, Erik Hellman erik.d.hell...@gmail.com wrote: On Jul 6, 7:35 pm, Mark Murphy mmur...@commonsware.com wrote: 3. If you use binding to implicitly start your service, Android will shut down the service when there is nothing else bound to it. ...and I don't want it to shut down because it will keep working even after the user closes the UI. This is probably relevant for nearly all type of music player-like apps because they need some kind of UI to get started but still need to continue playing once that UI has been exited. Is there a way around this? When you say implicitly are you implying that the opposite is true when explicitly starting a service? --~--~-~--~~~---~--~~ 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: Design guidelines question; Services vs. Intent broadcasts.
On Jul 6, 2:20 pm, Mark Murphy mmur...@commonsware.com wrote: If your service is started via bindService(), it will be stopped sometime after the last client unbinds. If your service is started via startService(), it will run into somebody tells it to stop (stopService(), stopSelf(), Android terminating the process, gravity and a concrete floor negatively impacting the device). If you wish to use AIDL, but still want the service to run even after unbinding, use both startService() and bindService(). This is all fine. I have a working example where I use a service and publish an AIDL. However, it doesn't seem like an efficient way of designing my service to allow easy integration from third-party applications (yes, it is a quite rare sort of application). Using intents would require some re-design, which is fine by me but I'm looking for the drawback of using this from a performance and power- consumption point-of-view. Do broadcast intents consume more power than direct service calls? Does sending, receiving and parsing a broadcast intent take more CPU than a direct service call? I know it is a very general question, but I'm assuming there is a general guideline when to use intents and when to use a service? // Erik --~--~-~--~~~---~--~~ 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: Design guidelines question; Services vs. Intent broadcasts.
Erik Hellman wrote: Using intents would require some re-design, which is fine by me but I'm looking for the drawback of using this from a performance and power- consumption point-of-view. Do broadcast intents consume more power than direct service calls? Does sending, receiving and parsing a broadcast intent take more CPU than a direct service call? If you are creating a music player, playing music will take up much more CPU time and battery life than either communications mechanism, probably by a few orders of magnitude. Personally, I'd focus on other issues, such as usability of whatever third-party interface you're offering. I know it is a very general question, but I'm assuming there is a general guideline when to use intents and when to use a service? Not especially. I'm not aware of anyone publishing any sort of performance comparison, and both the AIDL and broadcast Intent stuff is deep enough in the code base as to be difficult to follow for us mere mortals. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 0.9 Available! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
