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. :)
Related
Which function is called when an app is killed by keeping it in recent apps list for a long time?
I am not asking about when an app is killed by swiping app from the recents list.
There is no such function in Android.
When user closes the app, the process is terminated with no notice. Even Activity's onDestroy method is not guaranteed to be called. Only when you explicitly call finish().
If you use ViewModel that is tied to the starting Activity's lifecycle, you can try to use onCleared() method, which is called always when ViewModel is no longer used and will be destroyed. See: https://developer.android.com/topic/libraries/architecture/viewmodel
There is no such function.
At the point when the system decides to kill your process, it will do so immediately without calling any more of your code beforehand.
Another answer suggests using ViewModel, but this won't work if you actually need a reliable signal. It is not guaranteed to trigger, and it may trigger in other circumstances (such as the user backing out of the activity, but the app process not being killed).
I'm using Agora RTC and Signaling SDK for building a video call function.
But I get a problem that if the receiver side exits app suddenly (like swiping app out from recent tray).
Then, the caller side is still on calling screen and can not get any event from receiver side to end the video call.
Please help
to solve this problem, you need to add leave channel logic at onDestroy method in receiver's activity. So that when the receiver exits the app, he will leave the channel and that will notify the caller.
When the battery on my Android device dies what methods in the Activity and Fragment classes (if any) are called during the "Powering Off" stage of the device?
Also, if a user is currently looking at a screen in my app and they hold the power button and choose switch off, do the events called/not called coincide with when the battery is depleted and shuts down automatically?
OnPause?
OnStop?
OnDestroy?
OnDetach?
Bonus:
Will I have enough time to save a small amount of data to a web server?
To clarify "dies" when the device's battery is 'completely' dead, accepts no more input and a message box/loading screen pops up on the screen stating "Powering Off". Shortly there after the device switches off.
I just need enough time to save a forms state before the phone switches off, I have a strategy to clean the saved data should the phone not switch off, but I want to get as close to the phone switching off as possible (any more than a minute is pointless really).
onDestroy is called on everything when the battery reaches 0.5%
EDIT: There is no specified time that you have to do anything in the shutdown process resulting from low/dead battery, that would be dependent on the specific phone battery and not the system, so you may have enough time to save data to a web server on some phones but not others. Experimentally, I have only been able to write a short line to a file I was already writing to before onDestroy was called and nothing more.
The methods you have mentioned is activity life cycle callback, none of them will be called when battery is low. You need to use a broadcast receiver for this
See this How to detect when the Battery's low : 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.
I'm having a small problem with the Android app I'm designing.
I need to run some code whenever either of these 2 events happen:
1. The app is NOT running in the background, so the user launches it.
2. The app IS already running in the background, so the user is really
just re-opening it.
(I only need to run the code once, not twice.)
No matter where I put the call to my code (onCreate, onStart, onRestart, onResume, etc) I always have undesired affects:
A. My code gets run twice when #2 happens.
B. My code runs even when the user is just moving from
MAIN to a SUB-ACTIVITY, then back to MAIN again.
C. My code doesn't run at all.
Isn't there come kind of distinction I can make to determine: onCreate() and onRestartingFromBackGround()?
I thought I could use onRestart(), but I was VERY surprised to see that onRestart() runs even just when I do #B. (Is #B really considered a "restart" of my app????)
From a pure java standpoint, you could use a loading thread for when the icon is first pressed. This loading thread can poll the phone to see if the main activity thread is currently running or not, then from your loading thread, move to the correct piece of code. For ANDROID, I THINK, that you will poll the process name, or process ID...anyone ever poll the OS for processes??