• No se han encontrado resultados

Con esta modificación se obtiene la no rotación de los elementos, por lo que no hay que realizar una configuración por cada giro del dispositivo móvil. Pero esta característica no solo se ha realizado por reducir la dificultad, si no que además se ha tenido en cuenta que el juego desarrollado es del género plataformas. En estos juegos, el movimiento del personaje que se controla es esencial, por lo que si se determina una zona de la pantalla para posicionar un pad con el que se controlan sus movimientos, tiene que ser suficientemente ancha como para que no haya errores a la hora de determinar los botones que se han pulsado del pad. De este modo, determinando que la única orientación posible en la aplicación es la conocida como landscape, se obtiene una mayor zona de pulsación. Esto es debido a que los dispositivos móviles, por lo general, son más altos que anchos en dimensiones, pero si se cambia a esa orientación citada, se obtiene una anchura mayor. Asimismo, con este cambio se podrá visualizar una mayor zona del escenario cuando se inicie la partida.

Otro aspecto que se ha tenido muy en cuenta ha sido el ciclo de vida de una aplicación y el de la Activity. Una aplicación Android se ejecuta en su propio proceso. Este proceso es creado cuando parte del código necesita ser ejecutado, y continuará vivo hasta que ya no sea requerido y el sistema reclame su memoria para asignársela a otra aplicación.

Cada componente de una aplicación tiene su propio ciclo de vida bien definido. Las

65 Activity, en el que Android permite al desarrollador poder controlar ese cambio y en cada momento saber en cuál se encuentra la Activity, consiguiendo así programar las acciones que mejor convengan y tomar decisiones adecuadas.

Figura 56. Ciclo de vida de un Activity [97]

El ciclo de vida de una Activity está profundamente relacionado con el de una aplicación, debido a que toda Activity tiene un ciclo de vida desde que se inicia la aplicación, hasta que se cierra, en el caso de una aplicación con una sola.

Cube´s War está compuesta por tres Activities denominadas Proyecto, Videojuego y Créditos, y en ellas se implementan cuatro estados de todos los que existen, por considerarse los más importantes:

 onCreate(): se ejecuta cuando se crea la Activity por primera vez. Es aquí donde se deben crear Views, linkar datos a listas… en definitiva, el proceso de inicialización de la aplicación.

 onPause(): cuando se tenga dos Activities en ejecución, la Activity que está en primer plano relega a la segunda Activity a un segundo plano actualizando esta al estado de pausa guardando su estado. Se utiliza para guardar datos que no se han grabado anteriormente o detener acciones que consuman CPU o batería.

 onResume(): este método es llamado cuando una Activity que estaba en onPause(), vuelve al primer plano de ejecución, es decir, a su estado normal.

66

 onDestroy(): es la última llamada antes de destruir la actividad. Puede darse porque la actividad está acabando o debido a que el sistema destruirá la instancia por necesidad.

Por ultimo, en esta aplicación se hace uso de las fuentes que Android pone a disposición. Estas fuentes pueden ser archivos XML de distribución de pantalla, o que contengan cadenas de texto y/o definiendo colores, animaciones, archivos de imagen y/o sonido, siendo un conjunto de recursos para uso de la aplicación. Todos están ubicados y distribuidos en sus respectivas carpetas dentro del directorio res/, y que cuando se crea algún archivo, o se modifican, se añaden ficheros… esto provoca que el plugin ADT[98] de Android sobre Eclipse, actualice una clase Java de la aplicación llamada R.java alojada en el directorio gen/, que contiene los IDs únicos de los elementos contenidos en esas carpetas o archivos XML. Cargando estos IDs permiten acceder al contenido de estos recursos mediante la llamada al método correspondiente, e incluyendo R.id.xx, o R.string.xx, R.layout.xx, R.anim.xx, R.raw.xx, R.drawable.xx…

dependiendo de qué es lo que se quiera cargar en cada momento.

Una vez explicadas estas características de la aplicación desarrollada, se disponen a describir más detalles de la implementación del juego.

4.3.3.1 Reproducción de sonidos

Figura 57. Clase Reproductor

El videojuego desarrollado reproduce efectos de sonido antes distintas acciones del usuario como: pulsar los botones, presionar botones físicos del dispositivo móvil, al conseguir completar un escenario o la totalidad del juego, si el usuario mediante el control de su personaje provoca que salte, choque con los enemigos, caiga de la plataforma por donde se desplaza o sobre los pinchos que se disponen por el escenario y finalmente colisione con los meteoritos que caen de la parte superior del escenario.

Para este cometido se ha creado una clase dedicado a ello llamada Reproductor. Ésta contiene un boolean que indica si se permite la reproducción de sonidos y se modifica mediante la configuración de las opciones del juego dentro del menú principal o cuando se cargan las configuraciones al iniciar el juego.

La clase Reproductor además del boolean anterior, contiene dos métodos que realizan el cometido al que está dedicado:

 Play (Context context, int resource): se utiliza para la reproducción de sonidos. Se tienen que facilitar en su llamada, el Context de la Activity y el fichero de sonido almacenados en res/raw mediante la ID del fichero R.java, que se quiere reproducir en los momentos que se han establecido. Dentro de dicho método, se realiza la comprobación de si está habilitada la reproducción de

67 sonidos y si es así, se inicializa un reproductor, le pasa la fuente, inicia la reproducción y cuando finalice ésta se procederá a la liberación de recursos.

 Stop(Context context): la finalidad de este método es la de detener cualquier reproducción de sonido que se esté ejecutando en el momento en el que se precise, liberando los recursos que tenia asociada esa reproducción que estaba en curso.

Una vez implementado, mediante la realización de llamadas a estos métodos estáticos de la clase Reproductor, se origina la reproducción de los sonidos que se han establecido. Estos archivos de sonido tienen que ser de un determinado formato para que el dispositivo móvil pueda reproducirlos, siendo los siguientes los soportados por Android[99].

Se escoge el formato .wav de 8 y 16 bits PCM lineal, siendo éste un formato de calidad y a su vez de reducido peso.

4.3.3.2 Vibración

Cuando se ha hablado anteriormente de AndroidManifest.xml, se ha comentado que es en él donde se deben concretar los permisos que el desarrollador solicita utilizar para su aplicación. Esto es debido porque para las aplicaciones está prohibido por el sistema ejercer acciones restringidas como realizar llamadas de teléfono, leer y escribir la información de contactos o sms, disponer de acceso a Internet o utilizar un elemento hardware del dispositivo. La única manera de tener acceso a estas funcionalidades es declarándolas explícitamente para que el sistema autorice a ello.

Cube´s War solo necesita de un permiso para su funcionamiento, que es el del control de hardware, en concreto, el control de vibración. Por lo tanto, se tiene que añadir ese permiso al AndroidManifes.xml mediante la etiqueta:

<uses permission android:name="android.permission.VIBRATE"/>