Thanks for your feedback guys.

The experience I shared there was practical - and there are times and
requirements when you do need to start a service at the boot time, and
it's really better to run it in a separate process. For example, any
mail-like application would have such requirements. It's probably the
simplicity of the functionality of that small example that makes the
chosen architecture look a bit overshot.

Now, I would be happy to hear something about the loopers and the
handlers. :)

On Jun 4, 1:35 am, Mark Murphy <mmur...@commonsware.com> wrote:
> Dianne Hackborn wrote:
> > - Running the service in a separate process, just because.  The vast
> > majority of apps should keep their service in the same process.  This
> > greatly the interaction with the service (no IPC), and is generally a
> > lighter-weight solution.  There are certain cases where using another
> > process is useful, but this should not be encouraged.
>
> Demonstrating remote services using a Twitter app is reasonable -- heck,
> I do that myself. It's impossible to make a realistic scenario for
> remote services and keep it short.
>
> However, I would do it with separate APKs, highlighting remote services
> being used for inter-application integration. That should be the more
> common use of remote binding and such.
>
> > - Running the service at boot, forever.  Please please don't.  Please.
>
> Yeah, that's fairly evil.
>
> http://www.androidguys.com/2009/09/09/diamonds-are-forever-services-a...http://www.androidguys.com/2010/03/29/code-pollution-background-control/
>
> --
> Mark Murphy (a Commons 
> Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
>
> _Android Programming Tutorials_ Version 2.0 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

Reply via email to