hello, Roberto!

how can I help you today?

Mark, how are you doing ?

I am reading your book...

great stuff (btw)

thanks!

and i am working on an app similar to Expedia (booking tickets and stuff like that)

which basically consists on querying and sending data to APIs in a sequential steps...

so, the thing is I am thinking on the threading part

I think i could use AsynTasks, i am aware of the issues and also i think i can manage them

but i don't think they're the best way... i was also considering IntentServices

but i am curious because there are not much in your book about them

IMHO, there is a fair bit in the book on IntentService

so i just wanted to ask you about them...

at least as much as there is on AsyncTask

that being said, I am happy to try to answer any questions you have about IntentService

This stage is more from architecture point of view rather than specific issues

So, I am considering to use something like retrofit, picasso...

I just need to close the threading part...

it's quite open...

i don't know if it's ok to ask so wide questions on this chat sessions...

well, Retrofit and Picasso are designed to handle threading for you

well, you have not really asked a question yet :-)

Ok, let me put in a question way then :)

i've to do an app to consume APIs, i plan to use picasso and retrofit. The API calls are sequentials, ie until i don't finish a step i won't do another API call. How would you recommend to manage non-ui part, would you leave it to the libraries (using their callbacks), would you use them in synchronous-mode and use something like asynctasks, intenteservices ?

in the case of Retrofit, you certainly have the synchronous option (I don't recall seeing one in Picasso...)

so, from a transaction sort of mindset, I would go the synchronous route

as that, IMHO, will give you easier code to read than some chain of listeners, with one listener invoking the next step in the transaction

with respect to AsyncTask versus IntentService, here is my general rule of thumb:

1. if the work will take less than a second, and you do not mind if the work is discarded should the activity be destroyed, feel free to have an activity (or one of its fragments) use an AsyncTask

2. if the work will take 1+ seconds, or you want to ensure that it runs to completion, use an IntentService

3. if the work will take 15+ seconds, now you have to start thinking about my WakefulIntentService, so the device stays awake while all of this is going on

the 15 second value comes from the minimum automatic screen timeout value in Settings

as a result, given this set of rules, I usually reserve AsyncTask for light stuff needed by the UI layer

but "serious" work, such as updating a server, probably should use a service of some form

now, IntentService has its own limitations (e.g., only one thread per service), so you may need to replace it with your own service that calls stopSelf() when appropriate

Ok...

I am thinking on the 'only one thread per service' restriction... do have an example where that might be a problem ? at the moment i cannot figure out where that might be an issue

suppose your transaction consists of 5 Web service API calls

call these A, B, C, D, and E

the rule is that you have to do A first (e.g., create an invoice), and you have to do E last (e.g., mark the invoice as ready for processing)

B, C, and D are calls that have to happen in between A and E (e.g., add line items to the invoice)

but B, C, and D do not depend upon one another, and so could be performed in parallel, if your Web service supports it

with an IntentService, and only one thread, you have two key limitations:

1. you cannot readily do B, C, and D in parallel, so you would wind up serializing A through E, which would take more wall-clock time

2. you cannot do another independent transaction while processing an existing one; it will queue up instead

now, if neither of those are a particular problem for you, IntentService is easy to use

but, if either of those are a problem, you will need a more sophisticated threading model within your own subclass of Service instead of IntentService

I see. Even if I do an IntentService per API call, A, B, C, D and E. Would I have the same restriction ? which I guess it would be the same queue for all the intent services (if that's correct?)

each IntentService instance has its own thread, but services are natural singletons

so, if you have IntentServiceA and IntentServiceB and so on, they will run in parallel

however, in my scenario, you do need to do some serialization (e.g., B/C/D have to be after A, E has to be after B/C/D)

that could be by one service starting another one, but no matter how you approach it, complex business rules result in some amount of code complexity

"complex business rules result in some amount of code complexity" that's a very good one.

Ok... Fortunately I've some time to decide, so i'll keep researching a bit about it, doing some experiments and perhaps I come back with this topic in the near future.

Thank you very much for your service... i am very surprised about what you're doing, i consider your business awesome. Keep doing it!

I am happy to be useful

Bye, bye, have a good time.

have a pleasant day!

you too