I am trying to figure out which threads should do what in Android.
The only thing I have found stated in the official documentation is that camera.open() should be put into its own thread.
What about:
camera.startPreview()
camera.stopPreview()
camera.release()
It doesn't state which thread they need. Must they be run on the main thread (ui thread)? Or am I free to choose?
Why am I trying to figure this out? camera.startPreview() when run on the main thread is causing my app to jitter/lag for a short period of time, this heavily affects my application as it is put inside a viewPager and I do not wish to have the camera to always preview (which would cause no lag, but takes up system resources).
Any ideas?
The documentation for Camera states that the class is not thread safe and should not be called from multiple threads at once (I suppose, unless you are performing your own synchronization).
It says that the callbacks will be delivered to the thread that makes the call to open
From the reference (emphasis mine):
This class is not thread-safe, and is meant for use from one event thread. Most long-running operations (preview, focus, photo capture, etc) happen asynchronously and invoke callbacks as necessary. Callbacks will be invoked on the event thread open(int) was called from. This class's methods must never be called from multiple threads at once.
From the open(int) method reference:
Callbacks from other methods are delivered to the event loop of the thread which called open(). If this thread has no event loop, then callbacks are delivered to the main application event loop. If there is no main application event loop, callbacks are not delivered.
Caution: On some devices, this method may take a long time to complete. It is best to call this method from a worker thread (possibly using AsyncTask) to avoid blocking the main application UI thread.
The thread it needs is the one you use to call open(int).
So to answer your question, yes you are relatively free to choose, but you must remain consistent.
Related
I am using the AudioRecord object, and within AudioRecord.OnRecordPositionUpdateListener I am implementing AudioRecord.read to write data to a byte buffer, after this I am calling another object's method to process the byte buffer and return it afterwards to write to file, the problem is the object's processing is quite long and seems to be stopping the main thread,which is odd i thought the AudioRecord.OnRecordPositionUpdateListener was Threaded
Unless it explicitly says so, assume nothing is threaded in android. Its all callbacks on the UI thread.
The normal way to do this would be to start up a thread in onCreate or onStart of your app, and have it wait for a message from the main thread. Your implementation of onMarkerRead (or whatever other function you need) would then send a message to that thread. You could create a thread whenever the notification function is called, but keeping the thread around avoids thread creation overhead at the OS level every time you get a notification.
Avoid using AsyncTasks here. They sound like the right solution, but since all app tasks are single threaded they could be held up indefinitely.
My android app has a long running background service, which I also understand runs in the application's main thread and for that reason, any time consuming or blocking task should be moved to a separate thread.
Now, here is the situation, I don't understand/confused about:
When I bind to the service from an activity, i receive an reference to the service which allows me to invoke service methods from my activity. One of the methods allows me to pass a String object from the activity to the service, which is then added to a BlockingQueue. A separate worker thread which is started in the Service's onCreate method, checks the queue for available data and then performs the required task.
What I want to understand is, if at some point, the queue becomes full and an attempt to the queue blocks, will it affect the main thread the service is running on?
Yes. In this situation, if the queue becomes full, the calling thread will block (in your situation, the main thread). So this is a bad design.
The produced data coming from a field of an Activity doesn't force you to use it on the main thread. I suggest you use some Handler for your producer running on its own thread which will allow you to make the processing (and eventually waiting on the queue) outside of the main thread.
This is also good for communicating with your Service since you can use Handlers to communicate with a Service (see Android Services' guide).
Finally, if applying the produced data can be passed directly to an Handler using either
Handler.post(Runnable) or Handler.send(Message)
I think title itself says what the my question is...
AFAIK, in Java, when work of a Thread is completed i.e. run() method has completed executing, Thread itself will finish and dies.
So, When my Activity(I mean UI) is idle for a long time, what the UI thread will do? does it sleeps? or does it do any other work?
Thanks to all...
I believe the question is not really about Java threads in general, but about the Android "main thread" (also called the "UI thread").
To quote from the JavaDoc for the Android Handler:
When a process is created for your application, its main thread is
dedicated to running a message queue that takes care of managing the
top-level application objects (activities, broadcast receivers, etc)
and any windows they create. You can create your own threads, and
communicate back with the main application thread through a Handler.
This is done by calling the same post or sendMessage methods as
before, but from your new thread. The given Runnable or Message will
then be scheduled in the Handler's message queue and processed when
appropriate.
In other words: The main thread is responsible for dequeuing messages/runnables from a queue and processing them. That main thread is blocked while the queue is empty (since there is nothing for it to do). If you use a Handler that was created in the main thread, that Handler's messages and runnables will actually be added to the same queue used by the main thread. Normally, the main thread will run as long as the process does.
Note: An Android app can actually have multiple processes, and each one will have its own main thread. However, most Android apps will only have one process (and therefore one main thread).
i am using threads to do few tasks. and after that i want to access the main thread via runOnUiThread(). but how to determine whether that ui thread still running or not?
Two options are there one use a static boolean variable and see whether the activity is running or not, or you can check all the running tasks and determine whether your activity is running or not.
The only instance when your UI thread is not running is when your main thread has spawned a thread which needs to communicate with the UI thread and the non-UI thread has not been killed when the life of the context ends.
You must avoid a situation like this by interrupt()ing your threads in onStop() or onDestory() (whatever is appropriate).
After you've taken care of this, you can always safely assume that a runOnUiThread() call is appropriate.
In an Android app, I need several listeners (for network changes, location changes, etc.).
As far as I can see, these are called in a thread (or threads) which are not my main background service thread. (I'm creating a service-only app.)
My question is:
Can my app be hit by listeners firing simultaneously, or does Android mitigate this by invoking my listeners in a single thread?
Secondly, if the listeners aren't 'sequentialised', are the individual listeners re-entrant?
In other words, can I carry out complex processing in my listeners, or should they just dump what happened into a synchronized list, for later processing my background service thread (and wakeup the background service thread from its sleep while they're at it).
There seems to be very little coverage of thread synchronisation in Android example docs and books.
Thanks,
Chris.
I don't know what types of listeners you're talking about specifically, but generally they are not called on their own threads. They are called on the thread that you register the listener on, so if you register the listener on the UI thread it will fire on the UI thread. If you create a Looper thread, then you can register listeners on that thread, and they will fire in that thread sequentially as they hit.