I got a quick question about ArrayLists

I have 2 ArrayLists, one for active TouchPoints and one for inactive TouchPoints.
In an Event Listener, When a finger is pressed on the screen the first object in my inactive list is moved over to my active list.

 
public void TouchPointDown()
{
	TouchPoint o = inactiveTouchPoint.get(0);
	o.Revive();
	
	activeTouchPoint.add(b);
	inactiveTouchPoint.remove(b);
}
 

Now when a finger is removed from the screen, I do the reverse. I remove the TouchPoint from the active list and move it back over to the inactive list.

 
public void MakeTouchPointInactive(int index)
{
	TouchPoint o = activeTouchPoint.get(index);
	o.Kill();

	inactiveTouchPoint.add(b);	
	activeTouchPoint.remove(b);

}
 

Now I think I have a problem here right?

If I am looping through my list of active TouchPoints and updating/checking them. I have the potential to throw an exception, because it would be possible to be in the middle of updating/checking the active TouchPoints, but then at the same time the Listener could be triggered by removing a finger from the screen. Causing a TouchPoint to be removed from the active list, and then my loop explodes on being out of bounds because I'm still tyring to update/check my active TouchPoints.

How can I stop this? What is the best solution?

Could I just loop through my array list backwards? Does this call for the synchronized keyword?

Also can someone explain to me what the synchronize keyword actually does?

I understand its like a semaphore, but what happens if something already has the lock? Does the syncronized code section get skipped over or do I block until the lock becomes available?

If you use a thread-safe collection then these race conditions won't happen.

http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html

public void TouchPointDown()
{
	for(int i = 0; i < touchPointList.size(); ++i)
	{
		TouchPoint o = touchPointList.get(i);
		if(o.isActive == false)
		{
			o.Revive(); //Gets IsActive set to true
			break;
		}
	}
}

public void TouchPointUp(int touchPointID)
{
	for(int i = 0; i < touchPointList.size(); ++i)
	{
		TouchPoint o = touchPointList.get(i);
		if(o.ID == touchPointID)
		{
			o.Kill(); //Gets IsActive set to false
			break;
		}
	}
}

I would just have one list. When a touch point is down, add it to the list. When it's up, remove it.

Wouldn't I just run into my original problem then? Since the touch listener is executed on a separate thread?

I always cringe when I see a loop iterating over a collection in synchronized block because it's often a place where deadlocks are lurking. It might be OK, it's probably OK, but I've been burned too many times before. Also, if processing the list takes any length of time (unlikely in a tight game loop, but still) then your UI thread could be blocked waiting for the chance to add/remove an item.

In this case I would highly recommend the CopyOnWriteArrayList (in the java.util.concurrent package). Unlike ArrayList, the class itself is thread-safe so you don't need to be burdened with figuring out where to put the synchronized keyword. In particular, you can iterate over the contents of the list (using an Iterator) without needing to hold a lock the entire time. This means your game thread can be processing touch points at the same time that you're adding/removing points on the UI thread.

This means your game thread can be processing touch points at the same time that you're adding/removing points on the UI thread.

public class MainClass
{
	
	public TouchListenerObject myTouchListner = new TouchListenerObject(); // Creates a new listener. Automatically gets pushed to its own thread?
	public static void main(String [] args)
	{
                while(true)
                {
                   myTouchListener.CheckOnTouchPoints();
		   /* Do other main stuff */
                }
	}

}

I always cringe when I see a loop iterating over a collection in synchronized block because it's often a place where deadlocks are lurking. It might be OK, it's probably OK, but I've been burned too many times before. Also, if processing the list takes any length of time (unlikely in a tight game loop, but still) then your UI thread could be blocked waiting for the chance to add/remove an item.