We Keep Coding

Keep thread running after onDestroy

I am currently building an android application that will be used as an anti theft sort of application. Basically, once the alarm has bee launched, the application will monitor the accelerometer to detect movement. If it does, the user will have 15 seconds to enter a set password to deactivate the alarm, otherwise : BIIIIIP!
My problem is the following: how do I manage to keep the monitoring and counter process running after the activity is destroyed (if for example the user presses back) in a way that I can access it again from a notification.
I was thinking of using a thread to run the monitoring and counting process and when the notification was pressed, for example, the class could, in it's onCreate method, be aware whether an already existing thread is running and if so, get the handle to it?
Thanks.

What you are looking for is a Service. They are meant for this exact purpose; to run on the background (this does not mean a background Thread ) even if there are no Activities running.

You should consider using services for this purpose. Here is one of the example: http://blog.kozaxinan.com/2012/08/using-accelerometer-when-screen-off_16.html

How to detect and manage incoming call (Android)?

I want to create an application that can detect incoming calls and start my custom activity after a certain number of beeps (rings), I mean after 2 or 3 or 5 beeps (rings) my activity is triggered. How can I do it?
Thanks

I don't think you can count the number of rings the phone made since the start of the incoming call. There can't be a definitive measure of a single ring because the user can easily change the ringtone to a non-repetitive tune, for example, a song.
What you can do, however, is count the amount of time that passed since the arrival of the call. Set up a BroadcastReceiver for PHONE_STATE (you will need the corresponding permission in the manifest to receive the event). Once you receive the EXTRA_STATE_RINGING that came with the PHONE_STATE, set an alarm via the AlarmManager that will fire a Service that checks if EXTRA_STATE_OFFHOOK (broadcast when the call is picked up) has been broadcast after your waiting time. If not, then you can start your answering machine.
I have written a quick tutorial in my website on how to catch the call's arrival (when the phone rings), when the call is picked up, and when it ends.

My article about detecting incoming and outgoing calls, with the step-by-step instructions:
Detecting incoming and outgoing phone calls on Android
When you detect incoming call, you can start a timer, with interval equal to beepInterval * beepCount. And launch activity on this timer.

Android dialog management

I'm developing an android app (if you want more info http://www.txty.mobi) and I am having some problems with dialogs management. I'm quite new to Android so the way I'm doing things completely wrong. If the case please just say so pointing me to the right documentation to follow.
Background:
The main blocks of the app so far are one activity and one Service (which derives from IntentService).
The actvity needs to interact with the service in just two occasions: start/stop the service. The intent service will self regulate its lifetime using the AlarmManager.
A typical flow when clicking on start/stop:
1) the activity on its onResume registers a broadcast receiver to events sent by the service (unregisters it in the onPause)
2) the activity starts a indeterminate progress dialog
3) the activty sends a single shot alarm event (either start or stop) which will be send **straight away to the service
4) the service does what it needs to do to start
5) the service emits a broadcast event basically saying "done"
6) the activity receive this event and gets rid of the dialog.
The Problem:
The activity can lose its foreground status let's say if the user switches focus or a call is received, so the onPause method is called (at this point the activity could even be killed by the system to claim memory). obviously if this is the case the activity will never receive its broadcast event because the receiver has been unregistered. This will leave the app in the awkward situation, when the activity is brought again to the front, of having a dialog that you can't kill nor will never get rid of.
The (possible??) solution:
The way I am handling this now (apart for keeping the broadcast receiver in place) is by creating a utility class that uses preferences to keep track of which operations are being executed and their status:
Activity
- in the onResume using my utility class gets the list of operations the activity is waiting for
- check their status
- if they are completed perform some actions accordingly (in my case get rid of dialog!)
- delete the operation from the preferences.
- just before asking for a operation to the service it saves it to the preference using my utility class.
Service
perform operation and save state of the operation to the preference using my utility class.
emit broadcast.
Disasters happen!
Now this saves me in a normal situation, but if a disaster happens (i.e. with the task killer app you kill everything) the service might be killed before it can save the status of the operation I am stuck as before (the activity will think the operation is still going on so it won't touch the dialog). So as for now I add a Dismiss button to very dialog just in case :)
Now all of this looks too complicated for what I think should be a fairly common thing to do. That's why, as said at the beginning of the post, I might (very likely!) be completely wrong.
Any ideas? Apologies if this question has been asked already, I looked around but didn't find anything. Please point me to any resource online explaining this.
Thanks and sorry for the lenghty post :P
Luca

Have you tried using a StickyBroadcast? This caches the latest broadcast, so it can be received onResume. Please see this post.

Send data from Service to Widget on Android

I am writing a widget on Android 1.6 that shows the minutes that a person has used on the current month.
The way I have it setup is by having a service that listens to the state of the phone and when the phone is picked up, it starts the timer and when the person hangs up, ends a timer. I would like to send this variable(long duration) over to my appWidgetProvider so I could update the edit text on it.

I'm no expert, but the AppWidgetProvider is the one that starts the service, right? Why not simply give a reference to the AppWidgetProvider upon creation of the service?

Android app components - a word of advice needed

I am a complete newbie to Android development;
Basically, I am about to write an application, that will let the user to take photo, which (with a bunch of extra data) will be submitted to the remote webservice.
So I'm guessing I will need:
A Photo-taking application (Activity) that will gather all the extra data and put in the SQLite DB.
A background service looking up the DB in time intervals and sending the data over the Internet, optionally making web requests with current GPS location (I'm trying to keep in mind, that sometimes network would not be accessible).
A receiver object that will run the service at boot, and optionally check if the service needs to be restarted.
My concerns are:
Do I really need to monitor the service and care about anything bad that could kill it.
Will the battery last for at least 12 hours with a non-stop running service, making some networking/GPS actions in, let's say, 30-minute intervals. (G1/Dream)
What else should I be careful about?
Any ideas/suggestions will be appreciated.

a word of advice needed
Rutabaga.
Oh, wait. You're probably looking for something related to Android. OK, carry on.
A receiver object that will run the
service at boot, and optionally check
if the service needs to be restarted.
Yuck. Use AlarmManager and have your service behave more like a cron job/Windows scheduled task.
Do I really need to monitor the
service and care about anything bad
that could kill it.
Not if you use AlarmManager and have your service behave more like a cron job.
Will the battery last for at least 12
hours with a non-stop running service,
making some networking/GPS actions in,
let's say, 30-minute intervals.
(G1/Dream)
If you use AlarmManager and have your service behave more like a cron job, a 30-minute interval should be OK. Just make sure you shut down the GPS radio when you are done with it. Note that using the GPS radio from a cron job sort of task is a bit tricky, since it takes a while to get its first fix. You will also want to take a look at using PowerManager.WakeLock to keep the device awake until your work is completed.
What else should I be careful about?
Mynd you, moose bites kan be pretti nasti.
Beyond that and what I wrote above, you should be in OK shape. Note that what you are diving into is not exactly "newbie" material.