We Keep Coding

onActivityResult() no longer calls after I speak into the Android mic

I developed an app a little over 2 years ago, where I call the function...
startActivityForResult(intent);
to get microphone input. The program doesn't read past that line of code until I say something into the mic. If I say nothing, then I have the option to tap the mic button and say something. Then, the function onActivityResult() gets called after I finally say something into the mic.
Eventually, my phone updated its operating system, and I noticed that onActivityResult() no longer gets called after I say something into the microphone. Not only that. but since I also have startActivityForResult(intent) used inside a threaded loop, that function repeatedly gets called WHILE it is waiting for me to say something into the mic, not allowing me enough time for me to say anything into the mic (whereas the old operating system waited for me to say something into the mic before continuing onto the function onActivityForResult() to get the results). How would I fix this problem?
Thank you.

I believe I was able to resolve the reason why my app was behaving differently (after my Android operating system updated itself)... with the OLD operating system, after startActivityForResult() gets called (with a 'microphone' intent to get microphone input), the microphone widget would open up and the 'program flow' of my app would 'pause' UNTIL microphone input is retrieved from the widget. Then, the program flow of my app would continue after onActivityResult() gets called, whereas the NEW operating system allows the 'program flow' of my app to continue past startActivityForResult() WHILE the microphone widget is opened, thus causing my timer to call startActivityForResult() repeatedly, instead of waiting until the widget (which is a separate program) get input, and then close. If there is a way to code the program flow of my app to 'pause itself' WHILE the microphone widget is open (like the OLD way), please let me know. Thank you.

I solved the problem...
When my Android updated its operating system (thus causing the microphone widget to NO LONGER 'pause' my app's program flow until it got microphone input, like it USED TO with the OLD operating system), I had to add an extra private boolean member variable to my MainActivity class (called 'isGetting'). Before the function startActivityForResult() gets called, isGetting gets set to true, and IF isGetting is true, the timer that calls startActivityForResult() skips past that line of code until isGetting is false. Then, when the microphone widget gets input and closes (without the timer calling startActivityForResult() repeatedly, or, as long as 'isGetting' is false), onActivityResult() gets called. Inside onActivityResult(), I added...
isGetting = false;
so that startActivityForResult() can get called once again in my timer after onActivityResult() executes and performs the 'instructions' on what to do WITH the results, and that fixed the problem. :)

Android service and asynctask communication

I have a problem trying to figure out the best way to complete a simple app following the Android best practises. Here is the scenario:
1) I have an activity where the user enters something, its then send to a background Service
2) The background service performs some checks on the input and spawns a new AsyncTask to process the input.
3) The asynctask updates a Status Hashmap in the service with its progress and status
4) There is an second activity that binds to the Service to display a list of currently running tasks from the service and their progresses. The idea is that even if this activity is closed the service will continue to run the tasks and when the activity is reopened the refreshed stats will be shown.
I have problems in 3 and 4. What is the best way to communicate to the Service from within the AsyncTask's onProgressUpdate method and at the same time update the listing activity if its opened, if its not opened its simpler, just update the service tracking maps and when the activity is opened it will read them and update.
Im not sure what is the standart approach to handle "Events" of that sort. Do you have to use a Broadcast listener and subscriber or its too much for this simple purpose?

If you want to communicate between the service and an activity, you could broadcast updates from the service within the AsyncTask.onProgressUpdate method (alternatively within the AsyncTask.onPostExecute(Result) method) and listen for the updates using a broadcast receiver within your activity.
Instead of me copying and pasting a lotta code, check out Vogella's tutorial on services, especially the exercise (7. Exercise: Using services and service communication), found here
www.vogella.com/tutorials/AndroidServices/article.html#tutorial_intentservice
Within the exercise, you're looking for the DownloadService.publishResults(...) method which sends out a broadcast from the service to whichever broadcastreceiver is listening for updates, and the use of the BroadcastReceiver in MainActivity, which handles the updates from the service.

How do I know when my service is called from a broadcast receiver vs Android?

So, I have a service for my app that is always running if the user turns it on. It listens with a broadcast receiver for USER_PRESENT to show a message. It is only supposed to show a message on unlocking.
The problem is though, when Android runs out of memory and kills it, then restarts it, it will show the message again, even if the user hasn't just unlocked their device. Is there a way to know who called the service?
I use service.START_NOT_STICKY, but would service.START_STICKY be better for this job? I guess I don't fully understand the differences but I'm pretty sure I want NOT_STICKY.

You can set the action field in the intent to a specific string when you call your receiver and then check it in onReceieve.
If it has your string then you called it , otherwise someone else.

Run BroadcastReceiver in the background and when device is alseep?

I have a simple BroadcastReceiver set up to do something when the user gets an incoming SMS. But I need it to run in the background and when the device is asleep. So would I use a Service that starts the BroadcastReceiver? If so, can someone give me some pseudo-code? And how would this work if the device is asleep?

I have a simple BroadcastReceiver set up to do something when the user gets an incoming SMS.
OK.
But I need it to run in the background and when the device is asleep.
Not really.
So would I use a Service that starts the BroadcastReceiver?
No. Your BroadcastReceiver should be in the manifest, so it can be invoked regardless of whether any of the rest of your code is running. That's why I say "not really" to "run in the background" -- you DO NOT WANT code running all the time in the background. Rather, you want to be able to receive broadcasts at any point, and that is what putting the receiver in the manifest is for.
If so, can someone give me some pseudo-code?
https://github.com/commonsguy/cw-advandroid/tree/master/SMS/Monitor
And how would this work if the device is asleep?
It won't. However, an incoming SMS, like an incoming phone call, will wake up the device.

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.