Skip to content

Instantly share code, notes, and snippets.

@thmq
Last active August 8, 2018 17:10
GSoC18 Catroid

[GSoC18] Introduce Architecture and Separate Components

0. Abstract

0.1 All Related PRs

This is a list of all PRs related to the work within the scope of GSoC 2018. The PRs are referenced in a chronological order and a more detailed description can be found below.

1. Refactor LookData

related PR: [1]

The LookData serves as a meta information object that is closely related to a image file. Consequently it seemed reasonalble to model this relationship in the LookData class. Therefore I introduced a File object as field, that contains the complete path to the file. This has multiple advantages: 1) whenever we want to access the file, we do not have to dynamically construct a path that never changes during the lifetime of the object anyway. 2) it is now obsolete to track if the object is in the backpack via the field isBackpackLookData. In combination with the changes to the storage handling that I implemented during the preperations for GSoC, these changes increase stability, performance, and maintenance. The changes include some other code cleanup and simplifications.

Potential Future Work

The clone method for LookData could be improved to comply with the Java language specifications and the serialization and deserialization methods could potentially simplified by correctly using the writeReplace() and readResolve() methods respectively.

2. Refactor Scene

related PR: [2]

In the Scene class there was some potential to remove and simplify code, although nothing major had to be changed here. I added a function to correcly obtain the directory containing all files related to the Scene. I also moved all the code that is used for renaming and copying to the SceneControler.

I added annotations to avoid some of the common NullPointerExceptions, that regularly occured before and removed the Context context parameter from the constructor that was only used to get the String that was used the Background Sprite's name. The Background now has to be added deliberately, which means that this version complies more closely with the Android appoach of having to rely on the current context to obtain String resources and simplifies testing. Additonally I removed all methods that directly polled the DataContainer and instead provided the functionaly directly within it.

Potential Future Work

Try to define and model the Scene in more detail (e.g. remove DataContainer and add variables and lists to Project or Sprite, depending on their scope, removed global buffers from Projectmanage, that always provide access to currently edited, currently playing, first and default Scenes) and try to remove the Scene as dependency from as many classes as possible.

3. Refactor DataContainer

related PR: [5]

The DataContainer, which acts as a wrapper for the UserVariables and UserLists (i.e. UserData), got a new map which allows for searching UserData by name and provides null security. I removed the new instance creation for UserData from the DataContainer -> now you can just use new UserVariable / new UserList instead of having to create it through the DataContainer. I cleaned up getters, removed the dependency on the project, simplified conversion of projects of older language versions (projects without Scenes) and fixed some copying isssues.

4. Brick Refactoring (pt. 1)

related PR: [6]

As a first step for the Brick refactoring I removed at lot of unused or Cargo Cult code (mostly stuff related to the appearance of the Brick's view such as the alpha value and code that was hidden behind boolean flags that never became true anyway). This PR consists of 4 commits because all of the things are in a way different but yet related.

5. Brick Refactoring (pt. 2)

related PR: [7]

Next I removed the unused parameters from the getView(..) and getPrototypeView(..) methods. I also unified the CheckBox ids so that the Adapter can be sure that every Brick's CheckBox can be found by the same id. This simplifies inflation, because the .findViewById(checkBoxId) does not have to be duplicated for every Brick.

5. Brick Refactoring (pt. 3)

related PR: [8] Because all Bricks use the same code (except for the resId) to inflate their views I moved the inflation to the BrickBaseType which is the Base class for all brick and added an abstract method to obtain the correct layoutRes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment