Refactoring @V2

ScoreBoard.java

CODE SMELL 1: "unused??" ---maybe it's more like "unnecessary." However, when first implement, it's safe to make assumption that returning rankings are unsorted...

ACTION

line #154-176: [remove]sortingNonoScores() is unnecessary because the backend code can easily return a sorted list of NonoScores for front-end to use.

line #238-267: [remove]accordingly, minScoreCompare() and maxScoreCompare() are unnecessary as well once sortingNonoScores() is removed

CODE SMELL 2: "duplicate??" ---scoreSmall(), scoreMedium() and scoreLarge() are very similar except calling getScore would passed different values based on the difficulty level chosen.

ACTION

line #60-123: [extract to one function]redundancy among scoreSmall(), scoreMedium() and scoreLarge()

*more comments

PlayGameScreen.java

CODE SMELL 1: Modularity, the timer set up should be spitted from the onCreate()

Action

line #90-103: [remove] from the onCreate(), and make a new private method named setupTimer(). line 106-113: [remove] from the onCreate(), and make a new private method named setupButton().

Backend (Done during ZFR, Alpha, Beta, and V1)

The refactoring of backend code is not done as a one step, but rather I constantly refactored as it is built. The major things that were refactored during the development are:

1. NonoDatabase:

• The table names, column names, and things that are needed for connection are factored out as the class constants.
• The common code for getting the connection are factored out as a private method.
• The common code for closing resources are factored out as a private method.

2. Enums:

• The common operations that client request, common server response are factored out as enum ClientRequest and ServerResponse so that they can be used in switch statement.
• Similar sized puzzles are grouped together using enum Difficulty. The codes for getting difficulty from puzzle dimensions are moved from NonoPuzzle to Difficulty.

3. ParameterPolice:

• The common code for checking parameter validity (checking for is factored out as a separate class ParameterPolice.

4. NonoUtil:

• The ugly codes for converting things back and forth from JSON objects are refactored into separate class NonoUtil. This class contains all conversion related functionalities used throughout the project.
• The string tags used with JSON object are factored into the class constants.

5. NonoNetwork:

• The networking related functionalities (sending & receiving messages) are factored into a separate class NonoNetwork since both client & server uses same code for networking

6. NonoConfig:

• Networking related constants used in multiple classes (server name, base port, max port, socket timeout etc.) are factored into separate class NonoConfig, so that in case it needs to change we don't have to look through multiple files.
• Also getting the server IP and NonoNetwork is refactored to this class so that when other class just wants to get IP or Network with default set up it can simply call that method from NonoConfig.

7. Nonogram:

• The bulky code for un-wrapping parameters from JSON Object is refactored into Nonogram class so that the code in NonoServer is cleaner.