We Keep Coding

ConcurrentModificationException when updating sprite images

I keep getting a ConcurrentModificationException when running my game which utilizes multithreading to create new sprites and move them. The main problem appears to happen with the creation and/or movement of "Fireballs".
I've been able to run my program successfully with no exceptions appearing by commenting out the createNewFireballs method. However, whenever I do utilize the createNewFireballs method, the error commonly appears whenever I call a function that updates the image of the Fireball Sprite (and doesn't ever happen for any other type of sprite.) I was wondering if anyone could help me locate the source of my problem and potentially solve the issue.
public synchronized void createNewFireball() {
new Thread(new Runnable() {
public void run() {
while (gameNotPaused && hero.isNotDead()) {
fireball = new Fireball(dragon.getX(), dragon.getY());
fireballs.add(fireball);
try
{
Thread.sleep(100); //Waits for .1 second
}
catch(InterruptedException e)
{
e.printStackTrace();
Thread.currentThread().interrupt();
}
}
}
}).start();
}
//The problem commonly occurs in the update method,
//specifically the line "FireballIter.next().updateImage(g);"
public synchronized void update(Graphics g) {
Iterator<Sprite> FireballIter = fireballs.iterator();
Iterator<Sprite> arrowIter = arrows.iterator();
while (arrowIter.hasNext()) {
arrowIter.next().updateImage(g);
}
Iterator<Sprite> iterator = sprites.iterator();
while (iterator.hasNext()) {
iterator.next().updateImage(g);
}
while (FireballIter.hasNext()) {
FireballIter.next().updateImage(g);
}
}
//Although sometimes it occurs as a result of updateScene, which is
//called in another method which moves all the "projectile" sprites
public synchronized void updateScene(int width, int height) {
Iterator<Sprite> arrowIter = arrows.iterator();
while(arrowIter.hasNext()) {
Sprite spriteObject = arrowIter.next();
((Arrow) spriteObject).updateState();
if (spriteObject.overlaps(dragon, 350, 350)) {
dragon.arrowHit();
System.out.printf("Dragon was hit at %d, %d%n, while arrow was at %d,%d%n", dragon.getX(), dragon.getY(), spriteObject.getX(), spriteObject.getY());
arrowIter.remove();
}
}
Iterator<Sprite> fireballIter = fireballs.iterator();
while(fireballIter.hasNext()) {
Sprite spriteObject = fireballIter.next();
((Fireball) spriteObject).updateState();
}
}
#Override
public synchronized void run() {
while (model.getGameNotPaused()) {
model.updateScene(view.getWidth(), view.getHeight());
view.repaint();
try {
Thread.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
Thread.currentThread().interrupt();
JOptionPane.showMessageDialog(null, "Press R to resume game.");
}
}
}

Making createNewFireball synchronized does nothing useful: the synchronization only applies to the execution of that method, not the runnable executed by the thread (which is good, because otherwise none of the other methods would be able to execute until the while loop finished).
Put the fireballs.add into a synchronized block, taking care to ensure you are synchronizing on the right thing:
If you simply use synchronized (this), you would be synchronizing on the Runnable.
Instead, use synchronized (TheContainingClass.this) (where TheContainingClass is the name of the class containing these methods).

Assuming your fireballs is an ArrayList<Fireball>, you could also consider switching it to CopyOnWriteArrayList , a thread-safe variant of ArrayList

Why we use a flag to stop a thread?

When I tried to figure out how to stop a thread in a program with multiple threads,
I was suggested to call a method which actually sets a flag to tell that thread stop doing real works,like this:
public class ThreadTobeTerminated implements Runnable {
private static final Logger LOGGER = LoggerFactory.getLogger(IndexProcessor.class);
private volatile boolean running = true;
public void terminate() {
running = false;
}
#Override
public void run() {
while (running) {
try {
LOGGER.debug("Doing some real work ,like Counting...");
for(int i=0;i<100;i++){}
} catch (InterruptedException e) {
LOGGER.error("Exception", e);
running = false;
}
}
}
}
when I want to stop this tread ,I'll call threadInstance.terminate();.
Don't I need to literally stop this thread ?
Why I should leave this thread to do some useless work (method run called ,test the flag running==false then return)? I mean :this is a waste of time ,isn't it?

When the execution scope goes beyond the run() method, the thread stops, so the moment that the while loop is broken, the thread will stop.
This would also allow you to do some clean up if the situation requires it:
public void run() {
while (running) {
try {
LOGGER.debug("Doing some real work ,like Counting...");
for(int i=0;i<100;i++){}
} catch (InterruptedException e) {
LOGGER.error("Exception", e);
running = false;
}
}
//Clean up
}
The above approach allows you some control over how is the thread stops and what happens after as opposed to potentially just kill it, which could cause all kinds of problems.

Android PictureCallback needs to execute first then continue to other code

I have code to take a picture that works, but after it gets to PictureCallback(), it continues chugging on code-wise and I end up executing other code before I have my byte array. Is there any way to halt this? It only takes milliseconds and I don't think I would mind halting the UI thread.
private static byte[] patronImage;
.
.
.
takePatronPicture();
//I want to do something with patronImage here, but the next line
//gets executed almost immediately while getJpegCallback is still
//doing its thing.
code that does something with patronImage;
.
.
.
public void takePatronPicture(){
if (camera != null) {
try {
SurfaceView surfaceView = (SurfaceView)getView().findViewById(R.id.surfaceView1);
camera.setPreviewDisplay(surfaceView.getHolder());
camera.startPreview();
camera.takePicture(null, null, getJpegCallback);
}
catch(Exception e) {
e.printStackTrace();
}
}
}
final PictureCallback getJpegCallback = new PictureCallback() {
#Override
public void onPictureTaken(byte[] data, Camera camera) {
try {
patronImage = data;
camera.release();
camera = null;
} catch (final Exception e) {
e.printStackTrace();
}
}
};

The purpose of a callback is that it will call you later when its done. If you have additional code to run that requires the operation's data, you put it in the callback. You don't freeze your current thread waiting for it. In fact doing so may lead to deadlock if the operation posts an event to the main thread's looper.

Setting up the correct multi threading

Unfortunately I have a pretty bad understanding of how to properly set up threading. I know there is a bunch of info on this both here on SO.SE and on other sites but I can't seem to relate what I read correctly to what I'm doing.
My problem is that I have a method that takes two parameters where one is divided by the other. The quotient (result) is used to fill up a visual progress bar. When the quotient gets to 1, (readBytes/contentLength == 1), I want some thread (I guess) to wait for a given time before the progress bar is removed from the layout. I know all the code needed to set the value to the progress bar and how to remove it from the view, my question is how do I make it wait for, say, 2000 ms before the action is triggered to remove the component?
This is probably basic threading knowledge but I'm having huge problems with it.
So far I've tried these two approaches:
#Override
public void updateProgress(long readBytes, long contentLength) {
this.contentLength = contentLength;
if(readBytes != 0 && contentLength != 0 && fileListItem != null) {
fileListItem.getProgressIndicator().setValue(readBytes/contentLength);
synchronized (this) {
while(readBytes/contentLength != 1) {
try {
wait();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
};
fileListItem.removeProgressIndicator();
}
}
}
if(!itemIsAdded) {
checkFileCompatibility(contentLength);
}
}
AND
#Override
public void updateProgress(long readBytes, long contentLength) {
this.contentLength = contentLength;
if(readBytes != 0 && contentLength != 0 && fileListItem != null) {
if(readBytes/contentLength == 1) {
Thread t = new Thread();
t.start();
try {
t.wait(2000);
fileListItem.removeProgressIndicator();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
t.interrupt();
} else {
fileListItem.getProgressIndicator().setValue(readBytes/contentLength);
}
}
if(!itemIsAdded) {
checkFileCompatibility(contentLength);
}
}
With no success. In the first example the main thread seems to be the one waiting and nothing happens. And in the second example I get an exception on the t.wait(2000);. I'm at a loss of how I should do..
EDIT: With the input from Bohemian I got it working.
#Override
public void updateProgress(final long readBytes, final long contentLength) {
this.contentLength = contentLength;
if(readBytes != 0 && contentLength != 0 && fileListItem != null) {
if(!threadIsRunning) {
new Thread(new Runnable() {
#Override
public void run() {
threadIsRunning = true;
while(!fileIsAdded) {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
LOGGER.error(e.getMessage());
break;
}
}
fileListItem.removeProgressIndicator();
threadIsRunning = false;
}
}).start();
}
fileListItem.getProgressIndicator().setValue(readBytes/contentLength);
if(readBytes == contentLength)
fileIsAdded = true;
}
if(!itemIsAdded) {
checkFileCompatibility(contentLength);
}
}
It still needs some tidying up but the basics are now working!

In all probability SwingWorker is the right tool for your task. There is a full code sample in the Javadoc. Notice the method setProgress -- that's ideal to update your progress bar.
If all you need is really just a fixed 2 second delay for clearing the progress bar, then you want to use a Swing Timer. It doesn't even involve multithreading, you just write a callback handler that will be executed after the specified delay.

I wouldn't have the main thread wait. It's bad practice because it isn't scalable and makes your GUI jittery.
Instead, I would pass a timeout value and a couple of callbacks to the worker thread to execute when it exceeds its timeout/completes its work. That way the main thread is free to go back to doing whatever it wants to.
Just for illustration purposes, your "completion" callback might look like:
new Runnable() {
public void run() {
// code that hides the progress bar
}
}
Your "timeout" callback might look like:
new Runnable() {
public void run() {
// code that displays an error message
}
}
By the way, to get a thread to do something, you also pass it a Runnable:
new Thread(new Runnable() {
public void run() {
// code that runs when your thread starts
}
}).start();

I think what you really need is
Thread.sleep(2000);
instead of wait. While wait can be used for sleeping, its primary function is for inter-thread signaling and requires a lock on the object being waited on, which you have not acquired, hence the exception.
Edit: Upon further inspection I notice that you are not doing things correctly. You are just creating a thread with no associated run method:
Thread t = new Thread();
t.start();
Hence your thread is not executing anything.
I suggest reading a Java threading tutorial on how to set up threads correctly: http://docs.oracle.com/javase/tutorial/essential/concurrency/runthread.html

Proper multitasking for android

Hi im developing an android application and im wondering how i make the app use less CPU while backgrounded. For example, my application pauses once it loses focus but the cpu usage is still 50%
Edit
while (!pause) {
Canvas c = null;
try {
c = sHolder.lockCanvas(null);
synchronized (sHolder) {
doDraw(c);
powerUps();
}
} finally {
if (c != null) {
sHolder.unlockCanvasAndPost(c);
}
}
}
Then when you pause and resume it just changes the pause variable

IMO, you should not be looping at all while your app is paused.
See this page for more details about the "proper" lifecycle of an android app.
Also note that with any busy loop design your app will be using 100% of the CPU - I'm not sure if starting a loop from the onResume() method is correct; my instinct is to have each iteration of your loop performed by a separate call initiated by a call to Handler.post(), with the last statement re-posting the next call. Otherwise, the application's main thread will be starved, right?
Maybe something like this:
void iterate() {
Canvas c = null;
try {
c = sHolder.lockCanvas(null);
synchronized (sHolder) {
doDraw(c);
powerUps();
}
} finally {
if (c != null) {
sHolder.unlockCanvasAndPost(c);
}
}
this.handler.post(this.iterateRunnable);
}
void onResume() {
this.handler = new Handler();
this.iterateRunnable = new Runnable() {
#Override public void run() { iterate(); }
};
this.handler.post(this.iterateRunnable);
}