Refactor categories to extend GameCategory #989
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a refactor which removes
GameLevelCategory,GameUserCategory, their equivalent game and API serialization classes and makes all category classes directly extendGameCategory. De-duplicating category code, especially for the API responses, was suggested in a previous PR's review, and this is the easiest and least hacky way I could think of.While I have tried to implement the suggested strategy of using a generic type for
ApiCategoryResponse, it became too complicated for me due to one of the twoFromOldListmethods needing to call theFetchmethod of every category in order to add their preview items to the responses. I've thought to instead have the preview item attribute be of typeIApiResultResponsewhich bothApiGameLevelResponseandApiGameUserResponseimplement.For LBP3 the
Resultsattribute, which used to be inSerializedLevelCategoryandSerializedUserCategory, is now inSerializedCategoryand of typeSerializedCategoryResultsListso the categories could include either users or levels as previews. This works with LBP3.The overridden
GameCategory.Fetchmethod now returns aDatabaseResultList, which references a nullableDatabaseListofGameLevels,GameUsers andGamePlaylists each (3 lists in total). This is so that both level and user categories could override the method without any problems, while also being a preparation to make searching users for LBP1-3 and the API (and then maybe also playlists in LBP1/3/API) alongside levels possible.