Inherently, a FrameGrabber.getState() method would not be thread-safe: there is absolutely no guarantee that the state returned by getState() is still valid by the time your application reads it and takes a decision based on it, unless your application ensures access to a frame grabber instance is
serialised, ie. the frame grabber's state wont be changed by other
threads while calling frameGrabber.getState().
In my opinion, it would be easier to ensure all possible call sequences are valid (one call to startCapture() can only be followed by a call to stopCapture() in your example) than to synchronise access to a frame grabber. Of course, this might not be possible all the time, but in your case I think it is.
If you decide to go the serialisation route, I would just create a single method similar to the toggleCapture() method below, and call it when you need to start or stop the capture.
class LiveView
{
private bool captureStarted;
public LiveView(...)
{
// constructor
....
captureStarted = false;
...
}
// call with startCapture set to true to start the capture, false to stop it
void synchronized toggleCapture(bool startCapture)
{
// if we want to start the capture, but it is already started OR
// if we want to stop it and it is already stopped, do nothing
if ((startCapture == captureStarted) || (frameGrabber == null))
return;
try {
if (startCapture)
frameGrabber.startCapture();
else
frameGrabber.stopCatpture();
captureStarted = startCapture;
} catch (V4L4JException e) {
e.printStackTrace();
}
}
public void windowActivated(WindowEvent arg0)
{
toggleCapture(true);
}
public void windowClosing(WindowEvent arg0)
{
toggleCapture(false)