

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer

I found this article on implementing an input pipeline for Android, but I don't really understand how it works. I also don't completely understand the programming concept of a pipeline or a pool either. Could someone explain these concepts and how they work as this input pipeline?

share|improve this question
up vote 5 down vote accepted

I haven't looked at the code in depth but the basic idea is that input events are asynchronous in Android, meaning they could happen at any time. You don't want to interrupt your main loop code to process input events because it could slow down your game and might alter your game state in unexpected ways.

The traditional approach used in the Lunar Lander sample is to have a synchronized block around the main loop and around each of your input handlers to ensure that they'd never happen at the same time. This might be a valid approach for a small game but as your game gets more complicated you'll find that it's not very efficient and it might not work correctly.

The article suggests a better approach of storing the input events in a queue, and processing them at a known point in your main loop. Input handlers simply push the event (after wrapping them in an InputObject that describe them) to the end of the queue, and they are later processed in the processInput method in the game thread.

The author of the article actually uses two queues, an input queue and an input object pool. The input object pool in the main activity is used because we don't want to keep creating new input objects every time we get an input event. This is bad because input events happen frequently and creating a lot of object will cause the garbage collector to run often, which makes your game choppy and unresponsive. The better approach is to create a pool of object once (basically a queue) and take objects from the queue when you need them and return them to the queue when you're done. That's what the queue in the main activity is for. The other queue is an input queue in the game thread which actually contains the input events received and which is processed game loop using the processInput method.

The pool queue will always have a fixed number of objects (specified by the INPUT_QUEUE_SIZE constant which can be 30 for example) which are allocated in the createInputObjectPool method when the activity is created, while the input queue will have a variable number of input events which are fed by the activity and returned back to the pool queue once they are processed using the returnToPool method. These queues are ArrayBlockingQueues which are normal queues (first in first out) implemented using an array (as opposed to linked list for example) that would block, in circumstances where a normal queue would overflow and underflow, until the queue is ready for the operation.

share|improve this answer
Great answer, +2 if I could – Joe Aug 29 '11 at 15:43

Your Answer


