After reading around for hours, I am little bit unclear on how an Activity and a Foreground service can co-exists in an android app.
Taking example of a Music Player app -
I create an Activity for displaying the UI and controls for the music player, and the music player gets started into a Foreground service. Based on the articles I have read.
And based on this -
A service runs in the main thread of its hosting process—the service does not create its own thread and does not run in a separate process (unless you specify otherwise). This means that, if your service is going to do any CPU intensive work or blocking operations (such as MP3 playback or networking), you should create a new thread within the service to do that work.
So, now at this time, if I have to perform any actions on UI in my Activity, why will I not see an ANR or any other kind of sluggishness, since the music and user actions are both happening on the UI thread ?
Related
I was asked this question in an interview. I am not sure if this the right forum to ask this question because it does not involve any code, but an understanding of android concept.
The question is 'Why do we need a service when everything can be done by a background thread in Android?'
Service runs in the main thread, why do we need something that runs in the main thread but in the background?
Examples like music play can be done in the background thread also so why do we need a service.
Please let me know if this should be asked in another forum.
Service:
Service is like Activity. but it doesn't require UI to work with. whereas when the thread created from the activity , thread will run until the activity lives. so, if you play the music in thread it will run. but it will crash when the activity ends, whereas when you implemented the music playing from service it will run entire the life cycle of the service.
See my answer boundservice to communicate between service and activity. when your music player runs you have to maintain the notification on notification panel.
UPDATE
When you are playing the music with background thread, the music will play even the app closed your background thread will become orphanage thread. You cannot control the state of the music player. Whereas when you are working with service ,music will play and it won't become orphanage service when the app exits. When you recreat the app you can communicate with music player whereas background thread cannot.
I was going through Bound Service in Android Developer website. I thought I understood the service enough but I just found another way of connecting service through Using a Messenger class especially for local service. There I got confused. Maybe I got the concept wrong.
Here is my understanding of Android Service. You create a service when
You want to do separate jobs in the background.
You want to make it a separate process.
You want to make it run in a lifecycle that's independent of the component that started it.
Confusion is the first item in the list, the definition of the background. Isn't the background a thread or process? I never thought that it can run on the main thread.
Here is the caution of service in the dev pages about.
Caution: A service runs in the main thread of its hosting process—the service does not create its own thread and does not run in a separate process (unless you specify otherwise). This means that, if your service is going to do any CPU intensive work or blocking operations (such as MP3 playback or networking), you should create a new thread within the service to do that work. By using a separate thread, you will reduce the risk of Application Not Responding (ANR) errors and the application's main thread can remain dedicated to user interaction with your activities.
Questions
Why does one choose to use service if the service function will anyway run on the main thread?
Do we have to write a service only to block ANR even if the time-consuming job is done in the main thread? Assume the service is only for my application.
Are there any practical cases or reasons to use a service as private and running in the same thread?
Application main thread is not always the UI thread. For example, when Activity is stopped, the onStop() is invoked, hence the UI thread is taken away from that Activity and moved to another Activity within the same or a different application. However it doesn't mean the application is no longer active, it can continue working in the background until it is closed either by OS or by user. Then who keeps it running in the background? It is the main thread and not the UI thread.
What are services
In Android, a Service is an application component that can perform
long-running operations in the background on the UI thread. By
background, it means that it doesn’t have a user interface. A Service
runs on the main thread of the calling Component’s process by default
(and hence can degrade responsiveness and cause ANRs), hence you
should create a new Thread to perform long running operations. A
Service can also be made to run in a completely different process.
Unlike Activity components, Services do not have any graphical
interfaces. Also Broadcast Receivers are for receiving broadcast
messages (broadcast, multicast, unicast) and perform short tasks
whereas Services are meant to do lengthy processing like streaming
music, network transactions, file I/O, interact with databases, etc.
When a Service is started by an application component like an Activity
it runs in the background and keeps running even if the user switches
to another application or the starting component is itself destroyed
Why use service
Services are given higher priority than other Background processes and
hence it’s less likely that Android will terminate it. Although it can
be configured to restart once there is ample resources available
again. You should go through the different processes and their
priority/important level in the documentation on processes and
threads. Assigning them the same priority as foreground activities is
definitely possible in which case it’ll need to have a visible
notification active (generally used for Services playing music).
Use IntentService if you don't want to fiddle with managing threads on your own. Otherwise, use AsyncTasks.
Please read this excellent article to understand more in detail and also read this answer.
Service basically runs in UI thread or main thread.But,if we are going to perform long running operations in service,we need to create a background thread and perform that task.
But why we have to use service?
Now let's think of Music Application.We need songs to be played continuously even if we leave music app.If we use activities,we can't achieve above requirement.So,service helps in these kind of scenarios.Even if the app is not in foreground, service keeps on running and we are able to listen to songs.This is why we use service even though it runs on main thread.
In short, Services runs on the background of the UI thread.
You can perform tasks like client-server authentication or write to a database where the tasks are done in the background with no graphical interface.
But if you're doing a really long processing tasks that could freeze the interface, you use a service on a separate thread.
eg of a Service on a separate thread is IntentService
I've built a music player which is running on a Service.
I'm preforming various actions as play, pause, next song, previous song etc through a binding to the service from my activity.
It works totally fine.
So to my question:
Is it ideal to put the service on a new thread? I know Service run by default on Main/UI thread.
If not, how do I know when to actually put something on a new thread? Can I put the whole Service instance on new thread or just a part of the code in the Service?
I guess this is called a long running service, shouldnt that be on a own thread to not block the UI?
When debugging I can see this in Logcat: I/Choreographer(691): Skipped 60 frames! The application may be doing too much work on its main thread...
That got me wondering too! :o
As my title says, I'm very confused about this!
You are right, Services are not threads (they do not create a different thread).
When started form an activity they would block the main/UI thread fi running long operations.
you can use IntentService - which start their own thread to perform background long running operations - but that would probably suits a download file task or long running calculation better than playing music.
note that IntentService creates and destroys the thread by itself (when the work is done).
Another option would be to create you own thread manually.
That said, I would consider this article:
http://developer.android.com/guide/topics/media/mediaplayer.html
It talks about a service in the foreground using startForeground() which adds a notification to the status bar, letting the user be aware of the fact that the service is running - as well as promoting the service so it won't get destroyed in case of low memory conditions (it could be - but it will probably be the last one to be closed).
the example is about running media player while taking the main thread blocking into consideration as well as handling system events to pause and play music as expected (using BroadcastReceiver )
Also note this:
http://developer.android.com/guide/components/services.html
Should you use a service or a thread?
A service is simply a component that can run in the background even
when the user is not interacting with your application. Thus, you
should create a service only if that is what you need.
If you need to perform work outside your main thread, but only while
the user is interacting with your application, then you should
probably instead create a new thread and not a service. For example,
if you want to play some music, but only while your activity is
running, you might create a thread in onCreate(), start running it in
onStart(), then stop it in onStop(). Also consider using AsyncTask or
HandlerThread, instead of the traditional Thread class. See the
Processes and Threading document for more information about threads.
Remember that if you do use a service, it still runs in your
application's main thread by default, so you should still create a new
thread within the service if it performs intensive or blocking
operations.
I know that a process is an executing instance of an a program running in the foreground or background and that background processes run asynchronously(runs outside the main thread).
Would background music in your application be an example of a background process?(doesn't freeze up your UI in the main thread and it runs in its own thread)
Does process imply then that another program is running the music in the background?
I don't think that you need another process for playing music - you just need another thread. I don't think that you want to play music while your app is not in the foreground. For example if your app is a game which only produces sounds when it is active.
Obviously this is not true if your app is a media player which still plays music while in the background letting user interact with it using notifications which let the user play/pause, skip a song or stop playback.
Please see a question like this one: How to put media controller button on notification bar?
Your android application consist of process, services, threads, message queues. It application developer choice when to use what. As good developer, you should always try to make you application user experience smooth without and any hang. Always perform heavy/time consuming activity with service or async threads, and avoid such activity on main thread as it cause UI hangs.
I'm building an app that streams music from a web server. The app has foreground service that uses a MediaPlayer for playback.
My code is based on this example: http://developer.android.com/guide/topics/media/mediaplayer.html
In the example, nothing is threaded except the prepareAsync() call. What confuses me is that when I read about the Service class I find this information:
"Caution: A service runs in the main thread of its hosting process—the service does not create its own thread and does not run in a separate process (unless you specify otherwise). This means that, if your service is going to do any CPU intensive work or blocking operations (such as MP3 playback or networking), you should create a new thread within the service to do that work. By using a separate thread, you will reduce the risk of Application Not Responding (ANR) errors and the application's main thread can remain dedicated to user interaction with your activities."
The reason I'm asking is that the app some times (usually when loosing connection) freezes the UI when streaming audio. I totally understand that the UI freezes if the service is making CPU intense work, since the activity and the service runs on the same thread. But, should I expect the MediaPlayer to be this intense? That is, should it run on a separate thread?
Unfortunately, calling prepareAsync() is simply not good enough to avoid ANR prompts and your application hanging for a few seconds, especially if you're playing a file from the network. Your best bet is to put your MediaPlayer instance in its own thread, or at the very least execute intensive calls in a Handler (like mediaplayer.start()). I've been using MediaPlayer for over a year and I can tell you it definitely hangs after various calls, depending on the circumstances.
Could the streaming music be causing the main thread to stop until the music has finished streaming? This could be why it is slowing it right down.
I'm no expert and am currently learning myself, but it's worth thinking about.
No if you are doing any network transfer you should keep that in a thread, mediaplayer is not that resource intensive. Keep it on your activity.