I'm trying to deal with some timing issues I've seen with a VirtualDisplay as mentioned here and I decided to use a VirtualDisplay.Callback to see if it would potentially fix my timing issues.
Only problem is that my callback never receives onPause when I call virtualDisplay.setSurface(null). The documentation states that it should, but it does not. My handler is not in a tight loop, other methods in the VirtualDisplay.callback are called on VirtualDisplay start up. It just seems like the documentation is incorrect.
Anyone know how to get the callback called when the surface is set to null?
Related
I create SuperpoweredAndroidAudioIO for recording, and it starts working right away, which is fine. However, when I try to use the .onForeground() method when the android activity calls .onResume() it causes a crash... Even if I call onBackground() during onPause().
I also never call start()/stop(), and things seem to work find without calling any of these methods. I can't tell if it's draining battery, and why the methods fail or aren't seemingly needed.
http://superpowered.com/docs/_superpowered_android_audio_i_o_8h_source.html
How should I be using these appropriately?
In the App i am developing, I have to connect to a server/broker to send and receive some messages to and from the broker, and also I have to provide a callback synchronous and an asynchronous listener. As far as I understand, such operation should be better placed in onResume(). am I right? please guide me and confirm whether onResume is the best place to connect to servers/brokers with callbacks or they woud better be inside other lifecycle callback?
As you probably will do something with your UI as soon as you have the answer from the server, you'll want to contact it only when your UI has been created and set up.
OnCreate is fine in an Activity (after setContentView and assigning your Views), OnViewCreated for a Fragment. As long as you're 'prepared' to receive the server's answer instantaniously, it doesn't really matter.
Remember that most 'startup' lifecycle callbacks will be called again if the screen rotates, so don't do the server call twice if you don't have to.
I am developing a simple app which will speak the contact name or an unknown number when call is received. I am implementing the app using broadcastReceiver and Services. If i run the app on emulator and start the call using DDMS, with 2 or 3 contacts saved, the app works fine since onInit() is called before tts.speak() runs.
Now when i try to run the same app on my android phone, onInit is called after the tts.speak(). From what i have understood while searching for an answer to this question, this happens due to tts.speak() not waiting for onInit to called.
One solution i found on this question was on How to wait for TextToSpeech initialization on Android but that didn't work either.
This question has been asked a lot of times but i couldn't find a working solution. This link suggested to use handler http://davidcheney.wordpress.com/2010/11/16/multitasking-in-android/ but being a newbie i have no idea as to how to implement that.
From what i understood i have to wait till onInit is called before i can use tts.speak() but i don't know how to do it.
Update
I was trying to call speak function outside the onInit since the data which was to be spoken was coming from elsewhere and i didn't want to do all the coding in onInit,this was not working. So i changed my code and finally somehow managed to run that speak() inside onInit().
Although the code is now running but there must be a way to call speak() outside onInit. So i will wait for a better answer else post my code for others facing same problem.
You either set a class member flag boolean mTtsInitialized and check this flag everytime you call speak or put the code to get the data to be spoken in onInit
This is not the most elegant way of handling this, I'm sure, but could you extend the class containing the onInit() method?
In this class, you could have a boolean variable that effectively "locks" your thread. Override the onInit() method, call super(), and then after super() set this value to true. Then, enter a loop that blocks the thread which calls tts.speak() until this value is true.
You'll want to keep in mind that you can't do this in the UI thread, because if you block that for too long it will crash your app.
I hope I understood your question correctly. :)
Right so here I am obsessing over memory leaks, and quite frankly not understanding what could really lead to one (and yes I've read the usual links such as http://kohlerm.blogspot.co.uk/2009/02/memory-leaks-are-easy-to-find.html).
I've tried to create some on purpose, for example by leaving a PhoneStateListener subclass inside my activity and opened and closed it a bazillion time, can't see anything in DDMS heap or MAT out of the ordinary. Yet on SO I read over and over again that not only it needs to be deregistered onDestroy, but also onPause (PhoneStateListener() isn´t finished)
Question: is there such a list?
Bonus question: is it true that a PhoneStateListener will create leaks unless it's deregistered onPause/onDestroy etc.
UPDATE: I stand corrected. When re-spawning my app over and over again, even in singleinstance mode, the PhoneStateListener(s) it has registered are still alive after onDestroy was called, and start adding up. I'm currently working on an elegant way to kill them, and will post my results here.
UPDATE2: The correct way to deregister the listener is:
instanceOfTelephonyManager.listen(phoneStateListener, PhoneStateListener.LISTEN_NONE);
... according to the API
UPDATE3: As promised linking this to a better phrased question: https://stackoverflow.com/a/4607435/821423
It is good practice for activity to clean up after yourself and prepare to die in onPause() - this is always called before it goes out of focus, and can not interact with user. onDestroy() is possibly called after this (but not guaranted).
Is your activity is not in focus for user, it does not need any listeners anymore, as it can not show results of those listeners.
For various reasons, I need to use the raw SpeechRecognizer API instead of the easier RecognizerIntent (RECOGNIZE_SPEECH) activity.
That means, among other things, that I need to handle RecognitionListener.onError() myself.
In response to some of the errors, I simply want to re-start listening. This looks straightforward but when I just call SpeechRecognizer.startListening() upon error, this sometimes seems to trigger two different errors:
ERROR/ServerConnectorImpl(619): Previous session not destroyed
and
"concurrent startListening received - ignoring this call"
Which hints that I should have done some cleanup before attempting to call SpeechRecognizer.startListening() again.
If this is true, it means that upon a RecognitionListener error, listening is not automatically stopped and/or canceled.
It is also possible that some errors do stop/cancel listening, while others don't. There are really only 9 SpeechRecognizer errors:
ERROR_NETWORK_TIMEOUT
ERROR_NETWORK
ERROR_AUDIO
ERROR_SERVER
ERROR_CLIENT
ERROR_SPEECH_TIMEOUT
ERROR_NO_MATCH
ERROR_RECOGNIZER_BUSY
ERROR_INSUFFICIENT_PERMISSIONS
Since the documentation isn't very detailed about which error cancels listening and which doesn't, do you happen to know, based on your experience, which errors require doing cleanup (and to which extent) before attempting SpeechRecognizer.startListening() again?
No, cancel is not called when onError is invoked. You can look at the source here.
you can destroy current session by destroy(). And you can restart it again
Actually Femi, some of the error conditions DO stop the transcription service from listening (SpeechRecognizer.ERROR_SPEECH_TIMEOUT for example). It is not necessary to call destroy, just startlistening again.