Data Model

The application stores data locally in a SQLite Database. Content is fetched from the TBA API, stored, and later queried when rendering.

The datafeed is powered by RxJava, an implementation of the Observer design pattern. For every "screen load", two events come through the Observable chain. The first is the result from querying the local database. This allows us to prioritize showing some content to the user ASAP (so there are not long-running spinners over network operations), which improves the UX in bad/nonexistent network situations often found at competitions. The second item to come through the Observable chain is the result from the corresponding API request. This way, we can just update the display when new data comes in. We also store the incoming data locally for later access.

To see how the whole process comes together, also read the Data Flow page

API

All information is fetched from the TBA API. We rely heavily on OkHttp and Retrofit to interface with the API. We also rely on OkHttp's Cache features, which will uses Cache-Control and If-Modified-Since HTTP headers to hit the server smartly and only transfer the full response when it is not cached locally or has changed. We can hit the API frequently, because Google's App Engine Edge Cache can take care of many requests (especially when content is unchanged), so we don't flood the server with a large number of small requests.

Database

Each model that the code defines (Event, Team, Match, etc.) has its own table in the database. Each table extends ModelTable which defines some basic operations to be performed on that table. These operations include inserting a row, and updating an existing row. Each parameter of a model has its own column in the model's database table (the datatypes for this all have to be primitive types). Additionally, each model class contains static query methods, which allow the caller to pass through a SQL-like query (it basically allows you to get specific models from the database while specifying a WHERE clause).

This approach reduces redundant code, since each table class can share code and defining a new table only requires a definition of the required constants (e.g. column names).

Search

There are also two additional tables used for search. These two tables store the search keywords for each event model and each team model. We want these tables to remain separate from the main model tables (especially because there's minimal redundancy) because we need the search tables to contain a full dataset always (because, y'know, searching), while the model tables are never guaranteed to contain any fields associated with the model.