You should keep your resources, like images, strings, values, etc. separate from your code.
Some of the folders in the res directory
Our tutorial app uses a Service to play a sound clip.
We start a Service when the app starts. The Service will run as long as the app is alive.
We need to bind to the Service to start and stop playing a sound clip. We can leave the clip playing in the Service while it is running. It will continue to play even if the activity is paused or destroyed.
So what happens when we bind to a Service?
It’s unlikely that the system will kill a foreground Service.
Typically we’d use foreground Services for work that the user is aware of, like playing music.
When we use a foreground Service, we have to send a notification to:
Our tutorial app shows you how to use Services to:
There are two parts to the tutorial: Part 1 shows you how to use a simple Service and Part 2 shows you how to use a foreground Service.
Services are app components that you can use to do work in the background. They don’t have a User Interface.
They are started and stopped by other components (like Activities, Broadcast Receivers and other Services).
You can also share Services with other apps.
Have you read the article on Processes and Threads yet?
Always remember the two most important rules when working with threads:
Speed up your apps response times. Move all processing and I/O operations off the main thread. Do the work in a child thread. Our tutorial will show you how.
All Android apps run in their own process and by default, in a single thread.
Android follows a multitasking design. This allows a number of applications to run at the same time. The problem is that all these apps need memory which is in short supply.
We only have one activity in our app. It hosts the fragments.
If you haven't already done so, have a look at :
We’re using the support library so make sure that you import the correct class: