Androidlnput The Great Coordinator

The Input implementation of our game framework ties together all the handlers we just developed. Any method calls will be delegated to the corresponding handler. The only interesting part of this implementation is where we choose which TouchHandler implementation we use based on the Android version the device is running. Listing 5-11 shows you the implementation, called AndroidInput.

Listing 5-11. AndroidInput.java; Handling the Handlers with Style package com.badlogic.androidgames.framework.impl;

import java.util.List;

import android.content.Context; import android.os.Build.VERSION; import android.view.View;

import com.badlogic.androidgames.framework.Input;

public class AndroidInput implements Input { AccelerometerHandler accelHandler; KeyboardHandler keyHandler; TouchHandler touchHandler;

We start off by letting the class implement the Input interface we defined in Chapter 3. Next we find three members: an AccelerometerHandler, a KeyboardHandler, and a TouchHandler.

public AndroidInput(Context context, View view, float scaleX, float scaleY) { accelHandler = new AccelerometerHandler(context); keyHandler = new KeyboardHandler(view); if(Integer.parseIdt(VERSION.SDK) < 5)

touchHandler = new SingleTouchHandler(view, scaleX, scaleY);

else touchHandler = new MultiTouchHandler(view, scaleX, scaleY);

These members get initialized in the constructor, which takes a Context, a View, and those scaleX and scaleY parameters that we can happily ignore again. The AccelerometerHandler gets instantiated via the Context parameter, and the KeyboardHandler needs the View that gets passed in.

To decide which TouchHandler to use, we simply check the Android version the application runs on. This can be done via the VERSION.SDK string, a constant provided by the Android API. Why it is a string is unclear, as it directly encodes the SDK version numbers we use in our manifest file. We therefore need to make it an integer to do some comparisons. The first Android version to support the multitouch API was version 2.0, which corresponds to SDK version 5. If the current device runs an Android version below that, we instantiate the SingleTouchHandler; otherwise we use the MultiTouchHandler. And that's all the fragmentation we have to care about at an API level. When we start doing OpenGL rendering, we'll hit a few more of these fragmentation issues—but don't worry, they can be as easily resolved as the touch API problems.

^Override public boolean isKeyPressed(int keyCode) { return keyHandler.isKeyPressed(keyCode);

^Override public boolean isTouchDown(int pointer) { return touchHandler.isTouchDown(pointer);

^Override public int getTouchX(int pointer) {

return touchHandler.getTouchX(pointer);

^Override public int getTouchY(int pointer) {

return touchHandler.getTouchY(pointer);

@Override public float getAccelX() {

return accelHandler.getAccelX();

@Override public float getAccelY() {

return accelHandler.getAccelY();

@Override public float getAccelZ() {

return accelHandler.getAccelZ();

@Override public List<TouchEvent> getTouchEvents() { return touchHandler.getTouchEvents();

@Override public List<KeyEvent> getKeyEvents() { return keyHandler.getKeyEvents();

The rest of this class is more than self-explanatory. Each method call is delegated to the appropriate handler, which does the actual work. And with this, we have finished the input API of our little game framework. Next we'll move on to graphics.

0 0

Post a comment