Develop Reference

Best way to do a background timer

Im trying to make a simple game. The game is going great only I want to use a background timer. Like in citybuild games, a task takes x hours to complete and after that there should be a notification. What is the best way to do this? Do I need a background service, an alarmmanager, both? and is it smart to also keep the start timer of the task in an SQLLite db so if the timer stops he can still see it after it starts in the db?
Basicly what I'm asking is, what is best practive and do you guys have some pointers or better yet, examples/tutorials for me?

I recommend you to use the AlarmManager, it's native, you don't have to implement some background service, it doesn't consume battery, and it's easy to use.
Please refer to this tutorial.
Also, you can save the start time in SharedPreferences (or DB, as you prefer), and when the user re-starts the app, check if the job isn't already completed. This is an extra-step to make sure everything works as expected even if AlarmManager goes wrong

Is Application class data will persistent after wake up of application from long sleeping in Android?

i am using application class to save global data for all intents.So what happen if the application went to background and after 5 hours i launch the application from icon the data will available or not?

The system can kill your app at any moment so you have to save things in some persistent storage.

It's completely unpredictable. As per the documentation looks like android would try to keep proccess (and, so Your Application class) as long as resources allow. e.g. if some service with higher priority would need resources, Your process might be killed. However, there's no way You can predict it for sure.
I would suggest to utilize SharedPreferences or ContentProvider mechanism (depends on Your data) then Your last activity get stopped in order to be sure not to lose any essential data.

Persist objects after activity/app is exited

I need to be able to gain access to objects after my activity has been destroyed (or even after the app has been quit).
The object is an AAC decoder and plays in the background if the user hits home, or stays in the app. However, when the activity/app is exited the object is lost. This means that if the aac stream is playing there is no way to stop it (short of restarting the device) and subsequent visits to the app just layers the streams on top of the last one.
I thought about adding the object to a service, however I have no idea how this would work, or if its even a good idea. I also thought that the answer might lay in static variables, however I assume that once an application has been exited (or force quit/killed for memory/whatever) even these objects are lost.
The library I'm using for the aac decoder is http://code.google.com/p/aacdecoder-android (if that helps).
Currently I'm playing the stream in a service completely. This gets around the problem above, however I need to be able to update the UI when the app is running (and when the user goes to the app in the future). So this is a problem. I realise the way around this would be to use a broadcast intent, but I wonder if its more complicated than necessary.
Is there any way around this?
Thank you.

I thought about adding the object to a service, however I have no idea how this would work, or if its even a good idea.
Not only is it a good idea, but it is your only real option. Here is a sample project showing a (fake) audio client sending commands to a (fake) audio service that handles the playback and indicates to Android that the service is part of the user's foreground experience.
I also thought that the answer might lay in static variables, however I assume that once an application has been exited (or force quit/killed for memory/whatever) even these objects are lost.
Once your process is terminated, the object is gone. Of course, so is the audio playback.
A service is effectively a marker, to the OS, indicating that you have code that is still running, so Android is less likely to terminate your process to free up RAM to run other apps. Marking it as part of the foreground user experience further reduces, but does not eliminate, the odds that Android will terminate your process.
I realise the way around this would be to use a broadcast intent, but I wonder if its more complicated than necessary.
It doesn't get much simpler than a broadcast. It's not your only option -- you could use a Messenger or a PendingIntent or a handful of other techniques.
Is there any way around this?
Why would you want to get "around" the right answer?

Is an always-on Android service ever not an anti-pattern?

I understand why an always-on service is normally an anti-pattern in Android, but my app really seems to be begging for one:
On first load, the app has to go through potentially thousands of small entities from the database to construct the initial state. There's not much data brought into memory (most is lazy loaded later), but that first scan is unavoidable by the nature of the app. This scan can take at worst 6-7 seconds with slow hardware and a big dataset, average is probably around 3. The app is a "impulse use in short bursts" type of thing, so those repeated loads are really not desirable.
I think this begs for a background service to be perpetually alive and holding that state, thus avoiding that load time. It will always be ready to be killed, and not in the foreground, so should the system or user decide that they have it out for the service, no harm is done. But if the service is left in peace, the app will start instantly, and in my case that does a lot for the user experience.
Am I still wrong?

I think this begs for a background service to be perpetually alive and holding that state, thus avoiding that load time.
As the British say, bollocks.
On first load, the app has to go through potentially thousands of small entities from the database to construct the initial state.
Then fix that. Either simplify this work, or persist the initial state in a simpler form for later reuse (e.g., JSON).
If it is OK for you to use a cached result of this work that is held in RAM, it is OK for you to use a cached result of this work that is held in an easier-to-read-in persistent data structure.

An "always-on" service would essentially act like a daemon process and there are plenty of services on Android phones that never turn off.
In this case, though, it seems a better solution would be to simply have a splash screen and/or wait dialog that sits there until the data is loaded. It seems like a bad idea to me to take up resources when the app isn't running just so the app will load faster when the user finally opens it. If the average use of the app is much smaller than the load time, then it would probably be even better to speed up the scan in some way.

People use taskkillers to kill such kind of services. My view is, that when you make the user aware of why your service is running (say, this will load the app quicker), he will understand it and not kill it. You could also ofcourse add an option to use the service or not.

A background sensor data collector in Android

I am now programming a program that collects sensor data, e.g. acclerometer values for a whole day.
Current I just use an Activity and run the activity for a whole day (I turn off screen auto-black), and don't make any shortmessages or phone calls during the day.
I've heard I can make this kind of long running data collector in background using Service. But after I've checked the pedometer at http://code.google.com/p/pedometer/. I found that, when the screen blacks out, the pedometer does not work. (But An application like predometer should work in any case as long as the power is on.)
Although I don't care about the power problem of always sensing acclerometers, I do want to black out the screen to save the power in screen to record more acclerometer data points.
I am thinking about two ways:
1.Using an Service, however, as the pedometer application showed. When the screen blacks out, the service seems stoped working too! Maybe the code has bugs.
2.My application is still an Activity. But I change the scrren light into 0 or totally black to save power.
My question is that: for 1) does a Service have the abality to be always running even when the screen blacks out for a long time; For 2, how to change the screen light?
Thanks!

concerning 1 - what you need is a remote service. this is a service nearly similar to a 'local' service (that is used in the pedometer example) but can run even if no activity is bound to it, in the background. you can turn off the screen and even the activity can crash (in a bad case ;) ) but the service keeps running if you started it with startService(...) instead of bindService(...).
try getting through this and see if that helps.
concerning 2 - you should really use (1) ;)

You do not need a remote service - this can be done with a local Service.
Use the command pattern instead of the binding pattern for the service i.e. use startService() / stopService() rather than bind() / unbind().
In your service onStartCommand() method, return Service.START_REDELIVER_INTENT or something similar, so that the service lives longer than the Activity.
Now the trick: to keep the service processing properly when the phone goes to sleep, you need to work with a PowerManager.WakeLock. These are quite difficult to get right, and I don't think a full explanation is needed in this answer.
Here is some more info:
How to get an Android WakeLock to work?
Also try Lars Vogel's blog: Using Android Wakelock – Staying up all night long
Apologies for the summary answer, but your question is quite broad in terms that it touches on some advanced topics.

Background service can be implemented with IntentService for the most of the scenarios.
Make sure that the background service works in latest and earlier Android version like 2.3 or 2.2.
Designing background operations is different starting from Android 4.0.
Best Practices for Background Jobs
Performing Network Operations