Skip to content

Android app

Jump to bottom
lucullusTheOnly edited this page Jan 14, 2018 · 1 revision

At this page we want to speak about the functionality of the Android app, which does all the management of the game and the game logic.

The Android app consists of 3 threads, that are running parallel:

  • The UI-Thread, which does all the interaction with the user,
  • the GameLogic-Thread, which loads and handles the game logic defined by an XML file
  • and the Serial-Thread, which handles the bluetooth device and receives the serial data send to the app

These threads are only communicating through handler messages (especially since you cannot use an UI element in an other thread than the UI thread). Each thread has a handler function, in which it is determined, what to do depending on the received message.

A Singleton - a class which has only one instance and persists during the whole lifetime of the app process - is used to make important data available for all activities and threads of the app. For example it stores Handler references for the GameLogic- and SerialThread and information about the state of some activities, which have to recover their data after a configuration change (like switching from portrait- to landscape orientation).

The heart of this app is the GameLogic-Thread. When instructed by the UI-Thread it loads an XML file, which defines the complete behavior and characteristics of a game(-type). When a special event occurs (e.g. the Serial-Thread received a shot) the system queues a signal, whose code (defined in the XML file) is then executed in the main loop of the thread. The set of available signals and commands is listed in the article about the XML file and its syntax. When a command demands it, the thread sends a message with the command bytes to the serial thread, which sends it to the tagger.

The GameLogic-Thread itself is organized in a part for signal handling and execution and an instance of a separate class for loading the the game information with an XML parser. The game information is stored in a class construct, which uses HashMaps to organize the data in the different categories. The subclass, which stores a command and its parameters, also implements a method to execute it. So the execution of a command takes place in the game information variable. Also every part of the game information implements the toString() method, so that you can get the information in a human readable form for debugging or such.

Known Bugs:

  • Not appearing app directory (or appearing as single file of 0 Bytes or 4kB) in the shared storage, when looking over MTP
Clone this wiki locally