Re: [android-developers] android design considerations: AsynchTask vs Service (IntentService?)

[Prakash Iyer]

Dianne,

With all due respect, HandlerThread or Thread do NOT convey the message that
they can be used with the UI in the same way that an AsyncTask does. In fact
even a small para saying something like

AsyncTask runs as a separate thread and does interact with the Activity's
lifecycle. It is associated with the instance that executed the AsyncTask,
however the onProgress and onResult are called in the main UI thread that
deals with the currently active instance which could be different than the
one that executed the AsyncTask. Thus the developer must ensure that any
reference to the Activity or UI components are not stale.

would help, IMHO.

I think we are beating a dead horse here and way off topic for the OP, so I
will stop...

On Sun, Oct 3, 2010 at 1:13 AM, Dianne Hackborn  wrote:

> On Sat, Oct 2, 2010 at 3:39 PM, Prakash Iyer  wrote:
>
>> Each his own. Try writing a AsyncTask that say lives for more than 10s and
>> in the final result say updates a text field. Now before the AsyncTask
>> completes, just change the orientation. I'd bet most developers would assume
>> the text field will get updated. Most developers would be wrong as the
>> AsyncTask's onResult will be calling the original object's (the one that did
>> the execute) text field and not the one that is currently displayed. Can you
>> make sure this works? Yes! Should this be documented? I would think it is
>> absolutely essential.
>
>
> This has *nothing* to do with AsyncTask, this is all about the
> peculiarities of Activity.  You will run into the same issue if you use
> HandlerThread, a raw Thread()...  heck, you'd even have the issue if you
> didn't use another thread at all but just Handler.postDelayedMessage().
>
> This behavior is documented in the material Activity; it doesn't make any
> sense to try to document this in every other generic facility for
> asynchronicity just because if you use that with an Activity you will need
> to understand how Activity instances can be fairly transient.
>
> And what you need to do with AsyncTask is *different* depending on where
> you are using it -- in an Activity, or a Service, or a View, or whatever.
>  They each have their own sometimes subtle details about lifecycle that you
> need to understand when introducing asynchronicity.  AsyncTask can't try to
> document exactly how to use it when combined with every other possible
> facility.
>
> --
> 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
>

-- 
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

Re: [android-developers] android design considerations: AsynchTask vs Service (IntentService?)

[Dianne Hackborn]

On Sat, Oct 2, 2010 at 3:39 PM, Prakash Iyer  wrote:

> Each his own. Try writing a AsyncTask that say lives for more than 10s and
> in the final result say updates a text field. Now before the AsyncTask
> completes, just change the orientation. I'd bet most developers would assume
> the text field will get updated. Most developers would be wrong as the
> AsyncTask's onResult will be calling the original object's (the one that did
> the execute) text field and not the one that is currently displayed. Can you
> make sure this works? Yes! Should this be documented? I would think it is
> absolutely essential.


This has *nothing* to do with AsyncTask, this is all about the peculiarities
of Activity.  You will run into the same issue if you use HandlerThread, a
raw Thread()...  heck, you'd even have the issue if you didn't use another
thread at all but just Handler.postDelayedMessage().

This behavior is documented in the material Activity; it doesn't make any
sense to try to document this in every other generic facility for
asynchronicity just because if you use that with an Activity you will need
to understand how Activity instances can be fairly transient.

And what you need to do with AsyncTask is *different* depending on where you
are using it -- in an Activity, or a Service, or a View, or whatever.  They
each have their own sometimes subtle details about lifecycle that you need
to understand when introducing asynchronicity.  AsyncTask can't try to
document exactly how to use it when combined with every other possible
facility.

-- 
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

Re: [android-developers] android design considerations: AsynchTask vs Service (IntentService?)

[Agus]

item #5 seems not user friendly to me.
assuming that user can open other applications on the phone and since
that the sync takes 10-20 minutes i suggest initiating an asynctask in
a service. If you use a service, android will try hard not kill your
application process.


On Tue, Sep 28, 2010 at 11:50 PM, Tia  wrote:
>
> I'm designing an android app which will need todo the following steps:
>
>   1. user pushes a button or otherwise indicates to "synch data".
>   2. synch process will use REST web services to move data to and
> from the server.
>   3. the data will be stored locally in a sqlite database.
>   4. the synch process should provide status updates/messages to the
> UI
>   5. the user should not be allowed to wander off to other parts of
> the application and do more work during the synch process.
>
> The first time the synch process runs, it may take 10-20 minutes.
> After the initial synch, less data will be transferred and stored and
> I expect the process to take 1-2 minutes or less.
>
> I've been doing a lot of reading about android's AsychTask and various
> examples of using a Service ... But I don't fully understand the
> design considerations and trade-offs of choosing one design over the
> other. I currently have my demo project stubbed out using an
> AsychTask. After watching (most of) Developing Android REST client
> applications: 
> http://code.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html#
> I'm left confused the design patterns described here feel overly
> complex, perhaps because I just "don't get it" yet.
>
> Would love to hear from some more experienced android developers out
> there who have already wrestled with these questions.
>
> --
> 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

-- 
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

Re: [android-developers] android design considerations: AsynchTask vs Service (IntentService?)

[Tom Gibara]

AsyncTasks can be used in a number of contexts, not only in Activities. And
where they are used in activities, there are many way of plumbing them to
the activity lifecycle. Here are three scenarios that I would generally use
AsyncTasks for (rather than services):

1) Dynamically rendering an image for the UI (here I would usually let the
task run to completion and then discard the bitmap if the Activity had been
destroyed).

2) Loading thumbnails from a web server (here I might explicitly cancel the
task when the activity is destroyed)

3) Logging a user into a server (here I typically keep the task running and
maintain a static reference to the 'current' activity instance)

My point here is that the range of possible ways of using AsyncTask is
broad, and the best way is heavily dependent on the specific case, so it
ceases to be something that can be adequately covered in the javadocs. It's
better suited to a book on Android development in my opinion.

Tom.

On 2 October 2010 23:39, Prakash Iyer  wrote:

> Each his own. Try writing a AsyncTask that say lives for more than 10s and
> in the final result say updates a text field. Now before the AsyncTask
> completes, just change the orientation. I'd bet most developers would assume
> the text field will get updated. Most developers would be wrong as the
> AsyncTask's onResult will be calling the original object's (the one that did
> the execute) text field and not the one that is currently displayed. Can you
> make sure this works? Yes! Should this be documented? I would think it is
> absolutely essential.
>
>
> On Sat, Oct 2, 2010 at 6:25 PM, Tom Gibara  wrote:
>
>> AsyncTask is excellently documented:
>>
>> http://developer.android.com/reference/android/os/AsyncTask.html
>>
>>  AsyncTask
>> has no interaction with the Activity lifecycle, except for that which you
>> introduce with your own code.
>>
>> It's for precisely this reason that AsyncTask and Service are mostly
>> orthogonal: An AsyncTask is helpful way of delegating work onto a thread
>> other than the main thread; a Service exposes a component lifecycle so that
>> a UI-free operation can be managed by the system.
>>
>> Tom.
>>
>> On 2 October 2010 22:20, Prakash Iyer  wrote:
>>
>>> I'm not sure I agree with your comment that it is the wrong question. In
>>> fact your explanation of how a majority of the cases a Service runs in the
>>> same process is precisely why most people will consider these as
>>> alternatives. I was trying to point out to the OP that if the OP ever wanted
>>> to create something that lived independent of the UI and/or was planned to
>>> be used by more than one activity independently developed/distributed, a
>>> service would be a better choice...
>>>
>>> IMHO the AsyncTask is notoriously poorly documented. It has some really
>>> strange interactions with the Activity lifecycle... As some one pointed out
>>> the IntentService is probably a better choice in many cases. Which again
>>> brings to question the orthogonality of AsyncTask & Service...
>>>
>>>
>>> On Sat, Oct 2, 2010 at 5:09 AM, Dianne Hackborn wrote:
>>>
 On Fri, Oct 1, 2010 at 2:07 PM, Prakash Iyer  wrote:

> Service, OTOH, is designed to work in the background without requiring
> user interaction. Problem is that for your Activity to display the results
> it must somehow interact with your service. Ideally you will want to spawn
> the service off in a separate process and use either Intents or AIDL to
> communicate back progress to the Activity.
>

 The vast majority of the time, there is no need to run the service in a
 separate process and thus deal with all of the additional complexity of 
 AIDL
 and such.

 As another poster mentioned, IntentService is very useful.

 Also "AsyncTask vs. Service" is the wrong question.  These are almost
 totally orthogonal to each other -- you very often may use an AsyncTask as
 part of implementing a service for example.

 And if your service is running in the same process as your activity, it
 is very easy to just bind to it from the activity, call on to it to get its
 current state, and supply a callback for when the state changes, just using
 normal Java coding.

 --
 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

Re: [android-developers] android design considerations: AsynchTask vs Service (IntentService?)

[Prakash Iyer]

Each his own. Try writing a AsyncTask that say lives for more than 10s and
in the final result say updates a text field. Now before the AsyncTask
completes, just change the orientation. I'd bet most developers would assume
the text field will get updated. Most developers would be wrong as the
AsyncTask's onResult will be calling the original object's (the one that did
the execute) text field and not the one that is currently displayed. Can you
make sure this works? Yes! Should this be documented? I would think it is
absolutely essential.

On Sat, Oct 2, 2010 at 6:25 PM, Tom Gibara  wrote:

> AsyncTask is excellently documented:
>
> http://developer.android.com/reference/android/os/AsyncTask.html
>
>  AsyncTask
> has no interaction with the Activity lifecycle, except for that which you
> introduce with your own code.
>
> It's for precisely this reason that AsyncTask and Service are mostly
> orthogonal: An AsyncTask is helpful way of delegating work onto a thread
> other than the main thread; a Service exposes a component lifecycle so that
> a UI-free operation can be managed by the system.
>
> Tom.
>
> On 2 October 2010 22:20, Prakash Iyer  wrote:
>
>> I'm not sure I agree with your comment that it is the wrong question. In
>> fact your explanation of how a majority of the cases a Service runs in the
>> same process is precisely why most people will consider these as
>> alternatives. I was trying to point out to the OP that if the OP ever wanted
>> to create something that lived independent of the UI and/or was planned to
>> be used by more than one activity independently developed/distributed, a
>> service would be a better choice...
>>
>> IMHO the AsyncTask is notoriously poorly documented. It has some really
>> strange interactions with the Activity lifecycle... As some one pointed out
>> the IntentService is probably a better choice in many cases. Which again
>> brings to question the orthogonality of AsyncTask & Service...
>>
>>
>> On Sat, Oct 2, 2010 at 5:09 AM, Dianne Hackborn wrote:
>>
>>> On Fri, Oct 1, 2010 at 2:07 PM, Prakash Iyer  wrote:
>>>
 Service, OTOH, is designed to work in the background without requiring
 user interaction. Problem is that for your Activity to display the results
 it must somehow interact with your service. Ideally you will want to spawn
 the service off in a separate process and use either Intents or AIDL to
 communicate back progress to the Activity.

>>>
>>> The vast majority of the time, there is no need to run the service in a
>>> separate process and thus deal with all of the additional complexity of AIDL
>>> and such.
>>>
>>> As another poster mentioned, IntentService is very useful.
>>>
>>> Also "AsyncTask vs. Service" is the wrong question.  These are almost
>>> totally orthogonal to each other -- you very often may use an AsyncTask as
>>> part of implementing a service for example.
>>>
>>> And if your service is running in the same process as your activity, it
>>> is very easy to just bind to it from the activity, call on to it to get its
>>> current state, and supply a callback for when the state changes, just using
>>> normal Java coding.
>>>
>>> --
>>> 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
>>
>>
>>  --
>> 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
>>
>
>  --
> 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

-- 
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-develo

Re: [android-developers] android design considerations: AsynchTask vs Service (IntentService?)

[Tom Gibara]

AsyncTask is excellently documented:

http://developer.android.com/reference/android/os/AsyncTask.html

AsyncTask
has no interaction with the Activity lifecycle, except for that which you
introduce with your own code.

It's for precisely this reason that AsyncTask and Service are mostly
orthogonal: An AsyncTask is helpful way of delegating work onto a thread
other than the main thread; a Service exposes a component lifecycle so that
a UI-free operation can be managed by the system.

Tom.

On 2 October 2010 22:20, Prakash Iyer  wrote:

> I'm not sure I agree with your comment that it is the wrong question. In
> fact your explanation of how a majority of the cases a Service runs in the
> same process is precisely why most people will consider these as
> alternatives. I was trying to point out to the OP that if the OP ever wanted
> to create something that lived independent of the UI and/or was planned to
> be used by more than one activity independently developed/distributed, a
> service would be a better choice...
>
> IMHO the AsyncTask is notoriously poorly documented. It has some really
> strange interactions with the Activity lifecycle... As some one pointed out
> the IntentService is probably a better choice in many cases. Which again
> brings to question the orthogonality of AsyncTask & Service...
>
>
> On Sat, Oct 2, 2010 at 5:09 AM, Dianne Hackborn wrote:
>
>> On Fri, Oct 1, 2010 at 2:07 PM, Prakash Iyer  wrote:
>>
>>> Service, OTOH, is designed to work in the background without requiring
>>> user interaction. Problem is that for your Activity to display the results
>>> it must somehow interact with your service. Ideally you will want to spawn
>>> the service off in a separate process and use either Intents or AIDL to
>>> communicate back progress to the Activity.
>>>
>>
>> The vast majority of the time, there is no need to run the service in a
>> separate process and thus deal with all of the additional complexity of AIDL
>> and such.
>>
>> As another poster mentioned, IntentService is very useful.
>>
>> Also "AsyncTask vs. Service" is the wrong question.  These are almost
>> totally orthogonal to each other -- you very often may use an AsyncTask as
>> part of implementing a service for example.
>>
>> And if your service is running in the same process as your activity, it is
>> very easy to just bind to it from the activity, call on to it to get its
>> current state, and supply a callback for when the state changes, just using
>> normal Java coding.
>>
>> --
>> 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
>
>
>  --
> 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
>

-- 
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

Re: [android-developers] android design considerations: AsynchTask vs Service (IntentService?)

[Prakash Iyer]

I'm not sure I agree with your comment that it is the wrong question. In
fact your explanation of how a majority of the cases a Service runs in the
same process is precisely why most people will consider these as
alternatives. I was trying to point out to the OP that if the OP ever wanted
to create something that lived independent of the UI and/or was planned to
be used by more than one activity independently developed/distributed, a
service would be a better choice...

IMHO the AsyncTask is notoriously poorly documented. It has some really
strange interactions with the Activity lifecycle... As some one pointed out
the IntentService is probably a better choice in many cases. Which again
brings to question the orthogonality of AsyncTask & Service...

On Sat, Oct 2, 2010 at 5:09 AM, Dianne Hackborn  wrote:

> On Fri, Oct 1, 2010 at 2:07 PM, Prakash Iyer  wrote:
>
>> Service, OTOH, is designed to work in the background without requiring
>> user interaction. Problem is that for your Activity to display the results
>> it must somehow interact with your service. Ideally you will want to spawn
>> the service off in a separate process and use either Intents or AIDL to
>> communicate back progress to the Activity.
>>
>
> The vast majority of the time, there is no need to run the service in a
> separate process and thus deal with all of the additional complexity of AIDL
> and such.
>
> As another poster mentioned, IntentService is very useful.
>
> Also "AsyncTask vs. Service" is the wrong question.  These are almost
> totally orthogonal to each other -- you very often may use an AsyncTask as
> part of implementing a service for example.
>
> And if your service is running in the same process as your activity, it is
> very easy to just bind to it from the activity, call on to it to get its
> current state, and supply a callback for when the state changes, just using
> normal Java coding.
>
> --
> 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

-- 
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

Re: [android-developers] android design considerations: AsynchTask vs Service (IntentService?)

[Dianne Hackborn]

On Fri, Oct 1, 2010 at 2:07 PM, Prakash Iyer  wrote:

> Service, OTOH, is designed to work in the background without requiring user
> interaction. Problem is that for your Activity to display the results it
> must somehow interact with your service. Ideally you will want to spawn the
> service off in a separate process and use either Intents or AIDL to
> communicate back progress to the Activity.
>

The vast majority of the time, there is no need to run the service in a
separate process and thus deal with all of the additional complexity of AIDL
and such.

As another poster mentioned, IntentService is very useful.

Also "AsyncTask vs. Service" is the wrong question.  These are almost
totally orthogonal to each other -- you very often may use an AsyncTask as
part of implementing a service for example.

And if your service is running in the same process as your activity, it is
very easy to just bind to it from the activity, call on to it to get its
current state, and supply a callback for when the state changes, just using
normal Java coding.

-- 
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

Re: [android-developers] android design considerations: AsynchTask vs Service (IntentService?)

[Miguel Morales]

You will more than likely need a service.  It'll save you a lot of
work later on.
You would start your service when your app starts, then your
activities bind to is and communicate via something like AIDL.  So the
activity can tell the service to start a sync.  And when the service
is done, it can send off an intent, or an AIDL callback method.

On Fri, Oct 1, 2010 at 2:07 PM, Prakash Iyer  wrote:
> Not sure I am experienced but I did use both AsncTask and Service, so here
> is my opinion.
> AyncTask works great - until the user does something to visually alter your
> app, e.g. changes orientation or goes to the home screen. Reason is that the
> AsyncTask will most likely be referring to UI elements in the original
> Activity instance and you will suddenly not see anything happening. Google
> on the forum and you will see a discussion on a persistent dialog that tells
> you the problem and one solution. Also, once the Activity is out of view, I
> am guessing the OS can destroy it and there isn't much control given to
> AsyncTask.
> Service, OTOH, is designed to work in the background without requiring user
> interaction. Problem is that for your Activity to display the results it
> must somehow interact with your service. Ideally you will want to spawn the
> service off in a separate process and use either Intents or AIDL to
> communicate back progress to the Activity.
> So, if your task can be paused and restarted along with the main Activity,
> AsyncTask might work quite well. If not, Service might be the way to go. You
> said the initial sync can take 15-20 min, so be sure you understand how an
> AsyncTask interacts with Activity if it moved away from the foreground coz'
> unless these are your real friends or you are showing something really
> compelling, people will move on...
> On Wed, Sep 29, 2010 at 2:50 AM, Tia  wrote:
>>
>> I'm designing an android app which will need todo the following steps:
>>
>>   1. user pushes a button or otherwise indicates to "synch data".
>>   2. synch process will use REST web services to move data to and
>> from the server.
>>   3. the data will be stored locally in a sqlite database.
>>   4. the synch process should provide status updates/messages to the
>> UI
>>   5. the user should not be allowed to wander off to other parts of
>> the application and do more work during the synch process.
>>
>> The first time the synch process runs, it may take 10-20 minutes.
>> After the initial synch, less data will be transferred and stored and
>> I expect the process to take 1-2 minutes or less.
>>
>> I've been doing a lot of reading about android's AsychTask and various
>> examples of using a Service ... But I don't fully understand the
>> design considerations and trade-offs of choosing one design over the
>> other. I currently have my demo project stubbed out using an
>> AsychTask. After watching (most of) Developing Android REST client
>> applications:
>> http://code.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html#
>> I'm left confused the design patterns described here feel overly
>> complex, perhaps because I just "don't get it" yet.
>>
>> Would love to hear from some more experienced android developers out
>> there who have already wrestled with these questions.
>>
>> --
>> 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
>
> --
> 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



-- 
~ Jeremiah:9:23-24
Android 2D MMORPG: http://developingthedream.blogspot.com/,
http://diastrofunk.com,
http://www.youtube.com/user/revoltingx

-- 
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

Re: [android-developers] android design considerations: AsynchTask vs Service (IntentService?)

[Prakash Iyer]

Not sure I am experienced but I did use both AsncTask and Service, so here
is my opinion.

AyncTask works great - until the user does something to visually alter your
app, e.g. changes orientation or goes to the home screen. Reason is that the
AsyncTask will most likely be referring to UI elements in the original
Activity instance and you will suddenly not see anything happening. Google
on the forum and you will see a discussion on a persistent dialog that tells
you the problem and one solution. Also, once the Activity is out of view, I
am guessing the OS can destroy it and there isn't much control given to
AsyncTask.

Service, OTOH, is designed to work in the background without requiring user
interaction. Problem is that for your Activity to display the results it
must somehow interact with your service. Ideally you will want to spawn the
service off in a separate process and use either Intents or AIDL to
communicate back progress to the Activity.

So, if your task can be paused and restarted along with the main Activity,
AsyncTask might work quite well. If not, Service might be the way to go. You
said the initial sync can take 15-20 min, so be sure you understand how an
AsyncTask interacts with Activity if it moved away from the foreground coz'
unless these are your real friends or you are showing something really
compelling, people will move on...

On Wed, Sep 29, 2010 at 2:50 AM, Tia  wrote:

>
> I'm designing an android app which will need todo the following steps:
>
>   1. user pushes a button or otherwise indicates to "synch data".
>   2. synch process will use REST web services to move data to and
> from the server.
>   3. the data will be stored locally in a sqlite database.
>   4. the synch process should provide status updates/messages to the
> UI
>   5. the user should not be allowed to wander off to other parts of
> the application and do more work during the synch process.
>
> The first time the synch process runs, it may take 10-20 minutes.
> After the initial synch, less data will be transferred and stored and
> I expect the process to take 1-2 minutes or less.
>
> I've been doing a lot of reading about android's AsychTask and various
> examples of using a Service ... But I don't fully understand the
> design considerations and trade-offs of choosing one design over the
> other. I currently have my demo project stubbed out using an
> AsychTask. After watching (most of) Developing Android REST client
> applications:
> http://code.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html#
> I'm left confused the design patterns described here feel overly
> complex, perhaps because I just "don't get it" yet.
>
> Would love to hear from some more experienced android developers out
> there who have already wrestled with these questions.
>
> --
> 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

-- 
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] android design considerations: AsynchTask vs Service (IntentService?)

[Tia]

I'm designing an android app which will need todo the following steps:

   1. user pushes a button or otherwise indicates to "synch data".
   2. synch process will use REST web services to move data to and
from the server.
   3. the data will be stored locally in a sqlite database.
   4. the synch process should provide status updates/messages to the
UI
   5. the user should not be allowed to wander off to other parts of
the application and do more work during the synch process.

The first time the synch process runs, it may take 10-20 minutes.
After the initial synch, less data will be transferred and stored and
I expect the process to take 1-2 minutes or less.

I've been doing a lot of reading about android's AsychTask and various
examples of using a Service ... But I don't fully understand the
design considerations and trade-offs of choosing one design over the
other. I currently have my demo project stubbed out using an
AsychTask. After watching (most of) Developing Android REST client
applications: 
http://code.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html#
I'm left confused the design patterns described here feel overly
complex, perhaps because I just "don't get it" yet.

Would love to hear from some more experienced android developers out
there who have already wrestled with these questions.

-- 
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