# MZAP--Mobile Application for Basketball Match Tracking and Digitalization of Endgame Reports
## 3 MZAP Android Application--Architecture and System Design
#### System Design  
This chapter presents the data flow, concurrency management, and error handling mechanisms implemented within the MZAP application. For each of these aspects, a corresponding flowchart is provided to visually support the discussion. Additionally, a system integration diagram illustrates the architectural relationships between the MZAP Android application, the MZAP Server, and the MZAP Converter (currently under development), as components of the overall MZAP software suite. The data flow model of the MZAP application, illustrated in Figure 1, is centered around a singleton object, the MZAP Match Record, which encapsulates multiple entities designed to store basketball match data. This object is coupled with the MZAP application's SharedPreferences, which acts as in-memory storage. Data flow between the aforementioned entities is bidirectional. Figure 1: MZAP data flowchart. Using a custom SharedPreferences manager, data are saved to the SharedPreferences storage every 10 s via an application-level thread, without compromising the user experience. Read and write operations are synchronized using a mutex mechanism (the synchronized keyword). As various application fragments handle distinct segments of basketball match data, to each fragment that manages data, references to the particular object within the MZAP Match Record singleton are sent. Updates to the singleton MZAP Match Record are propagated to SharedPreferences via the previously described thread. Changes in fragment properties are reflected in the Match Record, and conversely, fragments are refreshed with data from the Match Record upon initialization or redraw. Concurrency is managed using the ExecutorService. All processes related to network communication, complex object initialization, report generation, and similar tasks are executed as background tasks that can be canceled. Before each background task begins, a cancelable progress dialog is displayed to the user. If the task does not complete within the predefined maximum execution time, a timeout occurs. If the task finishes on time, its results are posted to the main thread and, provided the associated activity or fragment is still active, the user interface is updated accordingly. This concurrency flowchart is depicted in Figure 2.  
Error handling is implemented via an application-level thread managed by the ExecutorService. The error handler is initialized in the BaseActivity class, from which all other activities inherit. This thread waits for exceptions to occur, classifies each error, wraps it in a custom error object, logs the stack trace to a file, and notifies the user. This process is shown in Figure 3. When a user submits an error report, the corresponding log file containing the stack trace is also sent. This facilitates easier error reproduction, diagnostics, and error resolution. Figure 2: MZAP concurrency flowchart. The MZAP software suite integration diagram is shown in Figure 4. Although developed using different technologies and programming languages, both the MZAP Android application (Java) and the MZAP Converter (Python v3.13.5) generate locked, encrypted, and digitally signed match endgame reports from a unified JSON Match Record Structure. While these applications do not interact directly, they both communicate with the MZAP server. By submitting a match UUID, each application requests credentials necessary for locking, encrypting, and signing the generated PDF documents. As previously stated, the MZAP Converter currently features only a command-line interface, through which each request is handled using a predefined set of commands. Once a PDF document has been created, both solutions transmit the generated PDF along with the corresponding JSON match record to the MZAP server for validation and archival. Figure 4: MZAP integration diagram. Figure 3: MZAP error propagation flowchart.