I initialize a MediaPlayer object in my main activity to play music. I would like my app to keep playing music when the user closes the app. I guess when the user closes the app, the MediaPlayer object goes out of scope. How can I keep keep the music playing after the app is closed?
How extend life cycle of an activity object
You can't.
If you want to run code when your app is in the background, you have to use a Service
You're looking at this wrong. Extending the life cycle means opening the door to leaks. There's also a considerable amount of things to keep track of.
The recommended way is via a Foreground Service. Your activity ideally binds to your service and controls the music playback via the provided Binder interface.
You can also allow the service to be controlled directly through your service's Ongoing Notification.
An example of the the above is Google Play Music.
Good luck.
Related
I want to achieve following goals:
Record Audio
Send Audio to Server
Play Audio
I know that First 2 tasks are possible by Using Service as I've done that in one of the previous apps but when it comes to playing an audio file, it needs to be triggered from an Activity.
Because accessing Activity from Service can be achieved by using BroadcastReceiver but what about accessing method of a Service from an Activity?
So, now comes the question: Whether to go for Service itself for Playing the audio also(triggered from activity) OR to use IntentService.
Documentation says,
No easy or direct way to interact with user interface directly from IntentService.
and
Any tasks started using IntentService cannot be interrupted
I may want to stop recording ant time and play it any time.
Which would suit t he requirement best --> Service OR IntentService ??
Any suggestions will be highly appreciated.
I would use a Service rather than an IntentService for what you need.
In particular, use a bound Service which allows two-way communication between the Activity which binds to it and from the Service to the Activity.
The IntentService class is designed for one-shot operations using its own worker thread, once the work on the thread is complete, the thread terminates and the IntentService calls stopSelf() to terminate itself. This means any user interaction between the user (via an Activity) and an IntentService is problematic.
A bound Service on the other hand will exist until it is either explicitly stopped or untill the last bound component unbinds. This allows for longer term interaction.
For playback, the fact a Service runs on the UI thread isn't an issue if you use something like MediaPlayerwhich handles its own thread for playback purposes.
Further to this, if you use a bound Service, MediaPlayer and MediaController, you can control play, stop, pause, seek etc from the Activity.
EDIT: For further information see... Bound Services
I have an app which starts a service (using startService). This service performs something similar to playing music. It can be seen as an indefinite work which has to be stopped manually through my activity.
In my activity, I would like to use a "switch" to show the state of the service (running/not running). This is somewhat like a play/pause button on a music player.
When my activity is created, how would I create the UI (switch) to be consistent with the service state (running/not running)?
I don't this using saveInstanceState/restore... will work. My app could be killed completely and the service will service and I will not receive the instance state once started again.
I don't this using SharedPreferences/DB will work. My process could have been killed and at next start, the app would think that the service is running.
The only stable solution I've been able to come up with is to ask the service (maybe through binding) if it is doing work or not.
Would this work? How would you do this?
Binding to the service would work (we have this exact scenario with a background audio player and resolved it that way).
Be mindful that binding is asynchronous, though.
I currently have an activity that plays music. When the activity is destroyed (i.e. user rotates the screen) I have the application store the music player's state and then play the music from the exact spot in the song once the activity is re-created.
My only issue is that there is a noticeable pause in the music when the activity is re-created. Any ideas on how to increase the activity's performance in regards to re-creating the app more efficiently. I know I can stop the activity to not re-create objects by using the configChanges tag in the android manifest but I would like to avoid that.
Is running the music in a separate service my only option?
Since the activity is destroyed it will pause no matter what you do. You should use a Service for this purpose. A service runs on a separate thread and is not effected by your activity. There's loads of tutorials and stackoverflow questions for services
I read Anndroid document - http://developer.android.com/guide/topics/media/mediaplayer.html
which said ".. you want it to continue playing while the user is interacting with other applications—then you must start a Service and control the MediaPlayer instance from there. "
But I found if I start a local a music file from an activity, then leave that activity, ( for example, press HOME key and interact with another app ), the music continues playing.
So, I don't understand " the "must start a Service" in document. Did I miss something?
This was not a big obstacle for my app at this moment. I am just wondering what's the potential problems could be if I do not use Service.( Services have longer lifespan, so the mediaplayer could be killed earlier, any others ? )
Our development is based on Android 2.2.
Thanks for any help in advance.
Big reason, if you are not using a service, users cannot listen to music outside of your app when the the activity gets paused or terminated. Technically you can make a music app but if your users cant listen to music when another app is in the foreground or the phone is in a different state(locked) it wont make for a very good app. You should take a look at the activity lifecycle for a deeper understanding of the process. Note that this behavior is by design for saving power, memory and cpu cycles.
It helps also not to think of services in the more traditional desktop dev usage. You want this thing to live even when your activity is not up and about.
For more about activity life cycles Managing the Activity Lifecycle
For the How
http://www.androidcompetencycenter.com/2009/01/basics-of-android-part-iii-android-services/
For the why
Why is it important to use Services for background tasks?
Playing the music in the Activity might be fine for now, but when Android is low on resources it might try to kill your Activity. When you add a service to an app, Android will try to keep that process alive as long as possible if it falls under certain criteria (such as playing music). Read over the Process Lifecycle section on Services:
http://developer.android.com/reference/android/app/Service.html#ProcessLifecycle
The activity can get killed by Android or by the user and then the music would stop playing.
I wanted to know how to pass a MediaPlayer object between activities so that I can maintain a constant sound play through out the application.
You don't "pass a MediaPlayer object between activities".
You need to access MediaPlayer from a custom Service to play sound in the background, and have your activities interact with this service.
For interaction my personal preference is binding using AIDL. Whenever I tried to use simple intents and onStartCommand() it revealed insufficient for activity/service interaction (I work with audio too). But it could work for you.
With AIDL and binding, you could expose custom functions such as play(uri), pause(), rewind(), etc.... The MediaPlayer instance would be created in play(uri) if it isn't already instantiated, and released in your service's onDestroy().
You can even register a listener with a RemoteCallbackList to get notified about position changes or some other events. See the examples on the AIDL documentation. What's nice about this is that your service can detect when a listener unregisters. This way you can have a small timeout in the service before you call stopSelf(), if another listener (activity) doesn't register quickly. That's useful because you don't necessarily know if an activity pauses because the user pressed the home button, or because he's cycling from one activity to the other.
Yeah, it needs a little work ;)
Note: you still need to call startService() before binding, otherwise the service will stop whenever an activity unbinds.
Check below link
http://developer.android.com/guide/appendix/faq/framework.html#3