Develop Reference

IntentService vs AsyncTask for Login Activity?

I want to make a login activity in my app that uses a web service. What is the best practice to make the request?
Should I use an IntentService or should I use the AsynkTask class and override its methods?

Using AsyncTask will help to make your code much more simpler in your case.
In this case you will use just one class into another. In this case you transfer the data in the most easiest way.
In the second case - intentservice - you have to write/read/collect/extract your data, time lags and so on.
EDIT
1. You can cancel request before rotation
2. You can check if your request is in progress and do not launch it again.
3. You can disable rotation in the login screen.

If you use an IntentService you will have to implement a Binder to communicate with the UI whereas an AsyncTask provides callback for updating the UI.
However, an AsyncTask has a drawback that it is started every time the calling activity is started. So, to handle this issue you can use an AsyncTaskLoader which provides an AsyncTask for your background work and handles its state to avoid starting it again through configuration changes.
Android developer tutorial has a pretty good example of how to use an AsyncTaskLoader. You can find it here.

You should use Aysnc task because IntentService is run in background so you have to update UI after network call response.
So async task is better for your case.
IntentService we use for long background running task which will terminate it self after work done.

AsyncTask just runs the action async in the class.
IntentService runs a new service and does the action you want.
It would be much easier to use AsyncTask, because as you can use it inside your activity, you can run an intent from it to the target activity(registrer, the user area, etc).
If you use a IntentService, you would have to create binders, collect data, monitor it and more. IntentService, for this purpose, would be much more work than it is worth.

How to make service running even after manually swiping off of recent apps?

I am trying to build a count down timer that runs in the background in a separate thread. I am using a foreground service and passing a handler to the background thread from this service. So essentially, the activity will communicate with the service and the service will communicate with the thread.
Essentially, when the user swipes the app off from the recent apps, i need the timer to keep running.
What is the best design that does this?

You will need to use a started Service and startForeground().
Check this question for details.
Also if you create service in a separate process it will solve your issue.
Here is a great tutorial
A started service can use the startForeground(int, Notification) API
to put the service in a foreground state, where the system considers
it to be something the user is actively aware of and thus not a
candidate for killing when low on memory.

Like Ivan previously said, it is a combination of startService(), binding calls and startForeground() call to keep the service running in the background. Don't really require a separate process to do this.

Service inside a task? Or task inside a service

I´m developing an android app with more people in my team, the app has services to make calls to remote apis and you have to make those calls with in a separate thread with Asynctask.
Now i have to make a new service, and looking through the previously ones done by my mates, i see that one of them instanced the service and inside the service created the AsyncTask, while the other mate instanced the service inside the AsyncTask.
So I was wondering, what is the best practice for this? Or are both ways correct and there is a specific reason for each way?

The Service inside the AsyncTask seems really weird!
It is most common to have AsyncTasks in the Service or Thread-Handler pattern so as to make sure you have the "background" thread for the communication calls.
But if the task of your service is just to perform a call to your remote API and then return results to the caller, I would strongly suggest to take a look at IntentService. The difference is that the IntentService does not need any AsyncTask in order to achieve this "background" (other thread) thing.
Check google doc: http://developer.android.com/reference/android/app/IntentService.html

assuming you are saying Service which is the one in four Android components. a Service could only be instanced by Android system. you can not instance it in AsyncTask. if you instance service by java new keyword, the instance just perform like a normal Java class, out of the android system's control .
you can start a AsyncTask in service, it is a common design.

Is it better to use AsyncTask (Or Timer) within single process, or using Service in separate process?

I just read Android Architecture Tutorial: Developing an App with a Background Service (using IPC). It is basically
Have a service run in separate process.
A repeated timer event will occur in the service.
Within the timer event handler, it will perform networking to retrieve tweet, and inform all the listener attached to it. Listeners are attached to it through IPC.
I can see there are 2 major characteristics with this approach.
Tweet retrieving action run within separate process.
It always run, even the main activity has quit.
However, if "It always run" is not my requirement. I want everything to stop when I quit my main Activity.
Will it be better, if I use AsyncTask (Or Timer) within my main Activity, to perform tweet retrieving action? Everything will be run within single process. No more using Service.
Using AsyncTask (Or Timer), seems simpler. We no longer need to deal with IPC.
Or, using Service approach might be better? Am I missing some goodies provided by Service?

Using service is a better approach as it will allow you to perform the polling independent from the application flow.
As it is a task where no user interaction is required and it has to be done in the background without disturbing the main UI of application and whatever the user is doing, a service is an ideal candidate for its implementation.
It is possible to bind the service with the application in such a way that when the main application terminates, it will also turn off the service.

I would take the view that a TimerTask can be set to execute and repeat at a given interval, Timers run on a separate thread so all this work would occur in the background without disturbing the UI. It would be easy for you to trigger an update within your app when the TimerTask completes and update the UI when you want.
When you exit the app it's a simple case of calling cancel() on your Timer and the purging all the tasks with purge().
Nice and easy and you don't need to implement IPC, which can be very fiddly to get right.
EDIT
Using AsyncTask you can do pretty much exactly the same thing but you'll have to manually schedule the next run. I have used both solutions in the past and found them to work equally well so it's all down to your preference.

At first you have to know, that a service isn't a Thread. If a activity binds a Service and runs as a Deamon, but a ASynchTask is another thread.
ASynchTask's are designed for doing some work which should not running on UI-Thread (for example processing some larger calculations)
Services are designed to run permanantly on Background.
If you want to permanantly check for new tweets, even if your activity is stopped or paused, you should use a Service, which checks into an own thread for new data.
TimerTask are good old java style implementations which run on their own thread.
You can used them for processing some data, but you'll have some problems to manipulation UI. If you want to be it on propper "AndroidWay", use a Handler instead of TimerTask.

First of all, I know the tutorial you are following...I've followed that tutorial myself while trying to learn IPC. One thing you need to know is, The Android docs explicitly say,
Note: Using AIDL is necessary only if you allow clients from different applications to access your service for IPC and want to handle multithreading in your service.
If at all possible, you should just bind to the service.
Also, you must consider, do you really need a service? Consider that the Android Twitter app doesn't even refresh tweets for you, its on an as needed basis. Polling can be battery intensive, so you must consider if this is really necessary.
Also, will you be using these tweets from multiple activities? If so it would be nice to not duplicate the code in multiple places. So maybe you do want a service in this case.
Other than that, I would recommend that you start simple (Async task with a timer to update it), and move to a service if you think you need it.

Android - Computations in background

First question:
I know that in the Activities only view content should be implemented but is it usual to start an own service for each longer computation process?
Second question:
And the communication with the service is really extensive in code. If you want to invoke a method on the service you have to realize the hole IPC-mechanism?? Or is it also possible to invoke methods on local services without using the AIDL-files?

Depending on task you want to perform consider using AsyncTask or IntentService. Using regular Service should rather not suit your needs best here.
If you use regular Service you can easily pass your data or arguments or whatever in Intent. You do not need any IPC for this.

First question: you can start an AsynTask for longer computation process, service are generally used for action when application on background.
Second question: you can call any Method on your service, the use of idle make your services available for multiple applications, witch is not the case of a simple services, also, sample services runs on the same application process as your activities, witch is not the case of idle service.