Sunday, September 12, 2010

Re: [android-developers] Re: AsyncTask and screen rotation

Note that using android:process on a Service doesn't change its semantics w.r.t. its main thread.  No matter what process it is running in, the lifecycle callbacks happen on that process's main thread, and you don't want to block the main thread.  Running the service in a process that doesn't have UI may make the problem less visible, but it is still there.  For example, the system will at various points ask your process to do something -- to call your service's onStart() or to dispatch a broadcast or various other things -- and if it isn't responsive to that then it will be considered not responding and dealt with.  For stuff that isn't related to UI, this is just a little different: the timeout is a bit longer (currently 10s) and if an ANR does happen on user builds the process will be silently killed rather than annoying the user.

On Sun, Sep 12, 2010 at 5:23 PM, Lance Nanek <lnanek@gmail.com> wrote:
The non-default situation I was thinking of was there not being
anything like android:process=":remote" on the service declaration in
the manifest. Without any specific settings to prevent it like that
one, setting an alarm for a PendingIntent from
PendingIntent#getService will start the service on the same main/UI
thread that the activities in the app run on.

On Sep 12, 6:29 pm, Indicator Veritatis <mej1...@yahoo.com> wrote:
> But just as you say, that is by -default- that it is on the same
> process and thread. Now does anyone actually use it with that same
> process being an Activity? Often (though not always), it is launched
> by an Alarm, not by the main process hosting the UI thread in the
> first place. Then it is the Service that sends messages to the
> Activity that currently has the UI.
>
> Now since the whole purpose of AsyncTask is to provide communication
> and coordination between a UI thread and a worker thread (more
> conveniently than with java.lang.thread), it might make sense to use
> AsyncTask in a Service only if the Service itself has a UI thread. But
> although the docs you mention admit to this possibility, I am having
> trouble seeing why that would ever be good design.
>
> But knowing this group, if there are any such, someone will pop up out
> of the woodwork and show us:)
>
> On Sep 11, 2:36 am, Lance Nanek <lna...@gmail.com> wrote:
>
> > > peculiar problems in the way the classes are designed. Service by
> > > definition is already in the background, it HAS no UI thread, so why
>
> > Services, by default, run in the same on process and on the main/UI
> > thread.
>
> > >http://developer.android.com/reference/android/app/Service.html
> > > Note that services, like other application objects, run in the main thread of their hosting process. This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work.
>
> > On Sep 11, 4:55 am, Indicator Veritatis <mej1...@yahoo.com> wrote:> Option 4 certainly sounds like it will work, but it suggests some
> > > peculiar problems in the way the classes are designed. Service by
> > > definition is already in the background, it HAS no UI thread, so why
> > > do I need an AsyncTask there at all? The whole point of the latter is
> > > to communicate between UI thread and worker thread.
>
> > > As for documenting what works, I hope Google takes your hint and
> > > documents what the right way to do this really is. After all, these
> > > are the same people who keep warning us that "if it's not documented,
> > > then it is subject to change w/o notice".
>
> > > On Sep 10, 10:04 am, Mark Murphy <mmur...@commonsware.com> wrote:
>
> > > > On Fri, Sep 10, 2010 at 12:46 PM, Romain Guy <romain...@android.com> wrote:
> > > > > Option #1 is a lot more intrusive. You lose the ability to
> > > > > automatically switch layouts, drawables, etc.
>
> > > > Worst-case scenario:
>
> > > > Step #1: Take your UI setup that is in onCreate() and move it to a
> > > > separate method (e.g., setupViews())
>
> > > > Step #2: Call setupViews() from onCreate()
>
> > > > Step #3: Call setupViews() from onConfigurationChanged()
>
> > > > Done. ~4 lines of code. And it's the exact same code path that a
> > > > destroy/recreate will go down, so it's not like this adds unusual
> > > > performance overhead. There are certain circumstances where this may
> > > > not work (e.g., GLSurfaceView and a game), but you needed to do extra
> > > > work for those cases, anyway, to handle the destroy/recreate cycle.
>
> > > > > Saving and restoring an AsyncTask is not difficult.
>
> > > > No, it's not. The question is: is it reliable?
>
> > > > None of the AsyncTask documentation (class, article, etc.) covers this
> > > > case. It *appears* that you can write an AsyncTask such that
> > > > onPostExecute() or onProgressUpdate() will not be called in the middle
> > > > of the activity transition. However, that's not documented and hence
> > > > not guaranteed, and so while I'll describe a pattern that seems to
> > > > work, I personally don't trust it any further than I can throw your
> > > > large Froyo lawn ornament. If somebody could give us the recipe that
> > > > is guaranteed to work (i.e., works today, and is going to work in
> > > > Android 2.3/3.0/Turbo System 5000), that'd be *wonderful*.
>
> > > > Actually, I lied earlier. I'd choose Option #4:
>
> > > > Option #4: Don't do the AsyncTask in an activity. Use a Service and
> > > > have it do the AsyncTask, or use an IntentService if the sole purpose
> > > > of the service is to do stuff in a background thread. In particular,
> > > > an IntentService would be good for a download that you want to happen
> > > > regardless of what may go on with an activity (e.g., Android Market
> > > > downloading an APK), and so you don't need to worry about canceling
> > > > it.
>
> > > > --
> > > > Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
>
> > > > Android Training in London:http://skillsmatter.com/go/os-mobile-server

--
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en



--
Dianne Hackborn
Android framework engineer
hackbod@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

No comments:

Post a Comment